All of lore.kernel.org
 help / color / mirror / Atom feed
* [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
@ 2023-05-22 22:15 Rodrigo Vivi
  2023-05-22 22:17 ` [Intel-xe] ✓ CI.Patch_applied: success for " Patchwork
                   ` (3 more replies)
  0 siblings, 4 replies; 25+ messages in thread
From: Rodrigo Vivi @ 2023-05-22 22:15 UTC (permalink / raw)
  To: intel-xe
  Cc: Jani Nikula, Lucas De Marchi, Ville Syrjälä,
	Matthew Auld, Rodrigo Vivi, Matt Roper

It is the maximum protection we can do with the current infrastructure.

Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Francois Dugast <francois.dugast@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---


RFC
===

Okay, so, this is more an RFC to brainstorm the future of the force_wake in
Xe than anything else.

On i915 the force_wake is built-in the mmio functions at uncore component.

With that approach we had few historical issues iirc:

1. Display performance with vblank evasion that requested uncore to provide
the 'fw' variantes that are actually the ones that avoid fw (contrary to what
the name suggests).

2. Missed ranges updates. Sometimes we messed up with the ranges, there were
other times that the spec was updated and we didn't get the notification, and
there were cases that the BSpec had bugs.

For these reasons in Xe we have decided to let to the caller the
responsibility to set the force_wake bits for their domains before doing
the MMIO.

However I'm seeing many questions and doubts popping up:

1. Are we confident that we are not missing any wake-up?
2. Are we confident that the domains are set correctly?
3. Are we not wasting power if we are waking up ALL the domains instead
   of some specific one?
4. What about the display disconnection now because i915 and xe have different
   mmio approaches but reusing i915-display?

It looks to me that the cons of the current approach are superseding the
cons of the i915 approach. But I want to hear more thoughts here before
we decide which route to take.

Maybe we have that domain as part of the mmio calls themselves? Maybe
a double approach where the caller is responsible but mmio has the range
information and double check it?

Any other idea? Thoughts?

Thanks,
Rodrigo.

 drivers/gpu/drm/xe/xe_mmio.h | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/xe/xe_mmio.h b/drivers/gpu/drm/xe/xe_mmio.h
index 1407f1189b0d..6302ca85e3f4 100644
--- a/drivers/gpu/drm/xe/xe_mmio.h
+++ b/drivers/gpu/drm/xe/xe_mmio.h
@@ -18,8 +18,26 @@ struct xe_device;
 
 int xe_mmio_init(struct xe_device *xe);
 
+static inline void xe_mmio_assert_forcewake(struct xe_gt *gt,
+					    struct xe_reg reg)
+{
+	struct xe_force_wake *fw = &gt->mmio.fw;
+
+	/* No need for forcewake in this range */
+	if (reg.addr >= 0x40000 && reg.addr < 0x116000)
+		return;
+
+	/*
+	 * XXX: Weak. It checks for some domain, but impossible to determine
+	 * if the right one is selected, or if it was set by the same caller
+	 */
+	WARN_ON(!fw->awake_domains);
+}
+
 static inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
 {
+	xe_mmio_assert_forcewake(gt, reg);
+
 	if (reg.addr < gt->mmio.adj_limit)
 		reg.addr += gt->mmio.adj_offset;
 
@@ -29,6 +47,8 @@ static inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
 static inline void xe_mmio_write32(struct xe_gt *gt,
 				   struct xe_reg reg, u32 val)
 {
+	xe_mmio_assert_forcewake(gt, reg);
+
 	if (reg.addr < gt->mmio.adj_limit)
 		reg.addr += gt->mmio.adj_offset;
 
@@ -37,6 +57,8 @@ static inline void xe_mmio_write32(struct xe_gt *gt,
 
 static inline u32 xe_mmio_read32(struct xe_gt *gt, struct xe_reg reg)
 {
+	xe_mmio_assert_forcewake(gt, reg);
+
 	if (reg.addr < gt->mmio.adj_limit)
 		reg.addr += gt->mmio.adj_offset;
 
@@ -58,6 +80,8 @@ static inline u32 xe_mmio_rmw32(struct xe_gt *gt, struct xe_reg reg, u32 clr,
 static inline void xe_mmio_write64(struct xe_gt *gt,
 				   struct xe_reg reg, u64 val)
 {
+	xe_mmio_assert_forcewake(gt, reg);
+
 	if (reg.addr < gt->mmio.adj_limit)
 		reg.addr += gt->mmio.adj_offset;
 
@@ -66,6 +90,8 @@ static inline void xe_mmio_write64(struct xe_gt *gt,
 
 static inline u64 xe_mmio_read64(struct xe_gt *gt, struct xe_reg reg)
 {
+	xe_mmio_assert_forcewake(gt, reg);
+
 	if (reg.addr < gt->mmio.adj_limit)
 		reg.addr += gt->mmio.adj_offset;
 
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 25+ messages in thread

* [Intel-xe] ✓ CI.Patch_applied: success for drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-05-22 22:15 [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio Rodrigo Vivi
@ 2023-05-22 22:17 ` Patchwork
  2023-05-22 22:19 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 25+ messages in thread
From: Patchwork @ 2023-05-22 22:17 UTC (permalink / raw)
  To: Rodrigo Vivi; +Cc: intel-xe

== Series Details ==

Series: drm/xe: A minimal assert for some forcewake domain on xe_mmio.
URL   : https://patchwork.freedesktop.org/series/118162/
State : success

== Summary ==

=== Applying kernel patches on branch 'drm-xe-next' with base: ===
Base commit: 5918677fe drm/xe: Fail xe_device_create() if wq allocation fails
=== git am output follows ===
Applying: drm/xe: A minimal assert for some forcewake domain on xe_mmio.



^ permalink raw reply	[flat|nested] 25+ messages in thread

* [Intel-xe] ✓ CI.KUnit: success for drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-05-22 22:15 [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio Rodrigo Vivi
  2023-05-22 22:17 ` [Intel-xe] ✓ CI.Patch_applied: success for " Patchwork
@ 2023-05-22 22:19 ` Patchwork
  2023-05-22 22:23 ` [Intel-xe] ✓ CI.Build: " Patchwork
  2023-05-23  3:28 ` [Intel-xe] [RFC] " Matt Roper
  3 siblings, 0 replies; 25+ messages in thread
From: Patchwork @ 2023-05-22 22:19 UTC (permalink / raw)
  To: Rodrigo Vivi; +Cc: intel-xe

== Series Details ==

Series: drm/xe: A minimal assert for some forcewake domain on xe_mmio.
URL   : https://patchwork.freedesktop.org/series/118162/
State : success

== Summary ==

+ trap cleanup EXIT
+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/xe/.kunitconfig
stty: 'standard input': Inappropriate ioctl for device
[22:18:09] Configuring KUnit Kernel ...
Generating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[22:18:13] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make ARCH=um O=.kunit --jobs=48
[22:18:35] Starting KUnit Kernel (1/1)...
[22:18:35] ============================================================
[22:18:35] ==================== xe_bo (2 subtests) ====================
[22:18:35] [SKIPPED] xe_ccs_migrate_kunit
[22:18:35] [SKIPPED] xe_bo_evict_kunit
[22:18:35] ===================== [SKIPPED] xe_bo ======================
[22:18:35] ================== xe_dma_buf (1 subtest) ==================
[22:18:35] [SKIPPED] xe_dma_buf_kunit
[22:18:35] =================== [SKIPPED] xe_dma_buf ===================
[22:18:35] ================== xe_migrate (1 subtest) ==================
[22:18:35] [SKIPPED] xe_migrate_sanity_kunit
[22:18:35] =================== [SKIPPED] xe_migrate ===================
[22:18:35] =================== xe_pci (2 subtests) ====================
[22:18:35] [PASSED] xe_gmdid_graphics_ip
[22:18:35] [PASSED] xe_gmdid_media_ip
[22:18:35] ===================== [PASSED] xe_pci ======================
[22:18:35] ==================== xe_rtp (1 subtest) ====================
[22:18:35] ================== xe_rtp_process_tests  ===================
[22:18:35] [PASSED] coalesce-same-reg
[22:18:35] [PASSED] no-match-no-add
[22:18:35] [PASSED] no-match-no-add-multiple-rules
[22:18:35] [PASSED] two-regs-two-entries
[22:18:35] [PASSED] clr-one-set-other
[22:18:35] [PASSED] set-field
[22:18:35] [PASSED] conflict-duplicate
[22:18:35] [PASSED] conflict-not-disjoint
[22:18:35] [PASSED] conflict-reg-type
[22:18:35] ============== [PASSED] xe_rtp_process_tests ===============
[22:18:35] ===================== [PASSED] xe_rtp ======================
[22:18:35] ==================== xe_wa (1 subtest) =====================
[22:18:35] ======================== xe_wa_gt  =========================
[22:18:35] [PASSED] TIGERLAKE (B0)
[22:18:35] [PASSED] DG1 (A0)
[22:18:35] [PASSED] DG1 (B0)
[22:18:35] [PASSED] ALDERLAKE_S (A0)
[22:18:35] [PASSED] ALDERLAKE_S (B0)
[22:18:35] [PASSED] ALDERLAKE_S (C0)
[22:18:35] [PASSED] ALDERLAKE_S (D0)
[22:18:35] [PASSED] DG2_G10 (A0)
[22:18:35] [PASSED] DG2_G10 (A1)
[22:18:35] [PASSED] DG2_G10 (B0)
[22:18:35] [PASSED] DG2_G10 (C0)
[22:18:35] [PASSED] DG2_G11 (A0)
[22:18:35] [PASSED] DG2_G11 (B0)
[22:18:35] [PASSED] DG2_G11 (B1)
[22:18:35] [PASSED] DG2_G12 (A0)
[22:18:35] [PASSED] DG2_G12 (A1)
[22:18:35] [PASSED] PVC (B0)
[22:18:35] [PASSED] PVC (B1)
[22:18:35] [PASSED] PVC (C0)
[22:18:35] ==================== [PASSED] xe_wa_gt =====================
[22:18:35] ====================== [PASSED] xe_wa ======================
[22:18:35] ============================================================
[22:18:35] Testing complete. Ran 34 tests: passed: 30, skipped: 4
[22:18:35] Elapsed time: 26.383s total, 4.210s configuring, 22.004s building, 0.148s running

+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/tests/.kunitconfig
[22:18:35] Configuring KUnit Kernel ...
Regenerating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[22:18:37] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make ARCH=um O=.kunit --jobs=48
[22:18:55] Starting KUnit Kernel (1/1)...
[22:18:55] ============================================================
[22:18:55] ============ drm_test_pick_cmdline (2 subtests) ============
[22:18:55] [PASSED] drm_test_pick_cmdline_res_1920_1080_60
[22:18:55] =============== drm_test_pick_cmdline_named  ===============
[22:18:55] [PASSED] NTSC
[22:18:55] [PASSED] NTSC-J
[22:18:55] [PASSED] PAL
[22:18:55] [PASSED] PAL-M
[22:18:55] =========== [PASSED] drm_test_pick_cmdline_named ===========
[22:18:55] ============== [PASSED] drm_test_pick_cmdline ==============
[22:18:55] ================== drm_buddy (6 subtests) ==================
[22:18:55] [PASSED] drm_test_buddy_alloc_limit
[22:18:55] [PASSED] drm_test_buddy_alloc_range
[22:18:55] [PASSED] drm_test_buddy_alloc_optimistic
[22:18:55] [PASSED] drm_test_buddy_alloc_pessimistic
[22:18:55] [PASSED] drm_test_buddy_alloc_smoke
[22:18:55] [PASSED] drm_test_buddy_alloc_pathological
[22:18:55] ==================== [PASSED] drm_buddy ====================
[22:18:55] ============= drm_cmdline_parser (40 subtests) =============
[22:18:55] [PASSED] drm_test_cmdline_force_d_only
[22:18:55] [PASSED] drm_test_cmdline_force_D_only_dvi
[22:18:55] [PASSED] drm_test_cmdline_force_D_only_hdmi
[22:18:55] [PASSED] drm_test_cmdline_force_D_only_not_digital
[22:18:55] [PASSED] drm_test_cmdline_force_e_only
[22:18:55] [PASSED] drm_test_cmdline_res
[22:18:55] [PASSED] drm_test_cmdline_res_vesa
[22:18:55] [PASSED] drm_test_cmdline_res_vesa_rblank
[22:18:55] [PASSED] drm_test_cmdline_res_rblank
[22:18:55] [PASSED] drm_test_cmdline_res_bpp
[22:18:55] [PASSED] drm_test_cmdline_res_refresh
[22:18:55] [PASSED] drm_test_cmdline_res_bpp_refresh
[22:18:55] [PASSED] drm_test_cmdline_res_bpp_refresh_interlaced
[22:18:55] [PASSED] drm_test_cmdline_res_bpp_refresh_margins
[22:18:55] [PASSED] drm_test_cmdline_res_bpp_refresh_force_off
[22:18:55] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on
[22:18:55] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on_analog
[22:18:55] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on_digital
[22:18:55] [PASSED] drm_test_cmdline_res_bpp_refresh_interlaced_margins_force_on
[22:18:55] [PASSED] drm_test_cmdline_res_margins_force_on
[22:18:55] [PASSED] drm_test_cmdline_res_vesa_margins
[22:18:55] [PASSED] drm_test_cmdline_name
[22:18:55] [PASSED] drm_test_cmdline_name_bpp
[22:18:55] [PASSED] drm_test_cmdline_name_option
[22:18:55] [PASSED] drm_test_cmdline_name_bpp_option
[22:18:55] [PASSED] drm_test_cmdline_rotate_0
[22:18:55] [PASSED] drm_test_cmdline_rotate_90
[22:18:55] [PASSED] drm_test_cmdline_rotate_180
[22:18:55] [PASSED] drm_test_cmdline_rotate_270
[22:18:55] [PASSED] drm_test_cmdline_hmirror
[22:18:55] [PASSED] drm_test_cmdline_vmirror
[22:18:55] [PASSED] drm_test_cmdline_margin_options
[22:18:55] [PASSED] drm_test_cmdline_multiple_options
[22:18:55] [PASSED] drm_test_cmdline_bpp_extra_and_option
[22:18:55] [PASSED] drm_test_cmdline_extra_and_option
[22:18:55] [PASSED] drm_test_cmdline_freestanding_options
[22:18:55] [PASSED] drm_test_cmdline_freestanding_force_e_and_options
[22:18:55] [PASSED] drm_test_cmdline_panel_orientation
[22:18:55] ================ drm_test_cmdline_invalid  =================
[22:18:55] [PASSED] margin_only
[22:18:55] [PASSED] interlace_only
[22:18:55] [PASSED] res_missing_x
[22:18:55] [PASSED] res_missing_y
[22:18:55] [PASSED] res_bad_y
[22:18:55] [PASSED] res_missing_y_bpp
[22:18:55] [PASSED] res_bad_bpp
[22:18:55] [PASSED] res_bad_refresh
[22:18:55] [PASSED] res_bpp_refresh_force_on_off
[22:18:55] [PASSED] res_invalid_mode
[22:18:55] [PASSED] res_bpp_wrong_place_mode
[22:18:55] [PASSED] name_bpp_refresh
[22:18:55] [PASSED] name_refresh
[22:18:55] [PASSED] name_refresh_wrong_mode
[22:18:55] [PASSED] name_refresh_invalid_mode
[22:18:55] [PASSED] rotate_multiple
[22:18:55] [PASSED] rotate_invalid_val
[22:18:55] [PASSED] rotate_truncated
[22:18:55] [PASSED] invalid_option
[22:18:55] [PASSED] invalid_tv_option
[22:18:55] [PASSED] truncated_tv_option
[22:18:55] ============ [PASSED] drm_test_cmdline_invalid =============
[22:18:55] =============== drm_test_cmdline_tv_options  ===============
[22:18:55] [PASSED] NTSC
[22:18:55] [PASSED] NTSC_443
[22:18:55] [PASSED] NTSC_J
[22:18:55] [PASSED] PAL
[22:18:55] [PASSED] PAL_M
[22:18:55] [PASSED] PAL_N
[22:18:55] [PASSED] SECAM
[22:18:55] =========== [PASSED] drm_test_cmdline_tv_options ===========
[22:18:55] =============== [PASSED] drm_cmdline_parser ================
[22:18:55] ========== drm_get_tv_mode_from_name (2 subtests) ==========
[22:18:55] ========== drm_test_get_tv_mode_from_name_valid  ===========
[22:18:55] [PASSED] NTSC
[22:18:55] [PASSED] NTSC-443
[22:18:55] [PASSED] NTSC-J
[22:18:55] [PASSED] PAL
[22:18:55] [PASSED] PAL-M
[22:18:55] [PASSED] PAL-N
[22:18:55] [PASSED] SECAM
[22:18:55] ====== [PASSED] drm_test_get_tv_mode_from_name_valid =======
[22:18:55] [PASSED] drm_test_get_tv_mode_from_name_truncated
[22:18:55] ============ [PASSED] drm_get_tv_mode_from_name ============
[22:18:55] ============= drm_damage_helper (21 subtests) ==============
[22:18:55] [PASSED] drm_test_damage_iter_no_damage
[22:18:55] [PASSED] drm_test_damage_iter_no_damage_fractional_src
[22:18:55] [PASSED] drm_test_damage_iter_no_damage_src_moved
[22:18:55] [PASSED] drm_test_damage_iter_no_damage_fractional_src_moved
[22:18:55] [PASSED] drm_test_damage_iter_no_damage_not_visible
[22:18:55] [PASSED] drm_test_damage_iter_no_damage_no_crtc
[22:18:55] [PASSED] drm_test_damage_iter_no_damage_no_fb
[22:18:55] [PASSED] drm_test_damage_iter_simple_damage
[22:18:55] [PASSED] drm_test_damage_iter_single_damage
[22:18:55] [PASSED] drm_test_damage_iter_single_damage_intersect_src
[22:18:55] [PASSED] drm_test_damage_iter_single_damage_outside_src
[22:18:55] [PASSED] drm_test_damage_iter_single_damage_fractional_src
[22:18:55] [PASSED] drm_test_damage_iter_single_damage_intersect_fractional_src
[22:18:55] [PASSED] drm_test_damage_iter_single_damage_outside_fractional_src
[22:18:55] [PASSED] drm_test_damage_iter_single_damage_src_moved
[22:18:55] [PASSED] drm_test_damage_iter_single_damage_fractional_src_moved
[22:18:55] [PASSED] drm_test_damage_iter_damage
[22:18:55] [PASSED] drm_test_damage_iter_damage_one_intersect
[22:18:55] [PASSED] drm_test_damage_iter_damage_one_outside
[22:18:55] [PASSED] drm_test_damage_iter_damage_src_moved
[22:18:55] [PASSED] drm_test_damage_iter_damage_not_visible
[22:18:55] ================ [PASSED] drm_damage_helper ================
[22:18:55] ============== drm_dp_mst_helper (2 subtests) ==============
[22:18:55] ============== drm_test_dp_mst_calc_pbn_mode  ==============
[22:18:55] [PASSED] Clock 154000 BPP 30 DSC disabled
[22:18:55] [PASSED] Clock 234000 BPP 30 DSC disabled
[22:18:55] [PASSED] Clock 297000 BPP 24 DSC disabled
[22:18:55] [PASSED] Clock 332880 BPP 24 DSC enabled
[22:18:55] [PASSED] Clock 324540 BPP 24 DSC enabled
[22:18:55] ========== [PASSED] drm_test_dp_mst_calc_pbn_mode ==========
[22:18:55] ========= drm_test_dp_mst_sideband_msg_req_decode  =========
[22:18:55] [PASSED] DP_ENUM_PATH_RESOURCES with port number
[22:18:55] [PASSED] DP_POWER_UP_PHY with port number
[22:18:55] [PASSED] DP_POWER_DOWN_PHY with port number
[22:18:55] [PASSED] DP_ALLOCATE_PAYLOAD with SDP stream sinks
[22:18:55] [PASSED] DP_ALLOCATE_PAYLOAD with port number
[22:18:55] [PASSED] DP_ALLOCATE_PAYLOAD with VCPI
[22:18:55] [PASSED] DP_ALLOCATE_PAYLOAD with PBN
[22:18:55] [PASSED] DP_QUERY_PAYLOAD with port number
[22:18:55] [PASSED] DP_QUERY_PAYLOAD with VCPI
[22:18:55] [PASSED] DP_REMOTE_DPCD_READ with port number
[22:18:55] [PASSED] DP_REMOTE_DPCD_READ with DPCD address
[22:18:55] [PASSED] DP_REMOTE_DPCD_READ with max number of bytes
[22:18:55] [PASSED] DP_REMOTE_DPCD_WRITE with port number
[22:18:55] [PASSED] DP_REMOTE_DPCD_WRITE with DPCD address
[22:18:55] [PASSED] DP_REMOTE_DPCD_WRITE with data array
[22:18:55] [PASSED] DP_REMOTE_I2C_READ with port number
[22:18:55] [PASSED] DP_REMOTE_I2C_READ with I2C device ID
[22:18:55] [PASSED] DP_REMOTE_I2C_READ with transactions array
[22:18:55] [PASSED] DP_REMOTE_I2C_WRITE with port number
[22:18:55] [PASSED] DP_REMOTE_I2C_WRITE with I2C device ID
[22:18:55] [PASSED] DP_REMOTE_I2C_WRITE with data array
[22:18:55] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream ID
[22:18:55] [PASSED] DP_QUERY_STREAM_ENC_STATUS with client ID
[22:18:55] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream event
[22:18:55] [PASSED] DP_QUERY_STREAM_ENC_STATUS with valid stream event
[22:18:55] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream behavior
[22:18:55] [PASSED] DP_QUERY_STREAM_ENC_STATUS with a valid stream behavior
[22:18:55] ===== [PASSED] drm_test_dp_mst_sideband_msg_req_decode =====
[22:18:55] ================ [PASSED] drm_dp_mst_helper ================
[22:18:55] =========== drm_format_helper_test (11 subtests) ===========
[22:18:55] ============== drm_test_fb_xrgb8888_to_gray8  ==============
[22:18:55] [PASSED] single_pixel_source_buffer
[22:18:55] [PASSED] single_pixel_clip_rectangle
[22:18:55] [PASSED] well_known_colors
[22:18:55] [PASSED] destination_pitch
[22:18:55] ========== [PASSED] drm_test_fb_xrgb8888_to_gray8 ==========
[22:18:55] ============= drm_test_fb_xrgb8888_to_rgb332  ==============
[22:18:55] [PASSED] single_pixel_source_buffer
[22:18:55] [PASSED] single_pixel_clip_rectangle
[22:18:55] [PASSED] well_known_colors
[22:18:55] [PASSED] destination_pitch
[22:18:55] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb332 ==========
[22:18:55] ============= drm_test_fb_xrgb8888_to_rgb565  ==============
[22:18:55] [PASSED] single_pixel_source_buffer
[22:18:55] [PASSED] single_pixel_clip_rectangle
[22:18:55] [PASSED] well_known_colors
[22:18:55] [PASSED] destination_pitch
[22:18:55] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb565 ==========
[22:18:55] ============ drm_test_fb_xrgb8888_to_xrgb1555  =============
[22:18:55] [PASSED] single_pixel_source_buffer
[22:18:55] [PASSED] single_pixel_clip_rectangle
[22:18:55] [PASSED] well_known_colors
[22:18:55] [PASSED] destination_pitch
[22:18:55] ======== [PASSED] drm_test_fb_xrgb8888_to_xrgb1555 =========
[22:18:55] ============ drm_test_fb_xrgb8888_to_argb1555  =============
[22:18:55] [PASSED] single_pixel_source_buffer
[22:18:55] [PASSED] single_pixel_clip_rectangle
[22:18:55] [PASSED] well_known_colors
[22:18:55] [PASSED] destination_pitch
[22:18:55] ======== [PASSED] drm_test_fb_xrgb8888_to_argb1555 =========
[22:18:55] ============ drm_test_fb_xrgb8888_to_rgba5551  =============
[22:18:55] [PASSED] single_pixel_source_buffer
[22:18:55] [PASSED] single_pixel_clip_rectangle
[22:18:55] [PASSED] well_known_colors
[22:18:55] [PASSED] destination_pitch
[22:18:55] ======== [PASSED] drm_test_fb_xrgb8888_to_rgba5551 =========
[22:18:55] ============= drm_test_fb_xrgb8888_to_rgb888  ==============
[22:18:55] [PASSED] single_pixel_source_buffer
[22:18:55] [PASSED] single_pixel_clip_rectangle
[22:18:55] [PASSED] well_known_colors
[22:18:55] [PASSED] destination_pitch
[22:18:55] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb888 ==========
[22:18:55] ============ drm_test_fb_xrgb8888_to_argb8888  =============
[22:18:55] [PASSED] single_pixel_source_buffer
[22:18:55] [PASSED] single_pixel_clip_rectangle
[22:18:55] [PASSED] well_known_colors
[22:18:55] [PASSED] destination_pitch
[22:18:55] ======== [PASSED] drm_test_fb_xrgb8888_to_argb8888 =========
[22:18:55] =========== drm_test_fb_xrgb8888_to_xrgb2101010  ===========
[22:18:55] [PASSED] single_pixel_source_buffer
[22:18:55] [PASSED] single_pixel_clip_rectangle
[22:18:55] [PASSED] well_known_colors
[22:18:55] [PASSED] destination_pitch
[22:18:55] ======= [PASSED] drm_test_fb_xrgb8888_to_xrgb2101010 =======
[22:18:55] =========== drm_test_fb_xrgb8888_to_argb2101010  ===========
[22:18:55] [PASSED] single_pixel_source_buffer
[22:18:55] [PASSED] single_pixel_clip_rectangle
[22:18:55] [PASSED] well_known_colors
[22:18:55] [PASSED] destination_pitch
[22:18:55] ======= [PASSED] drm_test_fb_xrgb8888_to_argb2101010 =======
[22:18:55] ============== drm_test_fb_xrgb8888_to_mono  ===============
[22:18:55] [PASSED] single_pixel_source_buffer
[22:18:55] [PASSED] single_pixel_clip_rectangle
[22:18:55] [PASSED] well_known_colors
[22:18:55] [PASSED] destination_pitch
[22:18:55] ========== [PASSED] drm_test_fb_xrgb8888_to_mono ===========
[22:18:55] ============= [PASSED] drm_format_helper_test ==============
[22:18:55] ================= drm_format (18 subtests) =================
[22:18:55] [PASSED] drm_test_format_block_width_invalid
[22:18:55] [PASSED] drm_test_format_block_width_one_plane
[22:18:55] [PASSED] drm_test_format_block_width_two_plane
[22:18:55] [PASSED] drm_test_format_block_width_three_plane
[22:18:55] [PASSED] drm_test_format_block_width_tiled
[22:18:55] [PASSED] drm_test_format_block_height_invalid
[22:18:55] [PASSED] drm_test_format_block_height_one_plane
[22:18:55] [PASSED] drm_test_format_block_height_two_plane
[22:18:55] [PASSED] drm_test_format_block_height_three_plane
[22:18:55] [PASSED] drm_test_format_block_height_tiled
[22:18:55] [PASSED] drm_test_format_min_pitch_invalid
[22:18:55] [PASSED] drm_test_format_min_pitch_one_plane_8bpp
[22:18:55] [PASSED] drm_test_format_min_pitch_one_plane_16bpp
[22:18:55] [PASSED] drm_test_format_min_pitch_one_plane_24bpp
[22:18:55] [PASSED] drm_test_format_min_pitch_one_plane_32bpp
[22:18:55] [PASSED] drm_test_format_min_pitch_two_plane
[22:18:55] [PASSED] drm_test_format_min_pitch_three_plane_8bpp
[22:18:55] [PASSED] drm_test_format_min_pitch_tiled
[22:18:55] =================== [PASSED] drm_format ====================
[22:18:55] =============== drm_framebuffer (1 subtest) ================
[22:18:55] =============== drm_test_framebuffer_create  ===============
[22:18:55] [PASSED] ABGR8888 normal sizes
[22:18:55] [PASSED] ABGR8888 max sizes
[22:18:55] [PASSED] ABGR8888 pitch greater than min required
[22:18:55] [PASSED] ABGR8888 pitch less than min required
[22:18:55] [PASSED] ABGR8888 Invalid width
[22:18:55] [PASSED] ABGR8888 Invalid buffer handle
[22:18:55] [PASSED] No pixel format
[22:18:55] [PASSED] ABGR8888 Width 0
[22:18:55] [PASSED] ABGR8888 Height 0
[22:18:55] [PASSED] ABGR8888 Out of bound height * pitch combination
[22:18:55] [PASSED] ABGR8888 Large buffer offset
[22:18:55] [PASSED] ABGR8888 Set DRM_MODE_FB_MODIFIERS without modifiers
[22:18:55] [PASSED] ABGR8888 Valid buffer modifier
[22:18:55] [PASSED] ABGR8888 Invalid buffer modifier(DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
[22:18:55] [PASSED] ABGR8888 Extra pitches without DRM_MODE_FB_MODIFIERS
[22:18:55] [PASSED] ABGR8888 Extra pitches with DRM_MODE_FB_MODIFIERS
[22:18:55] [PASSED] NV12 Normal sizes
[22:18:55] [PASSED] NV12 Max sizes
[22:18:55] [PASSED] NV12 Invalid pitch
[22:18:55] [PASSED] NV12 Invalid modifier/missing DRM_MODE_FB_MODIFIERS flag
[22:18:55] [PASSED] NV12 different  modifier per-plane
[22:18:55] [PASSED] NV12 with DRM_FORMAT_MOD_SAMSUNG_64_32_TILE
[22:18:55] [PASSED] NV12 Valid modifiers without DRM_MODE_FB_MODIFIERS
[22:18:55] [PASSED] NV12 Modifier for inexistent plane
[22:18:55] [PASSED] NV12 Handle for inexistent plane
[22:18:55] [PASSED] NV12 Handle for inexistent plane without DRM_MODE_FB_MODIFIERS
[22:18:55] [PASSED] YVU420 Normal sizes
[22:18:55] [PASSED] YVU420 DRM_MODE_FB_MODIFIERS set without modifier
[22:18:55] [PASSED] YVU420 Max sizes
[22:18:55] [PASSED] YVU420 Invalid pitch
[22:18:55] [PASSED] YVU420 Different pitches
[22:18:55] [PASSED] YVU420 Different buffer offsets/pitches
[22:18:55] [PASSED] YVU420 Modifier set just for plane 0, without DRM_MODE_FB_MODIFIERS
[22:18:55] [PASSED] YVU420 Modifier set just for planes 0, 1, without DRM_MODE_FB_MODIFIERS
[22:18:55] [PASSED] YVU420 Modifier set just for plane 0, 1, with DRM_MODE_FB_MODIFIERS
[22:18:55] [PASSED] YVU420 Valid modifier
[22:18:55] [PASSED] YVU420 Different modifiers per plane
[22:18:55] [PASSED] YVU420 Modifier for inexistent plane
[22:18:55] [PASSED] X0L2 Normal sizes
[22:18:55] [PASSED] X0L2 Max sizes
[22:18:55] [PASSED] X0L2 Invalid pitch
[22:18:55] [PASSED] X0L2 Pitch greater than minimum required
stty: 'standard input': Inappropriate ioctl for device
[22:18:55] [PASSED] X0L2 Handle for inexistent plane
[22:18:55] [PASSED] X0L2 Offset for inexistent plane, without DRM_MODE_FB_MODIFIERS set
[22:18:55] [PASSED] X0L2 Modifier without DRM_MODE_FB_MODIFIERS set
[22:18:55] [PASSED] X0L2 Valid modifier
[22:18:55] [PASSED] X0L2 Modifier for inexistent plane
[22:18:55] =========== [PASSED] drm_test_framebuffer_create ===========
[22:18:55] ================= [PASSED] drm_framebuffer =================
[22:18:55] =============== drm-test-managed (1 subtest) ===============
[22:18:55] [PASSED] drm_test_managed_run_action
[22:18:55] ================ [PASSED] drm-test-managed =================
[22:18:55] =================== drm_mm (19 subtests) ===================
[22:18:55] [PASSED] drm_test_mm_init
[22:18:55] [PASSED] drm_test_mm_debug
[22:19:05] [PASSED] drm_test_mm_reserve
[22:19:15] [PASSED] drm_test_mm_insert
[22:19:16] [PASSED] drm_test_mm_replace
[22:19:16] [PASSED] drm_test_mm_insert_range
[22:19:16] [PASSED] drm_test_mm_frag
[22:19:16] [PASSED] drm_test_mm_align
[22:19:16] [PASSED] drm_test_mm_align32
[22:19:16] [PASSED] drm_test_mm_align64
[22:19:17] [PASSED] drm_test_mm_evict
[22:19:17] [PASSED] drm_test_mm_evict_range
[22:19:17] [PASSED] drm_test_mm_topdown
[22:19:17] [PASSED] drm_test_mm_bottomup
[22:19:17] [PASSED] drm_test_mm_lowest
[22:19:17] [PASSED] drm_test_mm_highest
[22:19:17] [PASSED] drm_test_mm_color
[22:19:18] [PASSED] drm_test_mm_color_evict
[22:19:18] [PASSED] drm_test_mm_color_evict_range
[22:19:18] ===================== [PASSED] drm_mm ======================
[22:19:18] ============= drm_modes_analog_tv (4 subtests) =============
[22:19:18] [PASSED] drm_test_modes_analog_tv_ntsc_480i
[22:19:18] [PASSED] drm_test_modes_analog_tv_ntsc_480i_inlined
[22:19:18] [PASSED] drm_test_modes_analog_tv_pal_576i
[22:19:18] [PASSED] drm_test_modes_analog_tv_pal_576i_inlined
[22:19:18] =============== [PASSED] drm_modes_analog_tv ===============
[22:19:18] ============== drm_plane_helper (2 subtests) ===============
[22:19:18] =============== drm_test_check_plane_state  ================
[22:19:18] [PASSED] clipping_simple
[22:19:18] [PASSED] clipping_rotate_reflect
[22:19:18] [PASSED] positioning_simple
[22:19:18] [PASSED] upscaling
[22:19:18] [PASSED] downscaling
[22:19:18] [PASSED] rounding1
[22:19:18] [PASSED] rounding2
[22:19:18] [PASSED] rounding3
[22:19:18] [PASSED] rounding4
[22:19:18] =========== [PASSED] drm_test_check_plane_state ============
[22:19:18] =========== drm_test_check_invalid_plane_state  ============
[22:19:18] [PASSED] positioning_invalid
[22:19:18] [PASSED] upscaling_invalid
[22:19:18] [PASSED] downscaling_invalid
[22:19:18] ======= [PASSED] drm_test_check_invalid_plane_state ========
[22:19:18] ================ [PASSED] drm_plane_helper =================
[22:19:18] ====== drm_connector_helper_tv_get_modes (1 subtest) =======
[22:19:18] ====== drm_test_connector_helper_tv_get_modes_check  =======
[22:19:18] [PASSED] None
[22:19:18] [PASSED] PAL
[22:19:18] [PASSED] NTSC
[22:19:18] [PASSED] Both, NTSC Default
[22:19:18] [PASSED] Both, PAL Default
[22:19:18] [PASSED] Both, NTSC Default, with PAL on command-line
[22:19:18] [PASSED] Both, PAL Default, with NTSC on command-line
[22:19:18] == [PASSED] drm_test_connector_helper_tv_get_modes_check ===
[22:19:18] ======== [PASSED] drm_connector_helper_tv_get_modes ========
[22:19:18] ================== drm_rect (9 subtests) ===================
[22:19:18] [PASSED] drm_test_rect_clip_scaled_div_by_zero
[22:19:18] [PASSED] drm_test_rect_clip_scaled_not_clipped
[22:19:18] [PASSED] drm_test_rect_clip_scaled_clipped
[22:19:18] [PASSED] drm_test_rect_clip_scaled_signed_vs_unsigned
[22:19:18] ================= drm_test_rect_intersect  =================
[22:19:18] [PASSED] top-left x bottom-right: 2x2+1+1 x 2x2+0+0
[22:19:18] [PASSED] top-right x bottom-left: 2x2+0+0 x 2x2+1-1
[22:19:18] [PASSED] bottom-left x top-right: 2x2+1-1 x 2x2+0+0
[22:19:18] [PASSED] bottom-right x top-left: 2x2+0+0 x 2x2+1+1
[22:19:18] [PASSED] right x left: 2x1+0+0 x 3x1+1+0
[22:19:18] [PASSED] left x right: 3x1+1+0 x 2x1+0+0
[22:19:18] [PASSED] up x bottom: 1x2+0+0 x 1x3+0-1
[22:19:18] [PASSED] bottom x up: 1x3+0-1 x 1x2+0+0
[22:19:18] [PASSED] touching corner: 1x1+0+0 x 2x2+1+1
[22:19:18] [PASSED] touching side: 1x1+0+0 x 1x1+1+0
[22:19:18] [PASSED] equal rects: 2x2+0+0 x 2x2+0+0
[22:19:18] [PASSED] inside another: 2x2+0+0 x 1x1+1+1
[22:19:18] [PASSED] far away: 1x1+0+0 x 1x1+3+6
[22:19:18] [PASSED] points intersecting: 0x0+5+10 x 0x0+5+10
[22:19:18] [PASSED] points not intersecting: 0x0+0+0 x 0x0+5+10
[22:19:18] ============= [PASSED] drm_test_rect_intersect =============
[22:19:18] ================ drm_test_rect_calc_hscale  ================
[22:19:18] [PASSED] normal use
[22:19:18] [PASSED] out of max range
[22:19:18] [PASSED] out of min range
[22:19:18] [PASSED] zero dst
[22:19:18] [PASSED] negative src
[22:19:18] [PASSED] negative dst
[22:19:18] ============ [PASSED] drm_test_rect_calc_hscale ============
[22:19:18] ================ drm_test_rect_calc_vscale  ================
[22:19:18] [PASSED] normal use
[22:19:18] [PASSED] out of max range
[22:19:18] [PASSED] out of min range
[22:19:18] [PASSED] zero dst
[22:19:18] [PASSED] negative src
[22:19:18] [PASSED] negative dst
[22:19:18] ============ [PASSED] drm_test_rect_calc_vscale ============
[22:19:18] ================== drm_test_rect_rotate  ===================
[22:19:18] [PASSED] reflect-x
[22:19:18] [PASSED] reflect-y
[22:19:18] [PASSED] rotate-0
[22:19:18] [PASSED] rotate-90
[22:19:18] [PASSED] rotate-180
[22:19:18] [PASSED] rotate-270
[22:19:18] ============== [PASSED] drm_test_rect_rotate ===============
[22:19:18] ================ drm_test_rect_rotate_inv  =================
[22:19:18] [PASSED] reflect-x
[22:19:18] [PASSED] reflect-y
[22:19:18] [PASSED] rotate-0
[22:19:18] [PASSED] rotate-90
[22:19:18] [PASSED] rotate-180
[22:19:18] [PASSED] rotate-270
[22:19:18] ============ [PASSED] drm_test_rect_rotate_inv =============
[22:19:18] ==================== [PASSED] drm_rect =====================
[22:19:18] ============================================================
[22:19:18] Testing complete. Ran 333 tests: passed: 333
[22:19:18] Elapsed time: 42.949s total, 1.692s configuring, 18.169s building, 23.058s running

+ cleanup
++ stat -c %u:%g /kernel
+ chown -R 1003:1003 /kernel



^ permalink raw reply	[flat|nested] 25+ messages in thread

* [Intel-xe] ✓ CI.Build: success for drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-05-22 22:15 [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio Rodrigo Vivi
  2023-05-22 22:17 ` [Intel-xe] ✓ CI.Patch_applied: success for " Patchwork
  2023-05-22 22:19 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
@ 2023-05-22 22:23 ` Patchwork
  2023-05-23  3:28 ` [Intel-xe] [RFC] " Matt Roper
  3 siblings, 0 replies; 25+ messages in thread
From: Patchwork @ 2023-05-22 22:23 UTC (permalink / raw)
  To: Rodrigo Vivi; +Cc: intel-xe

== Series Details ==

Series: drm/xe: A minimal assert for some forcewake domain on xe_mmio.
URL   : https://patchwork.freedesktop.org/series/118162/
State : success

== Summary ==

+ trap cleanup EXIT
+ cd /kernel
+ git clone https://gitlab.freedesktop.org/drm/xe/ci.git .ci
Cloning into '.ci'...
++ date +%s
+ echo -e '\e[0Ksection_start:1684793968:build_x86_64[collapsed=true]\r\e[0KBuild x86-64'
+ mkdir -p build64
^[[0Ksection_start:1684793968:build_x86_64[collapsed=true]
^[[0KBuild x86-64
+ cat .ci/kernel/kconfig
+ make O=build64 olddefconfig
make[1]: Entering directory '/kernel/build64'
  GEN     Makefile
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX     scripts/kconfig/lexer.lex.c
  YACC    scripts/kconfig/parser.tab.[ch]
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/menu.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
make[1]: Leaving directory '/kernel/build64'
++ nproc
+ make O=build64 -j48
make[1]: Entering directory '/kernel/build64'
  GEN     Makefile
  WRAP    arch/x86/include/generated/uapi/asm/bpf_perf_event.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
  WRAP    arch/x86/include/generated/uapi/asm/errno.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
  WRAP    arch/x86/include/generated/uapi/asm/fcntl.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_x32.h
  WRAP    arch/x86/include/generated/uapi/asm/ioctl.h
  SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
  WRAP    arch/x86/include/generated/uapi/asm/ioctls.h
  SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
  WRAP    arch/x86/include/generated/uapi/asm/ipcbuf.h
  SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
  WRAP    arch/x86/include/generated/uapi/asm/param.h
  SYSTBL  arch/x86/include/generated/asm/syscalls_64.h
  WRAP    arch/x86/include/generated/uapi/asm/poll.h
  WRAP    arch/x86/include/generated/uapi/asm/resource.h
  WRAP    arch/x86/include/generated/uapi/asm/socket.h
  WRAP    arch/x86/include/generated/uapi/asm/sockios.h
  WRAP    arch/x86/include/generated/uapi/asm/termbits.h
  WRAP    arch/x86/include/generated/uapi/asm/termios.h
  WRAP    arch/x86/include/generated/uapi/asm/types.h
  UPD     include/generated/uapi/linux/version.h
  UPD     include/config/kernel.release
  WRAP    arch/x86/include/generated/asm/early_ioremap.h
  UPD     include/generated/compile.h
  WRAP    arch/x86/include/generated/asm/export.h
  WRAP    arch/x86/include/generated/asm/mcs_spinlock.h
  WRAP    arch/x86/include/generated/asm/irq_regs.h
  WRAP    arch/x86/include/generated/asm/kmap_size.h
  WRAP    arch/x86/include/generated/asm/local64.h
  HOSTCC  arch/x86/tools/relocs_32.o
  WRAP    arch/x86/include/generated/asm/mmiowb.h
  HOSTCC  arch/x86/tools/relocs_64.o
  WRAP    arch/x86/include/generated/asm/module.lds.h
  HOSTCC  arch/x86/tools/relocs_common.o
  WRAP    arch/x86/include/generated/asm/rwonce.h
  WRAP    arch/x86/include/generated/asm/unaligned.h
  HOSTCC  scripts/unifdef
  UPD     include/generated/utsrelease.h
  HOSTCC  scripts/kallsyms
  HOSTCC  scripts/sorttable
  HOSTCC  scripts/asn1_compiler
  DESCEND objtool
  HOSTCC  /kernel/build64/tools/objtool/fixdep.o
  HOSTLD  /kernel/build64/tools/objtool/fixdep-in.o
  LINK    /kernel/build64/tools/objtool/fixdep
  INSTALL /kernel/build64/tools/objtool/libsubcmd/include/subcmd/exec-cmd.h
  INSTALL /kernel/build64/tools/objtool/libsubcmd/include/subcmd/help.h
  INSTALL /kernel/build64/tools/objtool/libsubcmd/include/subcmd/pager.h
  INSTALL /kernel/build64/tools/objtool/libsubcmd/include/subcmd/parse-options.h
  INSTALL /kernel/build64/tools/objtool/libsubcmd/include/subcmd/run-command.h
  CC      /kernel/build64/tools/objtool/libsubcmd/exec-cmd.o
  HOSTLD  arch/x86/tools/relocs
  CC      /kernel/build64/tools/objtool/libsubcmd/help.o
  CC      /kernel/build64/tools/objtool/libsubcmd/pager.o
  INSTALL libsubcmd_headers
  CC      /kernel/build64/tools/objtool/libsubcmd/parse-options.o
  CC      /kernel/build64/tools/objtool/libsubcmd/run-command.o
  CC      /kernel/build64/tools/objtool/libsubcmd/sigchain.o
  CC      /kernel/build64/tools/objtool/libsubcmd/subcmd-config.o
  CC      scripts/mod/empty.o
  HOSTCC  scripts/mod/mk_elfconfig
  CC      scripts/mod/devicetable-offsets.s
  HDRINST usr/include/video/edid.h
  HDRINST usr/include/video/sisfb.h
  HDRINST usr/include/video/uvesafb.h
  HDRINST usr/include/drm/amdgpu_drm.h
  HDRINST usr/include/drm/qaic_accel.h
  HDRINST usr/include/drm/i915_drm.h
  HDRINST usr/include/drm/vgem_drm.h
  HDRINST usr/include/drm/virtgpu_drm.h
  HDRINST usr/include/drm/xe_drm.h
  HDRINST usr/include/drm/omap_drm.h
  HDRINST usr/include/drm/radeon_drm.h
  HDRINST usr/include/drm/tegra_drm.h
  HDRINST usr/include/drm/ivpu_accel.h
  HDRINST usr/include/drm/drm_mode.h
  HDRINST usr/include/drm/drm_sarea.h
  HDRINST usr/include/drm/v3d_drm.h
  HDRINST usr/include/drm/exynos_drm.h
  HDRINST usr/include/drm/qxl_drm.h
  HDRINST usr/include/drm/drm_fourcc.h
  HDRINST usr/include/drm/nouveau_drm.h
  HDRINST usr/include/drm/habanalabs_accel.h
  HDRINST usr/include/drm/vmwgfx_drm.h
  HDRINST usr/include/drm/msm_drm.h
  HDRINST usr/include/drm/etnaviv_drm.h
  HDRINST usr/include/drm/vc4_drm.h
  HDRINST usr/include/drm/panfrost_drm.h
  HDRINST usr/include/drm/lima_drm.h
  HDRINST usr/include/drm/drm.h
  HDRINST usr/include/mtd/inftl-user.h
  HDRINST usr/include/mtd/nftl-user.h
  HDRINST usr/include/drm/armada_drm.h
  HDRINST usr/include/mtd/mtd-user.h
  HDRINST usr/include/mtd/mtd-abi.h
  HDRINST usr/include/mtd/ubi-user.h
  HDRINST usr/include/xen/gntdev.h
  HDRINST usr/include/xen/gntalloc.h
  HDRINST usr/include/xen/evtchn.h
  HDRINST usr/include/xen/privcmd.h
  HDRINST usr/include/asm-generic/auxvec.h
  HDRINST usr/include/asm-generic/bitsperlong.h
  HDRINST usr/include/asm-generic/posix_types.h
  HDRINST usr/include/asm-generic/ioctls.h
  HDRINST usr/include/asm-generic/mman.h
  HDRINST usr/include/asm-generic/shmbuf.h
  HDRINST usr/include/asm-generic/bpf_perf_event.h
  HDRINST usr/include/asm-generic/types.h
  HDRINST usr/include/asm-generic/poll.h
  HDRINST usr/include/asm-generic/msgbuf.h
  HDRINST usr/include/asm-generic/swab.h
  HDRINST usr/include/asm-generic/statfs.h
  HDRINST usr/include/asm-generic/unistd.h
  HDRINST usr/include/asm-generic/hugetlb_encode.h
  HDRINST usr/include/asm-generic/resource.h
  HDRINST usr/include/asm-generic/param.h
  HDRINST usr/include/asm-generic/termbits-common.h
  HDRINST usr/include/asm-generic/sockios.h
  HDRINST usr/include/asm-generic/kvm_para.h
  HDRINST usr/include/asm-generic/errno.h
  HDRINST usr/include/asm-generic/termios.h
  HDRINST usr/include/asm-generic/mman-common.h
  HDRINST usr/include/asm-generic/ioctl.h
  HDRINST usr/include/asm-generic/socket.h
  HDRINST usr/include/asm-generic/signal-defs.h
  HDRINST usr/include/asm-generic/termbits.h
  HDRINST usr/include/asm-generic/int-ll64.h
  HDRINST usr/include/asm-generic/signal.h
  HDRINST usr/include/asm-generic/siginfo.h
  HDRINST usr/include/asm-generic/stat.h
  HDRINST usr/include/asm-generic/int-l64.h
  HDRINST usr/include/asm-generic/errno-base.h
  HDRINST usr/include/asm-generic/fcntl.h
  HDRINST usr/include/asm-generic/setup.h
  HDRINST usr/include/asm-generic/ipcbuf.h
  HDRINST usr/include/asm-generic/sembuf.h
  UPD     scripts/mod/devicetable-offsets.h
  HDRINST usr/include/asm-generic/ucontext.h
  HDRINST usr/include/rdma/mlx5_user_ioctl_cmds.h
  HDRINST usr/include/rdma/irdma-abi.h
  HDRINST usr/include/rdma/mana-abi.h
  HDRINST usr/include/rdma/hfi/hfi1_user.h
  HDRINST usr/include/rdma/hfi/hfi1_ioctl.h
  HDRINST usr/include/rdma/rdma_user_rxe.h
  HDRINST usr/include/rdma/rdma_user_ioctl.h
  HDRINST usr/include/rdma/mlx5_user_ioctl_verbs.h
  HDRINST usr/include/rdma/bnxt_re-abi.h
  HDRINST usr/include/rdma/hns-abi.h
  HDRINST usr/include/rdma/qedr-abi.h
  HDRINST usr/include/rdma/ib_user_ioctl_cmds.h
  HDRINST usr/include/rdma/vmw_pvrdma-abi.h
  HDRINST usr/include/rdma/ib_user_sa.h
  HDRINST usr/include/rdma/ib_user_ioctl_verbs.h
  HDRINST usr/include/rdma/rvt-abi.h
  HDRINST usr/include/rdma/mlx5-abi.h
  HDRINST usr/include/rdma/rdma_netlink.h
  HDRINST usr/include/rdma/erdma-abi.h
  HDRINST usr/include/rdma/rdma_user_ioctl_cmds.h
  HDRINST usr/include/rdma/rdma_user_cm.h
  HDRINST usr/include/rdma/ib_user_verbs.h
  HDRINST usr/include/rdma/efa-abi.h
  HDRINST usr/include/rdma/siw-abi.h
  HDRINST usr/include/rdma/mlx4-abi.h
  HDRINST usr/include/rdma/mthca-abi.h
  HDRINST usr/include/rdma/ib_user_mad.h
  HDRINST usr/include/rdma/ocrdma-abi.h
  HDRINST usr/include/rdma/cxgb4-abi.h
  HDRINST usr/include/misc/xilinx_sdfec.h
  HDRINST usr/include/misc/uacce/hisi_qm.h
  HDRINST usr/include/misc/uacce/uacce.h
  HDRINST usr/include/misc/cxl.h
  HDRINST usr/include/misc/ocxl.h
  HDRINST usr/include/misc/fastrpc.h
  HDRINST usr/include/misc/pvpanic.h
  HDRINST usr/include/linux/i8k.h
  HDRINST usr/include/linux/acct.h
  HDRINST usr/include/linux/atmmpc.h
  HDRINST usr/include/linux/fs.h
  HDRINST usr/include/linux/cifs/cifs_mount.h
  HDRINST usr/include/linux/cifs/cifs_netlink.h
  HDRINST usr/include/linux/if_packet.h
  HDRINST usr/include/linux/route.h
  HDRINST usr/include/linux/patchkey.h
  HDRINST usr/include/linux/tc_ematch/tc_em_cmp.h
  HDRINST usr/include/linux/tc_ematch/tc_em_ipt.h
  HDRINST usr/include/linux/tc_ematch/tc_em_meta.h
  HDRINST usr/include/linux/tc_ematch/tc_em_nbyte.h
  HDRINST usr/include/linux/tc_ematch/tc_em_text.h
  HDRINST usr/include/linux/virtio_pmem.h
  HDRINST usr/include/linux/rkisp1-config.h
  HDRINST usr/include/linux/vhost.h
  HDRINST usr/include/linux/cec-funcs.h
  HDRINST usr/include/linux/ppdev.h
  HDRINST usr/include/linux/isdn/capicmd.h
  HDRINST usr/include/linux/virtio_fs.h
  HDRINST usr/include/linux/netfilter_ipv6.h
  HDRINST usr/include/linux/lirc.h
  HDRINST usr/include/linux/mroute6.h
  HDRINST usr/include/linux/nl80211-vnd-intel.h
  HDRINST usr/include/linux/ivtvfb.h
  HDRINST usr/include/linux/auxvec.h
  HDRINST usr/include/linux/dm-log-userspace.h
  HDRINST usr/include/linux/dccp.h
  MKELF   scripts/mod/elfconfig.h
  HDRINST usr/include/linux/virtio_scmi.h
  HDRINST usr/include/linux/atmarp.h
  HDRINST usr/include/linux/arcfb.h
  HDRINST usr/include/linux/nbd-netlink.h
  HDRINST usr/include/linux/sched/types.h
  HDRINST usr/include/linux/tcp.h
  HOSTCC  scripts/mod/modpost.o
  HDRINST usr/include/linux/neighbour.h
  HOSTCC  scripts/mod/file2alias.o
  HDRINST usr/include/linux/dlm_device.h
  HOSTCC  scripts/mod/sumversion.o
  HDRINST usr/include/linux/wmi.h
  HDRINST usr/include/linux/btrfs_tree.h
  HDRINST usr/include/linux/virtio_crypto.h
  HDRINST usr/include/linux/vbox_err.h
  HDRINST usr/include/linux/edd.h
  HDRINST usr/include/linux/loop.h
  HDRINST usr/include/linux/nvme_ioctl.h
  HDRINST usr/include/linux/mmtimer.h
  HDRINST usr/include/linux/if_pppol2tp.h
  HDRINST usr/include/linux/mtio.h
  HDRINST usr/include/linux/if_arcnet.h
  HDRINST usr/include/linux/romfs_fs.h
  HDRINST usr/include/linux/posix_types.h
  HDRINST usr/include/linux/rtc.h
  HDRINST usr/include/linux/landlock.h
  HDRINST usr/include/linux/gpio.h
  HDRINST usr/include/linux/selinux_netlink.h
  HDRINST usr/include/linux/pps.h
  HDRINST usr/include/linux/ndctl.h
  HDRINST usr/include/linux/virtio_gpu.h
  HDRINST usr/include/linux/android/binderfs.h
  HDRINST usr/include/linux/android/binder.h
  HDRINST usr/include/linux/virtio_vsock.h
  HDRINST usr/include/linux/sound.h
  HDRINST usr/include/linux/vtpm_proxy.h
  HDRINST usr/include/linux/nfs_fs.h
  HDRINST usr/include/linux/elf-fdpic.h
  HDRINST usr/include/linux/adfs_fs.h
  HDRINST usr/include/linux/target_core_user.h
  HDRINST usr/include/linux/netlink_diag.h
  HDRINST usr/include/linux/const.h
  HDRINST usr/include/linux/firewire-cdev.h
  HDRINST usr/include/linux/vdpa.h
  HDRINST usr/include/linux/if_infiniband.h
  HDRINST usr/include/linux/serial.h
  HDRINST usr/include/linux/iio/types.h
  HDRINST usr/include/linux/iio/buffer.h
  HDRINST usr/include/linux/iio/events.h
  HDRINST usr/include/linux/baycom.h
  HDRINST usr/include/linux/major.h
  HDRINST usr/include/linux/atmppp.h
  HDRINST usr/include/linux/ipv6_route.h
  HDRINST usr/include/linux/spi/spidev.h
  HDRINST usr/include/linux/spi/spi.h
  HDRINST usr/include/linux/virtio_ring.h
  HDRINST usr/include/linux/hdlc/ioctl.h
  HDRINST usr/include/linux/remoteproc_cdev.h
  HDRINST usr/include/linux/hyperv.h
  HDRINST usr/include/linux/rpl_iptunnel.h
  HDRINST usr/include/linux/sync_file.h
  HDRINST usr/include/linux/igmp.h
  HDRINST usr/include/linux/v4l2-dv-timings.h
  HDRINST usr/include/linux/virtio_i2c.h
  HDRINST usr/include/linux/xfrm.h
  HDRINST usr/include/linux/capability.h
  HDRINST usr/include/linux/gtp.h
  HDRINST usr/include/linux/xdp_diag.h
  HDRINST usr/include/linux/pkt_cls.h
  HDRINST usr/include/linux/suspend_ioctls.h
  HDRINST usr/include/linux/vt.h
  HDRINST usr/include/linux/loadpin.h
  HDRINST usr/include/linux/dlm_plock.h
  HDRINST usr/include/linux/fb.h
  HDRINST usr/include/linux/max2175.h
  HDRINST usr/include/linux/sunrpc/debug.h
  HDRINST usr/include/linux/gsmmux.h
  HDRINST usr/include/linux/watchdog.h
  HDRINST usr/include/linux/vhost_types.h
  HDRINST usr/include/linux/vduse.h
  HDRINST usr/include/linux/ila.h
  HDRINST usr/include/linux/tdx-guest.h
  HDRINST usr/include/linux/close_range.h
  HDRINST usr/include/linux/ivtv.h
  HDRINST usr/include/linux/cryptouser.h
  HDRINST usr/include/linux/netfilter/xt_string.h
  HDRINST usr/include/linux/netfilter/nfnetlink_compat.h
  HDRINST usr/include/linux/netfilter/nf_nat.h
  HDRINST usr/include/linux/netfilter/xt_recent.h
  HDRINST usr/include/linux/netfilter/xt_addrtype.h
  HDRINST usr/include/linux/netfilter/nf_conntrack_tcp.h
  HDRINST usr/include/linux/netfilter/xt_MARK.h
  HDRINST usr/include/linux/netfilter/xt_SYNPROXY.h
  HDRINST usr/include/linux/netfilter/xt_multiport.h
  HDRINST usr/include/linux/netfilter/nfnetlink.h
  HDRINST usr/include/linux/netfilter/xt_cgroup.h
  HDRINST usr/include/linux/netfilter/nf_synproxy.h
  HDRINST usr/include/linux/netfilter/xt_TCPOPTSTRIP.h
  HDRINST usr/include/linux/netfilter/nfnetlink_log.h
  HDRINST usr/include/linux/netfilter/xt_TPROXY.h
  HDRINST usr/include/linux/netfilter/xt_u32.h
  HDRINST usr/include/linux/netfilter/nfnetlink_osf.h
  HDRINST usr/include/linux/netfilter/xt_ecn.h
  HDRINST usr/include/linux/netfilter/xt_esp.h
  HDRINST usr/include/linux/netfilter/nfnetlink_hook.h
  HDRINST usr/include/linux/netfilter/xt_mac.h
  HDRINST usr/include/linux/netfilter/xt_comment.h
  HDRINST usr/include/linux/netfilter/xt_NFQUEUE.h
  HDRINST usr/include/linux/netfilter/xt_osf.h
  HDRINST usr/include/linux/netfilter/xt_hashlimit.h
  HDRINST usr/include/linux/netfilter/nf_conntrack_sctp.h
  HDRINST usr/include/linux/netfilter/xt_socket.h
  HDRINST usr/include/linux/netfilter/xt_connmark.h
  HDRINST usr/include/linux/netfilter/xt_sctp.h
  HDRINST usr/include/linux/netfilter/xt_tcpudp.h
  HDRINST usr/include/linux/netfilter/xt_DSCP.h
  HDRINST usr/include/linux/netfilter/xt_time.h
  HDRINST usr/include/linux/netfilter/xt_IDLETIMER.h
  HDRINST usr/include/linux/netfilter/xt_policy.h
  HDRINST usr/include/linux/netfilter/xt_rpfilter.h
  HDRINST usr/include/linux/netfilter/xt_nfacct.h
  HDRINST usr/include/linux/netfilter/xt_SECMARK.h
  HDRINST usr/include/linux/netfilter/xt_length.h
  HDRINST usr/include/linux/netfilter/nfnetlink_cthelper.h
  HDRINST usr/include/linux/netfilter/xt_quota.h
  HDRINST usr/include/linux/netfilter/xt_CLASSIFY.h
  HDRINST usr/include/linux/netfilter/xt_ipcomp.h
  HDRINST usr/include/linux/netfilter/xt_iprange.h
  HDRINST usr/include/linux/netfilter/xt_bpf.h
  HDRINST usr/include/linux/netfilter/xt_LOG.h
  HDRINST usr/include/linux/netfilter/xt_rateest.h
  HDRINST usr/include/linux/netfilter/xt_CONNSECMARK.h
  HDRINST usr/include/linux/netfilter/xt_HMARK.h
  HDRINST usr/include/linux/netfilter/xt_CONNMARK.h
  HDRINST usr/include/linux/netfilter/xt_pkttype.h
  HDRINST usr/include/linux/netfilter/xt_ipvs.h
  HDRINST usr/include/linux/netfilter/xt_devgroup.h
  HDRINST usr/include/linux/netfilter/xt_AUDIT.h
  HDRINST usr/include/linux/netfilter/xt_realm.h
  HDRINST usr/include/linux/netfilter/nf_conntrack_common.h
  HDRINST usr/include/linux/netfilter/xt_set.h
  HDRINST usr/include/linux/netfilter/xt_LED.h
  HDRINST usr/include/linux/netfilter/xt_connlabel.h
  HDRINST usr/include/linux/netfilter/xt_owner.h
  HDRINST usr/include/linux/netfilter/xt_dccp.h
  HDRINST usr/include/linux/netfilter/xt_limit.h
  HDRINST usr/include/linux/netfilter/xt_conntrack.h
  HDRINST usr/include/linux/netfilter/xt_TEE.h
  HDRINST usr/include/linux/netfilter/xt_RATEEST.h
  HDRINST usr/include/linux/netfilter/xt_connlimit.h
  HDRINST usr/include/linux/netfilter/ipset/ip_set.h
  HDRINST usr/include/linux/netfilter/ipset/ip_set_list.h
  HDRINST usr/include/linux/netfilter/ipset/ip_set_hash.h
  HDRINST usr/include/linux/netfilter/ipset/ip_set_bitmap.h
  HDRINST usr/include/linux/netfilter/x_tables.h
  HDRINST usr/include/linux/netfilter/xt_dscp.h
  HDRINST usr/include/linux/netfilter/nf_conntrack_ftp.h
  HDRINST usr/include/linux/netfilter/xt_cluster.h
  HDRINST usr/include/linux/netfilter/nf_conntrack_tuple_common.h
  HDRINST usr/include/linux/netfilter/nf_log.h
  HDRINST usr/include/linux/netfilter/xt_tcpmss.h
  HDRINST usr/include/linux/netfilter/xt_NFLOG.h
  HDRINST usr/include/linux/netfilter/xt_l2tp.h
  HDRINST usr/include/linux/netfilter/xt_helper.h
  HDRINST usr/include/linux/netfilter/xt_statistic.h
  HDRINST usr/include/linux/netfilter/nfnetlink_queue.h
  HDRINST usr/include/linux/netfilter/nfnetlink_cttimeout.h
  HDRINST usr/include/linux/netfilter/xt_CT.h
  HDRINST usr/include/linux/netfilter/xt_CHECKSUM.h
  HDRINST usr/include/linux/netfilter/xt_connbytes.h
  HDRINST usr/include/linux/netfilter/xt_state.h
  HDRINST usr/include/linux/netfilter/nf_tables.h
  HDRINST usr/include/linux/netfilter/xt_mark.h
  HDRINST usr/include/linux/netfilter/xt_cpu.h
  HDRINST usr/include/linux/netfilter/nf_tables_compat.h
  HDRINST usr/include/linux/netfilter/xt_physdev.h
  HDRINST usr/include/linux/netfilter/nfnetlink_conntrack.h
  HDRINST usr/include/linux/netfilter/nfnetlink_acct.h
  HDRINST usr/include/linux/netfilter/xt_TCPMSS.h
  HDRINST usr/include/linux/tty_flags.h
  HDRINST usr/include/linux/if_phonet.h
  HDRINST usr/include/linux/elf-em.h
  HDRINST usr/include/linux/vm_sockets.h
  HDRINST usr/include/linux/dlmconstants.h
  HDRINST usr/include/linux/bsg.h
  HDRINST usr/include/linux/matroxfb.h
  HDRINST usr/include/linux/sysctl.h
  HDRINST usr/include/linux/unix_diag.h
  HDRINST usr/include/linux/pcitest.h
  HDRINST usr/include/linux/mman.h
  HDRINST usr/include/linux/if_plip.h
  HDRINST usr/include/linux/virtio_balloon.h
  HDRINST usr/include/linux/pidfd.h
  HDRINST usr/include/linux/f2fs.h
  HDRINST usr/include/linux/x25.h
  HDRINST usr/include/linux/if_cablemodem.h
  HDRINST usr/include/linux/utsname.h
  HDRINST usr/include/linux/counter.h
  HDRINST usr/include/linux/atm_tcp.h
  HDRINST usr/include/linux/atalk.h
  HDRINST usr/include/linux/virtio_rng.h
  HDRINST usr/include/linux/vboxguest.h
  HDRINST usr/include/linux/bpf_perf_event.h
  HDRINST usr/include/linux/ipmi_ssif_bmc.h
  HDRINST usr/include/linux/nfs_mount.h
  HDRINST usr/include/linux/sonet.h
  HDRINST usr/include/linux/netfilter.h
  HDRINST usr/include/linux/keyctl.h
  HDRINST usr/include/linux/nl80211.h
  HDRINST usr/include/linux/misc/bcm_vk.h
  HDRINST usr/include/linux/audit.h
  HDRINST usr/include/linux/tipc_config.h
  HDRINST usr/include/linux/tipc_sockets_diag.h
  HDRINST usr/include/linux/futex.h
  HDRINST usr/include/linux/sev-guest.h
  HDRINST usr/include/linux/ublk_cmd.h
  HDRINST usr/include/linux/types.h
  HDRINST usr/include/linux/virtio_input.h
  HDRINST usr/include/linux/if_slip.h
  HDRINST usr/include/linux/personality.h
  HDRINST usr/include/linux/openat2.h
  HDRINST usr/include/linux/poll.h
  HDRINST usr/include/linux/posix_acl.h
  HDRINST usr/include/linux/smc_diag.h
  HDRINST usr/include/linux/snmp.h
  HDRINST usr/include/linux/errqueue.h
  HDRINST usr/include/linux/if_tunnel.h
  HDRINST usr/include/linux/fanotify.h
  HDRINST usr/include/linux/kernel.h
  HDRINST usr/include/linux/rtnetlink.h
  HDRINST usr/include/linux/rpl.h
  HDRINST usr/include/linux/memfd.h
  HDRINST usr/include/linux/serial_core.h
  HDRINST usr/include/linux/dns_resolver.h
  HDRINST usr/include/linux/pr.h
  HDRINST usr/include/linux/atm_eni.h
  HDRINST usr/include/linux/lp.h
  HDRINST usr/include/linux/virtio_mem.h
  HDRINST usr/include/linux/ultrasound.h
  HDRINST usr/include/linux/sctp.h
  HDRINST usr/include/linux/uio.h
  HDRINST usr/include/linux/tcp_metrics.h
  HDRINST usr/include/linux/wwan.h
  HDRINST usr/include/linux/atmbr2684.h
  HDRINST usr/include/linux/in_route.h
  HDRINST usr/include/linux/qemu_fw_cfg.h
  HDRINST usr/include/linux/if_macsec.h
  HDRINST usr/include/linux/usb/charger.h
  HDRINST usr/include/linux/usb/g_uvc.h
  HDRINST usr/include/linux/usb/gadgetfs.h
  HDRINST usr/include/linux/usb/raw_gadget.h
  HDRINST usr/include/linux/usb/cdc-wdm.h
  HDRINST usr/include/linux/usb/g_printer.h
  HDRINST usr/include/linux/usb/midi.h
  HDRINST usr/include/linux/usb/tmc.h
  HDRINST usr/include/linux/usb/video.h
  HDRINST usr/include/linux/usb/functionfs.h
  HDRINST usr/include/linux/usb/audio.h
  HDRINST usr/include/linux/usb/ch11.h
  HDRINST usr/include/linux/usb/ch9.h
  HDRINST usr/include/linux/usb/cdc.h
  HDRINST usr/include/linux/jffs2.h
  HDRINST usr/include/linux/ax25.h
  HDRINST usr/include/linux/auto_fs.h
  HDRINST usr/include/linux/tiocl.h
  HDRINST usr/include/linux/scc.h
  HDRINST usr/include/linux/psci.h
  HDRINST usr/include/linux/swab.h
  HDRINST usr/include/linux/cec.h
  HDRINST usr/include/linux/kfd_ioctl.h
  HDRINST usr/include/linux/smc.h
  HDRINST usr/include/linux/qrtr.h
  HDRINST usr/include/linux/screen_info.h
  HDRINST usr/include/linux/nfsacl.h
  HDRINST usr/include/linux/seg6_hmac.h
  HDRINST usr/include/linux/gameport.h
  HDRINST usr/include/linux/wireless.h
  HDRINST usr/include/linux/fdreg.h
  HDRINST usr/include/linux/cciss_defs.h
  HDRINST usr/include/linux/serial_reg.h
  HDRINST usr/include/linux/perf_event.h
  HDRINST usr/include/linux/in6.h
  HDRINST usr/include/linux/hid.h
  HDRINST usr/include/linux/netlink.h
  HDRINST usr/include/linux/fuse.h
  HDRINST usr/include/linux/magic.h
  HDRINST usr/include/linux/ioam6_iptunnel.h
  HDRINST usr/include/linux/stm.h
  HDRINST usr/include/linux/vsockmon.h
  HDRINST usr/include/linux/seg6.h
  HDRINST usr/include/linux/idxd.h
  HDRINST usr/include/linux/nitro_enclaves.h
  HDRINST usr/include/linux/ptrace.h
  HDRINST usr/include/linux/ioam6_genl.h
  HDRINST usr/include/linux/qnx4_fs.h
  HDRINST usr/include/linux/fsl_mc.h
  HDRINST usr/include/linux/net_tstamp.h
  HDRINST usr/include/linux/msg.h
  HDRINST usr/include/linux/netfilter_ipv4/ipt_TTL.h
  HDRINST usr/include/linux/netfilter_ipv4/ipt_ttl.h
  HDRINST usr/include/linux/netfilter_ipv4/ipt_ah.h
  HDRINST usr/include/linux/netfilter_ipv4/ipt_ECN.h
  HDRINST usr/include/linux/netfilter_ipv4/ip_tables.h
  HDRINST usr/include/linux/netfilter_ipv4/ipt_ecn.h
  HDRINST usr/include/linux/netfilter_ipv4/ipt_CLUSTERIP.h
  HDRINST usr/include/linux/netfilter_ipv4/ipt_REJECT.h
  HDRINST usr/include/linux/netfilter_ipv4/ipt_LOG.h
  HDRINST usr/include/linux/sem.h
  HDRINST usr/include/linux/net_namespace.h
  HDRINST usr/include/linux/radeonfb.h
  HDRINST usr/include/linux/tee.h
  HDRINST usr/include/linux/udp.h
  HDRINST usr/include/linux/virtio_bt.h
  HDRINST usr/include/linux/v4l2-subdev.h
  HDRINST usr/include/linux/posix_acl_xattr.h
  HDRINST usr/include/linux/v4l2-mediabus.h
  HDRINST usr/include/linux/atmapi.h
  HDRINST usr/include/linux/raid/md_p.h
  HDRINST usr/include/linux/raid/md_u.h
  HDRINST usr/include/linux/zorro_ids.h
  HDRINST usr/include/linux/nbd.h
  HDRINST usr/include/linux/isst_if.h
  HDRINST usr/include/linux/rxrpc.h
  HDRINST usr/include/linux/unistd.h
  HDRINST usr/include/linux/if_arp.h
  HDRINST usr/include/linux/atm_zatm.h
  HDRINST usr/include/linux/io_uring.h
  HDRINST usr/include/linux/if_fddi.h
  HDRINST usr/include/linux/bpqether.h
  HDRINST usr/include/linux/sysinfo.h
  HDRINST usr/include/linux/auto_dev-ioctl.h
  HDRINST usr/include/linux/nfs4_mount.h
  HDRINST usr/include/linux/keyboard.h
  HDRINST usr/include/linux/virtio_mmio.h
  HDRINST usr/include/linux/input.h
  HDRINST usr/include/linux/qnxtypes.h
  HDRINST usr/include/linux/mdio.h
  HDRINST usr/include/linux/lwtunnel.h
  HDRINST usr/include/linux/gfs2_ondisk.h
  HDRINST usr/include/linux/nfs4.h
  HDRINST usr/include/linux/ptp_clock.h
  HDRINST usr/include/linux/nubus.h
  HDRINST usr/include/linux/if_bonding.h
  HDRINST usr/include/linux/kcov.h
  HDRINST usr/include/linux/fadvise.h
  HDRINST usr/include/linux/taskstats.h
  HDRINST usr/include/linux/veth.h
  HDRINST usr/include/linux/atm.h
  HDRINST usr/include/linux/ipmi.h
  HDRINST usr/include/linux/kdev_t.h
  HDRINST usr/include/linux/mount.h
  HDRINST usr/include/linux/shm.h
  HDRINST usr/include/linux/resource.h
  HDRINST usr/include/linux/prctl.h
  HDRINST usr/include/linux/watch_queue.h
  HDRINST usr/include/linux/sched.h
  HDRINST usr/include/linux/phonet.h
  HDRINST usr/include/linux/random.h
  HDRINST usr/include/linux/tty.h
  HDRINST usr/include/linux/apm_bios.h
  HDRINST usr/include/linux/fd.h
  HDRINST usr/include/linux/um_timetravel.h
  HDRINST usr/include/linux/tls.h
  HDRINST usr/include/linux/rpmsg_types.h
  HDRINST usr/include/linux/pfrut.h
  HDRINST usr/include/linux/mei.h
  HDRINST usr/include/linux/fsi.h
  HDRINST usr/include/linux/rds.h
  HDRINST usr/include/linux/if_x25.h
  HDRINST usr/include/linux/param.h
  HDRINST usr/include/linux/netdevice.h
  HDRINST usr/include/linux/binfmts.h
  HDRINST usr/include/linux/if_pppox.h
  HDRINST usr/include/linux/sockios.h
  HDRINST usr/include/linux/kcm.h
  HDRINST usr/include/linux/virtio_9p.h
  HDRINST usr/include/linux/genwqe/genwqe_card.h
  HDRINST usr/include/linux/if_tun.h
  HDRINST usr/include/linux/if_ether.h
  HDRINST usr/include/linux/kvm_para.h
  HDRINST usr/include/linux/kernel-page-flags.h
  HDRINST usr/include/linux/cdrom.h
  HDRINST usr/include/linux/un.h
  HDRINST usr/include/linux/module.h
  HDRINST usr/include/linux/mqueue.h
  HDRINST usr/include/linux/a.out.h
  HDRINST usr/include/linux/input-event-codes.h
  HDRINST usr/include/linux/coda.h
  HDRINST usr/include/linux/rio_mport_cdev.h
  HDRINST usr/include/linux/ipsec.h
  HDRINST usr/include/linux/blkpg.h
  HDRINST usr/include/linux/blkzoned.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_arpreply.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_redirect.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_nflog.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_802_3.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_nat.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_mark_m.h
  HDRINST usr/include/linux/netfilter_bridge/ebtables.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_vlan.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_limit.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_log.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_stp.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_pkttype.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_ip.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_ip6.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_arp.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_mark_t.h
  HDRINST usr/include/linux/netfilter_bridge/ebt_among.h
  HDRINST usr/include/linux/reiserfs_fs.h
  HDRINST usr/include/linux/cciss_ioctl.h
  HDRINST usr/include/linux/fsmap.h
  HDRINST usr/include/linux/smiapp.h
  HDRINST usr/include/linux/switchtec_ioctl.h
  HDRINST usr/include/linux/atmdev.h
  HDRINST usr/include/linux/hpet.h
  HDRINST usr/include/linux/virtio_config.h
  HDRINST usr/include/linux/string.h
  HDRINST usr/include/linux/kfd_sysfs.h
  HDRINST usr/include/linux/inet_diag.h
  HDRINST usr/include/linux/netdev.h
  HDRINST usr/include/linux/xattr.h
  HDRINST usr/include/linux/iommufd.h
  HDRINST usr/include/linux/errno.h
  HDRINST usr/include/linux/icmp.h
  HDRINST usr/include/linux/i2o-dev.h
  HDRINST usr/include/linux/pg.h
  HDRINST usr/include/linux/if_bridge.h
  HDRINST usr/include/linux/thermal.h
  HDRINST usr/include/linux/uinput.h
  HDRINST usr/include/linux/dqblk_xfs.h
  HDRINST usr/include/linux/v4l2-common.h
  HDRINST usr/include/linux/nvram.h
  HDRINST usr/include/linux/if_vlan.h
  HDRINST usr/include/linux/uhid.h
  HDRINST usr/include/linux/omap3isp.h
  HDRINST usr/include/linux/rose.h
  HDRINST usr/include/linux/phantom.h
  HDRINST usr/include/linux/ipmi_msgdefs.h
  HDRINST usr/include/linux/bcm933xx_hcs.h
  HDRINST usr/include/linux/bpf.h
  HDRINST usr/include/linux/mempolicy.h
  HDRINST usr/include/linux/efs_fs_sb.h
  HDRINST usr/include/linux/nexthop.h
  HDRINST usr/include/linux/net_dropmon.h
  HDRINST usr/include/linux/surface_aggregator/cdev.h
  HDRINST usr/include/linux/surface_aggregator/dtx.h
  HDRINST usr/include/linux/net.h
  HDRINST usr/include/linux/mii.h
  HDRINST usr/include/linux/cm4000_cs.h
  HDRINST usr/include/linux/virtio_pcidev.h
  HDRINST usr/include/linux/termios.h
  HDRINST usr/include/linux/cgroupstats.h
  HDRINST usr/include/linux/mpls.h
  HDRINST usr/include/linux/iommu.h
  HDRINST usr/include/linux/toshiba.h
  HDRINST usr/include/linux/virtio_scsi.h
  HDRINST usr/include/linux/zorro.h
  HDRINST usr/include/linux/chio.h
  HDRINST usr/include/linux/pkt_sched.h
  HDRINST usr/include/linux/cramfs_fs.h
  HDRINST usr/include/linux/nfs3.h
  HDRINST usr/include/linux/vfio_ccw.h
  HDRINST usr/include/linux/atm_nicstar.h
  HDRINST usr/include/linux/ncsi.h
  HDRINST usr/include/linux/virtio_net.h
  HDRINST usr/include/linux/ioctl.h
  HDRINST usr/include/linux/stddef.h
  HDRINST usr/include/linux/limits.h
  HDRINST usr/include/linux/ipmi_bmc.h
  HDRINST usr/include/linux/netfilter_arp.h
  HDRINST usr/include/linux/if_addr.h
  HDRINST usr/include/linux/rpmsg.h
  HDRINST usr/include/linux/media-bus-format.h
  HDRINST usr/include/linux/kernelcapi.h
  HDRINST usr/include/linux/ppp_defs.h
  HDRINST usr/include/linux/ethtool.h
  HDRINST usr/include/linux/aspeed-video.h
  HDRINST usr/include/linux/hdlc.h
  HDRINST usr/include/linux/fscrypt.h
  HDRINST usr/include/linux/batadv_packet.h
  HDRINST usr/include/linux/uuid.h
  HDRINST usr/include/linux/capi.h
  HDRINST usr/include/linux/mptcp.h
  HDRINST usr/include/linux/hidraw.h
  HDRINST usr/include/linux/virtio_console.h
  HDRINST usr/include/linux/irqnr.h
  HDRINST usr/include/linux/coresight-stm.h
  HDRINST usr/include/linux/cxl_mem.h
  HDRINST usr/include/linux/iso_fs.h
  HDRINST usr/include/linux/virtio_blk.h
  HDRINST usr/include/linux/udf_fs_i.h
  HDRINST usr/include/linux/coff.h
  HDRINST usr/include/linux/ife.h
  HDRINST usr/include/linux/dma-buf.h
  HDRINST usr/include/linux/agpgart.h
  HDRINST usr/include/linux/socket.h
  HDRINST usr/include/linux/nilfs2_ondisk.h
  HDRINST usr/include/linux/connector.h
  HDRINST usr/include/linux/auto_fs4.h
  HDRINST usr/include/linux/bt-bmc.h
  HDRINST usr/include/linux/map_to_7segment.h
  LD      /kernel/build64/tools/objtool/libsubcmd/libsubcmd-in.o
  HDRINST usr/include/linux/tc_act/tc_skbedit.h
  HDRINST usr/include/linux/tc_act/tc_ctinfo.h
  HDRINST usr/include/linux/tc_act/tc_defact.h
  HDRINST usr/include/linux/tc_act/tc_gact.h
  HDRINST usr/include/linux/tc_act/tc_vlan.h
  HDRINST usr/include/linux/tc_act/tc_skbmod.h
  HDRINST usr/include/linux/tc_act/tc_sample.h
  HDRINST usr/include/linux/tc_act/tc_tunnel_key.h
  HDRINST usr/include/linux/tc_act/tc_gate.h
  HDRINST usr/include/linux/tc_act/tc_mirred.h
  HDRINST usr/include/linux/tc_act/tc_nat.h
  HDRINST usr/include/linux/tc_act/tc_csum.h
  HDRINST usr/include/linux/tc_act/tc_connmark.h
  HDRINST usr/include/linux/tc_act/tc_ife.h
  HDRINST usr/include/linux/tc_act/tc_mpls.h
  HDRINST usr/include/linux/tc_act/tc_ct.h
  HDRINST usr/include/linux/tc_act/tc_pedit.h
  HDRINST usr/include/linux/tc_act/tc_bpf.h
  HDRINST usr/include/linux/tc_act/tc_ipt.h
  HDRINST usr/include/linux/netrom.h
  HDRINST usr/include/linux/joystick.h
  HDRINST usr/include/linux/falloc.h
  HDRINST usr/include/linux/cycx_cfm.h
  HDRINST usr/include/linux/omapfb.h
  HDRINST usr/include/linux/msdos_fs.h
  HDRINST usr/include/linux/virtio_types.h
  HDRINST usr/include/linux/mroute.h
  HDRINST usr/include/linux/psample.h
  HDRINST usr/include/linux/ipv6.h
  HDRINST usr/include/linux/dw100.h
  HDRINST usr/include/linux/psp-sev.h
  HDRINST usr/include/linux/vfio.h
  HDRINST usr/include/linux/if_ppp.h
  HDRINST usr/include/linux/byteorder/big_endian.h
  AR      /kernel/build64/tools/objtool/libsubcmd/libsubcmd.a
  HDRINST usr/include/linux/byteorder/little_endian.h
  HDRINST usr/include/linux/comedi.h
  HDRINST usr/include/linux/scif_ioctl.h
  HDRINST usr/include/linux/timerfd.h
  HDRINST usr/include/linux/time_types.h
  HDRINST usr/include/linux/firewire-constants.h
  HDRINST usr/include/linux/virtio_snd.h
  HDRINST usr/include/linux/ppp-ioctl.h
  HDRINST usr/include/linux/fib_rules.h
  HDRINST usr/include/linux/gen_stats.h
  HDRINST usr/include/linux/virtio_iommu.h
  HDRINST usr/include/linux/genetlink.h
  HDRINST usr/include/linux/uvcvideo.h
  HDRINST usr/include/linux/pfkeyv2.h
  HDRINST usr/include/linux/soundcard.h
  HDRINST usr/include/linux/times.h
  HDRINST usr/include/linux/nfc.h
  HDRINST usr/include/linux/affs_hardblocks.h
  HDRINST usr/include/linux/nilfs2_api.h
  HDRINST usr/include/linux/rseq.h
  HDRINST usr/include/linux/caif/caif_socket.h
  HDRINST usr/include/linux/caif/if_caif.h
  HDRINST usr/include/linux/i2c-dev.h
  HDRINST usr/include/linux/cuda.h
  HDRINST usr/include/linux/cn_proc.h
  HDRINST usr/include/linux/parport.h
  HDRINST usr/include/linux/v4l2-controls.h
  HDRINST usr/include/linux/hsi/cs-protocol.h
  HDRINST usr/include/linux/hsi/hsi_char.h
  HDRINST usr/include/linux/seg6_genl.h
  HDRINST usr/include/linux/am437x-vpfe.h
  HDRINST usr/include/linux/amt.h
  HDRINST usr/include/linux/netconf.h
  HDRINST usr/include/linux/erspan.h
  HDRINST usr/include/linux/nsfs.h
  HDRINST usr/include/linux/xilinx-v4l2-controls.h
  HDRINST usr/include/linux/aspeed-p2a-ctrl.h
  HDRINST usr/include/linux/vfio_zdev.h
  HDRINST usr/include/linux/serio.h
  HDRINST usr/include/linux/acrn.h
  HDRINST usr/include/linux/nfs2.h
  HDRINST usr/include/linux/virtio_pci.h
  HDRINST usr/include/linux/ipc.h
  HDRINST usr/include/linux/ethtool_netlink.h
  HDRINST usr/include/linux/kd.h
  HDRINST usr/include/linux/elf.h
  HDRINST usr/include/linux/videodev2.h
  HDRINST usr/include/linux/if_alg.h
  HDRINST usr/include/linux/sonypi.h
  HDRINST usr/include/linux/fsverity.h
  HDRINST usr/include/linux/if.h
  HDRINST usr/include/linux/btrfs.h
  HDRINST usr/include/linux/vm_sockets_diag.h
  HDRINST usr/include/linux/netfilter_bridge.h
  HDRINST usr/include/linux/packet_diag.h
  HDRINST usr/include/linux/netfilter_ipv4.h
  HDRINST usr/include/linux/kvm.h
  HDRINST usr/include/linux/pci.h
  HDRINST usr/include/linux/if_addrlabel.h
  HDRINST usr/include/linux/hdlcdrv.h
  HDRINST usr/include/linux/cfm_bridge.h
  HDRINST usr/include/linux/fiemap.h
  HDRINST usr/include/linux/dm-ioctl.h
  HDRINST usr/include/linux/aspeed-lpc-ctrl.h
  HDRINST usr/include/linux/atmioc.h
  HDRINST usr/include/linux/dlm.h
  CC      /kernel/build64/tools/objtool/weak.o
  CC      /kernel/build64/tools/objtool/check.o
  HDRINST usr/include/linux/pci_regs.h
  HDRINST usr/include/linux/cachefiles.h
  CC      /kernel/build64/tools/objtool/special.o
  HDRINST usr/include/linux/membarrier.h
  MKDIR   /kernel/build64/tools/objtool/arch/x86/
  HDRINST usr/include/linux/nfs_idmap.h
  CC      /kernel/build64/tools/objtool/builtin-check.o
  HDRINST usr/include/linux/ip.h
  HDRINST usr/include/linux/atm_he.h
  MKDIR   /kernel/build64/tools/objtool/arch/x86/lib/
  HDRINST usr/include/linux/nfsd/export.h
  HDRINST usr/include/linux/nfsd/stats.h
  CC      /kernel/build64/tools/objtool/elf.o
  CC      /kernel/build64/tools/objtool/objtool.o
  HDRINST usr/include/linux/nfsd/debug.h
  CC      /kernel/build64/tools/objtool/orc_gen.o
  CC      /kernel/build64/tools/objtool/arch/x86/special.o
  GEN     /kernel/build64/tools/objtool/arch/x86/lib/inat-tables.c
  CC      /kernel/build64/tools/objtool/orc_dump.o
  HDRINST usr/include/linux/nfsd/cld.h
  HDRINST usr/include/linux/ip_vs.h
  HDRINST usr/include/linux/vmcore.h
  CC      /kernel/build64/tools/objtool/libstring.o
  HDRINST usr/include/linux/vbox_vmmdev_types.h
  HDRINST usr/include/linux/dvb/osd.h
  CC      /kernel/build64/tools/objtool/libctype.o
  HDRINST usr/include/linux/dvb/dmx.h
  CC      /kernel/build64/tools/objtool/str_error_r.o
  HDRINST usr/include/linux/dvb/net.h
  CC      /kernel/build64/tools/objtool/librbtree.o
  HDRINST usr/include/linux/dvb/frontend.h
  HDRINST usr/include/linux/dvb/ca.h
  HDRINST usr/include/linux/dvb/version.h
  HDRINST usr/include/linux/dvb/video.h
  HDRINST usr/include/linux/dvb/audio.h
  HDRINST usr/include/linux/nfs.h
  HDRINST usr/include/linux/if_link.h
  HDRINST usr/include/linux/wait.h
  HDRINST usr/include/linux/icmpv6.h
  HDRINST usr/include/linux/media.h
  HDRINST usr/include/linux/seg6_local.h
  HDRINST usr/include/linux/openvswitch.h
  HDRINST usr/include/linux/atmsap.h
  HDRINST usr/include/linux/bpfilter.h
  HDRINST usr/include/linux/fpga-dfl.h
  HDRINST usr/include/linux/userio.h
  HDRINST usr/include/linux/signal.h
  HDRINST usr/include/linux/map_to_14segment.h
  HDRINST usr/include/linux/hdreg.h
  HDRINST usr/include/linux/utime.h
  HDRINST usr/include/linux/usbdevice_fs.h
  HDRINST usr/include/linux/timex.h
  HDRINST usr/include/linux/if_fc.h
  HDRINST usr/include/linux/reiserfs_xattr.h
  HDRINST usr/include/linux/hw_breakpoint.h
  HDRINST usr/include/linux/quota.h
  HDRINST usr/include/linux/ioprio.h
  HDRINST usr/include/linux/eventpoll.h
  HDRINST usr/include/linux/atmclip.h
  HDRINST usr/include/linux/can.h
  HDRINST usr/include/linux/if_team.h
  HDRINST usr/include/linux/usbip.h
  HDRINST usr/include/linux/stat.h
  HDRINST usr/include/linux/fou.h
  HDRINST usr/include/linux/hash_info.h
  HDRINST usr/include/linux/ppp-comp.h
  HDRINST usr/include/linux/ip6_tunnel.h
  HDRINST usr/include/linux/tipc_netlink.h
  HDRINST usr/include/linux/in.h
  HDRINST usr/include/linux/wireguard.h
  HDRINST usr/include/linux/btf.h
  HDRINST usr/include/linux/batman_adv.h
  HDRINST usr/include/linux/fcntl.h
  HDRINST usr/include/linux/if_ltalk.h
  HDRINST usr/include/linux/i2c.h
  HDRINST usr/include/linux/atm_idt77105.h
  HDRINST usr/include/linux/kexec.h
  HDRINST usr/include/linux/arm_sdei.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6_tables.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6t_ah.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6t_NPT.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6t_rt.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6t_REJECT.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6t_opts.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6t_srh.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6t_LOG.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6t_mh.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6t_HL.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6t_hl.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6t_frag.h
  HDRINST usr/include/linux/netfilter_ipv6/ip6t_ipv6header.h
  HDRINST usr/include/linux/minix_fs.h
  HDRINST usr/include/linux/aio_abi.h
  HDRINST usr/include/linux/pktcdvd.h
  HDRINST usr/include/linux/libc-compat.h
  HDRINST usr/include/linux/atmlec.h
  HDRINST usr/include/linux/signalfd.h
  HDRINST usr/include/linux/bpf_common.h
  HDRINST usr/include/linux/seg6_iptunnel.h
  HDRINST usr/include/linux/synclink.h
  HDRINST usr/include/linux/mpls_iptunnel.h
  CC      /kernel/build64/tools/objtool/arch/x86/decode.o
  HDRINST usr/include/linux/mctp.h
  HDRINST usr/include/linux/if_xdp.h
  HDRINST usr/include/linux/llc.h
  HDRINST usr/include/linux/atmsvc.h
  HDRINST usr/include/linux/sed-opal.h
  HDRINST usr/include/linux/sock_diag.h
  HDRINST usr/include/linux/time.h
  HDRINST usr/include/linux/securebits.h
  HDRINST usr/include/linux/fsl_hypervisor.h
  HDRINST usr/include/linux/if_hippi.h
  HDRINST usr/include/linux/dlm_netlink.h
  HDRINST usr/include/linux/seccomp.h
  HDRINST usr/include/linux/oom.h
  HDRINST usr/include/linux/filter.h
  HDRINST usr/include/linux/inotify.h
  HDRINST usr/include/linux/rfkill.h
  HDRINST usr/include/linux/reboot.h
  HDRINST usr/include/linux/can/vxcan.h
  HDRINST usr/include/linux/can/j1939.h
  HDRINST usr/include/linux/can/netlink.h
  HDRINST usr/include/linux/can/bcm.h
  HDRINST usr/include/linux/can/raw.h
  HDRINST usr/include/linux/can/gw.h
  HDRINST usr/include/linux/can/error.h
  HDRINST usr/include/linux/can/isotp.h
  HDRINST usr/include/linux/if_eql.h
  HDRINST usr/include/linux/hiddev.h
  HDRINST usr/include/linux/blktrace_api.h
  HDRINST usr/include/linux/ccs.h
  HDRINST usr/include/linux/ioam6.h
  HDRINST usr/include/linux/hsr_netlink.h
  HDRINST usr/include/linux/mmc/ioctl.h
  HDRINST usr/include/linux/bfs_fs.h
  HDRINST usr/include/linux/rio_cm_cdev.h
  HDRINST usr/include/linux/uleds.h
  HDRINST usr/include/linux/mrp_bridge.h
  HDRINST usr/include/linux/adb.h
  HDRINST usr/include/linux/pmu.h
  HDRINST usr/include/linux/udmabuf.h
  HDRINST usr/include/linux/kcmp.h
  HDRINST usr/include/linux/dma-heap.h
  HDRINST usr/include/linux/userfaultfd.h
  HDRINST usr/include/linux/netfilter_arp/arpt_mangle.h
  HDRINST usr/include/linux/netfilter_arp/arp_tables.h
  HDRINST usr/include/linux/tipc.h
  HDRINST usr/include/linux/virtio_ids.h
  HDRINST usr/include/linux/l2tp.h
  HDRINST usr/include/linux/devlink.h
  HDRINST usr/include/linux/virtio_gpio.h
  HDRINST usr/include/linux/dcbnl.h
  HDRINST usr/include/linux/cyclades.h
  HDRINST usr/include/sound/intel/avs/tokens.h
  HDRINST usr/include/sound/sof/fw.h
  HDRINST usr/include/sound/sof/abi.h
  HDRINST usr/include/sound/sof/tokens.h
  HDRINST usr/include/sound/sof/header.h
  HDRINST usr/include/sound/usb_stream.h
  HDRINST usr/include/sound/sfnt_info.h
  HDRINST usr/include/sound/asequencer.h
  HDRINST usr/include/sound/tlv.h
  HDRINST usr/include/sound/asound.h
  HDRINST usr/include/sound/asoc.h
  HDRINST usr/include/sound/sb16_csp.h
  HDRINST usr/include/sound/compress_offload.h
  HDRINST usr/include/sound/hdsp.h
  HDRINST usr/include/sound/emu10k1.h
  HDRINST usr/include/sound/snd_ar_tokens.h
  HDRINST usr/include/sound/snd_sst_tokens.h
  HDRINST usr/include/sound/asound_fm.h
  HDRINST usr/include/sound/hdspm.h
  HDRINST usr/include/sound/compress_params.h
  HDRINST usr/include/sound/firewire.h
  HDRINST usr/include/sound/skl-tplg-interface.h
  HDRINST usr/include/scsi/scsi_bsg_ufs.h
  HDRINST usr/include/scsi/scsi_netlink_fc.h
  HDRINST usr/include/scsi/scsi_bsg_mpi3mr.h
  HDRINST usr/include/scsi/fc/fc_ns.h
  HDRINST usr/include/scsi/fc/fc_fs.h
  HDRINST usr/include/scsi/fc/fc_els.h
  HDRINST usr/include/scsi/fc/fc_gs.h
  HDRINST usr/include/scsi/scsi_bsg_fc.h
  HDRINST usr/include/scsi/cxlflash_ioctl.h
  HDRINST usr/include/scsi/scsi_netlink.h
  HDRINST usr/include/linux/version.h
  HDRINST usr/include/asm/processor-flags.h
  HDRINST usr/include/asm/auxvec.h
  HDRINST usr/include/asm/svm.h
  HDRINST usr/include/asm/bitsperlong.h
  HDRINST usr/include/asm/kvm_perf.h
  HDRINST usr/include/asm/mce.h
  HDRINST usr/include/asm/posix_types.h
  HDRINST usr/include/asm/msr.h
  HDRINST usr/include/asm/sigcontext32.h
  HDRINST usr/include/asm/mman.h
  HDRINST usr/include/asm/shmbuf.h
  HDRINST usr/include/asm/e820.h
  HDRINST usr/include/asm/posix_types_64.h
  HDRINST usr/include/asm/swab.h
  HDRINST usr/include/asm/msgbuf.h
  HDRINST usr/include/asm/vsyscall.h
  HDRINST usr/include/asm/statfs.h
  HDRINST usr/include/asm/posix_types_x32.h
  HDRINST usr/include/asm/ptrace.h
  HDRINST usr/include/asm/unistd.h
  HDRINST usr/include/asm/ist.h
  HDRINST usr/include/asm/prctl.h
  HDRINST usr/include/asm/boot.h
  HDRINST usr/include/asm/sigcontext.h
  HDRINST usr/include/asm/posix_types_32.h
  HDRINST usr/include/asm/kvm_para.h
  HDRINST usr/include/asm/a.out.h
  HDRINST usr/include/asm/mtrr.h
  HDRINST usr/include/asm/amd_hsmp.h
  HDRINST usr/include/asm/hwcap2.h
  HDRINST usr/include/asm/ptrace-abi.h
  HDRINST usr/include/asm/vm86.h
  HDRINST usr/include/asm/vmx.h
  HDRINST usr/include/asm/ldt.h
  HDRINST usr/include/asm/perf_regs.h
  HDRINST usr/include/asm/kvm.h
  HDRINST usr/include/asm/debugreg.h
  HDRINST usr/include/asm/signal.h
  HDRINST usr/include/asm/bootparam.h
  HDRINST usr/include/asm/siginfo.h
  HDRINST usr/include/asm/hw_breakpoint.h
  HDRINST usr/include/asm/stat.h
  HDRINST usr/include/asm/setup.h
  HDRINST usr/include/asm/sembuf.h
  HDRINST usr/include/asm/sgx.h
  HDRINST usr/include/asm/ucontext.h
  HDRINST usr/include/asm/byteorder.h
  HDRINST usr/include/asm/unistd_64.h
  HDRINST usr/include/asm/ioctls.h
  HDRINST usr/include/asm/bpf_perf_event.h
  HDRINST usr/include/asm/types.h
  HDRINST usr/include/asm/poll.h
  HDRINST usr/include/asm/resource.h
  HDRINST usr/include/asm/param.h
  HDRINST usr/include/asm/sockios.h
  HDRINST usr/include/asm/errno.h
  HDRINST usr/include/asm/unistd_x32.h
  HDRINST usr/include/asm/termios.h
  HDRINST usr/include/asm/ioctl.h
  HDRINST usr/include/asm/socket.h
  HDRINST usr/include/asm/unistd_32.h
  HDRINST usr/include/asm/termbits.h
  HDRINST usr/include/asm/fcntl.h
  HDRINST usr/include/asm/ipcbuf.h
  HOSTLD  scripts/mod/modpost
  CC      kernel/bounds.s
  CHKSHA1 ../include/linux/atomic/atomic-arch-fallback.h
  CHKSHA1 ../include/linux/atomic/atomic-instrumented.h
  CHKSHA1 ../include/linux/atomic/atomic-long.h
  UPD     include/generated/timeconst.h
  UPD     include/generated/bounds.h
  CC      arch/x86/kernel/asm-offsets.s
  LD      /kernel/build64/tools/objtool/arch/x86/objtool-in.o
  UPD     include/generated/asm-offsets.h
  CALL    ../scripts/checksyscalls.sh
  LD      /kernel/build64/tools/objtool/objtool-in.o
  LINK    /kernel/build64/tools/objtool/objtool
  LDS     scripts/module.lds
  HOSTCC  usr/gen_init_cpio
  CC      ipc/compat.o
  CC      ipc/util.o
  CC      ipc/msgutil.o
  CC      ipc/msg.o
  CC      ipc/sem.o
  AR      certs/built-in.a
  CC      ipc/shm.o
  CC      ipc/syscall.o
  CC      ipc/ipc_sysctl.o
  CC      init/main.o
  CC      security/commoncap.o
  CC      init/do_mounts.o
  CC      io_uring/io_uring.o
  AR      arch/x86/video/built-in.a
  CC      ipc/mqueue.o
  AS      arch/x86/lib/clear_page_64.o
  CC      security/min_addr.o
  CC      io_uring/xattr.o
  CC      arch/x86/power/cpu.o
  CC      mm/filemap.o
  CC [M]  arch/x86/video/fbdev.o
  CC      arch/x86/pci/i386.o
  UPD     init/utsversion-tmp.h
  CC      security/keys/gc.o
  CC      net/ethernet/eth.o
  CC      net/802/p8022.o
  CC      arch/x86/pci/init.o
  CC      arch/x86/realmode/init.o
  AR      arch/x86/ia32/built-in.a
  CC      net/llc/llc_core.o
  CC      net/sched/sch_generic.o
  AS      arch/x86/crypto/aesni-intel_asm.o
  CC      arch/x86/pci/mmconfig_64.o
  AR      virt/lib/built-in.a
  CC      block/partitions/core.o
  CC      net/netlink/af_netlink.o
  AR      drivers/irqchip/built-in.a
  CC      net/core/sock.o
  CC      block/partitions/ldm.o
  CC      arch/x86/events/amd/core.o
  AR      arch/x86/platform/atom/built-in.a
  CC      fs/notify/dnotify/dnotify.o
  CC      sound/core/seq/seq.o
  CC [M]  virt/lib/irqbypass.o
  CC      arch/x86/kernel/fpu/init.o
  CC      arch/x86/mm/pat/set_memory.o
  AR      sound/i2c/other/built-in.a
  AR      drivers/bus/mhi/built-in.a
  CC      lib/kunit/test.o
  AR      sound/i2c/built-in.a
  AR      arch/x86/platform/ce4100/built-in.a
  AR      drivers/bus/built-in.a
  CC      arch/x86/lib/cmdline.o
  CC      arch/x86/entry/vdso/vma.o
  CC      sound/core/seq/seq_lock.o
  CC      arch/x86/platform/efi/memmap.o
  CC      mm/kasan/common.o
  AR      drivers/phy/allwinner/built-in.a
  CC      arch/x86/crypto/aesni-intel_glue.o
  CC      crypto/api.o
  CC      kernel/sched/core.o
  AR      drivers/phy/amlogic/built-in.a
  AR      drivers/phy/broadcom/built-in.a
  AR      drivers/phy/cadence/built-in.a
  AR      drivers/phy/freescale/built-in.a
  AR      drivers/phy/hisilicon/built-in.a
  AR      drivers/phy/ingenic/built-in.a
  AR      drivers/phy/intel/built-in.a
  AR      drivers/phy/lantiq/built-in.a
  AS      arch/x86/lib/cmpxchg16b_emu.o
  AR      drivers/phy/marvell/built-in.a
  AR      drivers/phy/mediatek/built-in.a
  CC      arch/x86/lib/copy_mc.o
  AR      drivers/phy/microchip/built-in.a
  AR      drivers/phy/motorola/built-in.a
  AR      drivers/phy/mscc/built-in.a
  AR      drivers/phy/qualcomm/built-in.a
  AR      drivers/phy/ralink/built-in.a
  AR      drivers/phy/renesas/built-in.a
  AR      drivers/phy/rockchip/built-in.a
  AR      drivers/phy/samsung/built-in.a
  GEN     usr/initramfs_data.cpio
  COPY    usr/initramfs_inc_data
  AS      usr/initramfs_data.o
  AR      drivers/phy/socionext/built-in.a
  AR      drivers/phy/st/built-in.a
  AR      drivers/phy/sunplus/built-in.a
  AR      usr/built-in.a
  AR      drivers/phy/tegra/built-in.a
  AR      drivers/phy/ti/built-in.a
  CC      security/inode.o
  AR      drivers/phy/xilinx/built-in.a
  CC      drivers/phy/phy-core.o
  CC      security/keys/key.o
  AR      virt/built-in.a
  AS      arch/x86/lib/copy_mc_64.o
  CC      arch/x86/mm/pat/memtype.o
  CC      arch/x86/events/amd/lbr.o
  AS      arch/x86/lib/copy_page_64.o
  CC      sound/core/seq/seq_clientmgr.o
  AS      arch/x86/realmode/rm/header.o
  CC      ipc/namespace.o
  AS      arch/x86/lib/copy_user_64.o
  CC      ipc/mq_sysctl.o
  CC      arch/x86/kernel/fpu/bugs.o
  AS      arch/x86/realmode/rm/trampoline_64.o
  CC      arch/x86/lib/cpu.o
  CC      arch/x86/entry/vdso/extable.o
  AS      arch/x86/realmode/rm/stack.o
  CC      io_uring/nop.o
  CC      io_uring/fs.o
  CC      arch/x86/entry/vdso/vdso32-setup.o
  AS      arch/x86/realmode/rm/reboot.o
  AR      fs/notify/dnotify/built-in.a
  CC      fs/notify/inotify/inotify_fsnotify.o
  LDS     arch/x86/entry/vdso/vdso.lds
  AS      arch/x86/realmode/rm/wakeup_asm.o
  CC      arch/x86/platform/efi/quirks.o
  CC      arch/x86/pci/direct.o
  CC      arch/x86/realmode/rm/wakemain.o
  CC      arch/x86/mm/init.o
  CC      net/802/psnap.o
  CC      arch/x86/kernel/fpu/core.o
  CC      lib/kunit/resource.o
  CC      block/partitions/msdos.o
  CC      fs/notify/inotify/inotify_user.o
  CC      net/llc/llc_input.o
  CC      crypto/cipher.o
  CC      arch/x86/realmode/rm/video-mode.o
  CC      arch/x86/power/hibernate_64.o
  CC      lib/kunit/static_stub.o
  CC      arch/x86/platform/efi/efi.o
  CC      sound/core/seq/seq_memory.o
  CC      mm/kasan/report.o
  AS      arch/x86/realmode/rm/copy.o
  AS      arch/x86/realmode/rm/bioscall.o
  CC      fs/nfs_common/grace.o
  CC      arch/x86/lib/delay.o
  CC      arch/x86/realmode/rm/regs.o
  CC      security/keys/keyring.o
  CC      arch/x86/realmode/rm/video-vga.o
  AS      arch/x86/crypto/aesni-intel_avx-x86_64.o
  CC      security/keys/keyctl.o
  CC      arch/x86/kernel/fpu/regset.o
  CC      arch/x86/kernel/fpu/signal.o
  CC      arch/x86/realmode/rm/video-vesa.o
  CC      net/sched/sch_mq.o
  CC      net/sched/sch_frag.o
  CC      init/do_mounts_initrd.o
  CC      init/initramfs.o
  CC      mm/kasan/init.o
  AR      net/ethernet/built-in.a
  CC      init/calibrate.o
  CC      arch/x86/events/intel/core.o
  CC      arch/x86/realmode/rm/video-bios.o
  AS      arch/x86/entry/vdso/vdso-note.o
  CC      crypto/compress.o
  CC      arch/x86/events/amd/ibs.o
  CC      arch/x86/entry/vdso/vclock_gettime.o
  AS      arch/x86/lib/getuser.o
  PASYMS  arch/x86/realmode/rm/pasyms.h
  LDS     arch/x86/realmode/rm/realmode.lds
  GEN     arch/x86/lib/inat-tables.c
  AR      drivers/phy/built-in.a
  LD      arch/x86/realmode/rm/realmode.elf
  AS      arch/x86/crypto/aes_ctrby8_avx-x86_64.o
  RELOCS  arch/x86/realmode/rm/realmode.relocs
  OBJCOPY arch/x86/realmode/rm/realmode.bin
  AS      arch/x86/realmode/rmpiggy.o
  CC      lib/kunit/string-stream.o
  CC      crypto/algapi.o
  AR      drivers/pinctrl/actions/built-in.a
  CC      arch/x86/events/amd/uncore.o
  AR      drivers/pinctrl/bcm/built-in.a
  CC      io_uring/splice.o
  CC      arch/x86/lib/insn-eval.o
  AR      arch/x86/realmode/built-in.a
  AR      drivers/pinctrl/cirrus/built-in.a
  CC      arch/x86/pci/mmconfig-shared.o
  AR      net/bpf/built-in.a
  CC      arch/x86/pci/fixup.o
  AR      drivers/pinctrl/freescale/built-in.a
  CC      drivers/pinctrl/intel/pinctrl-baytrail.o
  AS [M]  arch/x86/crypto/ghash-clmulni-intel_asm.o
  AR      drivers/pinctrl/mediatek/built-in.a
  CC      init/init_task.o
  CC      arch/x86/lib/insn.o
  CC      drivers/pinctrl/intel/pinctrl-intel.o
  CC [M]  arch/x86/crypto/ghash-clmulni-intel_glue.o
  AS      arch/x86/power/hibernate_asm_64.o
  CC      net/802/stp.o
  CC      arch/x86/power/hibernate.o
  CC      block/partitions/efi.o
  CC      arch/x86/platform/efi/efi_64.o
  CC      security/device_cgroup.o
  CC      arch/x86/mm/pat/memtype_interval.o
  CC      net/llc/llc_output.o
  AR      fs/nfs_common/built-in.a
  CC      arch/x86/events/zhaoxin/core.o
  CC      arch/x86/events/core.o
  CC      sound/core/seq/seq_queue.o
  CC      arch/x86/kernel/fpu/xstate.o
  CC      net/sched/sch_api.o
  AR      fs/notify/inotify/built-in.a
  CC      fs/notify/fanotify/fanotify.o
  AS      arch/x86/platform/efi/efi_stub_64.o
  CC      fs/iomap/trace.o
  CC      arch/x86/entry/vdso/vgetcpu.o
  CC      sound/core/seq/seq_fifo.o
  CC      fs/iomap/iter.o
  CC      lib/kunit/assert.o
  CC      fs/iomap/buffered-io.o
  CC      fs/notify/fanotify/fanotify_user.o
  HOSTCC  arch/x86/entry/vdso/vdso2c
  CC      arch/x86/mm/init_64.o
  CC      arch/x86/events/probe.o
  CC      block/bdev.o
  AS [M]  arch/x86/crypto/crc32-pclmul_asm.o
  CC [M]  arch/x86/crypto/crc32-pclmul_glue.o
  CC      mm/kasan/generic.o
  CC      arch/x86/events/intel/bts.o
  AR      ipc/built-in.a
  CC      crypto/scatterwalk.o
  CC      init/version.o
  CC      lib/kunit/try-catch.o
  CC      net/sched/sch_blackhole.o
  LDS     arch/x86/entry/vdso/vdso32/vdso32.lds
  CC      arch/x86/mm/fault.o
  CC      net/sched/sch_fifo.o
  AR      arch/x86/mm/pat/built-in.a
  CC      arch/x86/mm/ioremap.o
  AS      arch/x86/entry/vdso/vdso32/note.o
  CC      block/fops.o
  AR      arch/x86/power/built-in.a
  AS      arch/x86/entry/vdso/vdso32/system_call.o
  CC      crypto/proc.o
  AS      arch/x86/lib/memcpy_64.o
  AS      arch/x86/lib/memmove_64.o
  AS      arch/x86/lib/memset_64.o
  AS      arch/x86/entry/vdso/vdso32/sigreturn.o
  CC      io_uring/sync.o
  CC      arch/x86/lib/misc.o
  CC      security/keys/permission.o
  CC      arch/x86/pci/acpi.o
  CC      arch/x86/entry/vdso/vdso32/vclock_gettime.o
  CC      arch/x86/pci/legacy.o
  AR      net/802/built-in.a
  CC      fs/notify/fsnotify.o
  AR      net/llc/built-in.a
  CC      arch/x86/lib/pc-conf-reg.o
  AR      arch/x86/events/amd/built-in.a
  CC      arch/x86/events/utils.o
  AS [M]  arch/x86/crypto/crct10dif-pcl-asm_64.o
  AS      arch/x86/lib/putuser.o
  CC      block/bio.o
  CC      sound/core/seq/seq_prioq.o
  AR      init/built-in.a
  AR      arch/x86/platform/efi/built-in.a
  CC      security/keys/process_keys.o
  AS      arch/x86/lib/retpoline.o
  AR      arch/x86/platform/geode/built-in.a
  AR      arch/x86/platform/iris/built-in.a
  CC      io_uring/advise.o
  CC      arch/x86/platform/intel/iosf_mbi.o
  CC      io_uring/filetable.o
  AR      block/partitions/built-in.a
  CC      arch/x86/lib/usercopy.o
  CC      arch/x86/pci/irq.o
  AR      arch/x86/events/zhaoxin/built-in.a
  CC [M]  arch/x86/crypto/crct10dif-pclmul_glue.o
  CC      lib/math/div64.o
  CC      crypto/aead.o
  CC      arch/x86/lib/usercopy_64.o
  CC      io_uring/openclose.o
  CC      lib/math/gcd.o
  CC      lib/kunit/executor.o
  AR      sound/drivers/opl3/built-in.a
  AR      sound/drivers/opl4/built-in.a
  AR      sound/drivers/mpu401/built-in.a
  AR      sound/drivers/vx/built-in.a
  CC      lib/math/lcm.o
  AR      sound/drivers/pcsp/built-in.a
  AR      sound/drivers/built-in.a
  CC      net/core/request_sock.o
  CC      lib/math/int_pow.o
  CC      net/core/skbuff.o
  CC [M]  drivers/pinctrl/intel/pinctrl-cherryview.o
  CC      arch/x86/kernel/cpu/mce/core.o
  CC      lib/math/int_sqrt.o
  CC [M]  drivers/pinctrl/intel/pinctrl-broxton.o
  CC      block/elevator.o
  AR      drivers/pinctrl/mvebu/built-in.a
  CC      arch/x86/kernel/cpu/mce/severity.o
  CC      lib/math/reciprocal_div.o
  CC      sound/core/seq/seq_timer.o
  CC      net/netlink/genetlink.o
  CC      mm/kasan/report_generic.o
  CC      lib/math/rational.o
  CC      arch/x86/events/intel/ds.o
  CC      arch/x86/pci/common.o
  LD [M]  arch/x86/crypto/ghash-clmulni-intel.o
  CC [M]  lib/math/prime_numbers.o
  CC      arch/x86/entry/vdso/vdso32/vgetcpu.o
  LD [M]  arch/x86/crypto/crc32-pclmul.o
  LD [M]  arch/x86/crypto/crct10dif-pclmul.o
  AR      arch/x86/kernel/fpu/built-in.a
  CC      mm/kasan/shadow.o
  CC      fs/notify/notification.o
  AR      arch/x86/crypto/built-in.a
  AR      fs/quota/built-in.a
  CC      mm/kasan/quarantine.o
  CC      arch/x86/events/rapl.o
  CC      security/keys/request_key.o
  VDSO    arch/x86/entry/vdso/vdso64.so.dbg
  AR      drivers/pinctrl/nomadik/built-in.a
  CC      arch/x86/mm/extable.o
  AR      drivers/pinctrl/nuvoton/built-in.a
  CC      arch/x86/kernel/cpu/mtrr/mtrr.o
  CC      fs/notify/group.o
  VDSO    arch/x86/entry/vdso/vdso32.so.dbg
  CC      lib/kunit/hooks.o
  OBJCOPY arch/x86/entry/vdso/vdso64.so
  CC      arch/x86/lib/msr-smp.o
  OBJCOPY arch/x86/entry/vdso/vdso32.so
  VDSO2C  arch/x86/entry/vdso/vdso-image-64.c
  VDSO2C  arch/x86/entry/vdso/vdso-image-32.c
  CC      arch/x86/entry/vdso/vdso-image-64.o
  CC      arch/x86/entry/vdso/vdso-image-32.o
  CC      io_uring/uring_cmd.o
  AR      arch/x86/platform/intel/built-in.a
  AR      arch/x86/platform/intel-mid/built-in.a
  CC      fs/proc/task_mmu.o
  AR      arch/x86/platform/intel-quark/built-in.a
  AR      arch/x86/platform/olpc/built-in.a
  AR      arch/x86/platform/scx200/built-in.a
  AR      arch/x86/platform/ts5500/built-in.a
  CC      arch/x86/kernel/acpi/boot.o
  AR      arch/x86/platform/uv/built-in.a
  CC      fs/proc/inode.o
  AR      arch/x86/platform/built-in.a
  CC      crypto/geniv.o
  AR      fs/notify/fanotify/built-in.a
  CC      kernel/sched/fair.o
  CC      crypto/skcipher.o
  CC      crypto/seqiv.o
  CC      arch/x86/kernel/acpi/sleep.o
  CC      net/ethtool/ioctl.o
  CC      net/netlink/policy.o
  AR      lib/kunit/built-in.a
  AR      arch/x86/entry/vdso/built-in.a
  CC      net/ethtool/common.o
  CC      net/netlink/diag.o
  CC      arch/x86/entry/vsyscall/vsyscall_64.o
  CC      arch/x86/kernel/cpu/mce/genpool.o
  CC      arch/x86/lib/cache-smp.o
  CC      net/ethtool/netlink.o
  AR      arch/x86/net/built-in.a
  CC      arch/x86/kernel/apic/apic.o
  CC      mm/mempool.o
  CC      io_uring/epoll.o
  AR      lib/math/built-in.a
  CC      arch/x86/kernel/apic/apic_common.o
  CC      lib/crypto/memneq.o
  CC      arch/x86/lib/msr.o
  CC      sound/core/seq/seq_system.o
  CC      arch/x86/kernel/cpu/mce/intel.o
  CC      io_uring/statx.o
  CC      io_uring/net.o
  CC      mm/oom_kill.o
  CC      lib/crypto/utils.o
  CC      arch/x86/kernel/cpu/mce/threshold.o
  CC      arch/x86/pci/early.o
  AR      mm/kasan/built-in.a
  CC      fs/proc/root.o
  CC      fs/iomap/direct-io.o
  CC      fs/notify/mark.o
  AR      net/sched/built-in.a
  CC [M]  net/netfilter/ipvs/ip_vs_conn.o
  CC      arch/x86/mm/mmap.o
  CC      arch/x86/pci/bus_numa.o
  CC      arch/x86/kernel/cpu/mce/apei.o
  CC [M]  drivers/pinctrl/intel/pinctrl-geminilake.o
  CC      security/keys/request_key_auth.o
  CC      arch/x86/kernel/cpu/mtrr/if.o
  CC      arch/x86/kernel/cpu/mtrr/generic.o
  CC      fs/proc/base.o
  CC      fs/notify/fdinfo.o
  CC      arch/x86/pci/amd_bus.o
  CC      block/blk-core.o
  CC      lib/crypto/chacha.o
  CC      arch/x86/kernel/cpu/mtrr/cleanup.o
  AS      arch/x86/kernel/acpi/wakeup_64.o
  CC      net/ethtool/bitset.o
  CC      arch/x86/events/intel/knc.o
  CC      arch/x86/kernel/apic/apic_noop.o
  CC      sound/core/seq/seq_ports.o
  CC      arch/x86/kernel/apic/ipi.o
  CC      security/keys/user_defined.o
  CC      lib/crypto/aes.o
  AS      arch/x86/entry/vsyscall/vsyscall_emu_64.o
  AR      arch/x86/entry/vsyscall/built-in.a
  CC      lib/crypto/gf128mul.o
  AS      arch/x86/entry/entry.o
  CC      security/keys/compat.o
  AS      arch/x86/entry/entry_64.o
  CC      security/keys/proc.o
  CC      security/keys/sysctl.o
  CC      io_uring/msg_ring.o
  CC      net/netfilter/core.o
  CC      arch/x86/entry/syscall_64.o
  CC      arch/x86/kernel/kprobes/core.o
  CC      arch/x86/kernel/acpi/apei.o
  AS      arch/x86/lib/msr-reg.o
  CC      arch/x86/lib/msr-reg-export.o
  CC      sound/core/seq/seq_info.o
  CC      arch/x86/events/intel/lbr.o
  CC [M]  drivers/pinctrl/intel/pinctrl-sunrisepoint.o
  CC      arch/x86/mm/pgtable.o
  CC      arch/x86/kernel/acpi/cppc.o
  CC      fs/iomap/fiemap.o
  CC      fs/iomap/seek.o
  AR      arch/x86/kernel/cpu/mce/built-in.a
  CC      crypto/echainiv.o
  CC      arch/x86/kernel/apic/vector.o
  AS      arch/x86/lib/hweight.o
  AR      net/netlink/built-in.a
  CC      arch/x86/kernel/cpu/cacheinfo.o
  CC      crypto/ahash.o
  CC      arch/x86/lib/iomem.o
  CC      arch/x86/kernel/apic/hw_nmi.o
  CC      arch/x86/kernel/apic/io_apic.o
  CC      sound/core/sound.o
  AR      sound/isa/ad1816a/built-in.a
  AR      sound/isa/ad1848/built-in.a
  CC      net/netfilter/nf_log.o
  AR      sound/isa/cs423x/built-in.a
  AR      sound/isa/es1688/built-in.a
  AR      sound/isa/galaxy/built-in.a
  AR      sound/isa/gus/built-in.a
  AR      arch/x86/pci/built-in.a
  AR      sound/isa/msnd/built-in.a
  AR      sound/isa/opti9xx/built-in.a
  CC      net/netfilter/nf_queue.o
  AR      sound/isa/sb/built-in.a
  CC      arch/x86/events/intel/p4.o
  AR      sound/isa/wavefront/built-in.a
  CC [M]  arch/x86/kvm/../../../virt/kvm/kvm_main.o
  AR      sound/isa/wss/built-in.a
  CC      net/netfilter/nf_sockopt.o
  AR      sound/isa/built-in.a
  AR      fs/notify/built-in.a
  CC      net/netfilter/utils.o
  CC      lib/zlib_inflate/inffast.o
  CC      lib/zlib_inflate/inflate.o
  CC [M]  net/netfilter/nfnetlink.o
  CC      fs/iomap/swapfile.o
  CC      arch/x86/events/intel/p6.o
  CC      fs/kernfs/mount.o
  CC      lib/crypto/blake2s.o
  AS      arch/x86/lib/iomap_copy_64.o
  CC      lib/zlib_inflate/infutil.o
  AR      security/keys/built-in.a
  AR      sound/core/seq/built-in.a
  CC      fs/proc/generic.o
  AR      security/built-in.a
  CC      fs/proc/array.o
  CC      arch/x86/lib/inat.o
  CC      arch/x86/entry/common.o
  CC      sound/core/init.o
  AR      drivers/pinctrl/intel/built-in.a
  CC [M]  net/netfilter/ipvs/ip_vs_core.o
  AR      drivers/pinctrl/sprd/built-in.a
  CC      fs/kernfs/inode.o
  AR      drivers/pinctrl/sunplus/built-in.a
  AR      drivers/pinctrl/ti/built-in.a
  CC      drivers/pinctrl/core.o
  CC      arch/x86/kernel/acpi/cstate.o
  AR      arch/x86/kernel/cpu/mtrr/built-in.a
  CC      lib/zlib_deflate/deflate.o
  AR      arch/x86/lib/built-in.a
  AR      arch/x86/lib/lib.a
  CC      block/blk-sysfs.o
  CC      arch/x86/mm/physaddr.o
  CC      fs/kernfs/dir.o
  CC      crypto/shash.o
  CC      kernel/locking/mutex.o
  CC      kernel/locking/semaphore.o
  CC      arch/x86/kernel/kprobes/opt.o
  CC      lib/lzo/lzo1x_compress.o
  CC      lib/lz4/lz4_compress.o
  CC      lib/zstd/zstd_compress_module.o
  CC      lib/crypto/blake2s-generic.o
  CC      lib/lzo/lzo1x_decompress_safe.o
  CC      lib/crypto/blake2s-selftest.o
  CC      io_uring/timeout.o
  CC      lib/crypto/des.o
  CC      mm/fadvise.o
  CC      arch/x86/events/intel/pt.o
  AR      fs/iomap/built-in.a
  CC      arch/x86/kernel/kprobes/ftrace.o
  CC      lib/zlib_inflate/inftrees.o
  CC      arch/x86/kernel/cpu/scattered.o
  CC      io_uring/sqpoll.o
  CC      kernel/sched/build_policy.o
  AR      arch/x86/kernel/acpi/built-in.a
  CC      kernel/sched/build_utility.o
  CC      fs/kernfs/file.o
  CC      arch/x86/mm/tlb.o
  CC      lib/zlib_inflate/inflate_syms.o
  AS      arch/x86/entry/thunk_64.o
  CC      io_uring/fdinfo.o
  CC      mm/maccess.o
  AS      arch/x86/entry/entry_64_compat.o
  CC      lib/zstd/compress/fse_compress.o
  CC      arch/x86/entry/syscall_32.o
  CC      kernel/locking/rwsem.o
  CC      net/ethtool/strset.o
  CC [M]  net/netfilter/ipvs/ip_vs_ctl.o
  CC      io_uring/tctx.o
  CC      crypto/akcipher.o
  CC      kernel/locking/percpu-rwsem.o
  CC      mm/page-writeback.o
  AR      lib/lzo/built-in.a
  CC      arch/x86/events/intel/uncore.o
  CC      sound/core/memory.o
  CC      kernel/locking/irqflag-debug.o
  CC [M]  net/netfilter/nf_conntrack_core.o
  CC      lib/lz4/lz4hc_compress.o
  AR      lib/zlib_inflate/built-in.a
  CC      arch/x86/kernel/apic/msi.o
  CC [M]  net/netfilter/nf_conntrack_standalone.o
  CC      arch/x86/kernel/cpu/topology.o
  CC      kernel/locking/mutex-debug.o
  CC      lib/zlib_deflate/deftree.o
  CC      sound/core/control.o
  CC      net/core/datagram.o
  CC      arch/x86/kernel/apic/x2apic_phys.o
  CC      fs/sysfs/file.o
  AR      arch/x86/kernel/kprobes/built-in.a
  CC      fs/proc/fd.o
  CC      fs/proc/proc_tty.o
  CC      lib/zstd/compress/hist.o
  CC      lib/zlib_deflate/deflate_syms.o
  CC      mm/folio-compat.o
  CC      block/blk-flush.o
  CC      fs/configfs/inode.o
  CC      fs/devpts/inode.o
  CC      lib/zstd/compress/huf_compress.o
  CC      fs/kernfs/symlink.o
  CC      lib/zstd/compress/zstd_compress.o
  CC      fs/sysfs/dir.o
  CC      drivers/pinctrl/pinctrl-utils.o
  AR      arch/x86/entry/built-in.a
  CC      sound/core/misc.o
  CC      arch/x86/mm/cpu_entry_area.o
  CC      fs/proc/cmdline.o
  CC      net/core/stream.o
  CC      arch/x86/kernel/cpu/common.o
  CC      lib/crypto/sha1.o
  CC [M]  net/netfilter/ipvs/ip_vs_sched.o
  CC      crypto/kpp.o
  CC      io_uring/poll.o
  CC      io_uring/cancel.o
  CC      arch/x86/kernel/cpu/rdrand.o
  CC      crypto/acompress.o
  CC      lib/xz/xz_dec_syms.o
  CC      arch/x86/kernel/apic/x2apic_cluster.o
  AR      lib/zlib_deflate/built-in.a
  CC      kernel/locking/lockdep.o
  CC      kernel/locking/lockdep_proc.o
  CC      lib/crypto/sha256.o
  CC      arch/x86/mm/maccess.o
  CC [M]  net/netfilter/ipvs/ip_vs_xmit.o
  CC      arch/x86/events/intel/uncore_nhmex.o
  CC      drivers/pinctrl/pinmux.o
  CC      net/core/scm.o
  AR      fs/kernfs/built-in.a
  CC      fs/configfs/file.o
  CC      net/ethtool/linkinfo.o
  CC      arch/x86/kernel/apic/apic_flat_64.o
  CC      fs/sysfs/symlink.o
  CC      lib/raid6/algos.o
  CC      fs/proc/consoles.o
  CC      lib/raid6/recov.o
  CC      fs/sysfs/mount.o
  CC      arch/x86/events/msr.o
  CC      lib/fonts/fonts.o
  CC      fs/configfs/dir.o
  CC      lib/xz/xz_dec_stream.o
  CC      block/blk-settings.o
  AR      fs/devpts/built-in.a
  CC      arch/x86/mm/pgprot.o
  CC      lib/fonts/font_8x8.o
  CC      io_uring/kbuf.o
  CC      block/blk-ioc.o
  CC      lib/zstd/compress/zstd_compress_literals.o
  CC      arch/x86/kernel/apic/probe_64.o
  CC      lib/lz4/lz4_decompress.o
  CC      lib/zstd/compress/zstd_compress_sequences.o
  CC      lib/zstd/compress/zstd_compress_superblock.o
  CC      fs/configfs/symlink.o
  CC [M]  lib/crypto/arc4.o
  CC      fs/proc/cpuinfo.o
  CC      lib/fonts/font_8x16.o
  CC      arch/x86/mm/hugetlbpage.o
  CC      crypto/scompress.o
  CC      drivers/pinctrl/pinconf.o
  AR      arch/x86/kernel/apic/built-in.a
  CC      block/blk-map.o
  CC      arch/x86/mm/kasan_init_64.o
  CC      fs/proc/devices.o
  CC      drivers/pinctrl/pinconf-generic.o
  CC      arch/x86/events/intel/uncore_snb.o
  CC      fs/configfs/mount.o
  CC      io_uring/rsrc.o
  CC      arch/x86/mm/pkeys.o
  HOSTCC  lib/raid6/mktables
  UNROLL  lib/raid6/int1.c
  UNROLL  lib/raid6/int2.c
  UNROLL  lib/raid6/int4.c
  CC      drivers/gpio/gpiolib.o
  CC      drivers/gpio/gpiolib-devres.o
  AR      drivers/pwm/built-in.a
  CC      lib/xz/xz_dec_lzma2.o
  CC      kernel/locking/spinlock.o
  CC      fs/proc/interrupts.o
  CC      drivers/pci/msi/pcidev_msi.o
  CC      drivers/pci/pcie/portdrv.o
  CC      crypto/algboss.o
  CC      fs/sysfs/group.o
  CC      drivers/video/console/dummycon.o
  UNROLL  lib/raid6/int8.c
  CC      drivers/video/console/vgacon.o
  UNROLL  lib/raid6/int16.c
  UNROLL  lib/raid6/int32.c
  CC      lib/raid6/recov_ssse3.o
  AR      lib/crypto/built-in.a
  LD [M]  lib/crypto/libarc4.o
  AR      lib/fonts/built-in.a
  CC      lib/zstd/compress/zstd_double_fast.o
  CC      drivers/pci/hotplug/pci_hotplug_core.o
  CC      sound/core/device.o
  CC      net/ethtool/linkmodes.o
  CC      drivers/pci/hotplug/acpi_pcihp.o
  CC      arch/x86/kernel/cpu/match.o
  CC      sound/core/info.o
  LDS     arch/x86/kernel/vmlinux.lds
  AR      drivers/pci/controller/dwc/built-in.a
  CC      drivers/pci/controller/vmd.o
  AR      drivers/pci/controller/mobiveil/built-in.a
  CC      drivers/gpio/gpiolib-legacy.o
  CC      mm/readahead.o
  CC      block/blk-merge.o
  AS      arch/x86/kernel/head_64.o
  CC      net/core/gen_stats.o
  CC [M]  net/netfilter/nf_conntrack_expect.o
  CC      fs/configfs/item.o
  CC      net/ethtool/rss.o
  CC      fs/proc/loadavg.o
  CC      kernel/locking/osq_lock.o
  AR      drivers/pinctrl/built-in.a
  CC      mm/swap.o
  CC      drivers/idle/intel_idle.o
  CC      fs/proc/meminfo.o
  CC      net/core/gen_estimator.o
  CC      kernel/locking/qspinlock.o
  AR      net/ipv4/netfilter/built-in.a
  CC      arch/x86/mm/pti.o
  CC [M]  net/ipv4/netfilter/nf_defrag_ipv4.o
  CC      net/core/net_namespace.o
  CC [M]  net/ipv4/netfilter/nf_reject_ipv4.o
  CC      drivers/pci/msi/api.o
  AR      lib/lz4/built-in.a
  CC      net/ethtool/linkstate.o
  CC      net/ipv4/route.o
  CC      lib/xz/xz_dec_bcj.o
  AR      fs/sysfs/built-in.a
  CC      crypto/testmgr.o
  CC      arch/x86/kernel/cpu/bugs.o
  CC      crypto/cmac.o
  CC      lib/raid6/recov_avx2.o
  CC      lib/raid6/mmx.o
  CC      arch/x86/events/intel/uncore_snbep.o
  CC      mm/truncate.o
  CC      block/blk-timeout.o
  CC      kernel/locking/rtmutex_api.o
  CC      drivers/pci/pcie/rcec.o
  CC      fs/proc/stat.o
  AR      sound/pci/ac97/built-in.a
  AR      sound/ppc/built-in.a
  AR      sound/pci/ali5451/built-in.a
  CC      crypto/hmac.o
  AR      fs/configfs/built-in.a
  AR      sound/pci/asihpi/built-in.a
  CC      kernel/locking/spinlock_debug.o
  AR      sound/pci/au88x0/built-in.a
  CC      lib/argv_split.o
  AR      sound/pci/aw2/built-in.a
  AR      sound/pci/ctxfi/built-in.a
  AR      sound/pci/ca0106/built-in.a
  CC      drivers/pci/hotplug/pciehp_core.o
  AR      sound/pci/cs46xx/built-in.a
  CC [M]  net/netfilter/ipvs/ip_vs_app.o
  CC [M]  net/netfilter/ipvs/ip_vs_sync.o
  AR      sound/pci/cs5535audio/built-in.a
  CC [M]  net/netfilter/ipvs/ip_vs_est.o
  AR      sound/pci/lola/built-in.a
  AR      sound/pci/lx6464es/built-in.a
  CC      net/ethtool/debug.o
  AR      sound/pci/echoaudio/built-in.a
  AR      sound/pci/emu10k1/built-in.a
  AR      sound/pci/hda/built-in.a
  CC [M]  sound/pci/hda/hda_bind.o
  CC      sound/core/isadma.o
  AR      drivers/video/console/built-in.a
  CC      drivers/video/logo/logo.o
  CC [M]  sound/pci/hda/hda_codec.o
  CC      net/ethtool/wol.o
  AR      lib/xz/built-in.a
  CC      kernel/locking/qrwlock.o
  CC      block/blk-lib.o
  CC      drivers/pci/msi/msi.o
  AR      arch/x86/mm/built-in.a
  CC      net/core/secure_seq.o
  CC      net/ethtool/features.o
  CC      io_uring/rw.o
  AR      drivers/pci/controller/built-in.a
  CC      mm/vmscan.o
  CC [M]  net/netfilter/nf_conntrack_helper.o
  CC      crypto/vmac.o
  CC      lib/raid6/sse1.o
  AR      drivers/pci/switch/built-in.a
  CC      drivers/pci/access.o
  CC      lib/raid6/sse2.o
  CC      drivers/pci/bus.o
  HOSTCC  drivers/video/logo/pnmtologo
  CC      drivers/pci/pcie/aspm.o
  CC      fs/proc/uptime.o
  CC      lib/bug.o
  CC [M]  net/netfilter/ipvs/ip_vs_proto.o
  CC      sound/core/vmaster.o
  CC      lib/raid6/avx2.o
  CC      net/core/flow_dissector.o
  AR      drivers/idle/built-in.a
  CC      arch/x86/kernel/cpu/aperfmperf.o
  CC      arch/x86/kernel/cpu/cpuid-deps.o
  LOGO    drivers/video/logo/logo_linux_clut224.c
  CC      drivers/pci/hotplug/pciehp_ctrl.o
  CC      lib/buildid.o
  CC      drivers/video/logo/logo_linux_clut224.o
  CC      kernel/power/qos.o
  CC      lib/cmdline.o
  AR      drivers/video/logo/built-in.a
  CC      kernel/power/main.o
  CC      drivers/video/backlight/backlight.o
  CC [M]  arch/x86/kvm/../../../virt/kvm/eventfd.o
  CC [M]  net/ipv4/netfilter/ip_tables.o
  CC      drivers/video/aperture.o
  CC      drivers/video/fbdev/core/fb_notify.o
  CC      drivers/video/cmdline.o
  CC [M]  net/netfilter/nf_conntrack_proto.o
  CC      net/ethtool/privflags.o
  CC      fs/proc/util.o
  CC      block/blk-mq.o
  CC      kernel/printk/printk.o
  CC      net/core/sysctl_net_core.o
  CC      net/core/dev.o
  CC      net/ethtool/rings.o
  CC      block/blk-mq-tag.o
  CC [M]  net/netfilter/ipvs/ip_vs_pe.o
  CC      kernel/power/console.o
  CC      arch/x86/kernel/cpu/umwait.o
  CC      sound/core/ctljack.o
  CC      sound/core/jack.o
  CC      drivers/pci/msi/irqdomain.o
  AR      drivers/video/fbdev/omap/built-in.a
  CC      net/ethtool/channels.o
  CC [M]  drivers/video/fbdev/core/fbmem.o
  CC      lib/raid6/avx512.o
  CC [M]  net/ipv4/netfilter/iptable_filter.o
  CC      drivers/pci/pcie/aer.o
  CC      block/blk-stat.o
  CC      net/ethtool/coalesce.o
  CC      fs/proc/version.o
  CC      drivers/pci/hotplug/pciehp_pci.o
  CC      fs/proc/softirqs.o
  CC [M]  drivers/video/fbdev/core/fbmon.o
  CC      sound/core/timer.o
  CC      net/core/dev_addr_lists.o
  CC      net/core/dst.o
  CC [M]  drivers/video/fbdev/core/fbcmap.o
  CC      drivers/gpio/gpiolib-cdev.o
  CC [M]  net/ipv4/netfilter/iptable_mangle.o
  AR      drivers/video/backlight/built-in.a
  CC      lib/cpumask.o
  CC [M]  net/netfilter/ipvs/ip_vs_proto_tcp.o
  CC [M]  net/netfilter/nf_conntrack_proto_generic.o
  CC      sound/core/hrtimer.o
  CC [M]  drivers/video/fbdev/core/fbsysfs.o
  CC      block/blk-mq-sysfs.o
  CC      kernel/power/process.o
  CC      arch/x86/kernel/cpu/proc.o
  CC      io_uring/opdef.o
  MKCAP   arch/x86/kernel/cpu/capflags.c
  AR      kernel/locking/built-in.a
  CC      net/ethtool/pause.o
  CC      block/blk-mq-cpumap.o
  CC      arch/x86/events/intel/uncore_discovery.o
  CC      lib/raid6/recov_avx512.o
  CC [M]  net/ipv4/netfilter/iptable_nat.o
  AR      drivers/pci/msi/built-in.a
  CC      drivers/video/nomodeset.o
  CC      crypto/xcbc.o
  CC      fs/proc/namespaces.o
  CC [M]  arch/x86/kvm/../../../virt/kvm/binary_stats.o
  CC      net/ethtool/eee.o
  CC      fs/ext4/balloc.o
  CC      fs/jbd2/transaction.o
  CC      drivers/pci/hotplug/pciehp_hpc.o
  CC      drivers/pci/hotplug/acpiphp_core.o
  CC      fs/jbd2/commit.o
  CC      kernel/power/suspend.o
  CC      sound/core/seq_device.o
  AR      drivers/char/ipmi/built-in.a
  AR      kernel/sched/built-in.a
  CC      io_uring/notif.o
  CC      lib/ctype.o
  CC [M]  net/netfilter/nf_conntrack_proto_tcp.o
  CC      drivers/acpi/acpica/dsargs.o
  CC      net/core/netevent.o
  CC [M]  sound/pci/hda/hda_jack.o
  CC      drivers/acpi/acpica/dscontrol.o
  CC      drivers/pnp/pnpacpi/core.o
  AR      drivers/amba/built-in.a
  CC [M]  drivers/video/fbdev/core/modedb.o
  CC      lib/dec_and_lock.o
  CC      crypto/crypto_null.o
  CC      drivers/pci/pcie/err.o
  CC      block/blk-mq-sched.o
  CC [M]  net/ipv4/netfilter/ipt_REJECT.o
  TABLE   lib/raid6/tables.c
  CC      lib/raid6/int1.o
  CC      drivers/pnp/pnpacpi/rsparser.o
  CC      drivers/acpi/acpica/dsdebug.o
  CC      lib/zstd/compress/zstd_fast.o
  CC [M]  drivers/video/fbdev/core/fbcvt.o
  CC      lib/decompress.o
  CC      net/core/neighbour.o
  CC      drivers/acpi/acpica/dsfield.o
  CC      kernel/irq/irqdesc.o
  CC      fs/proc/self.o
  CC      fs/proc/thread_self.o
  CC      arch/x86/kernel/cpu/powerflags.o
  CC      kernel/irq/handle.o
  CC      drivers/acpi/acpica/dsinit.o
  CC      kernel/power/hibernate.o
  CC      net/core/rtnetlink.o
  CC [M]  sound/pci/hda/hda_auto_parser.o
  CC [M]  arch/x86/kvm/../../../virt/kvm/vfio.o
  CC      drivers/pnp/core.o
  CC [M]  drivers/video/fbdev/core/fb_cmdline.o
  CC      drivers/pnp/card.o
  CC      arch/x86/events/intel/cstate.o
  CC      drivers/pnp/driver.o
  CC      net/ethtool/tsinfo.o
  CC      fs/proc/proc_sysctl.o
  CC      net/ethtool/cabletest.o
  CC      lib/zstd/compress/zstd_lazy.o
  CC [M]  drivers/video/fbdev/core/fb_defio.o
  CC      crypto/md5.o
  CC      crypto/sha1_generic.o
  CC      kernel/printk/printk_safe.o
  CC [M]  net/netfilter/ipvs/ip_vs_proto_udp.o
  CC      drivers/pci/pcie/aer_inject.o
  CC [M]  sound/core/control_led.o
  CC      lib/raid6/int2.o
  CC      lib/zstd/compress/zstd_ldm.o
  CC      drivers/acpi/acpica/dsmethod.o
  CC [M]  drivers/video/fbdev/core/fbcon.o
  CC      drivers/pci/hotplug/acpiphp_glue.o
  CC      io_uring/io-wq.o
  CC      crypto/sha256_generic.o
  CC      drivers/gpio/gpiolib-sysfs.o
  CC      drivers/pci/probe.o
  CC      arch/x86/kernel/head64.o
  CC      arch/x86/kernel/ebda.o
  CC      drivers/gpio/gpiolib-acpi.o
  CC      lib/raid6/int4.o
  CC      lib/raid6/int8.o
  CC      block/ioctl.o
  AR      drivers/pnp/pnpacpi/built-in.a
  CC      kernel/irq/manage.o
  CC      drivers/pnp/resource.o
  AR      drivers/video/fbdev/omap2/omapfb/dss/built-in.a
  CC      net/ipv4/inetpeer.o
  CC [M]  drivers/video/fbdev/core/bitblit.o
  AR      drivers/video/fbdev/omap2/omapfb/displays/built-in.a
  AR      drivers/video/fbdev/omap2/omapfb/built-in.a
  AR      drivers/video/fbdev/omap2/built-in.a
  CC [M]  sound/pci/hda/hda_sysfs.o
  CC      drivers/pnp/manager.o
  CC [M]  drivers/video/fbdev/uvesafb.o
  CC [M]  arch/x86/kvm/../../../virt/kvm/coalesced_mmio.o
  CC [M]  arch/x86/kvm/../../../virt/kvm/async_pf.o
  CC      drivers/pci/host-bridge.o
  AR      arch/x86/events/intel/built-in.a
  AR      arch/x86/events/built-in.a
  CC      kernel/printk/printk_ringbuffer.o
  CC      fs/ext4/bitmap.o
  CC      drivers/acpi/apei/apei-base.o
  CC      drivers/acpi/apei/hest.o
  CC      drivers/acpi/acpica/dsmthdat.o
  CC      drivers/acpi/apei/erst.o
  CC      fs/jbd2/recovery.o
  CC      crypto/sha512_generic.o
  CC      fs/jbd2/checkpoint.o
  CC [M]  arch/x86/kvm/../../../virt/kvm/irqchip.o
  CC      kernel/power/snapshot.o
  CC [M]  sound/pci/hda/hda_controller.o
  CC [M]  drivers/video/fbdev/core/softcursor.o
  CC      drivers/pci/pcie/pme.o
  CC      lib/raid6/int16.o
  CC [M]  sound/core/hwdep.o
  CC      fs/jbd2/revoke.o
  CC      crypto/blake2b_generic.o
  CC      drivers/gpio/gpiolib-swnode.o
  CC      net/ethtool/tunnels.o
  CC      arch/x86/kernel/platform-quirks.o
  CC      block/genhd.o
  CC      drivers/pnp/support.o
  CC      drivers/acpi/acpica/dsobject.o
  CC      mm/shmem.o
  CC      drivers/pnp/interface.o
  CC [M]  sound/pci/hda/hda_proc.o
  CC      drivers/pnp/quirks.o
  CC      kernel/printk/sysctl.o
  CC      fs/ext4/block_validity.o
  AR      drivers/pci/hotplug/built-in.a
  CC      crypto/ecb.o
  CC      crypto/cbc.o
  CC [M]  net/netfilter/ipvs/ip_vs_nfct.o
  AR      drivers/acpi/pmic/built-in.a
  CC      crypto/pcbc.o
  CC      lib/raid6/int32.o
  CC      net/ethtool/fec.o
  CC      drivers/acpi/dptf/int340x_thermal.o
  CC      drivers/acpi/tables.o
  CC      drivers/pnp/system.o
  CC      drivers/acpi/apei/bert.o
  CC [M]  sound/core/pcm.o
  AR      drivers/gpio/built-in.a
  AR      kernel/printk/built-in.a
  CC      fs/ramfs/inode.o
  CC [M]  drivers/video/fbdev/core/tileblit.o
  CC      fs/hugetlbfs/inode.o
  CC      net/ipv4/protocol.o
  CC      fs/proc/proc_net.o
  CC      fs/proc/kcore.o
  CC [M]  drivers/video/fbdev/core/cfbfillrect.o
  CC      drivers/pci/remove.o
  CC      drivers/pci/pcie/dpc.o
  CC      drivers/acpi/acpica/dsopcode.o
  AR      drivers/clk/actions/built-in.a
  AR      drivers/clk/analogbits/built-in.a
  AR      drivers/clk/bcm/built-in.a
  AR      drivers/clk/imgtec/built-in.a
  CC [M]  arch/x86/kvm/../../../virt/kvm/dirty_ring.o
  AR      drivers/clk/imx/built-in.a
  CC [M]  arch/x86/kvm/../../../virt/kvm/pfncache.o
  AR      drivers/clk/ingenic/built-in.a
  CC      fs/proc/kmsg.o
  AR      drivers/clk/mediatek/built-in.a
  AR      io_uring/built-in.a
  AR      drivers/clk/microchip/built-in.a
  CC      drivers/acpi/blacklist.o
  CC [M]  net/netfilter/nf_conntrack_proto_udp.o
  AR      drivers/clk/mstar/built-in.a
  CC [M]  net/netfilter/nf_conntrack_proto_icmp.o
  AR      drivers/clk/mvebu/built-in.a
  CC      kernel/power/swap.o
  CC      fs/jbd2/journal.o
  AR      drivers/clk/ralink/built-in.a
  AR      drivers/clk/renesas/built-in.a
  CC      kernel/power/user.o
  AR      drivers/clk/socfpga/built-in.a
  CC      drivers/acpi/acpica/dspkginit.o
  AR      drivers/clk/sprd/built-in.a
  AR      drivers/clk/sunxi-ng/built-in.a
  CC      crypto/cts.o
  AR      drivers/clk/ti/built-in.a
  AR      drivers/clk/versatile/built-in.a
  CC      kernel/irq/spurious.o
  CC      drivers/clk/x86/clk-lpss-atom.o
  CC      lib/raid6/tables.o
  AR      drivers/clk/xilinx/built-in.a
  CC      drivers/clk/clk-devres.o
  AR      drivers/acpi/dptf/built-in.a
  CC      drivers/acpi/acpica/dsutils.o
  CC      kernel/rcu/update.o
  AR      drivers/pnp/built-in.a
  CC      drivers/acpi/osi.o
  CC [M]  net/netfilter/nf_conntrack_extend.o
  CC      drivers/acpi/apei/ghes.o
  CC      arch/x86/kernel/cpu/feat_ctl.o
  CC      fs/ext4/dir.o
  CC [M]  drivers/video/fbdev/simplefb.o
  CC      kernel/irq/resend.o
  CC      net/core/utils.o
  CC      fs/ramfs/file-mmu.o
  CC      drivers/video/hdmi.o
  CC      kernel/irq/chip.o
  CC      lib/decompress_bunzip2.o
  CC      arch/x86/kernel/process_64.o
  CC [M]  sound/pci/hda/hda_hwdep.o
  CC      drivers/pci/pci.o
  CC      kernel/irq/dummychip.o
  CC      kernel/irq/devres.o
  CC      block/ioprio.o
  CC      drivers/clk/x86/clk-pmc-atom.o
  CC      arch/x86/kernel/cpu/intel.o
  CC [M]  sound/core/pcm_native.o
  CC [M]  drivers/video/fbdev/core/cfbcopyarea.o
  AR      drivers/pci/pcie/built-in.a
  CC      net/ethtool/eeprom.o
  CC      drivers/pci/pci-driver.o
  CC      net/ipv4/ip_input.o
  CC      drivers/dma/dw/core.o
  AR      drivers/soc/apple/built-in.a
  AR      drivers/soc/aspeed/built-in.a
  CC      drivers/acpi/acpica/dswexec.o
  AR      drivers/soc/bcm/bcm63xx/built-in.a
  AR      drivers/soc/bcm/built-in.a
  AR      drivers/soc/fsl/built-in.a
  AR      drivers/soc/fujitsu/built-in.a
  CC      drivers/virtio/virtio.o
  CC [M]  net/netfilter/ipvs/ip_vs_rr.o
  AR      drivers/soc/imx/built-in.a
  CC      fs/proc/page.o
  AR      drivers/soc/ixp4xx/built-in.a
  AR      drivers/soc/loongson/built-in.a
  AR      drivers/soc/mediatek/built-in.a
  CC      drivers/virtio/virtio_ring.o
  AR      drivers/soc/microchip/built-in.a
  CC      crypto/lrw.o
  AR      drivers/soc/nuvoton/built-in.a
  AR      drivers/soc/pxa/built-in.a
  CC      drivers/virtio/virtio_anchor.o
  CC      kernel/power/poweroff.o
  AR      drivers/soc/amlogic/built-in.a
  CC      drivers/dma/hsu/hsu.o
  AR      drivers/soc/qcom/built-in.a
  AR      lib/raid6/built-in.a
  CC [M]  arch/x86/kvm/x86.o
  AR      drivers/soc/renesas/built-in.a
  AR      drivers/soc/rockchip/built-in.a
  CC      drivers/dma/dw/dw.o
  AR      drivers/soc/sifive/built-in.a
  AR      drivers/soc/sunxi/built-in.a
  AR      drivers/soc/ti/built-in.a
  AR      drivers/soc/xilinx/built-in.a
  AR      drivers/soc/built-in.a
  CC      drivers/acpi/osl.o
  CC      drivers/clk/clk-bulk.o
  AR      fs/ramfs/built-in.a
  CC      fs/fat/cache.o
  CC      kernel/irq/autoprobe.o
  CC      kernel/irq/irqdomain.o
  CC [M]  sound/core/pcm_lib.o
  CC [M]  net/netfilter/nf_conntrack_acct.o
  AR      fs/hugetlbfs/built-in.a
  CC      fs/fat/dir.o
  AR      drivers/clk/x86/built-in.a
  CC      arch/x86/kernel/cpu/intel_pconfig.o
  CC [M]  sound/pci/hda/hda_generic.o
  CC      fs/nfs/client.o
  CC      fs/nfs/dir.o
  CC      drivers/acpi/acpica/dswload.o
  CC      fs/exportfs/expfs.o
  CC      fs/nfs/file.o
  CC      fs/lockd/clntlock.o
  CC      net/core/link_watch.o
  CC      net/core/filter.o
  AR      kernel/power/built-in.a
  CC      net/core/sock_diag.o
  CC      fs/lockd/clntproc.o
  CC      block/badblocks.o
  CC      fs/ext4/ext4_jbd2.o
  CC      crypto/xts.o
  CC [M]  drivers/video/fbdev/core/cfbimgblt.o
  CC      drivers/virtio/virtio_pci_modern_dev.o
  CC      drivers/dma/dw/idma32.o
  CC      drivers/virtio/virtio_pci_legacy_dev.o
  AR      drivers/acpi/apei/built-in.a
  CC      drivers/clk/clkdev.o
  CC      fs/nls/nls_base.o
  CC      drivers/clk/clk.o
  CC      drivers/virtio/virtio_mmio.o
  CC      fs/lockd/clntxdr.o
  CC      net/ethtool/stats.o
  CC      drivers/virtio/virtio_pci_modern.o
  CC      kernel/rcu/sync.o
  AR      fs/proc/built-in.a
  CC      drivers/acpi/acpica/dswload2.o
  CC      arch/x86/kernel/cpu/tsx.o
  CC      kernel/irq/proc.o
  AR      drivers/dma/hsu/built-in.a
  CC      drivers/acpi/utils.o
  CC      drivers/acpi/acpica/dswscope.o
  LD [M]  net/netfilter/ipvs/ip_vs.o
  CC [M]  net/netfilter/nf_conntrack_seqadj.o
  CC [M]  net/netfilter/nf_conntrack_proto_icmpv6.o
  CC      drivers/acpi/reboot.o
  AR      fs/exportfs/built-in.a
  CC      kernel/rcu/srcutree.o
  AR      sound/pci/ice1712/built-in.a
  AR      sound/pci/korg1212/built-in.a
  AR      sound/pci/mixart/built-in.a
  AR      sound/pci/nm256/built-in.a
  AR      sound/pci/oxygen/built-in.a
  AR      sound/pci/pcxhr/built-in.a
  AR      sound/pci/riptide/built-in.a
  AR      sound/pci/rme9652/built-in.a
  CC [M]  net/netfilter/nf_conntrack_proto_dccp.o
  CC      fs/nls/nls_cp437.o
  CC      lib/decompress_inflate.o
  CC      block/blk-rq-qos.o
  CC      kernel/rcu/tree.o
  CC      fs/ext4/extents.o
  CC      arch/x86/kernel/cpu/intel_epb.o
  CC      kernel/irq/migration.o
  CC      mm/util.o
  CC      crypto/ctr.o
  CC      net/ipv4/ip_fragment.o
  CC      net/ipv4/ip_forward.o
  CC      mm/mmzone.o
  CC      drivers/dma/dw/acpi.o
  CC      drivers/acpi/acpica/dswstate.o
  CC      net/ethtool/phc_vclocks.o
  CC      block/disk-events.o
  CC      lib/zstd/compress/zstd_opt.o
  CC      lib/zstd/zstd_decompress_module.o
  CC      drivers/clk/clk-divider.o
  CC [M]  drivers/video/fbdev/core/sysfillrect.o
  CC      drivers/dma/dw/pci.o
  CC      fs/nls/nls_ascii.o
  CC      mm/vmstat.o
  CC [M]  drivers/video/fbdev/core/syscopyarea.o
  CC      drivers/virtio/virtio_pci_common.o
  CC      drivers/acpi/nvs.o
  CC      drivers/acpi/wakeup.o
  CC      arch/x86/kernel/cpu/amd.o
  CC      drivers/pci/search.o
  CC      crypto/gcm.o
  CC      kernel/irq/cpuhotplug.o
  CC      fs/lockd/host.o
  CC      fs/fat/fatent.o
  CC      drivers/acpi/acpica/evevent.o
  CC      lib/zstd/decompress/huf_decompress.o
  CC [M]  sound/core/pcm_misc.o
  CC [M]  sound/core/pcm_memory.o
  CC      drivers/virtio/virtio_pci_legacy.o
  CC      kernel/rcu/rcu_segcblist.o
  AR      fs/jbd2/built-in.a
  CC      mm/backing-dev.o
  CC      lib/zstd/decompress/zstd_ddict.o
  CC [M]  sound/core/memalloc.o
  CC      drivers/acpi/acpica/evgpe.o
  CC      fs/nls/nls_iso8859-1.o
  CC      lib/zstd/decompress/zstd_decompress.o
  AR      drivers/dma/dw/built-in.a
  AR      drivers/dma/idxd/built-in.a
  AR      drivers/dma/mediatek/built-in.a
  CC      block/blk-ia-ranges.o
  CC [M]  drivers/virtio/virtio_mem.o
  AR      drivers/dma/qcom/built-in.a
  AR      drivers/dma/ti/built-in.a
  CC      lib/zstd/decompress/zstd_decompress_block.o
  AR      drivers/dma/xilinx/built-in.a
  CC      lib/zstd/zstd_common_module.o
  CC [M]  drivers/dma/ioat/init.o
  CC      drivers/acpi/sleep.o
  CC      drivers/dma/dmaengine.o
  CC      fs/nfs/getroot.o
  CC [M]  sound/core/pcm_timer.o
  CC [M]  drivers/dma/ioat/dma.o
  CC      net/ethtool/mm.o
  CC      kernel/irq/pm.o
  CC [M]  net/netfilter/nf_conntrack_proto_sctp.o
  CC      drivers/pci/pci-sysfs.o
  CC      lib/zstd/common/debug.o
  CC      arch/x86/kernel/cpu/hygon.o
  CC [M]  net/netfilter/nf_conntrack_netlink.o
  CC      fs/nls/nls_utf8.o
  CC      mm/mm_init.o
  AR      fs/unicode/built-in.a
  CC      fs/ntfs/aops.o
  CC [M]  drivers/video/fbdev/core/sysimgblt.o
  CC      drivers/acpi/acpica/evgpeblk.o
  LD [M]  sound/core/snd-ctl-led.o
  LD [M]  sound/core/snd-hwdep.o
  CC      drivers/tty/vt/vt_ioctl.o
  CC      fs/autofs/init.o
  CC      drivers/tty/vt/vc_screen.o
  CC      drivers/tty/vt/selection.o
  CC      net/ipv4/ip_options.o
  CC      fs/debugfs/inode.o
  CC      drivers/tty/hvc/hvc_console.o
  AR      drivers/tty/ipwireless/built-in.a
  CC      drivers/tty/serial/8250/8250_core.o
  CC      drivers/tty/serial/serial_core.o
  CC      fs/autofs/inode.o
  CC      drivers/tty/serial/earlycon.o
  AR      fs/nls/built-in.a
  CC [M]  sound/pci/hda/patch_realtek.o
  CC      crypto/pcrypt.o
  CC      arch/x86/kernel/cpu/centaur.o
  CC      block/bsg.o
  CC      crypto/cryptd.o
  AR      sound/core/built-in.a
  LD [M]  sound/core/snd-pcm.o
  CC [M]  net/netfilter/nf_nat_core.o
  CC      fs/fat/file.o
  CC [M]  net/netfilter/nf_nat_proto.o
  CC      drivers/tty/vt/keyboard.o
  CC      drivers/acpi/acpica/evgpeinit.o
  CC      fs/lockd/svc.o
  CC      kernel/irq/msi.o
  AR      sound/arm/built-in.a
  CC      kernel/irq/affinity.o
  CC      crypto/des_generic.o
  CC      fs/nfs/inode.o
  CC      net/ethtool/module.o
  CC      fs/tracefs/inode.o
  CC      drivers/acpi/device_sysfs.o
  CC [M]  drivers/video/fbdev/core/fb_sys_fops.o
  CC      mm/percpu.o
  CC      fs/autofs/root.o
  CC      drivers/tty/vt/consolemap.o
  CC      fs/pstore/inode.o
  CC      fs/debugfs/file.o
  CC      net/core/dev_ioctl.o
  CC      arch/x86/kernel/cpu/zhaoxin.o
  CC      net/ethtool/pse-pd.o
  CC [M]  drivers/dma/ioat/prep.o
  CC      drivers/acpi/acpica/evgpeutil.o
  CC      fs/btrfs/super.o
  CC      fs/ntfs/attrib.o
  AR      drivers/tty/hvc/built-in.a
  CC      fs/btrfs/ctree.o
  CC      net/core/tso.o
  CC      drivers/tty/serial/serial_mctrl_gpio.o
  CC      fs/pstore/platform.o
  CC      drivers/pci/rom.o
  CC      fs/pstore/pmsg.o
  CC      block/bsg-lib.o
  CC      drivers/acpi/acpica/evglock.o
  CC      drivers/tty/serial/8250/8250_pnp.o
  CC      fs/fat/inode.o
  CC      net/ipv4/ip_output.o
  CC      arch/x86/kernel/cpu/perfctr-watchdog.o
  CC      crypto/aes_generic.o
  CC      drivers/acpi/acpica/evhandler.o
  CC      drivers/clk/clk-fixed-factor.o
  AR      drivers/virtio/built-in.a
  CC      crypto/deflate.o
  CC      drivers/acpi/device_pm.o
  AR      fs/tracefs/built-in.a
  CC      mm/slab_common.o
  CC      drivers/acpi/proc.o
  LD [M]  drivers/video/fbdev/core/fb.o
  CC      drivers/acpi/acpica/evmisc.o
  CC      drivers/clk/clk-fixed-rate.o
  CC      mm/compaction.o
  AR      drivers/video/fbdev/core/built-in.a
  AR      drivers/video/fbdev/built-in.a
  AR      drivers/video/built-in.a
  CC      lib/zstd/common/entropy_common.o
  CC      fs/autofs/symlink.o
  CC      drivers/pci/setup-res.o
  CC      kernel/irq/matrix.o
  CC      fs/efivarfs/inode.o
  CC      fs/lockd/svclock.o
  AR      fs/pstore/built-in.a
  CC      fs/ext4/extents_status.o
  CC      fs/efivarfs/file.o
  CC      fs/efivarfs/super.o
  CC      net/ethtool/plca.o
  AR      fs/debugfs/built-in.a
  CC [M]  fs/netfs/buffered_read.o
  CC      drivers/acpi/acpica/evregion.o
  CC [M]  fs/netfs/io.o
  CC [M]  net/netfilter/nf_nat_helper.o
  CC      block/blk-cgroup.o
  CC [M]  arch/x86/kvm/emulate.o
  CC      arch/x86/kernel/cpu/vmware.o
  CC [M]  fs/netfs/iterator.o
  CC      drivers/tty/serial/8250/8250_port.o
  CC [M]  drivers/dma/ioat/dca.o
  CC      fs/ntfs/collate.o
  CC      drivers/clk/clk-gate.o
  CC      arch/x86/kernel/cpu/hypervisor.o
  CC [M]  fs/netfs/main.o
  HOSTCC  drivers/tty/vt/conmakehash
  CC [M]  net/netfilter/nf_nat_redirect.o
  CC [M]  fs/fscache/cache.o
  CC      fs/ext4/file.o
  CC      fs/autofs/waitq.o
  CC      drivers/tty/vt/vt.o
  CC      fs/efivarfs/vars.o
  CC [M]  fs/fscache/cookie.o
  CC [M]  fs/fscache/io.o
  CC [M]  net/netfilter/nf_nat_masquerade.o
  CC [M]  fs/fscache/main.o
  CC      net/core/sock_reuseport.o
  CC      drivers/pci/irq.o
  CC      drivers/acpi/acpica/evrgnini.o
  CC      drivers/char/hw_random/core.o
  CC      crypto/crc32c_generic.o
  CC      drivers/clk/clk-multiplier.o
  CC      arch/x86/kernel/cpu/mshyperv.o
  CC      fs/ntfs/compress.o
  CC      drivers/char/hw_random/intel-rng.o
  CC [M]  arch/x86/kvm/i8259.o
  CC [M]  drivers/dma/ioat/sysfs.o
  CC [M]  arch/x86/kvm/irq.o
  CC      fs/fat/misc.o
  AR      net/ethtool/built-in.a
  CC      fs/lockd/svcshare.o
  CC      fs/fat/nfs.o
  CC      drivers/char/agp/backend.o
  CC      fs/autofs/expire.o
  CC      drivers/char/agp/generic.o
  AR      kernel/irq/built-in.a
  AR      kernel/livepatch/built-in.a
  CC [M]  sound/pci/hda/patch_analog.o
  CC      drivers/acpi/acpica/evsci.o
  CC [M]  arch/x86/kvm/lapic.o
  CC      crypto/crct10dif_common.o
  COPY    drivers/tty/vt/defkeymap.c
  CC      drivers/acpi/bus.o
  CC      lib/zstd/common/error_private.o
  CC      drivers/pci/vpd.o
  CC [M]  fs/netfs/objects.o
  CC      drivers/char/tpm/tpm-chip.o
  CC      drivers/char/mem.o
  CC      drivers/clk/clk-mux.o
  AR      fs/efivarfs/built-in.a
  CC      drivers/acpi/glue.o
  AR      drivers/iommu/amd/built-in.a
  CC      drivers/iommu/intel/dmar.o
  AR      drivers/gpu/host1x/built-in.a
  CC      drivers/connector/cn_queue.o
  CC      drivers/connector/connector.o
  AR      drivers/gpu/drm/tests/built-in.a
  CC [M]  drivers/gpu/drm/tests/drm_kunit_helpers.o
  CC [M]  drivers/gpu/drm/tests/drm_buddy_test.o
  CC      fs/nfs/super.o
  CC [M]  drivers/gpu/drm/tests/drm_cmdline_parser_test.o
  AR      drivers/char/hw_random/built-in.a
  CC      drivers/connector/cn_proc.o
  CC      fs/nfs/io.o
  AR      kernel/rcu/built-in.a
  LD [M]  drivers/dma/ioat/ioatdma.o
  CC      kernel/dma/mapping.o
  CC      arch/x86/kernel/cpu/capflags.o
  CC      crypto/crct10dif_generic.o
  CC      drivers/acpi/acpica/evxface.o
  CC      drivers/dma/virt-dma.o
  AR      arch/x86/kernel/cpu/built-in.a
  CC      arch/x86/kernel/signal.o
  CC      kernel/dma/direct.o
  CC      mm/interval_tree.o
  CC      fs/fat/namei_vfat.o
  CC      fs/autofs/dev-ioctl.o
  AR      sound/pci/trident/built-in.a
  CC      block/blk-cgroup-rwstat.o
  CC      crypto/authenc.o
  CC      fs/ext4/fsmap.o
  CC      drivers/clk/clk-composite.o
  CC [M]  net/netfilter/x_tables.o
  CC [M]  fs/fscache/volume.o
  CC      arch/x86/kernel/signal_64.o
  CC      fs/ntfs/debug.o
  CC [M]  sound/pci/hda/patch_hdmi.o
  CC      fs/lockd/svcproc.o
  CC [M]  drivers/gpu/drm/tests/drm_connector_test.o
  CC      drivers/clk/clk-fractional-divider.o
  LD [M]  fs/netfs/netfs.o
  CC      drivers/char/tpm/tpm-dev-common.o
  CC      drivers/pci/setup-bus.o
  CC      fs/btrfs/extent-tree.o
  CC [M]  net/netfilter/xt_tcpudp.o
  CC      fs/ext4/fsync.o
  CC [M]  sound/pci/hda/hda_eld.o
  CC      drivers/tty/serial/8250/8250_dma.o
  CC      net/ipv4/ip_sockglue.o
  CC      drivers/char/tpm/tpm-dev.o
  CC      drivers/acpi/acpica/evxfevnt.o
  CC      drivers/char/agp/isoch.o
  CC      drivers/dma/acpi-dma.o
  CC      lib/zstd/common/fse_decompress.o
  CC      drivers/iommu/intel/iommu.o
  CC      fs/nfs/direct.o
  CC      crypto/authencesn.o
  CC      fs/ntfs/dir.o
  CC      net/core/fib_notifier.o
  AR      fs/autofs/built-in.a
  CC      drivers/clk/clk-gpio.o
  CC      lib/zstd/common/zstd_common.o
  CC      fs/nfs/pagelist.o
  CC      block/blk-throttle.o
  CC      net/ipv4/inet_hashtables.o
  CC      kernel/dma/ops_helpers.o
  CC      net/ipv4/inet_timewait_sock.o
  CC      drivers/char/tpm/tpm-interface.o
  CC      block/mq-deadline.o
  CC      drivers/acpi/acpica/evxfgpe.o
  AR      drivers/connector/built-in.a
  CC      kernel/dma/dummy.o
  CC      net/ipv4/inet_connection_sock.o
  CC      arch/x86/kernel/traps.o
  CC      drivers/char/agp/intel-agp.o
  CC      drivers/acpi/scan.o
  CC      mm/list_lru.o
  AR      drivers/gpu/drm/arm/built-in.a
  CC      drivers/char/tpm/tpm1-cmd.o
  AR      drivers/gpu/drm/display/built-in.a
  CC [M]  drivers/gpu/drm/display/drm_display_helper_mod.o
  CC      fs/fat/namei_msdos.o
  CC      drivers/tty/serial/8250/8250_dwlib.o
  CC [M]  fs/fscache/proc.o
  CC [M]  drivers/gpu/drm/display/drm_dp_dual_mode_helper.o
  CC      drivers/char/random.o
  AR      drivers/dma/built-in.a
  CC      drivers/char/tpm/tpm2-cmd.o
  AR      drivers/clk/built-in.a
  CC      drivers/char/agp/intel-gtt.o
  CC      drivers/base/power/sysfs.o
  CONMK   drivers/tty/vt/consolemap_deftbl.c
  CC      drivers/tty/vt/defkeymap.o
  CC      fs/lockd/svcsubs.o
  CC      drivers/base/regmap/regmap.o
  CC      drivers/base/firmware_loader/builtin/main.o
  CC [M]  drivers/gpu/drm/tests/drm_damage_helper_test.o
  CC      drivers/acpi/acpica/evxfregn.o
  CC      drivers/base/regmap/regcache.o
  CC      kernel/dma/contiguous.o
  CC      drivers/base/firmware_loader/main.o
  CC [M]  net/netfilter/xt_mark.o
  CC [M]  drivers/gpu/drm/tests/drm_dp_mst_helper_test.o
  CC      drivers/tty/vt/consolemap_deftbl.o
  AR      drivers/tty/vt/built-in.a
  CC      crypto/lzo.o
  CC      fs/ext4/hash.o
  CC      kernel/entry/common.o
  CC      drivers/char/misc.o
  CC      kernel/entry/syscall_user_dispatch.o
  AR      drivers/base/firmware_loader/builtin/built-in.a
  CC      drivers/iommu/intel/pasid.o
  CC      net/core/xdp.o
  LD [M]  fs/fscache/fscache.o
  CC      drivers/tty/serial/8250/8250_pcilib.o
  CC [M]  drivers/gpu/drm/tests/drm_format_helper_test.o
  CC [M]  drivers/gpu/drm/tests/drm_format_test.o
  CC      fs/ntfs/file.o
  CC      drivers/acpi/acpica/exconcat.o
  CC      drivers/base/power/generic_ops.o
  CC      kernel/module/main.o
  CC      mm/workingset.o
  CC      arch/x86/kernel/idt.o
  CC      drivers/pci/vc.o
  CC      lib/decompress_unlz4.o
  AR      fs/fat/built-in.a
  CC      kernel/time/time.o
  CC      kernel/futex/core.o
  CC      kernel/dma/swiotlb.o
  CC [M]  drivers/gpu/drm/display/drm_dp_helper.o
  CC      kernel/time/timer.o
  CC      kernel/cgroup/cgroup.o
  CC      crypto/lzo-rle.o
  CC      kernel/futex/syscalls.o
  CC      kernel/cgroup/rstat.o
  CC [M]  net/netfilter/xt_nat.o
  CC      block/kyber-iosched.o
  CC      drivers/char/tpm/tpmrm-dev.o
  CC      net/ipv4/tcp.o
  AR      drivers/char/agp/built-in.a
  CC [M]  drivers/gpu/drm/display/drm_dp_mst_topology.o
  CC      drivers/acpi/acpica/exconfig.o
  CC [M]  arch/x86/kvm/i8254.o
  CC      kernel/time/hrtimer.o
  CC      fs/ext4/ialloc.o
  CC [M]  sound/pci/hda/hda_intel.o
  CC      drivers/base/power/common.o
  CC      kernel/cgroup/namespace.o
  CC      fs/btrfs/print-tree.o
  CC      drivers/tty/serial/8250/8250_pci.o
  CC      fs/lockd/mon.o
  CC [M]  drivers/gpu/drm/tests/drm_framebuffer_test.o
  AR      drivers/gpu/drm/rcar-du/built-in.a
  AR      drivers/base/firmware_loader/built-in.a
  CC      drivers/acpi/acpica/exconvrt.o
  CC      drivers/base/power/qos.o
  CC      kernel/futex/pi.o
  CC      fs/ntfs/index.o
  CC      kernel/entry/kvm.o
  CC      arch/x86/kernel/irq.o
  CC      drivers/pci/mmap.o
  CC      drivers/char/virtio_console.o
  CC      crypto/lz4.o
  CC      drivers/acpi/acpica/excreate.o
  CC [M]  drivers/gpu/drm/tests/drm_managed_test.o
  CC      drivers/pci/setup-irq.o
  CC      mm/debug.o
  CC      drivers/base/regmap/regcache-rbtree.o
  CC      fs/nfs/read.o
  CC      drivers/char/tpm/tpm2-space.o
  CC      lib/decompress_unlzma.o
  AR      drivers/base/test/built-in.a
  CC      drivers/base/component.o
  CC      fs/lockd/xdr.o
  CC      fs/lockd/clnt4xdr.o
  CC      drivers/acpi/acpica/exdebug.o
  CC      fs/lockd/xdr4.o
  CC      fs/ntfs/inode.o
  CC      drivers/acpi/acpica/exdump.o
  CC      arch/x86/kernel/irq_64.o
  CC      net/ipv4/tcp_input.o
  CC      crypto/lz4hc.o
  CC      arch/x86/kernel/dumpstack_64.o
  CC      kernel/futex/requeue.o
  CC      drivers/pci/proc.o
  CC      kernel/dma/remap.o
  CC [M]  drivers/gpu/drm/tests/drm_mm_test.o
  CC      net/core/flow_offload.o
  CC      drivers/base/regmap/regcache-flat.o
  CC      crypto/xxhash_generic.o
  CC [M]  net/netfilter/xt_REDIRECT.o
  CC      mm/gup.o
  CC      drivers/acpi/acpica/exfield.o
  CC      drivers/acpi/acpica/exfldio.o
  AR      kernel/entry/built-in.a
  CC      drivers/base/regmap/regmap-debugfs.o
  CC      drivers/acpi/resource.o
  CC      drivers/base/power/runtime.o
  CC [M]  drivers/gpu/drm/tests/drm_modes_test.o
  CC      drivers/iommu/intel/trace.o
  CC [M]  arch/x86/kvm/ioapic.o
  CC      kernel/futex/waitwake.o
  CC      kernel/cgroup/cgroup-v1.o
  CC      drivers/base/power/wakeirq.o
  CC      drivers/iommu/intel/cap_audit.o
  CC      drivers/base/power/main.o
  CC      block/bfq-iosched.o
  CC      drivers/base/power/wakeup.o
  CC      drivers/char/tpm/tpm-sysfs.o
  CC      crypto/rng.o
  CC      drivers/char/tpm/eventlog/common.o
  CC      drivers/tty/serial/8250/8250_exar.o
  CC      drivers/char/tpm/eventlog/tpm1.o
  CC      arch/x86/kernel/time.o
  AR      kernel/dma/built-in.a
  CC      kernel/cgroup/freezer.o
  CC      drivers/base/power/wakeup_stats.o
  CC      kernel/cgroup/legacy_freezer.o
  CC      kernel/cgroup/pids.o
  LD [M]  sound/pci/hda/snd-hda-codec.o
  CC      drivers/acpi/acpica/exmisc.o
  CC      drivers/pci/slot.o
  CC      drivers/acpi/acpi_processor.o
  LD [M]  sound/pci/hda/snd-hda-codec-generic.o
  CC      drivers/char/hpet.o
  LD [M]  sound/pci/hda/snd-hda-codec-realtek.o
  CC      kernel/time/timekeeping.o
  CC      fs/lockd/svc4proc.o
  LD [M]  sound/pci/hda/snd-hda-codec-analog.o
  LD [M]  sound/pci/hda/snd-hda-codec-hdmi.o
  CC      drivers/char/nvram.o
  LD [M]  sound/pci/hda/snd-hda-intel.o
  CC      kernel/module/strict_rwx.o
  AR      sound/pci/ymfpci/built-in.a
  AR      kernel/futex/built-in.a
  AR      sound/pci/vx222/built-in.a
  CC      fs/lockd/procfs.o
  AR      sound/pci/built-in.a
  AR      sound/sh/built-in.a
  CC      drivers/base/power/domain.o
  CC      crypto/drbg.o
  CC      drivers/base/regmap/regmap-i2c.o
  CC [M]  net/netfilter/xt_MASQUERADE.o
  CC      fs/ntfs/mft.o
  CC      drivers/base/power/domain_governor.o
  AR      sound/synth/emux/built-in.a
  AR      sound/synth/built-in.a
  AR      sound/usb/misc/built-in.a
  AR      sound/usb/usx2y/built-in.a
  AR      sound/usb/caiaq/built-in.a
  CC      fs/btrfs/root-tree.o
  CC      fs/ntfs/mst.o
  AR      sound/usb/6fire/built-in.a
  AR      sound/usb/hiface/built-in.a
  AR      sound/usb/bcd2000/built-in.a
  AR      sound/usb/built-in.a
  CC      arch/x86/kernel/ioport.o
  AR      sound/firewire/built-in.a
  AR      sound/sparc/built-in.a
  AR      sound/spi/built-in.a
  CC      arch/x86/kernel/dumpstack.o
  AR      sound/parisc/built-in.a
  CC      drivers/char/tpm/eventlog/tpm2.o
  AR      sound/pcmcia/vx/built-in.a
  CC      fs/ext4/indirect.o
  CC      net/core/gro.o
  CC      net/ipv4/tcp_output.o
  AR      drivers/gpu/drm/omapdrm/built-in.a
  AR      sound/pcmcia/pdaudiocf/built-in.a
  CC      net/core/netdev-genl.o
  CC      drivers/acpi/acpica/exmutex.o
  AR      sound/pcmcia/built-in.a
  CC      drivers/char/tpm/tpm_ppi.o
  AR      sound/mips/built-in.a
  AR      sound/soc/built-in.a
  CC      fs/nfs/symlink.o
  AR      sound/atmel/built-in.a
  AR      sound/hda/built-in.a
  CC [M]  sound/hda/hda_bus_type.o
  CC      fs/btrfs/dir-item.o
  CC [M]  sound/hda/hdac_bus.o
  CC      drivers/base/power/clock_ops.o
  CC      fs/ext4/inline.o
  CC      drivers/tty/serial/8250/8250_early.o
  CC      drivers/acpi/acpica/exnames.o
  CC      drivers/iommu/intel/irq_remapping.o
  CC [M]  drivers/gpu/drm/display/drm_dsc_helper.o
  AR      lib/zstd/built-in.a
  CC      lib/decompress_unlzo.o
  CC      drivers/pci/pci-acpi.o
  CC      kernel/module/tree_lookup.o
  CC [M]  arch/x86/kvm/irq_comm.o
  CC      drivers/base/core.o
  CC      drivers/base/bus.o
  CC      block/bfq-wf2q.o
  CC      fs/ntfs/namei.o
  CC      block/bfq-cgroup.o
  CC      lib/decompress_unxz.o
  CC      drivers/base/dd.o
  CC      drivers/base/syscore.o
  AR      sound/x86/built-in.a
  CC      net/core/netdev-genl-gen.o
  CC      drivers/base/regmap/regmap-irq.o
  AR      drivers/iommu/arm/arm-smmu/built-in.a
  CC      arch/x86/kernel/nmi.o
  CC      drivers/tty/serial/8250/8250_dw.o
  AR      drivers/iommu/arm/arm-smmu-v3/built-in.a
  AR      drivers/iommu/arm/built-in.a
  CC      net/ipv4/tcp_timer.o
  AR      sound/xen/built-in.a
  AR      drivers/iommu/iommufd/built-in.a
  CC      drivers/acpi/acpica/exoparg1.o
  CC [M]  drivers/gpu/drm/tests/drm_plane_helper_test.o
  CC      drivers/iommu/iommu.o
  CC [M]  drivers/gpu/drm/tests/drm_probe_helper_test.o
  CC [M]  drivers/gpu/drm/tests/drm_rect_test.o
  CC      drivers/char/tpm/eventlog/acpi.o
  AR      fs/lockd/built-in.a
  CC      fs/ntfs/runlist.o
  CC [M]  net/netfilter/xt_addrtype.o
  CC [M]  net/netfilter/xt_conntrack.o
  CC [M]  fs/smbfs_common/cifs_arc4.o
  CC      net/core/net-sysfs.o
  CC [M]  sound/hda/hdac_device.o
  CC      kernel/module/debug_kmemleak.o
  CC [M]  sound/hda/hdac_sysfs.o
  CC      drivers/char/tpm/eventlog/efi.o
  CC      fs/nfs/unlink.o
  CC      lib/decompress_unzstd.o
  CC [M]  drivers/gpu/drm/display/drm_hdcp_helper.o
  CC      kernel/time/ntp.o
  CC      fs/ntfs/super.o
  CC      fs/ntfs/sysctl.o
  CC      crypto/jitterentropy.o
  CC      kernel/time/clocksource.o
  CC      net/ipv4/tcp_ipv4.o
  CC      mm/mmap_lock.o
  CC [M]  fs/smbfs_common/cifs_md4.o
  CC      mm/highmem.o
  CC      crypto/jitterentropy-kcapi.o
  CC      drivers/acpi/acpica/exoparg2.o
  CC [M]  drivers/gpu/drm/display/drm_hdmi_helper.o
  CC      fs/btrfs/file-item.o
  CC [M]  arch/x86/kvm/cpuid.o
  CC      drivers/tty/serial/8250/8250_lpss.o
  CC      drivers/char/tpm/tpm_crb.o
  AR      drivers/base/power/built-in.a
  CC      drivers/base/driver.o
  CC      drivers/acpi/processor_core.o
  CC      drivers/pci/quirks.o
  CC      crypto/ghash-generic.o
  CC      kernel/module/kallsyms.o
  CC      drivers/acpi/processor_pdc.o
  CC [M]  arch/x86/kvm/pmu.o
  CC      drivers/acpi/ec.o
  CC      fs/ntfs/unistr.o
  CC [M]  fs/cifs/trace.o
  CC      lib/dump_stack.o
  CC      drivers/iommu/intel/perfmon.o
  CC      arch/x86/kernel/ldt.o
  CC [M]  fs/cifs/cifsfs.o
  CC [M]  sound/hda/hdac_regmap.o
  CC      lib/earlycpio.o
  CC      arch/x86/kernel/setup.o
  CC      drivers/acpi/dock.o
  CC [M]  fs/fuse/dev.o
  CC      drivers/acpi/pci_root.o
  CC      drivers/acpi/pci_link.o
  CC      drivers/acpi/acpica/exoparg3.o
  CC      drivers/acpi/acpica/exoparg6.o
  CC      fs/ntfs/upcase.o
  CC      drivers/acpi/pci_irq.o
  AR      drivers/base/regmap/built-in.a
  CC      arch/x86/kernel/x86_init.o
  CC      drivers/base/class.o
  CC      crypto/af_alg.o
  AR      drivers/gpu/drm/tilcdc/built-in.a
  CC [M]  drivers/gpu/drm/display/drm_scdc_helper.o
  CC      kernel/trace/trace_clock.o
  CC      drivers/iommu/iommu-traces.o
  CC [M]  net/netfilter/xt_ipvs.o
  AR      drivers/gpu/vga/built-in.a
  CC      crypto/algif_hash.o
  CC      fs/ext4/inode.o
  CC [M]  arch/x86/kvm/mtrr.o
  CC      net/core/net-procfs.o
  CC      drivers/tty/serial/8250/8250_mid.o
  CC      lib/extable.o
  CC      kernel/time/jiffies.o
  CC      net/xfrm/xfrm_policy.o
  CC      net/unix/af_unix.o
  CC      mm/memory.o
  CC      mm/mincore.o
  CC      drivers/acpi/acpica/exprep.o
  AR      drivers/char/tpm/built-in.a
  AR      drivers/char/built-in.a
  CC      net/unix/garbage.o
  CC      kernel/module/procfs.o
  CC      kernel/trace/ftrace.o
  CC [M]  sound/hda/hdac_controller.o
  CC [M]  sound/hda/hdac_stream.o
  CC [M]  sound/hda/array.o
  CC      block/blk-mq-pci.o
  AR      fs/ntfs/built-in.a
  CC [M]  drivers/gpu/drm/display/drm_dp_aux_dev.o
  CC      kernel/cgroup/cpuset.o
  CC      lib/flex_proportions.o
  CC [M]  sound/hda/hdmi_chmap.o
  CC      fs/nfs/write.o
  CC      kernel/time/timer_list.o
  CC      kernel/bpf/core.o
  CC      kernel/events/core.o
  CC      kernel/fork.o
  CC      net/core/netpoll.o
  CC      drivers/tty/serial/8250/8250_pericom.o
  CC      arch/x86/kernel/i8259.o
  CC [M]  arch/x86/kvm/hyperv.o
  CC      drivers/acpi/acpica/exregion.o
  CC      drivers/acpi/acpi_lpss.o
  CC      net/core/fib_rules.o
  CC      drivers/tty/tty_io.o
  AR      drivers/iommu/intel/built-in.a
  CC      drivers/iommu/iommu-sysfs.o
  AR      sound/virtio/built-in.a
  CC      drivers/iommu/dma-iommu.o
  CC      kernel/module/sysfs.o
  CC      drivers/iommu/ioasid.o
  CC      lib/idr.o
  CC [M]  sound/hda/trace.o
  CC      net/xfrm/xfrm_state.o
  CC [M]  sound/hda/hdac_component.o
  CC      lib/irq_regs.o
  LD [M]  net/netfilter/nf_conntrack.o
  CC      kernel/exec_domain.o
  CC      block/blk-mq-virtio.o
  CC      fs/btrfs/inode-item.o
  LD [M]  net/netfilter/nf_nat.o
  CC      drivers/base/platform.o
  AR      net/netfilter/built-in.a
  CC      sound/sound_core.o
  CC      net/xfrm/xfrm_hash.o
  CC      drivers/acpi/acpica/exresnte.o
  CC      arch/x86/kernel/irqinit.o
  CC      drivers/tty/n_tty.o
  CC      kernel/time/timeconv.o
  CC [M]  fs/cifs/cifs_debug.o
  CC      net/core/net-traces.o
  CC [M]  fs/cifs/connect.o
  AR      drivers/tty/serial/8250/built-in.a
  AR      drivers/tty/serial/built-in.a
  LD [M]  drivers/gpu/drm/display/drm_display_helper.o
  CC      kernel/time/timecounter.o
  CC [M]  fs/cifs/dir.o
  CC      drivers/acpi/acpica/exresolv.o
  CC [M]  sound/hda/hdac_i915.o
  AR      drivers/gpu/drm/imx/built-in.a
  AR      drivers/gpu/drm/i2c/built-in.a
  AR      drivers/gpu/drm/panel/built-in.a
  CC      drivers/acpi/acpica/exresop.o
  CC [M]  fs/cifs/file.o
  CC      drivers/acpi/acpica/exserial.o
  AR      drivers/gpu/drm/bridge/analogix/built-in.a
  AR      drivers/gpu/drm/bridge/cadence/built-in.a
  AR      drivers/gpu/drm/bridge/imx/built-in.a
  CC      crypto/algif_skcipher.o
  AR      drivers/gpu/drm/bridge/synopsys/built-in.a
  AR      drivers/gpu/drm/bridge/built-in.a
  CC      crypto/xor.o
  AR      drivers/gpu/drm/hisilicon/built-in.a
  CC      lib/is_single_threaded.o
  AR      kernel/module/built-in.a
  AR      drivers/gpu/drm/mxsfb/built-in.a
  CC      lib/klist.o
  AR      drivers/gpu/drm/tiny/built-in.a
  CC [M]  fs/fuse/dir.o
  AR      net/ipv6/netfilter/built-in.a
  CC      drivers/pci/ats.o
  CC [M]  net/ipv6/netfilter/nf_defrag_ipv6_hooks.o
  CC      drivers/pci/iov.o
  AR      drivers/gpu/drm/xlnx/built-in.a
  CC      kernel/time/alarmtimer.o
  AR      drivers/gpu/drm/gud/built-in.a
  CC [M]  fs/fuse/file.o
  AR      drivers/gpu/drm/solomon/built-in.a
  CC      block/blk-mq-debugfs.o
  CC [M]  drivers/gpu/drm/ttm/ttm_tt.o
  CC [M]  fs/fuse/inode.o
  CC      fs/nfs/namespace.o
  CC      net/packet/af_packet.o
  CC      fs/btrfs/disk-io.o
  CC [M]  net/ipv6/netfilter/nf_conntrack_reasm.o
  CC      net/key/af_key.o
  CC [M]  drivers/gpu/drm/ttm/ttm_bo.o
  CC [M]  fs/overlayfs/super.o
  CC      arch/x86/kernel/jump_label.o
  CC      net/ipv4/tcp_minisocks.o
  CC      drivers/acpi/acpica/exstore.o
  CC      lib/kobject.o
  CC [M]  fs/overlayfs/namei.o
  CC [M]  sound/hda/intel-dsp-config.o
  CC      drivers/base/cpu.o
  CC [M]  fs/cifs/inode.o
  CC      drivers/iommu/iova.o
  CC      net/core/selftests.o
  CC      drivers/pci/pci-label.o
  CC      net/unix/sysctl_net_unix.o
  CC      drivers/acpi/acpica/exstoren.o
  CC      crypto/hash_info.o
  CC [M]  drivers/gpu/drm/scheduler/sched_main.o
  CC      crypto/simd.o
  CC [M]  drivers/gpu/drm/scheduler/sched_fence.o
  CC      arch/x86/kernel/irq_work.o
  CC [M]  crypto/md4.o
  CC      block/blk-pm.o
  CC [M]  fs/overlayfs/util.o
  CC [M]  fs/cifs/link.o
  CC      kernel/time/posix-timers.o
  CC [M]  sound/hda/intel-nhlt.o
  CC      lib/kobject_uevent.o
  CC      drivers/tty/tty_ioctl.o
  CC [M]  drivers/gpu/drm/ttm/ttm_bo_util.o
  CC      block/holder.o
  CC      drivers/base/firmware.o
  CC      drivers/acpi/acpica/exstorob.o
  CC      fs/nfs/mount_clnt.o
  CC      kernel/panic.o
  CC [M]  fs/fuse/control.o
  CC      drivers/pci/pci-stub.o
  CC [M]  drivers/gpu/drm/scheduler/sched_entity.o
  CC      drivers/pci/vgaarb.o
  CC      drivers/iommu/irq_remapping.o
  CC      fs/nfs/nfstrace.o
  CC      fs/nfs/export.o
  CC [M]  crypto/ccm.o
  CC      fs/btrfs/transaction.o
  AR      kernel/bpf/built-in.a
  CC [M]  arch/x86/kvm/debugfs.o
  AR      kernel/cgroup/built-in.a
  CC      fs/btrfs/inode.o
  CC [M]  crypto/arc4.o
  CC      drivers/acpi/acpica/exsystem.o
  CC      drivers/base/init.o
  CC      sound/last.o
  LD [M]  net/ipv6/netfilter/nf_defrag_ipv6.o
  CC      net/ipv6/af_inet6.o
  CC [M]  sound/hda/intel-sdw-acpi.o
  CC      net/unix/diag.o
  CC      kernel/cpu.o
  CC      arch/x86/kernel/probe_roms.o
  CC      arch/x86/kernel/sys_ia32.o
  AR      block/built-in.a
  LD [M]  sound/hda/snd-hda-core.o
  CC      net/ipv4/tcp_cong.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o
  CC      mm/mlock.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_device.o
  CC      drivers/tty/tty_ldisc.o
  CC      drivers/acpi/acpica/extrace.o
  CC      kernel/exit.o
  CC      net/ipv4/tcp_metrics.o
  CC      mm/mmap.o
  CC [M]  drivers/gpu/drm/ttm/ttm_bo_vm.o
  CC [M]  fs/overlayfs/inode.o
  CC [M]  fs/fuse/xattr.o
  AR      drivers/iommu/built-in.a
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.o
  CC      kernel/softirq.o
  CC      drivers/base/map.o
  LD [M]  sound/hda/snd-intel-dspcfg.o
  LD [M]  sound/hda/snd-intel-sdw-acpi.o
  AR      sound/built-in.a
  CC      kernel/resource.o
  CC      drivers/acpi/acpica/exutils.o
  CC      lib/logic_pio.o
  LD [M]  drivers/gpu/drm/scheduler/gpu-sched.o
  CC [M]  crypto/ecc.o
  CC      kernel/trace/ring_buffer.o
  CC      arch/x86/kernel/signal_32.o
  CC      net/packet/diag.o
  CC      drivers/tty/tty_buffer.o
  CC [M]  arch/x86/kvm/mmu/mmu.o
  CC      mm/mmu_gather.o
  CC [M]  crypto/essiv.o
  CC [M]  drivers/gpu/drm/ttm/ttm_module.o
  CC      drivers/block/loop.o
  AR      drivers/pci/built-in.a
  CC      kernel/time/posix-cpu-timers.o
  CC [M]  fs/cifs/misc.o
  AR      drivers/misc/eeprom/built-in.a
  AR      drivers/misc/cb710/built-in.a
  AR      drivers/misc/ti-st/built-in.a
  AR      drivers/misc/lis3lv02d/built-in.a
  AR      drivers/misc/cardreader/built-in.a
  CC      net/xfrm/xfrm_input.o
  CC [M]  drivers/misc/mei/hdcp/mei_hdcp.o
  CC      net/unix/scm.o
  CC      drivers/base/devres.o
  CC      drivers/acpi/acpica/hwacpi.o
  CC      mm/mprotect.o
  AR      net/key/built-in.a
  CC [M]  fs/cifs/netmisc.o
  CC      net/ipv4/tcp_fastopen.o
  CC [M]  fs/fuse/acl.o
  CC [M]  drivers/gpu/drm/ttm/ttm_execbuf_util.o
  CC      lib/maple_tree.o
  CC      fs/ext4/ioctl.o
  CC [M]  drivers/gpu/drm/ttm/ttm_range_manager.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.o
  CC      drivers/acpi/acpica/hwesleep.o
  CC [M]  fs/overlayfs/file.o
  CC      drivers/tty/tty_port.o
  CC      drivers/tty/tty_mutex.o
  CC      arch/x86/kernel/sys_x86_64.o
  CC      net/ipv6/anycast.o
  CC      drivers/tty/tty_ldsem.o
  CC [M]  drivers/gpu/drm/ttm/ttm_resource.o
  CC      mm/mremap.o
  CC      lib/memcat_p.o
  AR      net/bridge/netfilter/built-in.a
  CC      net/bridge/br.o
  CC      fs/open.o
  CC      net/ipv4/tcp_rate.o
  CC [M]  net/sunrpc/auth_gss/auth_gss.o
  CC [M]  fs/fuse/readdir.o
  CC [M]  drivers/gpu/drm/ttm/ttm_pool.o
  AR      net/packet/built-in.a
  CC      net/sunrpc/clnt.o
  CC      drivers/base/attribute_container.o
  CC [M]  drivers/misc/mei/pxp/mei_pxp.o
  CC      drivers/acpi/acpica/hwgpe.o
  AR      net/unix/built-in.a
  CC [M]  fs/cifs/smbencrypt.o
  CC      net/core/ptp_classifier.o
  CC [M]  drivers/gpu/drm/ttm/ttm_device.o
  CC      drivers/mfd/mfd-core.o
  CC      net/xfrm/xfrm_output.o
  CC      net/xfrm/xfrm_sysctl.o
  CC [M]  drivers/gpu/drm/ttm/ttm_sys_manager.o
  CC [M]  drivers/gpu/drm/i915/i915_driver.o
  CC [M]  drivers/gpu/drm/i915/i915_drm_client.o
  CC      kernel/time/posix-clock.o
  CC      arch/x86/kernel/espfix_64.o
  CC      net/8021q/vlan_core.o
  CC      net/ipv4/tcp_recovery.o
  CC      kernel/time/itimer.o
  CC      drivers/tty/tty_baudrate.o
  CC      kernel/time/clockevents.o
  CC [M]  crypto/ecdh.o
  CC [M]  fs/overlayfs/dir.o
  CC [M]  crypto/ecdh_helper.o
  CC      drivers/base/transport_class.o
  CC      drivers/acpi/acpica/hwregs.o
  CC      net/xfrm/xfrm_replay.o
  CC      net/ipv4/tcp_ulp.o
  CC [M]  drivers/misc/mei/init.o
  CC [M]  fs/overlayfs/readdir.o
  CC      net/xfrm/xfrm_device.o
  AR      drivers/misc/built-in.a
  CC      drivers/mfd/intel-lpss.o
  CC      drivers/block/virtio_blk.o
  CC [M]  drivers/gpu/drm/ttm/ttm_agp_backend.o
  CC [M]  fs/fuse/ioctl.o
  CC      drivers/mfd/intel-lpss-pci.o
  CC      drivers/mfd/intel-lpss-acpi.o
  CC [M]  fs/cifs/transport.o
  CC      net/ipv6/ip6_output.o
  CC      net/bridge/br_device.o
  CC      net/sunrpc/xprt.o
  CC      drivers/tty/tty_jobctrl.o
  CC      drivers/base/topology.o
  CC [M]  drivers/block/nbd.o
  CC      net/ipv6/ip6_input.o
  CC      drivers/tty/n_null.o
  CC      arch/x86/kernel/ksysfs.o
  CC      net/core/netprio_cgroup.o
  CC      drivers/base/container.o
  LD [M]  crypto/ecdh_generic.o
  AR      crypto/built-in.a
  CC      drivers/acpi/acpica/hwsleep.o
  CC      fs/ext4/mballoc.o
  CC      mm/msync.o
  CC      net/ipv6/addrconf.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/atombios_crtc.o
  CC      arch/x86/kernel/bootflag.o
  CC [M]  drivers/gpu/drm/xe/tests/xe_bo_test.o
  CC      arch/x86/kernel/e820.o
  CC [M]  drivers/misc/mei/hbm.o
  CC      kernel/time/tick-common.o
  CC      net/ipv4/tcp_offload.o
  CC      kernel/trace/trace.o
  CC      drivers/acpi/acpi_apd.o
  AR      drivers/nfc/built-in.a
  CC      drivers/acpi/acpi_platform.o
  LD [M]  drivers/gpu/drm/ttm/ttm.o
  CC      drivers/mfd/intel_soc_pmic_crc.o
  CC      net/ipv4/tcp_plb.o
  AR      drivers/dax/hmem/built-in.a
  CC      drivers/dax/super.o
  CC [M]  drivers/gpu/drm/xe/xe_bb.o
  CC      drivers/dax/bus.o
  CC      kernel/sysctl.o
  CC [M]  net/8021q/vlan.o
  CC      drivers/acpi/acpica/hwvalid.o
  CC      drivers/base/property.o
  CC [M]  net/8021q/vlan_dev.o
  CC      net/sunrpc/socklib.o
  CC [M]  drivers/gpu/drm/xe/tests/xe_dma_buf_test.o
  CC      net/ipv6/addrlabel.o
  LD [M]  fs/fuse/fuse.o
  CC      lib/nmi_backtrace.o
  CC      net/bridge/br_fdb.o
  CC      drivers/tty/pty.o
  CC [M]  fs/overlayfs/copy_up.o
  CC [M]  drivers/gpu/drm/i915/i915_config.o
  CC      arch/x86/kernel/pci-dma.o
  CC      mm/page_vma_mapped.o
  CC      net/dcb/dcbnl.o
  CC      net/sunrpc/xprtsock.o
  CC      drivers/acpi/acpi_pnp.o
  CC      net/xfrm/xfrm_algo.o
  CC      mm/pagewalk.o
  CC      drivers/acpi/acpica/hwxface.o
  CC [M]  drivers/gpu/drm/xe/tests/xe_migrate_test.o
  CC      net/core/dst_cache.o
  CC [M]  net/sunrpc/auth_gss/gss_generic_token.o
  CC      net/bridge/br_forward.o
  CC [M]  drivers/gpu/drm/i915/i915_getparam.o
  CC      mm/pgtable-generic.o
  CC [M]  drivers/mfd/lpc_sch.o
  CC      fs/nfs/sysfs.o
  CC [M]  net/sunrpc/auth_gss/gss_mech_switch.o
  CC      net/xfrm/xfrm_user.o
  CC      kernel/time/tick-broadcast.o
  CC      arch/x86/kernel/quirks.o
  CC      net/core/gro_cells.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.o
  CC [M]  drivers/misc/mei/interrupt.o
  CC [M]  drivers/misc/mei/client.o
  CC [M]  drivers/gpu/drm/xe/tests/xe_pci_test.o
  CC      kernel/events/ring_buffer.o
  CC [M]  drivers/gpu/drm/xe/tests/xe_rtp_test.o
  CC      drivers/acpi/acpica/hwxfsleep.o
  CC      net/dcb/dcbevent.o
  CC      drivers/tty/sysrq.o
  CC      net/sunrpc/sched.o
  CC      net/ipv4/datagram.o
  CC      drivers/base/cacheinfo.o
  AR      drivers/dax/built-in.a
  CC      drivers/dma-buf/dma-buf.o
  CC      kernel/capability.o
  AR      drivers/cxl/core/built-in.a
  AR      drivers/cxl/built-in.a
  CC      kernel/ptrace.o
  CC [M]  net/8021q/vlan_netlink.o
  CC [M]  fs/overlayfs/export.o
  CC      kernel/user.o
  CC      drivers/base/swnode.o
  CC      net/sunrpc/auth.o
  CC      net/sunrpc/auth_null.o
  CC [M]  drivers/mfd/lpc_ich.o
  CC      mm/rmap.o
  CC      drivers/acpi/acpica/hwpci.o
  CC      kernel/time/tick-broadcast-hrtimer.o
  CC      kernel/time/tick-oneshot.o
  CC      arch/x86/kernel/topology.o
  CC [M]  fs/cifs/cached_dir.o
  CC [M]  net/8021q/vlanproc.o
  CC [M]  fs/cifs/cifs_unicode.o
  CC [M]  drivers/gpu/drm/i915/i915_ioctl.o
  CC      net/sunrpc/auth_unix.o
  CC      arch/x86/kernel/kdebugfs.o
  CC      fs/nfs/fs_context.o
  CC      net/core/failover.o
  CC [M]  drivers/gpu/drm/xe/tests/xe_wa_test.o
  CC      fs/nfs/sysctl.o
  CC [M]  drivers/gpu/drm/vgem/vgem_drv.o
  CC      arch/x86/kernel/alternative.o
  CC      drivers/acpi/acpica/nsaccess.o
  CC [M]  drivers/gpu/drm/vgem/vgem_fence.o
  CC      net/bridge/br_if.o
  CC [M]  arch/x86/kvm/mmu/page_track.o
  CC [M]  net/sunrpc/auth_gss/svcauth_gss.o
  AR      drivers/block/built-in.a
  CC      kernel/time/tick-sched.o
  AR      drivers/macintosh/built-in.a
  AR      drivers/tty/built-in.a
  CC      drivers/scsi/scsi.o
  CC      drivers/acpi/acpica/nsalloc.o
  CC      drivers/base/auxiliary.o
  CC      kernel/events/callchain.o
  CC      drivers/scsi/hosts.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/atom.o
  LD [M]  fs/overlayfs/overlay.o
  CC      fs/read_write.o
  AR      drivers/mfd/built-in.a
  CC [M]  drivers/gpu/drm/xe/xe_bo.o
  CC      drivers/base/devtmpfs.o
  AR      net/dcb/built-in.a
  CC      net/sunrpc/svc.o
  CC      net/ipv4/raw.o
  CC      drivers/nvme/host/core.o
  CC      drivers/nvme/host/ioctl.o
  CC      net/ipv4/udp.o
  CC      drivers/dma-buf/dma-fence.o
  CC      kernel/time/vsyscall.o
  CC      fs/file_table.o
  CC      drivers/acpi/acpica/nsarguments.o
  CC      kernel/signal.o
  CC      net/sunrpc/svcsock.o
  AR      net/8021q/built-in.a
  CC      fs/nfs/nfs2super.o
  LD [M]  net/8021q/8021q.o
  CC      fs/btrfs/file.o
  CC      fs/super.o
  CC [M]  drivers/misc/mei/main.o
  CC [M]  drivers/gpu/drm/xe/xe_bo_evict.o
  LD [M]  drivers/gpu/drm/vgem/vgem.o
  CC      drivers/scsi/scsi_ioctl.o
  CC [M]  drivers/gpu/drm/i915/i915_irq.o
  AR      net/core/built-in.a
  CC      net/bridge/br_input.o
  CC      kernel/time/timekeeping_debug.o
  CC [M]  arch/x86/kvm/mmu/spte.o
  CC [M]  drivers/misc/mei/dma-ring.o
  CC      fs/nfs/proc.o
  CC      drivers/base/memory.o
  CC      drivers/scsi/scsicam.o
  CC      drivers/scsi/scsi_error.o
  CC      kernel/events/hw_breakpoint.o
  CC      drivers/acpi/acpica/nsconvert.o
  CC      drivers/scsi/scsi_lib.o
  CC      net/ipv4/udplite.o
  CC      drivers/scsi/scsi_lib_dma.o
  CC [M]  fs/cifs/nterr.o
  CC [M]  fs/cifs/cifsencrypt.o
  CC      arch/x86/kernel/i8253.o
  CC      net/sunrpc/svcauth.o
  CC      net/sunrpc/svcauth_unix.o
  CC      kernel/time/namespace.o
  CC      fs/nfs/nfs2xdr.o
  CC      drivers/scsi/scsi_scan.o
  CC      lib/plist.o
  GEN     drivers/scsi/scsi_devinfo_tbl.c
  CC [M]  drivers/misc/mei/bus.o
  AR      net/xfrm/built-in.a
  CC      net/sunrpc/addr.o
  CC      drivers/scsi/scsi_devinfo.o
  CC      drivers/acpi/acpica/nsdump.o
  CC      net/ipv4/udp_offload.o
  CC [M]  arch/x86/kvm/mmu/tdp_iter.o
  CC      lib/radix-tree.o
  CC [M]  drivers/gpu/drm/xe/xe_debugfs.o
  CC      net/l3mdev/l3mdev.o
  CC      fs/nfs/nfs3super.o
  CC      drivers/base/module.o
  CC      drivers/dma-buf/dma-fence-array.o
  CC [M]  drivers/misc/mei/bus-fixup.o
  CC [M]  fs/cifs/readdir.o
  CC      arch/x86/kernel/hw_breakpoint.o
  CC      net/ipv6/route.o
  CC [M]  drivers/gpu/drm/xe/xe_devcoredump.o
  CC      mm/vmalloc.o
  CC      drivers/acpi/acpica/nseval.o
  CC      kernel/trace/trace_output.o
  CC      kernel/trace/trace_seq.o
  CC      fs/nfs/nfs3client.o
  CC      net/bridge/br_ioctl.o
  CC      drivers/base/pinctrl.o
  CC      drivers/base/devcoredump.o
  CC      mm/page_alloc.o
  AR      kernel/time/built-in.a
  CC [M]  net/sunrpc/auth_gss/gss_rpc_upcall.o
  CC      drivers/gpu/drm/drm_mipi_dsi.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.o
  CC [M]  drivers/gpu/drm/ast/ast_drv.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/object.o
  CC      drivers/dma-buf/dma-fence-chain.o
  CC [M]  drivers/gpu/drm/ast/ast_i2c.o
  CC      kernel/events/uprobes.o
  CC      drivers/acpi/acpica/nsinit.o
  CC      fs/nfs/nfs3proc.o
  CC [M]  arch/x86/kvm/mmu/tdp_mmu.o
  CC      drivers/acpi/acpica/nsload.o
  CC      drivers/base/platform-msi.o
  CC [M]  drivers/gpu/drm/ast/ast_main.o
  AR      drivers/nvme/target/built-in.a
  AR      net/l3mdev/built-in.a
  CC      drivers/acpi/power.o
  CC      net/sunrpc/rpcb_clnt.o
  CC      drivers/acpi/event.o
  CC      drivers/acpi/acpica/nsnames.o
  CC [M]  drivers/gpu/drm/xe/xe_device.o
  CC [M]  drivers/misc/mei/debugfs.o
  CC      kernel/trace/trace_stat.o
  CC [M]  net/bluetooth/af_bluetooth.o
  CC [M]  net/bluetooth/hci_core.o
  CC      arch/x86/kernel/tsc.o
  CC      lib/ratelimit.o
  CC [M]  net/bluetooth/hci_conn.o
  CC      drivers/base/physical_location.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/client.o
  CC [M]  drivers/gpu/drm/i915/i915_mitigations.o
  CC      fs/ext4/migrate.o
  CC      fs/nfs/nfs3xdr.o
  CC      drivers/acpi/acpica/nsobject.o
  CC      lib/rbtree.o
  CC      drivers/dma-buf/dma-fence-unwrap.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.o
  CC      drivers/scsi/scsi_sysctl.o
  CC [M]  net/bluetooth/hci_event.o
  CC      net/ipv4/arp.o
  CC [M]  drivers/gpu/drm/xe/xe_dma_buf.o
  CC      mm/init-mm.o
  CC      kernel/sys.o
  CC [M]  drivers/gpu/drm/ast/ast_mm.o
  CC [M]  net/sunrpc/auth_gss/gss_rpc_xdr.o
  CC [M]  net/bluetooth/mgmt.o
  CC      drivers/scsi/scsi_debugfs.o
  CC [M]  drivers/misc/mei/mei-trace.o
  CC      net/bridge/br_stp.o
  CC      net/bridge/br_stp_bpdu.o
  CC      lib/seq_buf.o
  CC      kernel/trace/trace_printk.o
  CC [M]  net/sunrpc/auth_gss/trace.o
  CC      drivers/base/trace.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_object.o
  CC [M]  drivers/gpu/drm/ast/ast_mode.o
  CC      drivers/acpi/acpica/nsparse.o
  CC [M]  arch/x86/kvm/smm.o
  CC      net/bridge/br_stp_if.o
  CC      drivers/dma-buf/dma-resv.o
  CC      net/bridge/br_stp_timer.o
  CC      fs/char_dev.o
  CC [M]  fs/cifs/ioctl.o
  CC      mm/memblock.o
  CC      net/ipv6/ip6_fib.o
  CC      fs/btrfs/defrag.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/conn.o
  CC      drivers/dma-buf/sync_file.o
  CC      arch/x86/kernel/tsc_msr.o
  CC      fs/ext4/mmp.o
  CC      drivers/acpi/acpica/nspredef.o
  CC [M]  drivers/gpu/drm/i915/i915_module.o
  CC      drivers/dma-buf/sw_sync.o
  CC      drivers/scsi/scsi_trace.o
  CC      lib/show_mem.o
  CC      fs/stat.o
  CC      arch/x86/kernel/io_delay.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/device.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_gart.o
  CC      fs/ext4/move_extent.o
  CC [M]  drivers/gpu/drm/xe/xe_engine.o
  CC [M]  drivers/misc/mei/pci-me.o
  CC      drivers/nvme/host/trace.o
  AR      drivers/base/built-in.a
  CC      kernel/trace/pid_list.o
  CC [M]  drivers/gpu/drm/ast/ast_post.o
  AR      kernel/events/built-in.a
  CC      kernel/umh.o
  CC [M]  drivers/gpu/drm/ast/ast_dp501.o
  CC      drivers/acpi/acpica/nsprepkg.o
  CC      fs/ext4/namei.o
  CC [M]  drivers/gpu/drm/i915/i915_params.o
  CC      fs/exec.o
  CC      arch/x86/kernel/rtc.o
  CC      fs/btrfs/extent_map.o
  CC      lib/siphash.o
  CC      net/bridge/br_netlink.o
  CC      drivers/acpi/acpica/nsrepair.o
  CC [M]  net/sunrpc/auth_gss/gss_krb5_mech.o
  CC      fs/pipe.o
  CC      drivers/ata/libata-core.o
  CC      net/bridge/br_netlink_tunnel.o
  CC [M]  arch/x86/kvm/vmx/vmx.o
  CC      drivers/scsi/scsi_logging.o
  CC      drivers/ata/libata-scsi.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/disp.o
  CC [M]  drivers/misc/mei/hw-me.o
  CC      drivers/dma-buf/sync_debug.o
  CC      lib/string.o
  CC      net/ipv4/icmp.o
  CC      kernel/workqueue.o
  AR      fs/nfs/built-in.a
  CC      net/ipv6/ipv6_sockglue.o
  CC      drivers/nvme/host/pci.o
  CC      kernel/trace/trace_sched_switch.o
  CC [M]  drivers/gpu/drm/ast/ast_dp.o
  CC      net/bridge/br_arp_nd_proxy.o
  CC      lib/timerqueue.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.o
  CC      drivers/acpi/acpica/nsrepair2.o
  CC      fs/namei.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/driver.o
  CC [M]  fs/cifs/sess.o
  CC      arch/x86/kernel/resource.o
  CC [M]  fs/cifs/export.o
  CC [M]  drivers/misc/mei/gsc-me.o
  CC      net/ipv4/devinet.o
  CC      kernel/trace/trace_functions.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/event.o
  CC      mm/memory_hotplug.o
  AS      arch/x86/kernel/irqflags.o
  CC [M]  drivers/gpu/drm/xe/xe_exec.o
  CC      arch/x86/kernel/static_call.o
  CC [M]  drivers/gpu/drm/i915/i915_pci.o
  CC [M]  drivers/dma-buf/selftest.o
  CC      drivers/scsi/scsi_pm.o
  CC [M]  net/sunrpc/auth_gss/gss_krb5_seal.o
  CC [M]  net/sunrpc/auth_gss/gss_krb5_unseal.o
  CC      lib/vsprintf.o
  CC      drivers/acpi/acpica/nssearch.o
  CC      net/bridge/br_sysfs_if.o
  CC      drivers/spi/spi.o
  CC [M]  net/sunrpc/auth_gss/gss_krb5_seqnum.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/fifo.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/head.o
  CC      net/sunrpc/timer.o
  LD [M]  drivers/gpu/drm/ast/ast.o
  CC      kernel/trace/trace_preemptirq.o
  CC      net/bridge/br_sysfs_br.o
  CC      fs/ext4/page-io.o
  CC      arch/x86/kernel/process.o
  CC [M]  arch/x86/kvm/kvm-asm-offsets.s
  CC [M]  drivers/gpu/drm/nouveau/nvif/mem.o
  CC      kernel/pid.o
  CC [M]  drivers/dma-buf/st-dma-fence.o
  CC      drivers/ata/libata-eh.o
  CC      fs/btrfs/sysfs.o
  CC      drivers/acpi/acpica/nsutils.o
  CC      fs/btrfs/accessors.o
  CC      arch/x86/kernel/ptrace.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_display.o
  CC      drivers/ata/libata-transport.o
  CC      kernel/trace/trace_nop.o
  CC      kernel/task_work.o
  CC      kernel/trace/trace_functions_graph.o
  CC      drivers/scsi/scsi_bsg.o
  CC [M]  drivers/gpu/drm/xe/xe_execlist.o
  CC      net/bridge/br_nf_core.o
  CC [M]  net/sunrpc/auth_gss/gss_krb5_wrap.o
  CC      drivers/acpi/evged.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/mmu.o
  CC [M]  drivers/gpu/drm/i915/i915_scatterlist.o
  CC      kernel/extable.o
  LD [M]  drivers/misc/mei/mei.o
  LD [M]  drivers/misc/mei/mei-me.o
  CC      drivers/acpi/acpica/nswalk.o
  CC      fs/ext4/readpage.o
  LD [M]  drivers/misc/mei/mei-gsc.o
  CC      net/bridge/br_multicast.o
  CC      drivers/net/phy/mdio-boardinfo.o
  CC      kernel/trace/fgraph.o
  CC      drivers/net/phy/mdio_devres.o
  CC [M]  drivers/dma-buf/st-dma-fence-chain.o
  CC      arch/x86/kernel/tls.o
  CC [M]  drivers/gpu/drm/xe/xe_force_wake.o
  CC      drivers/acpi/sysfs.o
  AR      drivers/net/pse-pd/built-in.a
  CC      kernel/params.o
  CC      kernel/trace/blktrace.o
  CC      drivers/scsi/scsi_common.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/outp.o
  CC      net/bridge/br_mdb.o
  CC [M]  arch/x86/kvm/vmx/pmu_intel.o
  CC      net/ipv4/af_inet.o
  CC      drivers/ata/libata-trace.o
  CC      drivers/acpi/acpica/nsxfeval.o
  CC      net/sunrpc/xdr.o
  CC [M]  net/sunrpc/auth_gss/gss_krb5_crypto.o
  CC [M]  net/sunrpc/auth_gss/gss_krb5_keys.o
  CC      drivers/net/phy/phy.o
  CC [M]  drivers/gpu/drm/xe/xe_ggtt.o
  CC      arch/x86/kernel/step.o
  CC [M]  arch/x86/kvm/vmx/vmcs12.o
  CC      net/ipv4/igmp.o
  CC      mm/madvise.o
  CC      drivers/scsi/sd.o
  CC [M]  fs/cifs/unc.o
  CC      arch/x86/kernel/i8237.o
  CC      drivers/net/phy/phy-c45.o
  CC [M]  arch/x86/kvm/vmx/hyperv.o
  CC      kernel/kthread.o
  AR      drivers/nvme/host/built-in.a
  CC      mm/page_io.o
  CC      net/bridge/br_multicast_eht.o
  AR      drivers/nvme/built-in.a
  CC      drivers/scsi/sg.o
  CC      net/ipv6/ndisc.o
  CC [M]  drivers/gpu/drm/i915/i915_suspend.o
  CC      fs/ext4/resize.o
  CC      drivers/acpi/acpica/nsxfname.o
  CC      fs/btrfs/xattr.o
  CC      drivers/acpi/property.o
  CC      net/ipv4/fib_frontend.o
  CC      fs/ext4/super.o
  CC      drivers/acpi/acpica/nsxfobj.o
  CC [M]  drivers/gpu/drm/xe/xe_gt.o
  CC      kernel/trace/trace_events.o
  CC      arch/x86/kernel/stacktrace.o
  CC [M]  drivers/dma-buf/st-dma-fence-unwrap.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/timer.o
  LD [M]  net/sunrpc/auth_gss/auth_rpcgss.o
  CC [M]  net/dns_resolver/dns_key.o
  CC      drivers/ata/libata-sata.o
  CC [M]  net/dns_resolver/dns_query.o
  CC      drivers/ata/libata-sff.o
  CC [M]  drivers/gpu/drm/i915/i915_switcheroo.o
  CC      lib/win_minmax.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/vmm.o
  CC      drivers/acpi/acpica/psargs.o
  CC      kernel/sys_ni.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.o
  CC      kernel/nsproxy.o
  LD [M]  net/sunrpc/auth_gss/rpcsec_gss_krb5.o
  CC      net/sunrpc/sunrpc_syms.o
  CC      arch/x86/kernel/reboot.o
  CC      arch/x86/kernel/msr.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/user.o
  CC [M]  drivers/dma-buf/st-dma-resv.o
  CC      fs/fcntl.o
  CC      lib/xarray.o
  CC      kernel/trace/trace_export.o
  CC [M]  fs/cifs/winucase.o
  CC      mm/swap_state.o
  CC      net/bridge/br_vlan.o
  CC      mm/swapfile.o
  CC [M]  fs/cifs/smb2ops.o
  CC      drivers/net/phy/phy-core.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.o
  CC      lib/lockref.o
  CC      drivers/acpi/acpica/psloop.o
  LD [M]  net/dns_resolver/dns_resolver.o
  CC      fs/ioctl.o
  CC      arch/x86/kernel/cpuid.o
  CC [M]  drivers/gpu/drm/xe/xe_gt_clock.o
  CC      drivers/acpi/acpi_cmos_rtc.o
  CC      kernel/notifier.o
  CC      fs/btrfs/ordered-data.o
  CC [M]  fs/cifs/smb2maperror.o
  CC      drivers/acpi/acpica/psobject.o
  CC      drivers/acpi/acpica/psopcode.o
  CC      net/devres.o
  CC      kernel/ksysfs.o
  CC [M]  drivers/gpu/drm/i915/i915_sysfs.o
  AR      drivers/dma-buf/built-in.a
  CC      fs/btrfs/extent_io.o
  LD [M]  drivers/dma-buf/dmabuf_selftests.o
  CC      drivers/acpi/x86/apple.o
  AR      drivers/spi/built-in.a
  CC      fs/btrfs/volumes.o
  CC [M]  drivers/gpu/drm/xe/xe_gt_debugfs.o
  AR      drivers/firewire/built-in.a
  AR      drivers/cdrom/built-in.a
  CC      net/ipv4/fib_semantics.o
  AR      drivers/auxdisplay/built-in.a
  CC      drivers/ata/libata-pmp.o
  CC      drivers/usb/common/common.o
  CC      drivers/ata/libata-acpi.o
  CC      kernel/cred.o
  CC      kernel/reboot.o
  CC [M]  drivers/gpu/drm/nouveau/nvif/userc361.o
  CC      drivers/usb/core/usb.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/client.o
  CC      drivers/usb/core/hub.o
  CC [M]  net/bluetooth/hci_sock.o
  CC      arch/x86/kernel/early-quirks.o
  CC      drivers/input/serio/serio.o
  CC [M]  drivers/gpu/drm/i915/i915_utils.o
  CC      drivers/input/keyboard/atkbd.o
  CC      drivers/acpi/acpica/psopinfo.o
  CC [M]  drivers/gpu/drm/xe/xe_gt_mcr.o
  CC      kernel/trace/trace_event_perf.o
  CC      drivers/input/serio/i8042.o
  CC      drivers/acpi/x86/utils.o
  CC      net/ipv4/fib_trie.o
  CC [M]  drivers/gpu/drm/xe/xe_gt_pagefault.o
  CC      net/sunrpc/cache.o
  CC [M]  drivers/gpu/drm/xe/xe_gt_sysfs.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.o
  CC      drivers/net/phy/phy_device.o
  CC      mm/swap_slots.o
  CC      net/socket.o
  CC [M]  arch/x86/kvm/vmx/nested.o
  CC      drivers/scsi/scsi_sysfs.o
  CC      lib/bcd.o
  CC      lib/sort.o
  CC      drivers/acpi/acpica/psparse.o
  CC      drivers/acpi/acpica/psscope.o
  CC      drivers/net/phy/linkmode.o
  CC      net/ipv6/udp.o
  CC      drivers/usb/common/debug.o
  CC      drivers/usb/core/hcd.o
  CC      drivers/acpi/x86/s2idle.o
  CC      fs/ext4/symlink.o
  AR      drivers/usb/common/built-in.a
  AR      drivers/input/mouse/built-in.a
  CC      drivers/rtc/lib.o
  CC      drivers/input/input.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/engine.o
  CC      lib/parser.o
  CC      drivers/rtc/class.o
  CC [M]  net/bluetooth/hci_sysfs.o
  CC      arch/x86/kernel/smp.o
  CC      drivers/input/input-compat.o
  CC      drivers/acpi/acpica/pstree.o
  CC [M]  drivers/gpu/drm/drm_aperture.o
  CC      drivers/rtc/interface.o
  AR      drivers/i2c/algos/built-in.a
  CC [M]  drivers/i2c/algos/i2c-algo-bit.o
  CC [M]  drivers/gpu/drm/i915/intel_clock_gating.o
  CC      drivers/ata/libata-pata-timings.o
  CC      drivers/i2c/busses/i2c-designware-common.o
  CC      drivers/acpi/acpica/psutils.o
  CC      kernel/trace/trace_events_filter.o
  CC      kernel/trace/trace_events_trigger.o
  CC      drivers/acpi/acpica/pswalk.o
  CC [M]  drivers/gpu/drm/i915/intel_device_info.o
  CC      drivers/input/input-mt.o
  AR      drivers/input/keyboard/built-in.a
  CC      drivers/input/input-poller.o
  CC      lib/debug_locks.o
  AR      drivers/i2c/muxes/built-in.a
  CC [M]  drivers/i2c/muxes/i2c-mux-gpio.o
  CC      lib/random32.o
  CC      drivers/input/ff-core.o
  CC      drivers/i2c/i2c-boardinfo.o
  CC [M]  drivers/gpu/drm/i915/intel_memory_region.o
  CC [M]  drivers/gpu/drm/i915/intel_pcode.o
  CC      drivers/acpi/acpica/psxface.o
  CC [M]  drivers/gpu/drm/i915/intel_region_ttm.o
  CC [M]  drivers/gpu/drm/drm_atomic.o
  CC      drivers/input/serio/libps2.o
  CC      fs/btrfs/async-thread.o
  CC [M]  drivers/gpu/drm/xe/xe_gt_tlb_invalidation.o
  CC      drivers/rtc/nvmem.o
  CC      drivers/acpi/debugfs.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/enum.o
  CC      mm/dmapool.o
  CC      lib/bust_spinlocks.o
  CC      drivers/ata/ahci.o
  CC      kernel/async.o
  CC [M]  net/bluetooth/l2cap_core.o
  CC      drivers/i2c/busses/i2c-designware-master.o
  CC      kernel/range.o
  CC      arch/x86/kernel/smpboot.o
  CC [M]  drivers/gpu/drm/xe/xe_gt_topology.o
  CC      drivers/i2c/i2c-core-base.o
  CC      mm/hugetlb.o
  CC      drivers/acpi/acpica/rsaddr.o
  AR      drivers/scsi/built-in.a
  CC      drivers/i2c/i2c-core-smbus.o
  CC      arch/x86/kernel/tsc_sync.o
  CC      drivers/input/touchscreen.o
  CC [M]  net/bluetooth/l2cap_sock.o
  CC      net/bridge/br_vlan_tunnel.o
  CC [M]  drivers/gpu/drm/i915/intel_runtime_pm.o
  CC      drivers/i2c/i2c-core-acpi.o
  CC      drivers/i2c/i2c-core-slave.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/event.o
  AR      drivers/input/serio/built-in.a
  AR      drivers/i3c/built-in.a
  CC      drivers/ata/libahci.o
  CC      drivers/net/phy/mdio_bus.o
  CC [M]  net/bluetooth/smp.o
  CC      drivers/acpi/acpica/rscalc.o
  CC      lib/kasprintf.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_bios.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/firmware.o
  CC      kernel/smpboot.o
  CC [M]  net/bluetooth/lib.o
  CC      drivers/i2c/busses/i2c-designware-platdrv.o
  CC      net/bridge/br_vlan_options.o
  CC      drivers/acpi/acpica/rscreate.o
  CC      drivers/usb/core/urb.o
  CC      drivers/rtc/dev.o
  CC      lib/bitmap.o
  CC [M]  drivers/gpu/drm/i915/intel_sbi.o
  CC [M]  net/bluetooth/ecdh_helper.o
  CC      kernel/trace/trace_eprobe.o
  CC [M]  net/bluetooth/hci_request.o
  CC      drivers/input/ff-memless.o
  CC [M]  drivers/gpu/drm/xe/xe_guc.o
  CC      drivers/acpi/acpi_lpat.o
  CC      drivers/acpi/acpi_lpit.o
  CC [M]  arch/x86/kvm/vmx/posted_intr.o
  CC      net/sunrpc/rpc_pipe.o
  CC      drivers/acpi/acpica/rsdumpinfo.o
  CC      net/ipv4/fib_notifier.o
  CC      net/ipv4/inet_fragment.o
  CC      net/sunrpc/sysfs.o
  CC      drivers/acpi/acpica/rsinfo.o
  CC [M]  drivers/gpu/drm/xe/xe_guc_ads.o
  CC [M]  fs/cifs/smb2transport.o
  CC      drivers/i2c/busses/i2c-designware-baytrail.o
  CC      fs/btrfs/ioctl.o
  CC      net/compat.o
  CC      drivers/net/phy/mdio_device.o
  CC      net/ipv4/ping.o
  CC [M]  drivers/gpu/drm/drm_atomic_uapi.o
  CC      drivers/rtc/proc.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/gpuobj.o
  CC      arch/x86/kernel/setup_percpu.o
  CC      arch/x86/kernel/ftrace.o
  AS      arch/x86/kernel/ftrace_64.o
  CC      net/ipv6/udplite.o
  CC      net/ipv6/raw.o
  CC      drivers/acpi/prmt.o
  CC      drivers/input/vivaldi-fmap.o
  CC      net/bridge/br_mst.o
  CC      drivers/rtc/sysfs.o
  CC      drivers/acpi/acpica/rsio.o
  CC [M]  fs/cifs/smb2misc.o
  CC      drivers/usb/core/message.o
  CC [M]  fs/cifs/smb2pdu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.o
  CC      lib/scatterlist.o
  CC      kernel/trace/trace_kprobe.o
  CC [M]  drivers/gpu/drm/i915/intel_step.o
  CC      kernel/ucount.o
  CC      arch/x86/kernel/trace_clock.o
  CC      drivers/input/input-leds.o
  CC      fs/btrfs/locking.o
  CC      drivers/rtc/rtc-mc146818-lib.o
  CC      drivers/rtc/rtc-cmos.o
  CC [M]  drivers/i2c/busses/i2c-scmi.o
  CC      drivers/acpi/acpica/rsirq.o
  CC [M]  drivers/gpu/drm/i915/intel_uncore.o
  CC [M]  net/bridge/br_netfilter_hooks.o
  CC      kernel/regset.o
  CC [M]  net/bridge/br_netfilter_ipv6.o
  CC      drivers/net/phy/swphy.o
  LD [M]  arch/x86/kvm/kvm.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/atombios_dp.o
  CC [M]  net/bluetooth/mgmt_util.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.o
  CC      drivers/net/phy/fixed_phy.o
  CC      net/sunrpc/svc_xprt.o
  CC      lib/list_sort.o
  CC      arch/x86/kernel/trace.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/intr.o
  CC      net/sunrpc/xprtmultipath.o
  CC      net/sunrpc/stats.o
  CC      lib/uuid.o
  CC [M]  drivers/net/phy/phylink.o
  CC      drivers/acpi/acpica/rslist.o
  CC      arch/x86/kernel/rethook.o
  CC [M]  drivers/gpu/drm/xe/xe_guc_ct.o
  CC      drivers/i2c/i2c-dev.o
  CC      drivers/ata/ata_piix.o
  CC      net/ipv4/ip_tunnel_core.o
  CC      drivers/input/mousedev.o
  CC      drivers/input/evdev.o
  CC      net/sysctl_net.o
  CC      arch/x86/kernel/crash_core_64.o
  CC      net/ipv6/icmp.o
  CC      net/sunrpc/sysctl.o
  CC      lib/iov_iter.o
  CC      drivers/usb/core/driver.o
  CC      arch/x86/kernel/module.o
  CC [M]  drivers/gpu/drm/drm_auth.o
  CC      net/ipv6/mcast.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_trace_points.o
  CC [M]  drivers/net/phy/aquantia_main.o
  CC [M]  drivers/i2c/busses/i2c-ccgx-ucsi.o
  CC      drivers/acpi/acpica/rsmemory.o
  AR      drivers/usb/phy/built-in.a
  CC [M]  fs/cifs/smb2inode.o
  CC      arch/x86/kernel/early_printk.o
  AR      drivers/rtc/built-in.a
  CC      arch/x86/kernel/hpet.o
  CC [M]  drivers/gpu/drm/drm_blend.o
  CC [M]  drivers/gpu/drm/drm_bridge.o
  CC      drivers/usb/core/config.o
  CC      drivers/acpi/acpica/rsmisc.o
  AR      net/bridge/built-in.a
  CC      kernel/kmod.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/atombios_encoders.o
  CC      drivers/usb/core/file.o
  CC [M]  drivers/i2c/busses/i2c-i801.o
  CC [M]  net/bluetooth/mgmt_config.o
  CC [M]  fs/cifs/smb2file.o
  CC [M]  drivers/net/phy/aquantia_hwmon.o
  CC [M]  fs/cifs/cifsacl.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/ioctl.o
  CC      net/ipv6/reassembly.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/memory.o
  CC      fs/ext4/sysfs.o
  CC      drivers/acpi/acpica/rsserial.o
  CC      fs/btrfs/orphan.o
  CC      drivers/net/mdio/acpi_mdio.o
  AR      drivers/net/pcs/built-in.a
  AR      drivers/net/ethernet/adi/built-in.a
  CC [M]  drivers/gpu/drm/i915/intel_wakeref.o
  AR      drivers/net/ethernet/alacritech/built-in.a
  AR      drivers/net/ethernet/amazon/built-in.a
  CC [M]  drivers/gpu/drm/i915/vlv_sideband.o
  AR      drivers/net/ethernet/aquantia/built-in.a
  CC      kernel/trace/error_report-traces.o
  CC [M]  drivers/gpu/drm/drm_cache.o
  AR      drivers/net/ethernet/asix/built-in.a
  AR      drivers/net/ethernet/cadence/built-in.a
  AR      drivers/net/ethernet/broadcom/built-in.a
  CC [M]  drivers/net/ethernet/broadcom/b44.o
  AR      drivers/ata/built-in.a
  CC      kernel/trace/power-traces.o
  CC [M]  drivers/i2c/i2c-smbus.o
  CC      net/ipv4/gre_offload.o
  AR      drivers/input/built-in.a
  CC      drivers/net/mdio/fwnode_mdio.o
  CC [M]  drivers/gpu/drm/drm_client.o
  CC      drivers/usb/host/pci-quirks.o
  CC      drivers/acpi/acpica/rsutils.o
  CC      drivers/usb/host/ehci-hcd.o
  CC [M]  net/bluetooth/hci_codec.o
  CC      net/ipv4/metrics.o
  CC [M]  drivers/gpu/drm/xe/xe_guc_debugfs.o
  CC [M]  net/bluetooth/eir.o
  CC      net/ipv4/netlink.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/mm.o
  AR      drivers/net/ethernet/cavium/common/built-in.a
  AR      drivers/net/ethernet/cavium/thunder/built-in.a
  CC      arch/x86/kernel/amd_nb.o
  AR      drivers/net/ethernet/cavium/liquidio/built-in.a
  AR      drivers/net/ethernet/cavium/octeon/built-in.a
  AR      drivers/net/ethernet/cavium/built-in.a
  CC [M]  drivers/gpu/drm/i915/vlv_suspend.o
  CC [M]  drivers/gpu/drm/i915/soc/intel_dram.o
  UPD     arch/x86/kvm/kvm-asm-offsets.h
  AS [M]  arch/x86/kvm/vmx/vmenter.o
  LD [M]  net/bridge/br_netfilter.o
  AR      drivers/net/usb/built-in.a
  CC [M]  drivers/net/usb/pegasus.o
  CC [M]  drivers/net/usb/rtl8150.o
  CC      net/ipv6/tcp_ipv6.o
  LD [M]  arch/x86/kvm/kvm-intel.o
  CC [M]  drivers/net/usb/r8152.o
  CC      fs/ext4/xattr.o
  CC [M]  drivers/gpu/drm/drm_client_modeset.o
  CC      drivers/usb/core/buffer.o
  CC      drivers/usb/core/sysfs.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/object.o
  CC      drivers/acpi/acpica/rsxface.o
  CC      fs/ext4/xattr_hurd.o
  CC [M]  drivers/net/ethernet/broadcom/bnx2.o
  CC      fs/btrfs/export.o
  AR      drivers/net/mdio/built-in.a
  CC [M]  drivers/net/ipvlan/ipvlan_core.o
  CC      fs/btrfs/tree-log.o
  CC [M]  drivers/net/vxlan/vxlan_core.o
  AR      net/sunrpc/built-in.a
  CC [M]  drivers/net/usb/asix_devices.o
  CC [M]  drivers/net/vxlan/vxlan_multicast.o
  CC [M]  drivers/gpu/drm/xe/xe_guc_hwconfig.o
  CC [M]  drivers/i2c/busses/i2c-isch.o
  CC [M]  fs/cifs/fs_context.o
  CC [M]  drivers/i2c/busses/i2c-ismt.o
  CC [M]  drivers/net/phy/ax88796b.o
  CC [M]  drivers/net/vxlan/vxlan_vnifilter.o
  CC [M]  drivers/gpu/drm/xe/xe_guc_log.o
  CC      arch/x86/kernel/kvm.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_sa.o
  AR      drivers/media/i2c/built-in.a
  AR      drivers/media/tuners/built-in.a
  CC      net/ipv4/nexthop.o
  CC [M]  drivers/gpu/drm/drm_color_mgmt.o
  AR      drivers/media/rc/keymaps/built-in.a
  AR      drivers/media/rc/built-in.a
  CC      drivers/acpi/acpica/tbdata.o
  CC      mm/hugetlb_vmemmap.o
  AR      drivers/media/common/b2c2/built-in.a
  CC [M]  drivers/i2c/i2c-mux.o
  AR      drivers/media/common/saa7146/built-in.a
  CC      net/ipv4/udp_tunnel_stub.o
  AR      drivers/media/common/siano/built-in.a
  AR      drivers/media/common/v4l2-tpg/built-in.a
  AR      drivers/media/platform/allegro-dvt/built-in.a
  AR      drivers/media/common/videobuf2/built-in.a
  AR      drivers/media/common/built-in.a
  AR      drivers/media/pci/ttpci/built-in.a
  AR      drivers/media/platform/amlogic/meson-ge2d/built-in.a
  AR      drivers/media/platform/amlogic/built-in.a
  AR      drivers/media/pci/b2c2/built-in.a
  AR      drivers/ptp/built-in.a
  AR      drivers/media/platform/amphion/built-in.a
  AR      drivers/media/pci/pluto2/built-in.a
  AR      drivers/power/reset/built-in.a
  CC [M]  drivers/ptp/ptp_clock.o
  AR      drivers/media/platform/aspeed/built-in.a
  AR      drivers/media/pci/dm1105/built-in.a
  CC      drivers/power/supply/power_supply_core.o
  AR      drivers/media/platform/atmel/built-in.a
  CC      drivers/hwmon/hwmon.o
  AR      drivers/media/pci/pt1/built-in.a
  AR      drivers/media/platform/cadence/built-in.a
  AR      drivers/media/pci/pt3/built-in.a
  AR      drivers/media/platform/chips-media/built-in.a
  AR      drivers/media/pci/mantis/built-in.a
  AR      drivers/media/platform/intel/built-in.a
  AR      drivers/media/pci/ngene/built-in.a
  AR      drivers/media/platform/marvell/built-in.a
  CC [M]  drivers/gpu/drm/i915/soc/intel_gmch.o
  AR      drivers/media/pci/ddbridge/built-in.a
  AR      drivers/media/pci/saa7146/built-in.a
  AR      drivers/media/platform/mediatek/jpeg/built-in.a
  AR      drivers/media/pci/smipcie/built-in.a
  AR      drivers/media/platform/mediatek/mdp/built-in.a
  AR      drivers/media/pci/netup_unidvb/built-in.a
  AR      drivers/media/platform/mediatek/vcodec/built-in.a
  AR      drivers/media/platform/mediatek/vpu/built-in.a
  AR      drivers/media/pci/intel/ipu3/built-in.a
  AR      drivers/media/pci/intel/built-in.a
  AR      drivers/media/usb/b2c2/built-in.a
  AR      drivers/media/platform/mediatek/mdp3/built-in.a
  AR      drivers/media/pci/built-in.a
  AR      drivers/media/platform/mediatek/built-in.a
  AR      drivers/media/usb/dvb-usb/built-in.a
  AR      drivers/media/usb/dvb-usb-v2/built-in.a
  AR      drivers/media/platform/microchip/built-in.a
  AR      drivers/media/usb/s2255/built-in.a
  CC      drivers/power/supply/power_supply_sysfs.o
  AR      drivers/media/platform/nvidia/tegra-vde/built-in.a
  AR      drivers/media/platform/nvidia/built-in.a
  AR      drivers/media/usb/siano/built-in.a
  AR      drivers/media/usb/ttusb-budget/built-in.a
  AR      drivers/media/platform/nxp/dw100/built-in.a
  AR      drivers/media/usb/ttusb-dec/built-in.a
  AR      drivers/media/platform/nxp/imx-jpeg/built-in.a
  AR      drivers/media/usb/built-in.a
  AR      drivers/media/platform/nxp/built-in.a
  CC      lib/clz_ctz.o
  CC      kernel/trace/rpm-traces.o
  CC      mm/sparse.o
  AR      drivers/media/platform/qcom/camss/built-in.a
  AR      drivers/media/platform/qcom/venus/built-in.a
  AR      drivers/media/platform/qcom/built-in.a
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/oproxy.o
  AR      drivers/media/platform/renesas/rcar-vin/built-in.a
  AR      drivers/media/platform/renesas/rzg2l-cru/built-in.a
  CC [M]  drivers/gpu/drm/drm_connector.o
  AR      drivers/media/platform/renesas/vsp1/built-in.a
  CC      lib/bsearch.o
  AR      drivers/media/platform/renesas/built-in.a
  AR      drivers/media/platform/rockchip/rga/built-in.a
  CC      drivers/usb/core/endpoint.o
  AR      drivers/media/platform/rockchip/rkisp1/built-in.a
  AR      drivers/media/platform/rockchip/built-in.a
  CC      drivers/usb/storage/scsiglue.o
  AR      drivers/thermal/broadcom/built-in.a
  AR      drivers/thermal/samsung/built-in.a
  AR      drivers/media/platform/samsung/exynos-gsc/built-in.a
  CC [M]  net/bluetooth/hci_sync.o
  AR      drivers/media/platform/samsung/exynos4-is/built-in.a
  CC      drivers/thermal/intel/intel_tcc.o
  AR      drivers/media/platform/samsung/s3c-camif/built-in.a
  CC      drivers/usb/storage/protocol.o
  AR      drivers/media/platform/samsung/s5p-g2d/built-in.a
  AR      drivers/media/platform/samsung/s5p-jpeg/built-in.a
  AR      drivers/media/platform/samsung/s5p-mfc/built-in.a
  AR      drivers/media/platform/samsung/built-in.a
  CC      drivers/acpi/acpica/tbfadt.o
  AR      drivers/media/platform/st/sti/bdisp/built-in.a
  AR      drivers/media/platform/st/sti/c8sectpfe/built-in.a
  CC [M]  drivers/net/phy/bcm7xxx.o
  AR      drivers/media/platform/st/sti/delta/built-in.a
  AR      drivers/media/platform/st/sti/hva/built-in.a
  CC [M]  drivers/i2c/busses/i2c-piix4.o
  CC [M]  drivers/gpu/drm/drm_crtc.o
  AR      drivers/media/platform/st/stm32/built-in.a
  CC [M]  drivers/gpu/drm/drm_displayid.o
  CC [M]  drivers/gpu/drm/xe/xe_guc_pc.o
  AR      drivers/media/platform/st/built-in.a
  AR      drivers/media/platform/sunxi/sun4i-csi/built-in.a
  CC      drivers/thermal/intel/therm_throt.o
  AR      drivers/media/platform/sunxi/sun6i-csi/built-in.a
  AR      drivers/media/platform/sunxi/sun6i-mipi-csi2/built-in.a
  AR      drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/built-in.a
  AR      drivers/media/platform/sunxi/sun8i-di/built-in.a
  CC      drivers/acpi/acpica/tbfind.o
  AR      drivers/media/platform/sunxi/sun8i-rotate/built-in.a
  AR      drivers/media/platform/sunxi/built-in.a
  AR      drivers/media/platform/ti/am437x/built-in.a
  CC [M]  drivers/net/ethernet/broadcom/cnic.o
  AR      drivers/media/platform/ti/cal/built-in.a
  CC [M]  drivers/net/ethernet/broadcom/tg3.o
  CC [M]  drivers/thermal/intel/x86_pkg_temp_thermal.o
  AR      drivers/media/platform/ti/vpe/built-in.a
  AR      drivers/media/platform/ti/davinci/built-in.a
  AR      drivers/media/platform/ti/omap/built-in.a
  CC [M]  drivers/gpu/drm/amd/amdgpu/atombios_i2c.o
  AR      drivers/media/platform/ti/omap3isp/built-in.a
  AR      drivers/media/platform/ti/built-in.a
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.o
  CC      arch/x86/kernel/kvmclock.o
  CC      drivers/acpi/acpica/tbinstal.o
  AR      drivers/media/platform/verisilicon/built-in.a
  AR      drivers/media/platform/via/built-in.a
  CC      kernel/trace/trace_dynevent.o
  CC      fs/btrfs/free-space-cache.o
  AR      drivers/media/platform/xilinx/built-in.a
  AR      drivers/media/platform/built-in.a
  CC      drivers/acpi/acpi_pcc.o
  AR      drivers/media/mmc/siano/built-in.a
  AR      drivers/media/mmc/built-in.a
  CC      lib/find_bit.o
  CC      drivers/usb/storage/transport.o
  AR      drivers/thermal/st/built-in.a
  AR      drivers/media/firewire/built-in.a
  CC [M]  drivers/ptp/ptp_chardev.o
  CC      drivers/watchdog/watchdog_core.o
  AR      drivers/media/spi/built-in.a
  CC      drivers/power/supply/power_supply_leds.o
  AR      drivers/media/test-drivers/built-in.a
  AR      drivers/media/built-in.a
  CC      lib/llist.o
  CC [M]  drivers/net/ipvlan/ipvlan_main.o
  CC      drivers/watchdog/watchdog_dev.o
  CC      drivers/usb/core/devio.o
  CC [M]  drivers/gpu/drm/drm_drv.o
  CC [M]  drivers/gpu/drm/i915/soc/intel_pch.o
  CC      lib/memweight.o
  AR      drivers/net/ethernet/cortina/built-in.a
  CC [M]  drivers/gpu/drm/drm_dumb_buffers.o
  CC [M]  drivers/thermal/intel/intel_menlow.o
  CC [M]  drivers/net/phy/bcm87xx.o
  CC [M]  drivers/net/phy/bcm-phy-lib.o
  CC      fs/ext4/xattr_trusted.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/option.o
  CC [M]  drivers/hwmon/acpi_power_meter.o
  CC      drivers/usb/core/notify.o
  CC      lib/kfifo.o
  CC      kernel/trace/trace_probe.o
  CC      drivers/acpi/acpica/tbprint.o
  CC      mm/sparse-vmemmap.o
  CC      drivers/usb/serial/usb-serial.o
  CC [M]  drivers/ptp/ptp_sysfs.o
  CC [M]  drivers/net/usb/asix_common.o
  CC      drivers/power/supply/power_supply_hwmon.o
  CC      kernel/trace/trace_uprobe.o
  CC      arch/x86/kernel/paravirt.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/ramht.o
  CC      drivers/usb/storage/usb.o
  CC      drivers/usb/serial/generic.o
  AR      drivers/thermal/intel/built-in.a
  CC      drivers/usb/serial/bus.o
  CC [M]  fs/cifs/dns_resolve.o
  CC [M]  drivers/i2c/busses/i2c-designware-pcidrv.o
  CC      drivers/acpi/acpica/tbutils.o
  CC [M]  drivers/gpu/drm/drm_edid.o
  AR      drivers/usb/misc/built-in.a
  CC [M]  drivers/net/usb/ax88172a.o
  CC [M]  drivers/usb/misc/ftdi-elan.o
  CC [M]  drivers/gpu/drm/xe/xe_guc_submit.o
  CC [M]  drivers/ptp/ptp_vclock.o
  CC      net/ipv6/ping.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.o
  CC      fs/ext4/xattr_user.o
  CC      net/ipv6/exthdrs.o
  CC      lib/percpu-refcount.o
  CC      drivers/usb/gadget/udc/core.o
  AR      drivers/usb/gadget/function/built-in.a
  AR      drivers/thermal/qcom/built-in.a
  CC [M]  drivers/gpu/drm/drm_encoder.o
  AR      drivers/thermal/tegra/built-in.a
  CC      drivers/watchdog/softdog.o
  AR      drivers/thermal/mediatek/built-in.a
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/subdev.o
  CC      lib/rhashtable.o
  CC      drivers/thermal/thermal_core.o
  AR      drivers/power/supply/built-in.a
  AR      drivers/power/built-in.a
  CC      drivers/usb/storage/initializers.o
  CC      drivers/usb/storage/sierra_ms.o
  CC      mm/mmu_notifier.o
  CC      mm/ksm.o
  CC [M]  drivers/hwmon/coretemp.o
  CC      drivers/acpi/acpica/tbxface.o
  CC      drivers/acpi/acpica/tbxfload.o
  CC      arch/x86/kernel/pvclock.o
  CC [M]  drivers/net/phy/broadcom.o
  CC [M]  drivers/gpu/drm/i915/i915_memcpy.o
  CC [M]  drivers/net/usb/ax88179_178a.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/core/uevent.o
  AR      drivers/watchdog/built-in.a
  CC      drivers/usb/gadget/udc/trace.o
  CC [M]  drivers/net/ipvlan/ipvlan_l3s.o
  CC      fs/ext4/fast_commit.o
  CC [M]  drivers/gpu/drm/i915/i915_mm.o
  LD [M]  drivers/i2c/busses/i2c-designware-pci.o
  AR      drivers/i2c/busses/built-in.a
  CC [M]  drivers/ptp/ptp_kvm_x86.o
  CC      drivers/usb/storage/option_ms.o
  AR      drivers/i2c/built-in.a
  CC      fs/ext4/orphan.o
  CC [M]  drivers/gpu/drm/drm_file.o
  CC      drivers/usb/serial/console.o
  CC [M]  drivers/usb/class/usbtmc.o
  CC      lib/base64.o
  CC      lib/once.o
  CC      kernel/groups.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/nvfw/fw.o
  CC [M]  drivers/net/usb/cdc_ether.o
  CC      drivers/acpi/acpica/tbxfroot.o
  CC      drivers/usb/core/generic.o
  CC      lib/refcount.o
  CC [M]  drivers/md/persistent-data/dm-array.o
  CC      arch/x86/kernel/pcspeaker.o
  ASN.1   fs/cifs/cifs_spnego_negtokeninit.asn1.[ch]
  CC [M]  fs/cifs/smb1ops.o
  CC [M]  drivers/md/persistent-data/dm-bitset.o
  CC      net/ipv4/sysctl_net_ipv4.o
  CC      drivers/usb/host/ehci-pci.o
  AR      drivers/hwmon/built-in.a
  CC      drivers/usb/storage/usual-tables.o
  CC      drivers/opp/core.o
  CC      drivers/usb/core/quirks.o
  CC      drivers/cpufreq/cpufreq.o
  CC      mm/slub.o
  CC      drivers/acpi/acpica/utaddress.o
  CC      mm/migrate.o
  CC      kernel/trace/rethook.o
  CC [M]  drivers/net/phy/lxt.o
  CC      net/ipv4/proc.o
  CC      arch/x86/kernel/check.o
  CC [M]  drivers/ptp/ptp_kvm_common.o
  CC [M]  drivers/net/usb/cdc_eem.o
  CC      drivers/usb/serial/ftdi_sio.o
  CC [M]  drivers/net/usb/smsc75xx.o
  CC      lib/usercopy.o
  CC      kernel/kcmp.o
  CC      drivers/acpi/acpica/utalloc.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/nvfw/hs.o
  AR      drivers/usb/storage/built-in.a
  AR      drivers/usb/gadget/udc/built-in.a
  CC      drivers/thermal/thermal_sysfs.o
  AR      drivers/usb/gadget/legacy/built-in.a
  CC      drivers/usb/gadget/usbstring.o
  CC [M]  drivers/gpu/drm/i915/i915_sw_fence.o
  CC      drivers/cpuidle/governors/menu.o
  CC [M]  drivers/gpu/drm/i915/i915_sw_fence_work.o
  CC      drivers/cpuidle/cpuidle.o
  LD [M]  drivers/net/ipvlan/ipvlan.o
  CC      drivers/acpi/acpica/utascii.o
  CC      drivers/usb/serial/pl2303.o
  CC      drivers/thermal/thermal_trip.o
  CC      drivers/acpi/acpica/utbuffer.o
  CC      drivers/cpuidle/driver.o
  CC      drivers/usb/host/ohci-hcd.o
  CC      drivers/cpufreq/freq_table.o
  CC [M]  drivers/md/persistent-data/dm-block-manager.o
  CC      drivers/mmc/core/core.o
  CC      drivers/usb/core/devices.o
  CC      lib/errseq.o
  LD [M]  drivers/net/vxlan/vxlan.o
  CC      arch/x86/kernel/uprobes.o
  CC      drivers/mmc/core/bus.o
  CC      lib/bucket_locks.o
  CC      fs/btrfs/zlib.o
  CC      lib/generic-radix-tree.o
  CC      net/ipv6/datagram.o
  AR      kernel/trace/built-in.a
  LD [M]  drivers/ptp/ptp.o
  AR      drivers/ufs/built-in.a
  CC [M]  drivers/gpu/drm/xe/xe_hw_engine.o
  LD [M]  drivers/ptp/ptp_kvm.o
  CC      drivers/usb/host/ohci-pci.o
  CC      drivers/cpuidle/governor.o
  CC      lib/string_helpers.o
  CC      drivers/net/loopback.o
  CC      drivers/cpuidle/governors/haltpoll.o
  CC      drivers/acpi/acpica/utcksum.o
  CC [M]  drivers/net/phy/realtek.o
  CC      drivers/usb/gadget/config.o
  CC      drivers/opp/cpu.o
  CC [M]  net/bluetooth/sco.o
  CC      drivers/opp/debugfs.o
  CC      kernel/freezer.o
  CC      drivers/cpufreq/cpufreq_performance.o
  CC      fs/btrfs/lzo.o
  CC      drivers/usb/gadget/epautoconf.o
  CC [M]  drivers/net/usb/smsc95xx.o
  CC      kernel/stacktrace.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.o
  CC      drivers/thermal/thermal_helpers.o
  CC [M]  net/bluetooth/iso.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/nvfw/ls.o
  CC [M]  drivers/md/persistent-data/dm-space-map-common.o
  CC      drivers/usb/gadget/composite.o
  CC      fs/btrfs/zstd.o
  CC [M]  drivers/net/usb/mcs7830.o
  CC      drivers/acpi/acpica/utcopy.o
  CC      drivers/acpi/acpica/utexcep.o
  CC      net/ipv4/syncookies.o
  CC      net/ipv4/esp4.o
  CC      drivers/usb/core/phy.o
  CC [M]  fs/cifs/cifssmb.o
  CC [M]  fs/cifs/cifs_spnego_negtokeninit.asn1.o
  CC      drivers/thermal/thermal_hwmon.o
  CC [M]  drivers/md/persistent-data/dm-space-map-disk.o
  CC      net/ipv4/esp4_offload.o
  CC [M]  drivers/net/phy/smsc.o
  CC      drivers/cpuidle/sysfs.o
  CC [M]  fs/cifs/asn1.o
  AR      drivers/usb/serial/built-in.a
  CC [M]  drivers/net/usb/usbnet.o
  CC [M]  drivers/gpu/drm/i915/i915_syncmap.o
  CC      arch/x86/kernel/perf_regs.o
  CC [M]  drivers/net/usb/cdc_ncm.o
  AR      fs/ext4/built-in.a
  CC [M]  drivers/gpu/drm/drm_fourcc.o
  AR      drivers/opp/built-in.a
  CC      drivers/cpufreq/cpufreq_ondemand.o
  CC      drivers/cpufreq/cpufreq_governor.o
  CC      lib/hexdump.o
  CC      lib/kstrtox.o
  AR      drivers/cpuidle/governors/built-in.a
  CC [M]  drivers/md/persistent-data/dm-space-map-metadata.o
  CC [M]  drivers/md/persistent-data/dm-transaction-manager.o
  CC      drivers/mmc/core/host.o
  CC      kernel/dma.o
  CC      drivers/usb/host/uhci-hcd.o
  CC      drivers/cpufreq/cpufreq_governor_attr_set.o
  CC      drivers/acpi/ac.o
  CC      fs/readdir.o
  CC      drivers/acpi/acpica/utdebug.o
  CC [M]  drivers/gpu/drm/xe/xe_hw_fence.o
  CC      mm/migrate_device.o
  CC      drivers/acpi/button.o
  CC      fs/select.o
  CC      lib/debug_info.o
  CC      drivers/cpuidle/poll_state.o
  CC      drivers/thermal/gov_fair_share.o
  CC      drivers/cpufreq/acpi-cpufreq.o
  CC      drivers/usb/core/port.o
  CC      lib/iomap.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/nvfw/acr.o
  CC      drivers/cpuidle/cpuidle-haltpoll.o
  CC      drivers/thermal/gov_step_wise.o
  CC      arch/x86/kernel/tracepoint.o
  CC [M]  drivers/net/usb/r8153_ecm.o
  CC      fs/btrfs/compression.o
  CC      drivers/usb/host/xhci.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/nvfw/flcn.o
  CC      kernel/smp.o
  CC      drivers/acpi/acpica/utdecode.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/falcon/base.o
  CC      drivers/acpi/fan_core.o
  CC      net/ipv6/ip6_flowlabel.o
  CC [M]  net/bluetooth/a2mp.o
  LD [M]  drivers/net/phy/aquantia.o
  AR      drivers/net/phy/built-in.a
  CC [M]  drivers/gpu/drm/xe/xe_huc.o
  CC [M]  drivers/gpu/drm/drm_framebuffer.o
  CC      drivers/thermal/gov_user_space.o
  CC [M]  drivers/gpu/drm/i915/i915_user_extensions.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.o
  CC [M]  drivers/md/persistent-data/dm-btree.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/falcon/cmdq.o
  CC      lib/pci_iomap.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_pll.o
  CC      arch/x86/kernel/itmt.o
  CC      drivers/mmc/core/mmc.o
  AR      drivers/cpuidle/built-in.a
  CC [M]  drivers/gpu/drm/i915/i915_ioc32.o
  CC      net/ipv6/inet6_connection_sock.o
  CC [M]  drivers/md/persistent-data/dm-btree-remove.o
  CC      drivers/usb/core/hcd-pci.o
  AR      drivers/leds/trigger/built-in.a
  CC      drivers/usb/core/usb-acpi.o
  CC [M]  drivers/leds/trigger/ledtrig-audio.o
  CC      net/ipv4/netfilter.o
  AR      drivers/leds/blink/built-in.a
  CC      drivers/acpi/acpica/utdelete.o
  CC      drivers/acpi/acpica/uterror.o
  CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.o
  CC      drivers/cpufreq/intel_pstate.o
  CC      drivers/md/md.o
  CC      drivers/usb/host/xhci-mem.o
  AR      drivers/thermal/built-in.a
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.o
  CC [M]  drivers/md/persistent-data/dm-btree-spine.o
  CC      lib/iomap_copy.o
  AR      drivers/leds/simple/built-in.a
  CC      drivers/leds/led-core.o
  CC      drivers/usb/host/xhci-ext-caps.o
  CC      kernel/uid16.o
  CC      drivers/usb/host/xhci-ring.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.o
  AR      drivers/firmware/arm_ffa/built-in.a
  AR      drivers/firmware/arm_scmi/built-in.a
  AR      drivers/firmware/broadcom/built-in.a
  AR      drivers/crypto/stm32/built-in.a
  CC      drivers/leds/led-class.o
  AR      drivers/crypto/xilinx/built-in.a
  AR      drivers/firmware/cirrus/built-in.a
  AR      drivers/crypto/hisilicon/built-in.a
  AR      drivers/firmware/meson/built-in.a
  CC      net/ipv6/udp_offload.o
  AR      drivers/crypto/keembay/built-in.a
  CC      net/ipv6/seg6.o
  CC [M]  drivers/gpu/drm/xe/xe_huc_debugfs.o
  AR      drivers/crypto/built-in.a
  CC      lib/devres.o
  CC      net/ipv6/fib6_notifier.o
  CC      drivers/usb/gadget/functions.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/falcon/fw.o
  CC      arch/x86/kernel/umip.o
  CC      drivers/acpi/acpica/uteval.o
  CC      drivers/firmware/efi/libstub/efi-stub-helper.o
  CC      drivers/md/md-bitmap.o
  CC      drivers/clocksource/acpi_pm.o
  CC      drivers/hid/usbhid/hid-core.o
  AR      drivers/staging/media/built-in.a
  AR      drivers/staging/built-in.a
  AR      drivers/platform/x86/amd/built-in.a
  LD [M]  drivers/net/usb/asix.o
  CC      drivers/hid/usbhid/hiddev.o
  CC      drivers/platform/x86/intel/pmc/core.o
  CC      drivers/platform/x86/p2sb.o
  CC      drivers/usb/host/xhci-hub.o
  AR      drivers/usb/core/built-in.a
  CC      drivers/platform/x86/intel/pmc/spt.o
  CC      drivers/usb/host/xhci-dbg.o
  AR      drivers/net/ethernet/engleder/built-in.a
  CC      arch/x86/kernel/unwind_orc.o
  CC [M]  drivers/platform/x86/intel/pmt/class.o
  AR      drivers/net/ethernet/ezchip/built-in.a
  CC      arch/x86/kernel/callthunks.o
  CC      drivers/platform/x86/intel/turbo_max_3.o
  CC      drivers/platform/x86/intel/pmc/cnp.o
  CC      mm/huge_memory.o
  CC      fs/dcache.o
  CC      mm/khugepaged.o
  CC      drivers/acpi/acpica/utglobal.o
  CC      net/ipv4/inet_diag.o
  CC      drivers/usb/gadget/configfs.o
  CC      drivers/leds/led-triggers.o
  CC [M]  drivers/gpu/drm/i915/i915_debugfs_params.o
  CC [M]  net/bluetooth/amp.o
  CC [M]  drivers/gpu/drm/xe/xe_irq.o
  CC      net/ipv6/rpl.o
  LD [M]  drivers/md/persistent-data/dm-persistent-data.o
  CC      drivers/platform/x86/intel/pmc/icl.o
  CC      drivers/firmware/efi/efi-bgrt.o
  CC      lib/check_signature.o
  CC      fs/btrfs/delayed-ref.o
  CC      net/ipv4/tcp_diag.o
  CC      kernel/kallsyms.o
  CC      drivers/firmware/efi/libstub/gop.o
  CC      mm/page_counter.o
  CC      drivers/clocksource/i8253.o
  CC      net/ipv6/ioam6.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.o
  CC      mm/memcontrol.o
  CC      mm/vmpressure.o
  AR      drivers/net/ethernet/fungible/built-in.a
  CC      mm/swap_cgroup.o
  CC      lib/interval_tree.o
  CC      drivers/acpi/acpica/uthex.o
  CC      lib/assoc_array.o
  CC      net/ipv4/udp_diag.o
  CC [M]  net/bluetooth/hci_debugfs.o
  CC      drivers/mmc/core/mmc_ops.o
  CC      drivers/md/md-autodetect.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/falcon/msgq.o
  CC      drivers/acpi/acpica/utids.o
  CC [M]  drivers/platform/x86/intel/pmt/telemetry.o
  CC      fs/btrfs/relocation.o
  CC      drivers/firmware/efi/libstub/secureboot.o
  CC      drivers/platform/x86/intel/pmc/tgl.o
  CC      kernel/acct.o
  CC      drivers/md/dm-uevent.o
  CC      arch/x86/kernel/mmconf-fam10h_64.o
  CC      drivers/mmc/host/sdhci.o
  AR      drivers/clocksource/built-in.a
  CC      drivers/firmware/efi/efi.o
  AR      drivers/leds/built-in.a
  CC      drivers/mmc/host/sdhci-pci-core.o
  CC      drivers/platform/x86/pmc_atom.o
  CC      drivers/mmc/host/sdhci-pci-o2micro.o
  CC      drivers/platform/x86/intel/pmc/adl.o
  CC [M]  drivers/platform/x86/intel/pmt/crashlog.o
  CC      drivers/acpi/acpica/utinit.o
  CC [M]  drivers/gpu/drm/i915/display/intel_display_debugfs.o
  LD [M]  drivers/platform/x86/intel/pmt/pmt_class.o
  CC [M]  drivers/platform/x86/wmi.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.o
  AR      drivers/platform/surface/built-in.a
  CC [M]  drivers/gpu/drm/i915/display/intel_pipe_crc.o
  CC      drivers/net/netconsole.o
  AR      drivers/cpufreq/built-in.a
  CC      drivers/firmware/efi/libstub/tpm.o
  CC      drivers/firmware/efi/libstub/file.o
  CC [M]  drivers/gpu/drm/xe/xe_lrc.o
  AR      drivers/hid/usbhid/built-in.a
  CC      drivers/hid/hid-core.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.o
  CC      drivers/platform/x86/intel/pmc/mtl.o
  CC      drivers/net/virtio_net.o
  CC      kernel/crash_core.o
  CC [M]  drivers/platform/x86/wmi-bmof.o
  CC      drivers/acpi/acpica/utlock.o
  CC      lib/list_debug.o
  CC      arch/x86/kernel/vsmp_64.o
  CC      drivers/usb/gadget/u_f.o
  CC      kernel/compat.o
  CC      drivers/mmc/core/sd.o
  CC      drivers/mmc/core/sd_ops.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.o
  CC      drivers/hid/hid-input.o
  LD [M]  fs/cifs/cifs.o
  CC      drivers/acpi/acpica/utmath.o
  CC      drivers/acpi/acpica/utmisc.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/falcon/qmgr.o
  CC      lib/debugobjects.o
  CC      drivers/usb/host/xhci-trace.o
  CC      drivers/net/net_failover.o
  CC      net/ipv4/tcp_cubic.o
  LD [M]  drivers/platform/x86/intel/pmt/pmt_telemetry.o
  LD [M]  drivers/platform/x86/intel/pmt/pmt_crashlog.o
  CC [M]  drivers/platform/x86/intel/vsec.o
  CC      drivers/acpi/acpica/utmutex.o
  CC      drivers/platform/x86/intel/pmc/pltdrv.o
  CC      drivers/md/dm.o
  AR      arch/x86/kernel/built-in.a
  CC [M]  drivers/gpu/drm/xe/xe_migrate.o
  CC [M]  drivers/gpu/drm/xe/xe_mmio.o
  AR      arch/x86/built-in.a
  CC      lib/bitrev.o
  CC      net/ipv6/sysctl_net_ipv6.o
  CC [M]  drivers/platform/x86/intel/rst.o
  CC      net/ipv6/xfrm6_policy.o
  CC      kernel/utsname.o
  CC [M]  drivers/platform/x86/mxm-wmi.o
  CC      drivers/firmware/efi/libstub/mem.o
  CC [M]  drivers/gpu/drm/i915/i915_pmu.o
  CC      drivers/firmware/efi/vars.o
  CC      lib/crc16.o
  AR      drivers/usb/gadget/built-in.a
  CC      drivers/hid/hid-quirks.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/falcon/v1.o
  LD [M]  net/bluetooth/bluetooth.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.o
  CC [M]  drivers/platform/x86/intel_ips.o
  CC [M]  drivers/net/dummy.o
  CC      fs/inode.o
  CC      drivers/mmc/core/sdio.o
  CC      drivers/acpi/acpica/utnonansi.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/falcon/gm200.o
  CC      net/ipv6/xfrm6_state.o
  CC      drivers/mmc/core/sdio_ops.o
  CC      drivers/acpi/acpica/utobject.o
  AR      drivers/platform/x86/intel/pmc/built-in.a
  CC      drivers/hid/hid-debug.o
  CC      drivers/firmware/efi/reboot.o
  CC      lib/crc-t10dif.o
  AR      drivers/platform/x86/intel/built-in.a
  CC      drivers/mmc/host/sdhci-pci-arasan.o
  CC      kernel/user_namespace.o
  CC [M]  drivers/gpu/drm/xe/xe_mocs.o
  CC [M]  drivers/gpu/drm/i915/gt/gen2_engine_cs.o
  CC      mm/hugetlb_cgroup.o
  LD [M]  drivers/platform/x86/intel/intel-rst.o
  LD [M]  drivers/platform/x86/intel/intel_vsec.o
  AR      drivers/net/ethernet/huawei/built-in.a
  CC      drivers/firmware/efi/memattr.o
  CC      drivers/hid/hidraw.o
  CC      drivers/firmware/efi/libstub/random.o
  HOSTCC  lib/gen_crc32table
  CC      fs/attr.o
  CC      drivers/acpi/acpica/utosi.o
  CC      lib/libcrc32c.o
  CC [M]  drivers/gpu/drm/i915/gt/gen6_engine_cs.o
  CC [M]  drivers/gpu/drm/drm_gem.o
  CC      drivers/firmware/efi/tpm.o
  CC [M]  drivers/gpu/drm/drm_ioctl.o
  CC      drivers/usb/host/xhci-debugfs.o
  CC      lib/xxhash.o
  CC      drivers/hid/hid-generic.o
  CC [M]  drivers/gpu/drm/i915/gt/gen6_ppgtt.o
  CC      drivers/mmc/core/sdio_bus.o
  CC      drivers/firmware/efi/libstub/randomalloc.o
  CC      drivers/firmware/efi/libstub/pci.o
  CC      net/ipv4/xfrm4_policy.o
  CC [M]  drivers/net/macvlan.o
  CC      drivers/mmc/core/sdio_cis.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.o
  CC [M]  drivers/net/mii.o
  CC      drivers/firmware/efi/libstub/skip_spaces.o
  CC      drivers/firmware/efi/memmap.o
  CC [M]  drivers/gpu/drm/xe/xe_module.o
  CC      drivers/mmc/core/sdio_io.o
  CC [M]  drivers/net/ethernet/intel/e1000/e1000_main.o
  CC      drivers/acpi/acpica/utownerid.o
  CC [M]  drivers/net/ethernet/intel/e1000e/82571.o
  CC      net/ipv6/xfrm6_input.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_main.o
  CC      net/ipv6/xfrm6_output.o
  AR      drivers/platform/x86/built-in.a
  AR      drivers/platform/built-in.a
  CC      drivers/mmc/core/sdio_irq.o
  CC [M]  drivers/net/ethernet/intel/e1000e/ich8lan.o
  CC [M]  drivers/gpu/drm/xe/xe_pat.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/falcon/gp102.o
  CC [M]  drivers/gpu/drm/xe/xe_pci.o
  AR      drivers/net/ethernet/i825xx/built-in.a
  CC      fs/bad_inode.o
  CC      kernel/pid_namespace.o
  CC      lib/genalloc.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_vf_error.o
  CC [M]  drivers/net/ethernet/intel/e1000/e1000_hw.o
  CC [M]  drivers/net/ethernet/intel/igc/igc_main.o
  CC      drivers/hid/hid-a4tech.o
  CC [M]  drivers/net/ethernet/intel/igbvf/vf.o
  CC      drivers/firmware/efi/libstub/lib-cmdline.o
  CC      drivers/mmc/host/sdhci-pci-dwc-mshc.o
  CC      drivers/acpi/acpica/utpredef.o
  CC [M]  drivers/net/ethernet/intel/igbvf/mbx.o
  CC      drivers/hid/hid-apple.o
  CC      drivers/firmware/efi/libstub/lib-ctype.o
  CC      drivers/mmc/core/slot-gpio.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_main.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_common.o
  CC      drivers/firmware/efi/libstub/alignedmem.o
  CC [M]  drivers/net/ethernet/intel/ixgbevf/vf.o
  CC [M]  drivers/net/ethernet/intel/ixgbevf/mbx.o
  CC      drivers/mmc/host/sdhci-pci-gli.o
  CC      drivers/firmware/efi/esrt.o
  CC      drivers/usb/host/xhci-pci.o
  CC      drivers/acpi/acpica/utresdecode.o
  CC [M]  drivers/gpu/drm/i915/gt/gen7_renderclear.o
  CC      fs/btrfs/delayed-inode.o
  CC      drivers/hid/hid-belkin.o
  CC [M]  drivers/net/ethernet/intel/ixgbevf/ethtool.o
  CC      drivers/hid/hid-cherry.o
  CC      net/ipv4/xfrm4_state.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.o
  CC [M]  drivers/net/ethernet/intel/ixgb/ixgb_main.o
  CC [M]  drivers/net/ethernet/intel/ixgb/ixgb_hw.o
  AR      drivers/net/ethernet/intel/built-in.a
  CC [M]  drivers/net/ethernet/intel/e100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/falcon/ga100.o
  CC [M]  drivers/gpu/drm/xe/xe_pcode.o
  CC [M]  drivers/gpu/drm/drm_lease.o
  CC [M]  drivers/net/ethernet/intel/ixgb/ixgb_ee.o
  CC [M]  drivers/gpu/drm/i915/gt/gen8_engine_cs.o
  CC      lib/percpu_counter.o
  CC      drivers/acpi/acpica/utresrc.o
  CC [M]  drivers/gpu/drm/xe/xe_pm.o
  UPD     kernel/config_data
  CC      kernel/stop_machine.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/falcon/ga102.o
  AR      drivers/net/ethernet/microsoft/built-in.a
  CC      drivers/acpi/acpica/utstate.o
  CC      drivers/firmware/efi/libstub/relocate.o
  AR      drivers/net/ethernet/litex/built-in.a
  CC      drivers/hid/hid-chicony.o
  CC      drivers/mmc/core/regulator.o
  CC      lib/fault-inject.o
  CC [M]  drivers/net/ethernet/intel/igbvf/ethtool.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_sched.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_82599.o
  CC      drivers/acpi/acpica/utstring.o
  CC      net/ipv6/xfrm6_protocol.o
  CC [M]  drivers/net/ethernet/intel/e1000e/80003es2lan.o
  CC      drivers/mmc/host/sdhci-acpi.o
  CC      drivers/firmware/efi/efi-pstore.o
  CC      drivers/firmware/efi/libstub/printk.o
  CC      lib/syscall.o
  CC [M]  drivers/gpu/drm/xe/xe_preempt_fence.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.o
  CC [M]  drivers/gpu/drm/xe/xe_pt.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.o
  CC [M]  drivers/net/ethernet/intel/igc/igc_mac.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_82598.o
  CC      drivers/acpi/acpica/utstrsuppt.o
  CC      lib/dynamic_debug.o
  CC      net/ipv4/xfrm4_input.o
  CC      drivers/firmware/efi/libstub/vsprintf.o
  CC      drivers/mmc/host/cqhci-core.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.o
  CC [M]  drivers/net/ethernet/intel/igc/igc_i225.o
  AR      drivers/usb/host/built-in.a
  CC      drivers/mmc/core/debugfs.o
  AR      drivers/usb/built-in.a
  CC      drivers/hid/hid-cypress.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_phy.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.o
  CC      kernel/kprobes.o
  CC [M]  drivers/gpu/drm/i915/gt/gen8_ppgtt.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/acr/gm200.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_breadcrumbs.o
  CC [M]  drivers/net/mdio.o
  CC [M]  drivers/gpu/drm/drm_managed.o
  CC      kernel/hung_task.o
  CC [M]  drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.o
  CC      mm/kmemleak.o
  CC      lib/errname.o
  CC      lib/nlattr.o
  CC      drivers/firmware/efi/libstub/x86-stub.o
  CC [M]  drivers/net/ethernet/intel/igbvf/netdev.o
  CC      drivers/mailbox/mailbox.o
  CC      drivers/mailbox/pcc.o
  CC      drivers/acpi/acpica/utstrtoul64.o
  CC [M]  drivers/gpu/drm/xe/xe_pt_walk.o
  CC [M]  drivers/gpu/drm/xe/xe_query.o
  CC      net/ipv6/netfilter.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_context.o
  CC      drivers/mmc/core/block.o
  CC      drivers/devfreq/devfreq.o
  CC      drivers/acpi/acpica/utxface.o
  CC      drivers/hid/hid-ezkey.o
  CC      drivers/powercap/powercap_sys.o
  CC      drivers/powercap/intel_rapl_common.o
  CC [M]  drivers/net/ethernet/intel/e1000e/mac.o
  CC [M]  drivers/net/ethernet/intel/ixgb/ixgb_ethtool.o
  CC      drivers/md/dm-table.o
  CC      drivers/hid/hid-kensington.o
  CC      drivers/acpi/acpica/utxfinit.o
  CC [M]  drivers/net/ethernet/intel/ixgbevf/ipsec.o
  CC      fs/file.o
  AR      drivers/perf/built-in.a
  CC [M]  drivers/net/ethernet/intel/e1000/e1000_ethtool.o
  CC [M]  drivers/net/ethernet/intel/e1000/e1000_param.o
  CC [M]  drivers/net/ethernet/intel/igc/igc_base.o
  CC [M]  drivers/gpu/drm/drm_mm.o
  CC      fs/filesystems.o
  CC      net/ipv4/xfrm4_output.o
  AR      drivers/mailbox/built-in.a
  CC      mm/page_isolation.o
  CC [M]  drivers/gpu/drm/xe/xe_reg_sr.o
  STUBCPY drivers/firmware/efi/libstub/alignedmem.stub.o
  STUBCPY drivers/firmware/efi/libstub/efi-stub-helper.stub.o
  STUBCPY drivers/firmware/efi/libstub/file.stub.o
  STUBCPY drivers/firmware/efi/libstub/gop.stub.o
  CC      kernel/watchdog.o
  CC      fs/btrfs/scrub.o
  CC [M]  drivers/gpu/drm/xe/xe_reg_whitelist.o
  STUBCPY drivers/firmware/efi/libstub/lib-cmdline.stub.o
  STUBCPY drivers/firmware/efi/libstub/lib-ctype.stub.o
  STUBCPY drivers/firmware/efi/libstub/mem.stub.o
  STUBCPY drivers/firmware/efi/libstub/pci.stub.o
  STUBCPY drivers/firmware/efi/libstub/printk.stub.o
  STUBCPY drivers/firmware/efi/libstub/random.stub.o
  STUBCPY drivers/firmware/efi/libstub/randomalloc.stub.o
  STUBCPY drivers/firmware/efi/libstub/relocate.stub.o
  STUBCPY drivers/firmware/efi/libstub/secureboot.stub.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/acr/gm20b.o
  STUBCPY drivers/firmware/efi/libstub/skip_spaces.stub.o
  STUBCPY drivers/firmware/efi/libstub/tpm.stub.o
  STUBCPY drivers/firmware/efi/libstub/vsprintf.stub.o
  STUBCPY drivers/firmware/efi/libstub/x86-stub.stub.o
  AR      drivers/firmware/efi/libstub/lib.a
  CC      drivers/firmware/efi/cper.o
  CC      drivers/acpi/acpica/utxferror.o
  CC [M]  drivers/mmc/host/sdhci-pltfm.o
  CC      net/ipv4/xfrm4_protocol.o
  CC [M]  net/ipv4/ip_tunnel.o
  CC      drivers/ras/ras.o
  AR      drivers/hwtracing/intel_th/built-in.a
  CC      drivers/android/binderfs.o
  CC      drivers/android/binder.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_mmhub.o
  CC      drivers/hid/hid-lg.o
  CC      drivers/android/binder_alloc.o
  CC [M]  drivers/net/tun.o
  CC      lib/checksum.o
  CC      drivers/ras/debugfs.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/acr/gp102.o
  CC      mm/early_ioremap.o
  CC      mm/cma.o
  CC      drivers/powercap/intel_rapl_msr.o
  CC      drivers/hid/hid-lg-g15.o
  CC      drivers/acpi/acpica/utxfmutex.o
  CC [M]  drivers/gpu/drm/drm_mode_config.o
  CC      drivers/mmc/core/queue.o
  CC [M]  drivers/net/veth.o
  CC      fs/btrfs/backref.o
  CC      lib/cpu_rmap.o
  CC [M]  drivers/gpu/drm/xe/xe_rtp.o
  CC      kernel/watchdog_hld.o
  CC [M]  drivers/net/ethernet/intel/igc/igc_nvm.o
  CC      net/ipv6/fib6_rules.o
  CC      net/ipv6/proc.o
  AR      drivers/mmc/host/built-in.a
  AR      drivers/net/ethernet/microchip/built-in.a
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/acr/gp108.o
  AR      drivers/net/ethernet/mscc/built-in.a
  AR      drivers/firmware/imx/built-in.a
  CC [M]  drivers/gpu/drm/i915/gt/intel_context_sseu.o
  CC      fs/btrfs/ulist.o
  AR      drivers/net/ethernet/neterion/built-in.a
  CC [M]  drivers/gpu/drm/drm_mode_object.o
  CC [M]  drivers/net/ethernet/intel/igc/igc_phy.o
  CC [M]  drivers/net/ethernet/intel/ixgb/ixgb_param.o
  CC [M]  net/ipv4/udp_tunnel_core.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/acr/gv100.o
  AR      drivers/acpi/acpica/built-in.a
  CC [M]  net/ipv4/udp_tunnel_nic.o
  CC      drivers/acpi/fan_attr.o
  CC      drivers/acpi/processor_driver.o
  AR      drivers/ras/built-in.a
  CC [M]  drivers/net/ethernet/intel/e1000e/manage.o
  CC [M]  drivers/net/ethernet/intel/e1000e/nvm.o
  CC [M]  drivers/devfreq/governor_simpleondemand.o
  CC [M]  drivers/net/ethernet/intel/igc/igc_diag.o
  CC      drivers/firmware/efi/cper_cxl.o
  AR      drivers/powercap/built-in.a
  CC      lib/dynamic_queue_limits.o
  CC      drivers/acpi/processor_thermal.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_hdp.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  AR      net/ipv4/built-in.a
  CC      drivers/md/dm-target.o
  CC [M]  drivers/net/ethernet/intel/e1000e/phy.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/acr/gp10b.o
  AR      drivers/net/ethernet/netronome/built-in.a
  CC [M]  drivers/gpu/drm/drm_modes.o
  CC      mm/secretmem.o
  CC      lib/glob.o
  CC [M]  drivers/gpu/drm/xe/xe_ring_ops.o
  CC      kernel/seccomp.o
  CC [M]  drivers/devfreq/governor_performance.o
  AR      drivers/mmc/core/built-in.a
  CC      drivers/nvmem/core.o
  AR      drivers/mmc/built-in.a
  CC [M]  drivers/net/ethernet/intel/igc/igc_ethtool.o
  CC [M]  drivers/mtd/chips/chipreg.o
  CC [M]  drivers/gpu/drm/drm_modeset_lock.o
  CC [M]  drivers/net/ethernet/intel/igc/igc_ptp.o
  CC      drivers/md/dm-linear.o
  CC [M]  drivers/net/ethernet/intel/igc/igc_dump.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/acr/tu102.o
  CC      drivers/hid/hid-microsoft.o
  CC [M]  drivers/gpu/drm/drm_plane.o
  CC      drivers/md/dm-stripe.o
  CC      drivers/md/dm-ioctl.o
  CC      drivers/firmware/efi/runtime-wrappers.o
  CC      drivers/md/dm-io.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/acr/ga100.o
  AR      drivers/net/ethernet/ni/built-in.a
  CC      net/ipv6/syncookies.o
  AR      drivers/net/ethernet/packetengines/built-in.a
  CC      lib/strncpy_from_user.o
  CC      drivers/firmware/efi/dev-path-parser.o
  CC      drivers/acpi/processor_idle.o
  AR      drivers/devfreq/built-in.a
  CC      drivers/firmware/efi/apple-properties.o
  CC [M]  drivers/gpu/drm/xe/xe_sa.o
  CC      fs/btrfs/qgroup.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_engine_cs.o
  LD [M]  drivers/net/ethernet/intel/ixgb/ixgb.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_engine_heartbeat.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_engine_pm.o
  CC      drivers/acpi/processor_throttling.o
  CC [M]  drivers/gpu/drm/xe/xe_sched_job.o
  CC      mm/userfaultfd.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.o
  CC      fs/btrfs/send.o
  CC [M]  drivers/mtd/mtdcore.o
  CC      fs/btrfs/dev-replace.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_ethtool.o
  CC      mm/memremap.o
  CC [M]  drivers/gpu/drm/xe/xe_step.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_csa.o
  LD [M]  drivers/net/ethernet/intel/ixgbevf/ixgbevf.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_engine_user.o
  CC      drivers/md/dm-kcopyd.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_execlists_submission.o
  CC      lib/strnlen_user.o
  CC      drivers/md/dm-sysfs.o
  CC      drivers/hid/hid-monterey.o
  CC      drivers/firmware/efi/earlycon.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/acr/ga102.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bar/base.o
  LD [M]  net/ipv4/udp_tunnel.o
  CC      drivers/firmware/efi/cper-x86.o
  CC      lib/net_utils.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.o
  AR      drivers/nvmem/built-in.a
  CC [M]  drivers/net/ethernet/intel/igb/e1000_82575.o
  CC      drivers/md/dm-stats.o
  AR      drivers/net/ethernet/realtek/built-in.a
  CC      drivers/md/dm-rq.o
  CC [M]  drivers/net/ethernet/realtek/8139cp.o
  AR      drivers/net/ethernet/renesas/built-in.a
  CC [M]  drivers/net/ethernet/intel/igc/igc_tsn.o
  CC [M]  drivers/gpu/drm/drm_prime.o
  CC      lib/sg_pool.o
  CC [M]  drivers/net/ethernet/intel/igc/igc_xdp.o
  CC      lib/stackdepot.o
  CC [M]  drivers/gpu/drm/xe/xe_sync.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.o
  CC      net/ipv6/mip6.o
  CC      drivers/acpi/processor_perflib.o
  CC      kernel/relay.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_mac.o
  CC      fs/namespace.o
  CC      fs/seq_file.o
  CC [M]  drivers/net/ethernet/intel/e1000e/param.o
  AR      drivers/hid/built-in.a
  CC [M]  drivers/net/ethernet/intel/e1000e/ethtool.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_nvm.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.o
  CC [M]  drivers/uio/uio.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.o
  AR      drivers/firmware/efi/built-in.a
  AR      drivers/firmware/psci/built-in.a
  AR      drivers/firmware/smccc/built-in.a
  AR      drivers/firmware/tegra/built-in.a
  CC      drivers/md/dm-io-rewind.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_phy.o
  AR      drivers/firmware/xilinx/built-in.a
  CC      drivers/firmware/dmi_scan.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_mbx.o
  CC      kernel/utsname_sysctl.o
  CC      lib/ucs2_string.o
  CC      mm/hmm.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_ggtt.o
  CC      drivers/acpi/container.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bar/g84.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_ggtt_fencing.o
  CC      mm/memfd.o
  CC      lib/sbitmap.o
  CC      kernel/delayacct.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_i210.o
  CC [M]  drivers/gpu/drm/xe/xe_trace.o
  CC      fs/btrfs/raid56.o
  CC [M]  drivers/mtd/mtdsuper.o
  CC [M]  drivers/gpu/drm/drm_print.o
  CC [M]  drivers/gpu/drm/drm_property.o
  CC [M]  drivers/vfio/pci/vfio_pci_core.o
  LD [M]  drivers/net/ethernet/intel/igc/igc.o
  CC [M]  drivers/vfio/pci/vfio_pci_intrs.o
  CC [M]  drivers/gpu/drm/drm_syncobj.o
  CC [M]  drivers/vfio/pci/vfio_pci_rdwr.o
  CC [M]  drivers/net/ethernet/realtek/8139too.o
  CC      drivers/acpi/thermal.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.o
  CC      drivers/md/dm-builtin.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_umc.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_x540.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_x550.o
  CC      kernel/taskstats.o
  CC      net/ipv6/addrconf_core.o
  CC      drivers/acpi/acpi_memhotplug.o
  CC [M]  drivers/vfio/pci/vfio_pci_config.o
  CC [M]  drivers/net/ethernet/realtek/r8169_main.o
  CC      net/ipv6/exthdrs_core.o
  CC      drivers/firmware/dmi-sysfs.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.o
  CC [M]  drivers/pps/pps.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.o
  CC [M]  drivers/mtd/mtdconcat.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_ptp.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bar/gk20a.o
  CC [M]  drivers/net/ethernet/realtek/r8169_firmware.o
  CC      kernel/tsacct.o
  CC [M]  drivers/net/ethernet/intel/e1000e/netdev.o
  CC      lib/group_cpus.o
  CC      drivers/firmware/dmi-id.o
  CC [M]  drivers/bluetooth/btusb.o
  CC      mm/bootmem_info.o
  CC [M]  drivers/bluetooth/btintel.o
  CC      fs/xattr.o
  CC [M]  drivers/vfio/pci/vfio_pci.o
  CC [M]  drivers/mtd/mtdpart.o
  CC [M]  lib/asn1_decoder.o
  GEN     lib/oid_registry_data.c
  CC      kernel/tracepoint.o
  CC [M]  drivers/md/dm-bufio.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt.o
  CC [M]  drivers/net/ethernet/realtek/r8169_phy_config.o
  CC      drivers/acpi/ioapic.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_lib.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.o
  CC [M]  drivers/bluetooth/btbcm.o
  CC      kernel/latencytop.o
  CC [M]  drivers/pps/kapi.o
  CC      drivers/firmware/memmap.o
  CC [M]  drivers/gpu/drm/drm_sysfs.o
  CC      fs/libfs.o
  CC      fs/fs-writeback.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_hwmon.o
  AR      mm/built-in.a
  CC      fs/btrfs/uuid-tree.o
  CC      net/ipv6/ip6_checksum.o
  CC      fs/btrfs/props.o
  AR      drivers/android/built-in.a
  CC [M]  drivers/gpu/drm/drm_trace_points.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bar/gm107.o
  CC [M]  drivers/gpu/drm/drm_vblank.o
  CC [M]  drivers/mtd/mtdchar.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_rap.o
  CC      net/ipv6/ip6_icmp.o
  CC [M]  lib/oid_registry.o
../drivers/gpu/drm/i915/gt/intel_engine_cs.c:1525: warning: expecting prototype for intel_engines_cleanup_common(). Prototype was for intel_engine_cleanup_common() instead
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.o
  CC [M]  drivers/gpu/drm/xe/xe_ttm_sys_mgr.o
  CC [M]  drivers/md/dm-bio-prison-v1.o
  CC [M]  drivers/md/dm-bio-prison-v2.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.o
  CC      fs/btrfs/free-space-tree.o
  CC      fs/btrfs/tree-checker.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt_clock_utils.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.o
  LD [M]  drivers/vfio/pci/vfio-pci.o
  LD [M]  drivers/vfio/pci/vfio-pci-core.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.o
  CC [M]  drivers/vfio/vfio_main.o
  CC [M]  drivers/pps/sysfs.o
  CC      drivers/acpi/battery.o
  CC      kernel/irq_work.o
  AR      drivers/firmware/built-in.a
  CC [M]  drivers/dca/dca-core.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.o
  AR      lib/lib.a
  GEN     lib/crc32table.h
  CC      lib/crc32.o
  CC [M]  drivers/dca/dca-sysfs.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bar/gm20b.o
  CC [M]  drivers/ssb/main.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_mca.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bar/tu102.o
  LD [M]  drivers/pps/pps_core.o
  CC [M]  drivers/gpu/drm/drm_vblank_work.o
  CC      drivers/acpi/hed.o
  CC [M]  drivers/md/dm-crypt.o
  CC [M]  drivers/gpu/drm/xe/xe_ttm_stolen_mgr.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  CC [M]  drivers/bluetooth/btrtl.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.o
  AR      drivers/net/ethernet/sfc/built-in.a
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/bit.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/boost.o
  AR      drivers/net/ethernet/smsc/built-in.a
  CC [M]  drivers/net/ethernet/smsc/smsc9420.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.o
  CC      kernel/static_call.o
  CC [M]  drivers/vhost/net.o
  CC      net/ipv6/output_core.o
  CC      net/ipv6/protocol.o
  CC [M]  drivers/vhost/vhost.o
  AR      lib/built-in.a
  CC      fs/pnode.o
  LD [M]  drivers/mtd/mtd.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_lsdma.o
  CC      fs/splice.o
  CC      net/ipv6/ip6_offload.o
  CC      fs/sync.o
  CC      kernel/static_call_inline.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.o
  CC      fs/utimes.o
  CC      kernel/user-return-notifier.o
  CC      fs/btrfs/space-info.o
  LD [M]  drivers/dca/dca.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.o
  CC      drivers/acpi/bgrt.o
  CC      drivers/acpi/cppc_acpi.o
  CC      kernel/padata.o
  CC [M]  drivers/md/dm-thin.o
  CC      drivers/acpi/spcr.o
  CC      kernel/jump_label.o
  CC [M]  drivers/gpu/drm/drm_vma_manager.o
  CC [M]  drivers/gpu/drm/drm_writeback.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/conn.o
  CC [M]  drivers/md/dm-thin-metadata.o
  CC      drivers/acpi/acpi_pad.o
  CC [M]  drivers/vfio/group.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_nl.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt_debugfs.o
  CC      fs/btrfs/block-rsv.o
  CC [M]  drivers/gpu/drm/xe/xe_ttm_vram_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_sysfs.o
  CC [M]  drivers/gpu/drm/xe/xe_tuning.o
  CC [M]  drivers/gpu/drm/xe/xe_uc.o
  CC [M]  drivers/ssb/scan.o
  CC      net/ipv6/tcpv6_offload.o
  LD [M]  drivers/net/ethernet/realtek/r8169.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt_engines_debugfs.o
  CC [M]  drivers/vfio/iova_bitmap.o
  CC [M]  drivers/net/ethernet/intel/e1000e/ptp.o
  CC      net/ipv6/exthdrs_offload.o
  AR      drivers/net/ethernet/socionext/built-in.a
  CC [M]  drivers/gpu/drm/xe/xe_uc_debugfs.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/cstep.o
  CC      net/ipv6/inet6_hashtables.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/cik.o
  CC [M]  drivers/ssb/sprom.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/dcb.o
  CC      fs/btrfs/delalloc-space.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/cik_ih.o
  CC      net/ipv6/mcast_snoop.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt_irq.o
  CC [M]  drivers/ssb/pci.o
  CC [M]  drivers/ssb/pcihost_wrapper.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/disp.o
  CC      kernel/context_tracking.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.o
  CC [M]  drivers/gpu/drm/lib/drm_random.o
  CC      fs/d_path.o
  CC [M]  drivers/gpu/drm/xe/xe_uc_fw.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/dce_v8_0.o
  CC [M]  drivers/ssb/driver_chipcommon.o
  CC [M]  drivers/vfio/container.o
  CC [M]  drivers/gpu/drm/xe/xe_vm.o
  CC      fs/stack.o
  CC [M]  drivers/acpi/acpi_video.o
  CC [M]  drivers/gpu/drm/xe/xe_vm_madvise.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt_mcr.o
  CC [M]  drivers/gpu/drm/drm_ioc32.o
  CC [M]  net/ipv6/ip6_udp_tunnel.o
  CC [M]  drivers/vhost/iotlb.o
  AR      drivers/net/ethernet/vertexcom/built-in.a
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt_pm.o
  CC [M]  drivers/gpu/drm/drm_panel.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/dp.o
  CC [M]  drivers/gpu/drm/drm_pci.o
  CC [M]  drivers/ssb/driver_chipcommon_pmu.o
  CC [M]  drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.o
  CC [M]  drivers/ssb/driver_pcicore.o
  CC      fs/fs_struct.o
  LD [M]  drivers/md/dm-bio-prison.o
  LD [M]  drivers/vhost/vhost_net.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.o
  CC      fs/statfs.o
  AR      drivers/md/built-in.a
  CC      fs/fs_pin.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt_pm_irq.o
  CC [M]  drivers/vfio/virqfd.o
  AR      drivers/net/ethernet/wangxun/built-in.a
  AR      drivers/net/ethernet/xilinx/built-in.a
  AR      drivers/net/ethernet/synopsys/built-in.a
  AR      drivers/net/ethernet/pensando/built-in.a
  CC [M]  drivers/vfio/vfio_iommu_type1.o
  CC      fs/btrfs/block-group.o
  CC      kernel/iomem.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/extdev.o
  CC      fs/nsfs.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/gpio.o
  CC      fs/btrfs/discard.o
  CC      fs/btrfs/reflink.o
  CC [M]  drivers/gpu/drm/drm_debugfs.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.o
  CC [M]  drivers/gpu/drm/xe/xe_wait_user_fence.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt_requests.o
  LD [M]  drivers/vhost/vhost_iotlb.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt_sysfs.o
  CC [M]  drivers/gpu/drm/xe/xe_wa.o
  CC      fs/btrfs/subpage.o
  CC      kernel/rseq.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/cik_sdma.o
  CC      fs/fs_types.o
  CC [M]  drivers/gpu/drm/xe/xe_wopcm.o
  CC      fs/fs_context.o
  CC [M]  drivers/gpu/drm/xe/xe_display.o
  CC [M]  drivers/acpi/video_detect.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/i2c.o
  CC [M]  drivers/gpu/drm/xe/display/xe_fb_pin.o
  CC [M]  drivers/gpu/drm/xe/display/xe_hdcp_gsc.o
  CC [M]  drivers/gpu/drm/drm_debugfs_crc.o
  CC      fs/btrfs/tree-mod-log.o
  CC      fs/btrfs/extent-io-tree.o
  CC [M]  drivers/gpu/drm/drm_edid_load.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.o
  CC      fs/btrfs/fs.o
  CC      fs/fs_parser.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.o
  CC      fs/btrfs/messages.o
  LD [M]  drivers/ssb/ssb.o
  AR      net/ipv6/built-in.a
  AR      net/built-in.a
  CC      fs/btrfs/bio.o
  CC      fs/fsopen.o
  CC [M]  drivers/gpu/drm/xe/display/xe_plane_initial.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/image.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.o
  LD [M]  drivers/md/dm-thin-pool.o
  CC      fs/init.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/vce_v2_0.o
  LD [M]  drivers/vfio/vfio.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gtt.o
  GZIP    kernel/config_data.gz
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/mxm.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  CC      fs/kernel_read_file.o
  CC      fs/mnt_idmapping.o
  AR      drivers/acpi/built-in.a
  CC      fs/btrfs/lru_cache.o
  CC [M]  drivers/gpu/drm/drm_panel_orientation_quirks.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/npde.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_llc.o
  CC      kernel/configs.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_lrc.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/si.o
  CC [M]  drivers/gpu/drm/xe/display/xe_display_rps.o
  CC [M]  drivers/gpu/drm/xe/display/ext/i915_irq.o
  CC [M]  drivers/gpu/drm/xe/display/ext/intel_clock_gating.o
  LD [M]  drivers/acpi/video.o
  CC [M]  drivers/gpu/drm/xe/display/ext/intel_device_info.o
  CC      fs/remap_range.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_migrate.o
  CC [M]  drivers/gpu/drm/drm_buddy.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/pcir.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/perf.o
  CC [M]  drivers/gpu/drm/drm_gem_shmem_helper.o
  CC      fs/buffer.o
  LD [M]  drivers/net/ethernet/intel/ixgbe/ixgbe.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_mocs.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/pll.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gmc_v6_0.o
  CC      fs/mpage.o
  CC      fs/proc_namespace.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.o
  CC [M]  drivers/gpu/drm/xe/display/ext/intel_dram.o
  AR      drivers/net/ethernet/built-in.a
  CC      fs/direct-io.o
  CC      fs/btrfs/acl.o
  AR      drivers/net/built-in.a
  CC [M]  drivers/gpu/drm/xe/display/ext/intel_pch.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.o
  AR      kernel/built-in.a
  CC      fs/eventpoll.o
  CC      fs/anon_inodes.o
  CC [M]  drivers/gpu/drm/drm_suballoc.o
  CC [M]  drivers/gpu/drm/drm_gem_ttm_helper.o
  CC [M]  drivers/gpu/drm/drm_atomic_helper.o
  CC [M]  drivers/gpu/drm/drm_atomic_state_helper.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/power_budget.o
  CC [M]  drivers/gpu/drm/xe/i915-display/icl_dsi.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_atomic.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_ppgtt.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_rc6.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/si_ih.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_region_lmem.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_atomic_plane.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/si_dma.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/ramcfg.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_renderstate.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/rammap.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.o
  CC      fs/signalfd.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_reset.o
  CC      fs/timerfd.o
  CC [M]  drivers/gpu/drm/drm_bridge_connector.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/dce_v6_0.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowramin.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_ring.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_audio.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_backlight.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_bios.o
  CC [M]  drivers/gpu/drm/drm_crtc_helper.o
  CC [M]  drivers/gpu/drm/drm_damage_helper.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/timing.o
  CC      fs/eventfd.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/therm.o
  CC [M]  drivers/gpu/drm/drm_encoder_slave.o
  CC [M]  drivers/gpu/drm/drm_flip_work.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/uvd_v3_1.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_ring_submission.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_bw.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_cdclk.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/vmap.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_rps.o
  CC [M]  drivers/gpu/drm/drm_format_helper.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/vi.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/volt.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_sa_media.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_sseu.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_color.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/nbio_v6_1.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/vpstate.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_combo_phy.o
  CC [M]  drivers/gpu/drm/drm_gem_atomic_helper.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_connector.o
  AR      fs/btrfs/built-in.a
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_crtc.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/xpio.o
  CC [M]  drivers/gpu/drm/drm_gem_framebuffer_helper.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/M0203.o
  CC [M]  drivers/gpu/drm/drm_kms_helper_common.o
  CC      fs/userfaultfd.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/M0205.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_sseu_debugfs.o
  CC [M]  drivers/gpu/drm/drm_modeset_helper.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/soc15.o
  CC [M]  drivers/gpu/drm/drm_plane_helper.o
  CC [M]  drivers/gpu/drm/drm_probe_helper.o
  CC      fs/aio.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_crtc_state_dump.o
  CC [M]  drivers/gpu/drm/drm_rect.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/M0209.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_timeline.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_wopcm.o
  CC      fs/locks.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_workarounds.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bios/P0260.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bus/base.o
  CC [M]  drivers/gpu/drm/drm_self_refresh_helper.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bus/hwsq.o
  CC [M]  drivers/gpu/drm/drm_simple_kms_helper.o
  CC [M]  drivers/gpu/drm/bridge/panel.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/emu_soc.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/mxgpu_ai.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/nbio_v7_0.o
  CC [M]  drivers/gpu/drm/i915/gt/shmem_utils.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv31.o
  CC [M]  drivers/gpu/drm/drm_fbdev_generic.o
  CC [M]  drivers/gpu/drm/drm_fb_helper.o
  CC      fs/binfmt_script.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_cursor.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/vega10_reg_init.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_cx0_phy.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv50.o
  LD [M]  drivers/gpu/drm/drm.o
  CC [M]  drivers/gpu/drm/i915/gt/sysfs_engines.o
  LD [M]  drivers/gpu/drm/drm_shmem_helper.o
  LD [M]  drivers/gpu/drm/drm_suballoc_helper.o
  LD [M]  drivers/gpu/drm/drm_ttm_helper.o
  AR      drivers/gpu/drm/built-in.a
  CC [M]  drivers/gpu/drm/i915/gt/intel_ggtt_gmch.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_ddi.o
  CC [M]  drivers/gpu/drm/i915/gt/gen6_renderstate.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bus/g94.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_ddi_buf_trans.o
  CC      fs/binfmt_elf.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_display.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/bus/gf100.o
  CC      fs/compat_binfmt_elf.o
  CC [M]  drivers/gpu/drm/i915/gt/gen7_renderstate.o
  CC [M]  drivers/gpu/drm/i915/gt/gen8_renderstate.o
  CC      fs/mbcache.o
  CC [M]  drivers/gpu/drm/i915/gt/gen9_renderstate.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_display_driver.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_busy.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_clflush.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_display_debugfs.o
  CC      fs/posix_acl.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.o
  CC      fs/coredump.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_context.o
  CC      fs/drop_caches.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_display_power.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_display_power_map.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/vega20_reg_init.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_create.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv04.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_domain.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/nbio_v7_4.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv40.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_internal.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_object.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/nbio_v2_3.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/nv.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_display_power_well.o
  CC      fs/fhandle.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/arct_reg_init.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/mxgpu_nv.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_lmem.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_mman.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_display_trace.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dkl_phy.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dmc.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/nbio_v7_2.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/hdp_v4_0.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dp.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/g84.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_pages.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_phys.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dp_aux.o
  LD [M]  drivers/gpu/drm/drm_kms_helper.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dp_aux_backlight.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dp_hdcp.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/hdp_v5_0.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/mcp77.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/gf100.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dp_link_training.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dp_mst.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dpll.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dpll_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/aldebaran_reg_init.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_pm.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_region.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_shmem.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_shrinker.o
  AR      fs/built-in.a
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dpt.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_stolen.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_throttle.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_tiling.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_ttm.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_drrs.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/aldebaran.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/soc21.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/sienna_cichlid.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk104.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dsb.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dsi.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dsi_dcs_backlight.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_dsi_vbt.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/smu_v13_0_10.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_userptr.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_fb.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/gm20b.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_wait.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/pllnv04.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/pllgt215.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/nbio_v4_3.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/base.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/hdp_v6_0.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/nbio_v7_7.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_fbc.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_fdi.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_fifo_underrun.o
  CC [M]  drivers/gpu/drm/i915/gem/i915_gemfs.o
  CC [M]  drivers/gpu/drm/i915/i915_active.o
  CC [M]  drivers/gpu/drm/i915/i915_cmd_parser.o
  CC [M]  drivers/gpu/drm/i915/i915_deps.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_frontbuffer.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/hdp_v5_2.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_global_state.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/lsdma_v6_0.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/nbio_v7_9.o
  CC [M]  drivers/gpu/drm/i915/i915_gem_evict.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/df_v1_7.o
  CC [M]  drivers/gpu/drm/i915/i915_gem_gtt.o
  CC [M]  drivers/gpu/drm/i915/i915_gem_ww.o
  CC [M]  drivers/gpu/drm/i915/i915_gem.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_gmbus.o
  CC [M]  drivers/gpu/drm/i915/i915_query.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_hdcp.o
  CC [M]  drivers/gpu/drm/i915/i915_request.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_hdmi.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/df_v3_6.o
  CC [M]  drivers/gpu/drm/i915/i915_scheduler.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_hotplug.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/df_v4_3.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv04.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv05.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv10.o
  CC [M]  drivers/gpu/drm/i915/i915_trace_points.o
  CC [M]  drivers/gpu/drm/i915/i915_ttm_buddy_manager.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.o
  CC [M]  drivers/gpu/drm/i915/i915_vma.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_hotplug_irq.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_hti.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv1a.o
  CC [M]  drivers/gpu/drm/i915/i915_vma_resource.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_lspcon.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_guc.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_modeset_setup.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_modeset_verify.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_panel.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv20.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv50.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/g84.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/g98.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_guc_capture.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_pipe_crc.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/mcp89.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_pps.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_psr.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_qp_tables.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_quirks.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_guc_fw.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_snps_phy.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_tc.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_guc_log.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_vblank.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_vdsc.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_guc_rc.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_huc.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_huc_debugfs.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm200.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gv100.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_vga.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_huc_fw.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_wm.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_vrr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gmc_v10_0.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_uc.o
  CC [M]  drivers/gpu/drm/xe/i915-display/skl_scaler.o
  CC [M]  drivers/gpu/drm/xe/i915-display/skl_universal_plane.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfxhub_v2_1.o
  CC [M]  drivers/gpu/drm/xe/i915-display/skl_watermark.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_acpi.o
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.o
  CC [M]  drivers/gpu/drm/i915/gt/intel_gsc.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/mmhub_v1_7.o
  CC [M]  drivers/gpu/drm/i915/i915_hwmon.o
  CC [M]  drivers/gpu/drm/i915/display/hsw_ips.o
  CC [M]  drivers/gpu/drm/i915/display/intel_atomic.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_opregion.o
  CC [M]  drivers/gpu/drm/i915/display/intel_atomic_plane.o
  CC [M]  drivers/gpu/drm/i915/display/intel_audio.o
  CC [M]  drivers/gpu/drm/i915/display/intel_bios.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/tu102.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/ga100.o
  CC [M]  drivers/gpu/drm/xe/i915-display/intel_fbdev.o
  HDRTEST drivers/gpu/drm/xe/abi/guc_klvs_abi.h
  HDRTEST drivers/gpu/drm/xe/abi/guc_errors_abi.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/mmhub_v3_0.o
  HDRTEST drivers/gpu/drm/xe/abi/guc_actions_slpc_abi.h
  HDRTEST drivers/gpu/drm/xe/abi/guc_communication_mmio_abi.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fault/base.o
  HDRTEST drivers/gpu/drm/xe/abi/guc_actions_abi.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_2.o
  HDRTEST drivers/gpu/drm/xe/abi/guc_communication_ctb_abi.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fault/user.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fault/gp100.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gmc_v11_0.o
  CC [M]  drivers/gpu/drm/i915/display/intel_bw.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_1.o
  CC [M]  drivers/gpu/drm/i915/display/intel_cdclk.o
  CC [M]  drivers/gpu/drm/i915/display/intel_color.o
  CC [M]  drivers/gpu/drm/i915/display/intel_combo_phy.o
  CC [M]  drivers/gpu/drm/i915/display/intel_connector.o
  CC [M]  drivers/gpu/drm/i915/display/intel_crtc.o
  HDRTEST drivers/gpu/drm/xe/abi/guc_messages_abi.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_vma_types.h
  CC [M]  drivers/gpu/drm/i915/display/intel_crtc_state_dump.o
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/vlv_sideband_reg.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/intel_wakeref.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/intel_pcode.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
  CC [M]  drivers/gpu/drm/i915/display/intel_cursor.o
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_reg_defs.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_trace.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_reg.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_active_types.h
  CC [M]  drivers/gpu/drm/i915/display/intel_display.o
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_utils.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_config.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_vma.h
  CC [M]  drivers/gpu/drm/i915/display/intel_display_driver.o
  CC [M]  drivers/gpu/drm/i915/display/intel_display_power.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fault/gp10b.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.o
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/vlv_sideband.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/intel_mchbar_regs.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_debugfs.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/soc/intel_gmch.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_vgpu.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_fixed.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/intel_runtime_pm.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/intel_pm_types.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fault/tu102.o
  CC [M]  drivers/gpu/drm/i915/display/intel_display_power_map.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/base.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv04.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0_3.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv10.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfxhub_v1_2.o
  CC [M]  drivers/gpu/drm/i915/display/intel_display_power_well.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.o
  CC [M]  drivers/gpu/drm/i915/display/intel_display_reset.o
  CC [M]  drivers/gpu/drm/i915/display/intel_display_rps.o
  CC [M]  drivers/gpu/drm/i915/display/intel_dmc.o
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/intel_pci_config.h
  HDRTEST drivers/gpu/drm/xe/compat-i915-headers/intel_clock_gating.h
  HDRTEST drivers/gpu/drm/xe/display/ext/i915_irq.h
  HDRTEST drivers/gpu/drm/xe/display/ext/intel_pch.h
  HDRTEST drivers/gpu/drm/xe/display/ext/intel_dram.h
  HDRTEST drivers/gpu/drm/xe/display/ext/intel_device_info.h
  HDRTEST drivers/gpu/drm/xe/regs/xe_reg_defs.h
  HDRTEST drivers/gpu/drm/xe/regs/xe_guc_regs.h
  HDRTEST drivers/gpu/drm/xe/regs/xe_gt_regs.h
  HDRTEST drivers/gpu/drm/xe/regs/xe_regs.h
  HDRTEST drivers/gpu/drm/xe/regs/xe_gpu_commands.h
  HDRTEST drivers/gpu/drm/xe/regs/xe_lrc_layout.h
  HDRTEST drivers/gpu/drm/xe/regs/xe_engine_regs.h
  HDRTEST drivers/gpu/drm/xe/tests/xe_test.h
  HDRTEST drivers/gpu/drm/xe/tests/xe_pci_test.h
  HDRTEST drivers/gpu/drm/xe/tests/xe_migrate_test.h
  CC [M]  drivers/gpu/drm/i915/display/intel_dpio_phy.o
  HDRTEST drivers/gpu/drm/xe/tests/xe_dma_buf_test.h
  HDRTEST drivers/gpu/drm/xe/tests/xe_bo_test.h
  HDRTEST drivers/gpu/drm/xe/xe_bb.h
  CC [M]  drivers/gpu/drm/i915/display/intel_dpll.o
  HDRTEST drivers/gpu/drm/xe/xe_bb_types.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/umc_v6_0.o
  HDRTEST drivers/gpu/drm/xe/xe_bo.h
  CC [M]  drivers/gpu/drm/i915/display/intel_dpll_mgr.o
  CC [M]  drivers/gpu/drm/i915/display/intel_dpt.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/umc_v6_1.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv1a.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/umc_v6_7.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/umc_v8_7.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv20.o
  CC [M]  drivers/gpu/drm/i915/display/intel_drrs.o
  HDRTEST drivers/gpu/drm/xe/xe_bo_doc.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/umc_v8_10.o
  HDRTEST drivers/gpu/drm/xe/xe_bo_evict.h
  HDRTEST drivers/gpu/drm/xe/xe_bo_types.h
  CC [M]  drivers/gpu/drm/i915/display/intel_dsb.o
  HDRTEST drivers/gpu/drm/xe/xe_debugfs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.o
  HDRTEST drivers/gpu/drm/xe/xe_devcoredump.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv25.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv30.o
  CC [M]  drivers/gpu/drm/i915/display/intel_fb.o
  CC [M]  drivers/gpu/drm/i915/display/intel_fb_pin.o
  CC [M]  drivers/gpu/drm/i915/display/intel_fbc.o
  HDRTEST drivers/gpu/drm/xe/xe_devcoredump_types.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv35.o
  HDRTEST drivers/gpu/drm/xe/xe_device.h
  CC [M]  drivers/gpu/drm/i915/display/intel_fdi.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv36.o
  CC [M]  drivers/gpu/drm/i915/display/intel_fifo_underrun.o
  CC [M]  drivers/gpu/drm/i915/display/intel_frontbuffer.o
  CC [M]  drivers/gpu/drm/i915/display/intel_global_state.o
  HDRTEST drivers/gpu/drm/xe/xe_device_types.h
  HDRTEST drivers/gpu/drm/xe/xe_display.h
  CC [M]  drivers/gpu/drm/i915/display/intel_hdcp.o
  HDRTEST drivers/gpu/drm/xe/xe_dma_buf.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv40.o
  CC [M]  drivers/gpu/drm/i915/display/intel_hdcp_gsc.o
  CC [M]  drivers/gpu/drm/i915/display/intel_hotplug.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv41.o
  CC [M]  drivers/gpu/drm/i915/display/intel_hotplug_irq.o
  CC [M]  drivers/gpu/drm/i915/display/intel_hti.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ih.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv44.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/iceland_ih.o
  HDRTEST drivers/gpu/drm/xe/xe_drv.h
  CC [M]  drivers/gpu/drm/i915/display/intel_load_detect.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/tonga_ih.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/cz_ih.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/vega10_ih.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/vega20_ih.o
  CC [M]  drivers/gpu/drm/i915/display/intel_lpe_audio.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv46.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv47.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv49.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/navi10_ih.o
  CC [M]  drivers/gpu/drm/i915/display/intel_modeset_verify.o
  HDRTEST drivers/gpu/drm/xe/xe_engine.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv4e.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.o
  HDRTEST drivers/gpu/drm/xe/xe_engine_types.h
  HDRTEST drivers/gpu/drm/xe/xe_exec.h
  HDRTEST drivers/gpu/drm/xe/xe_execlist.h
  CC [M]  drivers/gpu/drm/i915/display/intel_modeset_setup.o
  CC [M]  drivers/gpu/drm/i915/display/intel_overlay.o
  CC [M]  drivers/gpu/drm/i915/display/intel_pch_display.o
  CC [M]  drivers/gpu/drm/i915/display/intel_pch_refclk.o
  HDRTEST drivers/gpu/drm/xe/xe_execlist_types.h
  CC [M]  drivers/gpu/drm/i915/display/intel_plane_initial.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/g84.o
  CC [M]  drivers/gpu/drm/i915/display/intel_psr.o
  CC [M]  drivers/gpu/drm/i915/display/intel_quirks.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gt215.o
  CC [M]  drivers/gpu/drm/i915/display/intel_sprite.o
  CC [M]  drivers/gpu/drm/i915/display/intel_sprite_uapi.o
  HDRTEST drivers/gpu/drm/xe/xe_force_wake.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/mcp77.o
  HDRTEST drivers/gpu/drm/xe/xe_force_wake_types.h
  HDRTEST drivers/gpu/drm/xe/xe_ggtt.h
  HDRTEST drivers/gpu/drm/xe/xe_ggtt_types.h
  HDRTEST drivers/gpu/drm/xe/xe_gt.h
  HDRTEST drivers/gpu/drm/xe/xe_gt_clock.h
  CC [M]  drivers/gpu/drm/i915/display/intel_tc.o
  CC [M]  drivers/gpu/drm/i915/display/intel_vblank.o
  CC [M]  drivers/gpu/drm/i915/display/intel_vga.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/ih_v6_0.o
  HDRTEST drivers/gpu/drm/xe/xe_gt_debugfs.h
  CC [M]  drivers/gpu/drm/i915/display/intel_wm.o
  HDRTEST drivers/gpu/drm/xe/xe_gt_mcr.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/mcp89.o
  HDRTEST drivers/gpu/drm/xe/xe_gt_pagefault.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.o
  CC [M]  drivers/gpu/drm/i915/display/i9xx_plane.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.o
  CC [M]  drivers/gpu/drm/i915/display/i9xx_wm.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/psp_v3_1.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/psp_v10_0.o
  CC [M]  drivers/gpu/drm/i915/display/skl_scaler.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/psp_v11_0.o
  HDRTEST drivers/gpu/drm/xe/xe_gt_printk.h
  CC [M]  drivers/gpu/drm/i915/display/skl_universal_plane.o
  CC [M]  drivers/gpu/drm/i915/display/skl_watermark.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/psp_v11_0_8.o
  CC [M]  drivers/gpu/drm/i915/display/intel_acpi.o
  CC [M]  drivers/gpu/drm/i915/display/intel_opregion.o
  HDRTEST drivers/gpu/drm/xe/xe_gt_sysfs.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk20a.o
  HDRTEST drivers/gpu/drm/xe/xe_gt_sysfs_types.h
  HDRTEST drivers/gpu/drm/xe/xe_gt_tlb_invalidation.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/psp_v12_0.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.o
  HDRTEST drivers/gpu/drm/xe/xe_gt_tlb_invalidation_types.h
  CC [M]  drivers/gpu/drm/i915/display/intel_fbdev.o
  CC [M]  drivers/gpu/drm/i915/display/dvo_ch7017.o
  CC [M]  drivers/gpu/drm/i915/display/dvo_ch7xxx.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm200.o
  HDRTEST drivers/gpu/drm/xe/xe_gt_topology.h
  HDRTEST drivers/gpu/drm/xe/xe_gt_types.h
  CC [M]  drivers/gpu/drm/i915/display/dvo_ivch.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm20b.o
  HDRTEST drivers/gpu/drm/xe/xe_guc.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp102.o
  CC [M]  drivers/gpu/drm/i915/display/dvo_ns2501.o
  HDRTEST drivers/gpu/drm/xe/xe_guc_ads.h
  CC [M]  drivers/gpu/drm/i915/display/dvo_sil164.o
  HDRTEST drivers/gpu/drm/xe/xe_guc_ads_types.h
  HDRTEST drivers/gpu/drm/xe/xe_guc_ct.h
  CC [M]  drivers/gpu/drm/i915/display/dvo_tfp410.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp10b.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gv100.o
  CC [M]  drivers/gpu/drm/i915/display/g4x_dp.o
  CC [M]  drivers/gpu/drm/i915/display/g4x_hdmi.o
  CC [M]  drivers/gpu/drm/i915/display/icl_dsi.o
  CC [M]  drivers/gpu/drm/i915/display/intel_backlight.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/psp_v13_0.o
  CC [M]  drivers/gpu/drm/i915/display/intel_crt.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/tu102.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/psp_v13_0_4.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga100.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/dce_v10_0.o
  CC [M]  drivers/gpu/drm/i915/display/intel_cx0_phy.o
  HDRTEST drivers/gpu/drm/xe/xe_guc_ct_types.h
  HDRTEST drivers/gpu/drm/xe/xe_guc_debugfs.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga102.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/dce_v11_0.o
  HDRTEST drivers/gpu/drm/xe/xe_guc_engine_types.h
  HDRTEST drivers/gpu/drm/xe/xe_guc_fwif.h
  HDRTEST drivers/gpu/drm/xe/xe_guc_hwconfig.h
  CC [M]  drivers/gpu/drm/i915/display/intel_ddi.o
  CC [M]  drivers/gpu/drm/i915/display/intel_ddi_buf_trans.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.o
  CC [M]  drivers/gpu/drm/i915/display/intel_display_trace.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.o
  CC [M]  drivers/gpu/drm/i915/display/intel_dkl_phy.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.o
  CC [M]  drivers/gpu/drm/i915/display/intel_dp.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv04.o
  CC [M]  drivers/gpu/drm/i915/display/intel_dp_aux.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.o
  HDRTEST drivers/gpu/drm/xe/xe_guc_log.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv10.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.o
  HDRTEST drivers/gpu/drm/xe/xe_guc_log_types.h
  HDRTEST drivers/gpu/drm/xe/xe_guc_pc.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv20.o
  CC [M]  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv40.o
  HDRTEST drivers/gpu/drm/xe/xe_guc_pc_types.h
  CC [M]  drivers/gpu/drm/i915/display/intel_dp_hdcp.o
  CC [M]  drivers/gpu/drm/i915/display/intel_dp_link_training.o
  CC [M]  drivers/gpu/drm/i915/display/intel_dp_mst.o
  HDRTEST drivers/gpu/drm/xe/xe_guc_submit.h
  CC [M]  drivers/gpu/drm/i915/display/intel_dsi.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv41.o
  HDRTEST drivers/gpu/drm/xe/xe_guc_submit_types.h
  CC [M]  drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.o
  CC [M]  drivers/gpu/drm/i915/display/intel_dsi_vbt.o
  CC [M]  drivers/gpu/drm/i915/display/intel_dvo.o
  CC [M]  drivers/gpu/drm/i915/display/intel_gmbus.o
  CC [M]  drivers/gpu/drm/i915/display/intel_hdmi.o
  HDRTEST drivers/gpu/drm/xe/xe_guc_types.h
  CC [M]  drivers/gpu/drm/i915/display/intel_lspcon.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfx_v9_4.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.o
  HDRTEST drivers/gpu/drm/xe/xe_huc.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv44.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv49.o
  CC [M]  drivers/gpu/drm/i915/display/intel_lvds.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv4e.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv50.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.o
  HDRTEST drivers/gpu/drm/xe/xe_huc_debugfs.h
  HDRTEST drivers/gpu/drm/xe/xe_huc_types.h
  CC [M]  drivers/gpu/drm/i915/display/intel_panel.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.o
  HDRTEST drivers/gpu/drm/xe/xe_hw_engine.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/imu_v11_0.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.o
  CC [M]  drivers/gpu/drm/i915/display/intel_pps.o
  CC [M]  drivers/gpu/drm/i915/display/intel_qp_tables.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfx_v11_0.o
  HDRTEST drivers/gpu/drm/xe/xe_hw_engine_types.h
  CC [M]  drivers/gpu/drm/i915/display/intel_sdvo.o
  CC [M]  drivers/gpu/drm/i915/display/intel_snps_phy.o
  CC [M]  drivers/gpu/drm/i915/display/intel_tv.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.o
  CC [M]  drivers/gpu/drm/i915/display/intel_vdsc.o
  CC [M]  drivers/gpu/drm/i915/display/intel_vrr.o
  HDRTEST drivers/gpu/drm/xe/xe_hw_fence.h
  CC [M]  drivers/gpu/drm/i915/display/vlv_dsi.o
  CC [M]  drivers/gpu/drm/i915/display/vlv_dsi_pll.o
  CC [M]  drivers/gpu/drm/i915/i915_perf.o
  CC [M]  drivers/gpu/drm/i915/pxp/intel_pxp.o
  HDRTEST drivers/gpu/drm/xe/xe_hw_fence_types.h
  CC [M]  drivers/gpu/drm/i915/pxp/intel_pxp_tee.o
  HDRTEST drivers/gpu/drm/xe/xe_irq.h
  HDRTEST drivers/gpu/drm/xe/xe_lrc.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/gfx_v11_0_3.o
  CC [M]  drivers/gpu/drm/i915/pxp/intel_pxp_huc.o
  HDRTEST drivers/gpu/drm/xe/xe_lrc_types.h
  CC [M]  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.o
  CC [M]  drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/imu_v11_0_3.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.o
  CC [M]  drivers/gpu/drm/i915/pxp/intel_pxp_irq.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.o
  CC [M]  drivers/gpu/drm/i915/pxp/intel_pxp_pm.o
  CC [M]  drivers/gpu/drm/i915/pxp/intel_pxp_session.o
  HDRTEST drivers/gpu/drm/xe/xe_macros.h
  CC [M]  drivers/gpu/drm/i915/i915_gpu_error.o
  CC [M]  drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.o
  HDRTEST drivers/gpu/drm/xe/xe_map.h
  HDRTEST drivers/gpu/drm/xe/xe_migrate.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.o
  HDRTEST drivers/gpu/drm/xe/xe_migrate_doc.h
  HDRTEST drivers/gpu/drm/xe/xe_mmio.h
  CC [M]  drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/sdma_v4_4.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramga102.o
  CC [M]  drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.o
  CC [M]  drivers/gpu/drm/i915/selftests/i915_random.o
  CC [M]  drivers/gpu/drm/i915/selftests/i915_selftest.o
  CC [M]  drivers/gpu/drm/i915/selftests/igt_atomic.o
  HDRTEST drivers/gpu/drm/xe/xe_mocs.h
  HDRTEST drivers/gpu/drm/xe/xe_module.h
  HDRTEST drivers/gpu/drm/xe/xe_pat.h
  HDRTEST drivers/gpu/drm/xe/xe_pci.h
  HDRTEST drivers/gpu/drm/xe/xe_pci_types.h
  CC [M]  drivers/gpu/drm/i915/selftests/igt_flush_test.o
  HDRTEST drivers/gpu/drm/xe/xe_pcode.h
  HDRTEST drivers/gpu/drm/xe/xe_pcode_api.h
  HDRTEST drivers/gpu/drm/xe/xe_platform_types.h
  HDRTEST drivers/gpu/drm/xe/xe_pm.h
  HDRTEST drivers/gpu/drm/xe/xe_preempt_fence.h
  CC [M]  drivers/gpu/drm/i915/selftests/igt_live_test.o
  HDRTEST drivers/gpu/drm/xe/xe_preempt_fence_types.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.o
  CC [M]  drivers/gpu/drm/i915/selftests/igt_mmap.o
  CC [M]  drivers/gpu/drm/i915/selftests/igt_reset.o
  HDRTEST drivers/gpu/drm/xe/xe_pt.h
  CC [M]  drivers/gpu/drm/i915/selftests/igt_spinner.o
  CC [M]  drivers/gpu/drm/i915/selftests/librapl.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/sdma_v5_0.o
  HDRTEST drivers/gpu/drm/xe/xe_pt_types.h
  CC [M]  drivers/gpu/drm/i915/i915_vgpu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/sdma_v5_2.o
  HDRTEST drivers/gpu/drm/i915/display/intel_dkl_phy_regs.h
  HDRTEST drivers/gpu/drm/i915/display/intel_crtc_state_dump.h
  HDRTEST drivers/gpu/drm/i915/display/hsw_ips.h
  HDRTEST drivers/gpu/drm/xe/xe_pt_walk.h
  HDRTEST drivers/gpu/drm/i915/display/g4x_hdmi.h
  HDRTEST drivers/gpu/drm/xe/xe_query.h
  HDRTEST drivers/gpu/drm/xe/xe_reg_sr.h
  HDRTEST drivers/gpu/drm/xe/xe_reg_sr_types.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.o
  HDRTEST drivers/gpu/drm/i915/display/intel_hdcp_regs.h
  HDRTEST drivers/gpu/drm/xe/xe_reg_whitelist.h
  HDRTEST drivers/gpu/drm/i915/display/intel_overlay.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr5.o
  HDRTEST drivers/gpu/drm/xe/xe_res_cursor.h
  HDRTEST drivers/gpu/drm/i915/display/intel_display.h
  HDRTEST drivers/gpu/drm/i915/display/skl_watermark_regs.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dmc.h
  HDRTEST drivers/gpu/drm/i915/display/intel_vga.h
  HDRTEST drivers/gpu/drm/i915/display/intel_audio.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/sdma_v6_0.o
  HDRTEST drivers/gpu/drm/i915/display/intel_lvds.h
  HDRTEST drivers/gpu/drm/i915/display/intel_modeset_setup.h
  HDRTEST drivers/gpu/drm/i915/display/intel_cdclk.h
  HDRTEST drivers/gpu/drm/i915/display/intel_display_limits.h
  HDRTEST drivers/gpu/drm/xe/xe_ring_ops.h
  HDRTEST drivers/gpu/drm/xe/xe_ring_ops_types.h
  HDRTEST drivers/gpu/drm/i915/display/intel_hotplug.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_mes.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/mes_v10_1.o
  HDRTEST drivers/gpu/drm/xe/xe_rtp.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dkl_phy.h
  HDRTEST drivers/gpu/drm/i915/display/intel_atomic.h
  HDRTEST drivers/gpu/drm/xe/xe_rtp_types.h
  HDRTEST drivers/gpu/drm/xe/xe_sa.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/mes_v11_0.o
  HDRTEST drivers/gpu/drm/xe/xe_sa_types.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.o
  HDRTEST drivers/gpu/drm/xe/xe_sched_job.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fuse/base.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fuse/nv50.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.o
  HDRTEST drivers/gpu/drm/i915/display/intel_display_driver.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dpll.h
  HDRTEST drivers/gpu/drm/i915/display/vlv_dsi_pll_regs.h
  HDRTEST drivers/gpu/drm/xe/xe_sched_job_types.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dp_mst.h
  HDRTEST drivers/gpu/drm/i915/display/intel_fdi_regs.h
  HDRTEST drivers/gpu/drm/i915/display/g4x_dp.h
  HDRTEST drivers/gpu/drm/i915/display/intel_tc.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fuse/gf100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fuse/gm107.o
  HDRTEST drivers/gpu/drm/i915/display/intel_frontbuffer.h
  HDRTEST drivers/gpu/drm/xe/xe_step.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dsi_vbt.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.o
  HDRTEST drivers/gpu/drm/xe/xe_step_types.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/gpio/nv10.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/gpio/nv50.o
  HDRTEST drivers/gpu/drm/i915/display/intel_psr.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/gpio/g94.o
  HDRTEST drivers/gpu/drm/xe/xe_sync.h
  HDRTEST drivers/gpu/drm/i915/display/intel_crt.h
  HDRTEST drivers/gpu/drm/xe/xe_sync_types.h
  HDRTEST drivers/gpu/drm/i915/display/intel_opregion.h
  HDRTEST drivers/gpu/drm/xe/xe_trace.h
  HDRTEST drivers/gpu/drm/i915/display/intel_snps_phy_regs.h
  HDRTEST drivers/gpu/drm/xe/xe_ttm_stolen_mgr.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.o
  HDRTEST drivers/gpu/drm/xe/xe_ttm_sys_mgr.h
  HDRTEST drivers/gpu/drm/xe/xe_ttm_vram_mgr.h
  HDRTEST drivers/gpu/drm/i915/display/i9xx_wm.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/gpio/gf119.o
  HDRTEST drivers/gpu/drm/xe/xe_ttm_vram_mgr_types.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/vce_v3_0.o
  HDRTEST drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/vce_v4_0.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/gpio/gk104.o
  HDRTEST drivers/gpu/drm/xe/xe_tuning.h
  HDRTEST drivers/gpu/drm/i915/display/intel_global_state.h
  HDRTEST drivers/gpu/drm/xe/xe_uc.h
  HDRTEST drivers/gpu/drm/i915/display/intel_lpe_audio.h
  HDRTEST drivers/gpu/drm/xe/xe_uc_debugfs.h
  HDRTEST drivers/gpu/drm/xe/xe_uc_fw.h
  HDRTEST drivers/gpu/drm/i915/display/intel_drrs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/vcn_sw_ring.o
  HDRTEST drivers/gpu/drm/xe/xe_uc_fw_abi.h
  HDRTEST drivers/gpu/drm/i915/display/intel_display_rps.h
  HDRTEST drivers/gpu/drm/xe/xe_uc_fw_types.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/vcn_v1_0.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/vcn_v2_0.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/vcn_v2_5.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/vcn_v3_0.o
  HDRTEST drivers/gpu/drm/xe/xe_uc_types.h
  HDRTEST drivers/gpu/drm/i915/display/intel_fbdev.h
  HDRTEST drivers/gpu/drm/i915/display/intel_pps_regs.h
  HDRTEST drivers/gpu/drm/i915/display/intel_hdmi.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/vcn_v4_0.o
  HDRTEST drivers/gpu/drm/i915/display/intel_fdi.h
  HDRTEST drivers/gpu/drm/i915/display/intel_fb.h
  HDRTEST drivers/gpu/drm/xe/xe_vm.h
  HDRTEST drivers/gpu/drm/i915/display/intel_qp_tables.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dsb_regs.h
  HDRTEST drivers/gpu/drm/i915/display/intel_vdsc.h
  HDRTEST drivers/gpu/drm/xe/xe_vm_doc.h
  HDRTEST drivers/gpu/drm/xe/xe_vm_madvise.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/gpio/ga102.o
  HDRTEST drivers/gpu/drm/i915/display/intel_snps_phy.h
  HDRTEST drivers/gpu/drm/xe/xe_vm_types.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.o
  HDRTEST drivers/gpu/drm/i915/display/intel_display_core.h
../drivers/gpu/drm/i915/i915_gpu_error.c:2174: warning: Function parameter or member 'dump_flags' not described in 'i915_capture_error_state'
  HDRTEST drivers/gpu/drm/i915/display/vlv_dsi_pll.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dvo_dev.h
  HDRTEST drivers/gpu/drm/i915/display/intel_hdcp.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.o
  HDRTEST drivers/gpu/drm/i915/display/intel_sdvo_regs.h
  HDRTEST drivers/gpu/drm/xe/xe_wa.h
  HDRTEST drivers/gpu/drm/xe/xe_wait_user_fence.h
  HDRTEST drivers/gpu/drm/i915/display/intel_pch_refclk.h
  HDRTEST drivers/gpu/drm/xe/xe_wopcm.h
  HDRTEST drivers/gpu/drm/i915/display/intel_display_trace.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.o
  HDRTEST drivers/gpu/drm/xe/xe_wopcm_types.h
  LD [M]  drivers/gpu/drm/xe/xe.o
  HDRTEST drivers/gpu/drm/i915/display/intel_display_power.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dp_aux_regs.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/gsp/gv100.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ga102.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.o
  HDRTEST drivers/gpu/drm/i915/display/i9xx_plane.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/nv04.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/nv4e.o
  HDRTEST drivers/gpu/drm/i915/display/intel_dp_aux_backlight.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/nv50.o
  HDRTEST drivers/gpu/drm/i915/display/intel_dpll_mgr.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/athub_v1_0.o
  HDRTEST drivers/gpu/drm/i915/display/vlv_dsi.h
  HDRTEST drivers/gpu/drm/i915/display/intel_plane_initial.h
  HDRTEST drivers/gpu/drm/i915/display/intel_fifo_underrun.h
  HDRTEST drivers/gpu/drm/i915/display/intel_cursor.h
  HDRTEST drivers/gpu/drm/i915/display/vlv_dsi_regs.h
  HDRTEST drivers/gpu/drm/i915/display/intel_cx0_phy.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/athub_v2_0.o
  HDRTEST drivers/gpu/drm/i915/display/skl_scaler.h
  HDRTEST drivers/gpu/drm/i915/display/intel_hti.h
  HDRTEST drivers/gpu/drm/i915/display/icl_dsi_regs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/athub_v2_1.o
  HDRTEST drivers/gpu/drm/i915/display/intel_atomic_plane.h
  HDRTEST drivers/gpu/drm/i915/display/skl_watermark.h
  HDRTEST drivers/gpu/drm/i915/display/intel_fbc.h
  HDRTEST drivers/gpu/drm/i915/display/intel_acpi.h
  HDRTEST drivers/gpu/drm/i915/display/intel_display_reg_defs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/athub_v3_0.o
drivers/gpu/drm/xe/xe.o: warning: objtool: intel_set_cpu_fifo_underrun_reporting+0x2df: unreachable instruction
  CC [M]  drivers/gpu/drm/amd/amdgpu/smuio_v9_0.o
  HDRTEST drivers/gpu/drm/i915/display/intel_connector.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/g94.o
  HDRTEST drivers/gpu/drm/i915/display/intel_dpt.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/smuio_v11_0.o
../drivers/gpu/drm/i915/i915_perf.c:5307: warning: Function parameter or member 'i915' not described in 'i915_perf_ioctl_version'
  HDRTEST drivers/gpu/drm/i915/display/intel_quirks.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dp_link_training.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/smuio_v11_0_6.o
  HDRTEST drivers/gpu/drm/i915/display/intel_color.h
  HDRTEST drivers/gpu/drm/i915/display/intel_crtc.h
  HDRTEST drivers/gpu/drm/i915/display/intel_display_debugfs.h
  HDRTEST drivers/gpu/drm/i915/display/intel_modeset_verify.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/smuio_v13_0.o
  HDRTEST drivers/gpu/drm/i915/display/intel_display_power_well.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/smuio_v13_0_6.o
  HDRTEST drivers/gpu/drm/i915/display/intel_psr_regs.h
  HDRTEST drivers/gpu/drm/i915/display/intel_wm.h
  HDRTEST drivers/gpu/drm/i915/display/intel_pipe_crc.h
  HDRTEST drivers/gpu/drm/i915/display/intel_audio_regs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_reset.o
  HDRTEST drivers/gpu/drm/i915/display/intel_panel.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/mca_v3_0.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/gf117.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_module.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/gf119.o
  HDRTEST drivers/gpu/drm/i915/display/intel_sprite.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_chardev.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/gk104.o
  HDRTEST drivers/gpu/drm/i915/display/intel_wm_types.h
  HDRTEST drivers/gpu/drm/i915/display/intel_tv.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.o
  HDRTEST drivers/gpu/drm/i915/display/intel_hti_regs.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/gk110.o
  HDRTEST drivers/gpu/drm/i915/display/intel_vrr.h
  HDRTEST drivers/gpu/drm/i915/display/intel_load_detect.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_pasid.o
  HDRTEST drivers/gpu/drm/i915/display/skl_universal_plane.h
  HDRTEST drivers/gpu/drm/i915/display/intel_mg_phy_regs.h
  HDRTEST drivers/gpu/drm/i915/display/intel_bw.h
  HDRTEST drivers/gpu/drm/i915/display/intel_de.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/gm200.o
  HDRTEST drivers/gpu/drm/i915/display/intel_lvds_regs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_doorbell.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_flat_memory.o
  HDRTEST drivers/gpu/drm/i915/display/intel_gmbus_regs.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dvo.h
  HDRTEST drivers/gpu/drm/i915/display/intel_sdvo.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/pad.o
  HDRTEST drivers/gpu/drm/i915/display/intel_dp_aux.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padnv04.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.o
  HDRTEST drivers/gpu/drm/i915/display/intel_vdsc_regs.h
  HDRTEST drivers/gpu/drm/i915/display/intel_combo_phy.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dvo_regs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_queue.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_mqd_manager.o
  HDRTEST drivers/gpu/drm/i915/display/intel_gmbus.h
  HDRTEST drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dsi.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_mqd_manager_cik.o
  HDRTEST drivers/gpu/drm/i915/display/intel_dmc_regs.h
  HDRTEST drivers/gpu/drm/i915/display/intel_ddi.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padnv4e.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padnv50.o
  HDRTEST drivers/gpu/drm/i915/display/intel_hotplug_irq.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padg94.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padgf119.o
  HDRTEST drivers/gpu/drm/i915/display/intel_tv_regs.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dsb.h
  HDRTEST drivers/gpu/drm/i915/display/intel_bios.h
  HDRTEST drivers/gpu/drm/i915/display/intel_pch_display.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_mqd_manager_vi.o
  HDRTEST drivers/gpu/drm/i915/display/intel_display_types.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_mqd_manager_v9.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_mqd_manager_v10.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padgm200.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.o
  HDRTEST drivers/gpu/drm/i915/display/intel_backlight.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.o
  HDRTEST drivers/gpu/drm/i915/display/intel_vblank.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_mqd_manager_v11.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv4e.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv50.o
  HDRTEST drivers/gpu/drm/i915/display/intel_dp.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_kernel_queue.o
  HDRTEST drivers/gpu/drm/i915/display/intel_backlight_regs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_packet_manager.o
  HDRTEST drivers/gpu/drm/i915/display/intel_combo_phy_regs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_packet_manager_vi.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_packet_manager_v9.o
  HDRTEST drivers/gpu/drm/i915/display/intel_display_reset.h
  HDRTEST drivers/gpu/drm/i915/display/intel_display_power_map.h
  HDRTEST drivers/gpu/drm/i915/display/intel_ddi_buf_trans.h
  HDRTEST drivers/gpu/drm/i915/display/icl_dsi.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busgf119.o
  HDRTEST drivers/gpu/drm/i915/display/intel_lspcon.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process_queue_manager.o
  HDRTEST drivers/gpu/drm/i915/display/intel_dpio_phy.h
  HDRTEST drivers/gpu/drm/i915/display/intel_dp_hdcp.h
  HDRTEST drivers/gpu/drm/i915/display/intel_fb_pin.h
  HDRTEST drivers/gpu/drm/i915/display/intel_pps.h
  HDRTEST drivers/gpu/drm/i915/display/intel_sprite_uapi.h
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_ttm.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bit.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_region.h
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_context_types.h
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_lmem.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_mman.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_object_types.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager_cik.o
../drivers/gpu/drm/i915/gem/i915_gem_region.h:25: warning: Incorrect use of kernel-doc format:          * process_obj - Process the current object
../drivers/gpu/drm/i915/gem/i915_gem_region.h:35: warning: Function parameter or member 'process_obj' not described in 'i915_gem_apply_to_region_ops'
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_context.h
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_clflush.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager_vi.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgf119.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager_v9.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager_v10.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/anx9805.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_tiling.h
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_stolen.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager_v11.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_interrupt.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_create.h
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_events.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/gf100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/instmem/base.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/cik_event_interrupt.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_domain.h
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_internal.h
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_dmabuf.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_int_process_v9.o
  HDRTEST drivers/gpu/drm/i915/gem/selftests/mock_context.h
  HDRTEST drivers/gpu/drm/i915/gem/selftests/huge_gem_object.h
  HDRTEST drivers/gpu/drm/i915/gem/selftests/mock_gem_object.h
  HDRTEST drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.h
  HDRTEST drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv04.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_int_process_v11.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_userptr.h
../drivers/gpu/drm/i915/gem/i915_gem_ttm.h:50: warning: Function parameter or member 'bo' not described in 'i915_ttm_to_gem'
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_smi_events.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_pm.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_debugfs.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_shrinker.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gemfs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.o
  HDRTEST drivers/gpu/drm/i915/gem/i915_gem_object.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_timeline_types.h
  HDRTEST drivers/gpu/drm/i915/gt/selftest_engine.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_context_types.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_execlists_submission.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_pm.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv40.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.o
  HDRTEST drivers/gpu/drm/i915/gt/selftest_rc6.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_llc_types.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_region_lmem.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/ltc/base.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_requests.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_ggtt_gmch.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_print.h
  HDRTEST drivers/gpu/drm/i915/gt/gen8_ppgtt.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gf100.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_mcr.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_job.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_timeline.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_acp.o
  HDRTEST drivers/gpu/drm/i915/gt/gen6_engine_cs.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_workarounds_types.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gk104.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../acp/acp_hw.o
  HDRTEST drivers/gpu/drm/i915/gt/selftest_rps.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gm107.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gm200.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp100.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_sa_media.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_clock_utils.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_rps_types.h
  HDRTEST drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.h
  HDRTEST drivers/gpu/drm/i915/gt/sysfs_engines.h
../drivers/gpu/drm/i915/gem/i915_gem_object.h:94: warning: Function parameter or member 'file' not described in 'i915_gem_object_lookup_rcu'
../drivers/gpu/drm/i915/gem/i915_gem_object.h:94: warning: Excess function parameter 'filp' description in 'i915_gem_object_lookup_rcu'
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/arcturus_ppt.o
  HDRTEST drivers/gpu/drm/i915/gt/gen7_renderclear.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_context.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/navi10_ppt.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_wopcm.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/sienna_cichlid_ppt.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_mocs.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_engine_pm.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_rc6.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/cyan_skillfish_ppt.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/smu_v11_0.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_ring_types.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_workarounds.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp102.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_engine_regs.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_pm_irq.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.o
  HDRTEST drivers/gpu/drm/i915/gt/shmem_utils.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu12/renoir_ppt.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_engine.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_reset_types.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_regs.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_reset.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu12/smu_v12_0.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/ltc/ga102.o
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_uc.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/base.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/aldebaran_ppt.o
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/yellow_carp_ppt.o
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_fw.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/nv04.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_0_ppt.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/nv11.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/nv17.o
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/nv44.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/nv50.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/g84.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/g98.o
  HDRTEST drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_4_ppt.o
  HDRTEST drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/gt215.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_5_ppt.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/gf100.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_7_ppt.o
  HDRTEST drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/gk104.o
  HDRTEST drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/gk20a.o
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.o
../drivers/gpu/drm/i915/gt/intel_context.h:108: warning: Function parameter or member 'ce' not described in 'intel_context_lock_pinned'
../drivers/gpu/drm/i915/gt/intel_context.h:123: warning: Function parameter or member 'ce' not described in 'intel_context_is_pinned'
../drivers/gpu/drm/i915/gt/intel_context.h:142: warning: Function parameter or member 'ce' not described in 'intel_context_unlock_pinned'
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_huc.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/amdgpu_smu.o
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp100.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.o
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_slpc_types.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp10b.o
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'size' not described in '__guc_capture_bufstate'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'data' not described in '__guc_capture_bufstate'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'rd' not described in '__guc_capture_bufstate'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'wr' not described in '__guc_capture_bufstate'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'link' not described in '__guc_capture_parsed_output'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'is_partial' not described in '__guc_capture_parsed_output'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'eng_class' not described in '__guc_capture_parsed_output'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'eng_inst' not described in '__guc_capture_parsed_output'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'guc_id' not described in '__guc_capture_parsed_output'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'lrca' not described in '__guc_capture_parsed_output'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'reginfo' not described in '__guc_capture_parsed_output'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:62: warning: wrong kernel-doc identifier on line:
 * struct guc_debug_capture_list_header / struct guc_debug_capture_list
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:80: warning: wrong kernel-doc identifier on line:
 * struct __guc_mmio_reg_descr / struct __guc_mmio_reg_descr_group
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:105: warning: wrong kernel-doc identifier on line:
 * struct guc_state_capture_header_t / struct guc_state_capture_t /
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'is_valid' not described in '__guc_capture_ads_cache'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'ptr' not described in '__guc_capture_ads_cache'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'size' not described in '__guc_capture_ads_cache'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'status' not described in '__guc_capture_ads_cache'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:216: warning: Function parameter or member 'ads_null_cache' not described in 'intel_guc_state_capture'
../drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:216: warning: Function parameter or member 'max_mmio_per_node' not described in 'intel_guc_state_capture'
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.h
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_guc_rc.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smumgr.o
  HDRTEST drivers/gpu/drm/i915/gt/uc/intel_huc_debugfs.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_hwconfig.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_llc.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu8_smumgr.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.o
  HDRTEST drivers/gpu/drm/i915/gt/gen8_engine_cs.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_sseu_debugfs.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_rc6_types.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/tonga_smumgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/fiji_smumgr.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_context_param.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gpu_commands.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv04.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_engine_user.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_irq.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gsc.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/polaris10_smumgr.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv44.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_rps.h
  HDRTEST drivers/gpu/drm/i915/gt/selftest_llc.h
  HDRTEST drivers/gpu/drm/i915/gt/gen6_ppgtt.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv50.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/g84.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/iceland_smumgr.o
../drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'marker' not described in 'guc_log_buffer_state'
../drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'read_ptr' not described in 'guc_log_buffer_state'
../drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'write_ptr' not described in 'guc_log_buffer_state'
../drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'size' not described in 'guc_log_buffer_state'
../drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'sampled_write_ptr' not described in 'guc_log_buffer_state'
../drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'wrap_offset' not described in 'guc_log_buffer_state'
../drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'flush_to_file' not described in 'guc_log_buffer_state'
../drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'buffer_full_cnt' not described in 'guc_log_buffer_state'
../drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'reserved' not described in 'guc_log_buffer_state'
../drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'flags' not described in 'guc_log_buffer_state'
../drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'version' not described in 'guc_log_buffer_state'
  HDRTEST drivers/gpu/drm/i915/gt/intel_migrate_types.h
  HDRTEST drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/vega10_smumgr.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_lrc.h
../drivers/gpu/drm/i915/gt/uc/intel_guc.h:274: warning: Function parameter or member 'dbgfs_node' not described in 'intel_guc'
  HDRTEST drivers/gpu/drm/i915/gt/intel_lrc_reg.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_migrate.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu10_smumgr.o
  HDRTEST drivers/gpu/drm/i915/gt/mock_engine.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/ci_smumgr.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_engine_stats.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/vega12_smumgr.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_gtt.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_buffer_pool_types.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/mcp77.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/vegam_smumgr.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gf100.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_ring.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_types.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk104.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_renderstate.h
  HDRTEST drivers/gpu/drm/i915/gt/intel_sseu.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu9_smumgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/vega20_smumgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/hwmgr.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_engine_types.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gm200.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/processpptables.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gm20b.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/hardwaremanager.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gp100.o
  HDRTEST drivers/gpu/drm/i915/gt/intel_gt_engines_debugfs.h
  HDRTEST drivers/gpu/drm/i915/gt/gen2_engine_cs.h
  HDRTEST drivers/gpu/drm/i915/gvt/gvt.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gp10b.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu8_hwmgr.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gv100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/tu102.o
  HDRTEST drivers/gpu/drm/i915/gvt/trace.h
  HDRTEST drivers/gpu/drm/i915/gvt/debug.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/pppcielanes.o
  HDRTEST drivers/gpu/drm/i915/gvt/edid.h
  HDRTEST drivers/gpu/drm/i915/gvt/page_track.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/mem.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/memnv04.o
  HDRTEST drivers/gpu/drm/i915/gvt/mmio.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.o
  HDRTEST drivers/gpu/drm/i915/gvt/sched_policy.h
  HDRTEST drivers/gpu/drm/i915/gvt/fb_decoder.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.o
  HDRTEST drivers/gpu/drm/i915/gvt/cmd_parser.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomfwctrl.o
  HDRTEST drivers/gpu/drm/i915/gvt/dmabuf.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/memnv50.o
  HDRTEST drivers/gpu/drm/i915/gvt/mmio_context.h
  HDRTEST drivers/gpu/drm/i915/gvt/display.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/memgf100.o
../drivers/gpu/drm/i915/gt/intel_gtt.h:515: warning: Function parameter or member 'vm' not described in 'i915_vm_resv_put'
../drivers/gpu/drm/i915/gt/intel_gtt.h:515: warning: Excess function parameter 'resv' description in 'i915_vm_resv_put'
  HDRTEST drivers/gpu/drm/i915/gvt/gtt.h
  HDRTEST drivers/gpu/drm/i915/gvt/scheduler.h
  HDRTEST drivers/gpu/drm/i915/gvt/reg.h
  HDRTEST drivers/gpu/drm/i915/gvt/execlist.h
  HDRTEST drivers/gpu/drm/i915/gvt/interrupt.h
  HDRTEST drivers/gpu/drm/i915/i915_active.h
  HDRTEST drivers/gpu/drm/i915/i915_active_types.h
  HDRTEST drivers/gpu/drm/i915/i915_cmd_parser.h
  HDRTEST drivers/gpu/drm/i915/i915_config.h
  HDRTEST drivers/gpu/drm/i915/i915_debugfs.h
  HDRTEST drivers/gpu/drm/i915/i915_debugfs_params.h
  HDRTEST drivers/gpu/drm/i915/i915_deps.h
  HDRTEST drivers/gpu/drm/i915/i915_driver.h
  HDRTEST drivers/gpu/drm/i915/i915_drm_client.h
  HDRTEST drivers/gpu/drm/i915/i915_drv.h
  HDRTEST drivers/gpu/drm/i915/i915_file_private.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.o
  HDRTEST drivers/gpu/drm/i915/i915_fixed.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmnv04.o
../drivers/gpu/drm/i915/gt/intel_engine_types.h:293: warning: Function parameter or member 'preempt_hang' not described in 'intel_engine_execlists'
  HDRTEST drivers/gpu/drm/i915/i915_gem.h
  HDRTEST drivers/gpu/drm/i915/i915_gem_evict.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmnv41.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmnv44.o
  HDRTEST drivers/gpu/drm/i915/i915_gem_gtt.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmnv50.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmmcp77.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_powertune.o
  HDRTEST drivers/gpu/drm/i915/i915_gem_ww.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_thermal.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_clockpowergating.o
  HDRTEST drivers/gpu/drm/i915/i915_getparam.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk104.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm200.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_processpptables.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.o
  HDRTEST drivers/gpu/drm/i915/i915_gpu_error.h
  HDRTEST drivers/gpu/drm/i915/i915_hwmon.h
  HDRTEST drivers/gpu/drm/i915/i915_ioc32.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_powertune.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.o
  HDRTEST drivers/gpu/drm/i915/i915_ioctl.h
  HDRTEST drivers/gpu/drm/i915/i915_iosf_mbi.h
  HDRTEST drivers/gpu/drm/i915/i915_irq.h
  HDRTEST drivers/gpu/drm/i915/i915_memcpy.h
  HDRTEST drivers/gpu/drm/i915/i915_mitigations.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_thermal.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.o
  HDRTEST drivers/gpu/drm/i915/i915_mm.h
  HDRTEST drivers/gpu/drm/i915/i915_params.h
../drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'active' not described in '__i915_active_fence_init'
../drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fence' not described in '__i915_active_fence_init'
../drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fn' not described in '__i915_active_fence_init'
../drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'active' not described in 'i915_active_fence_set'
../drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'rq' not described in 'i915_active_fence_set'
../drivers/gpu/drm/i915/i915_active.h:102: warning: Function parameter or member 'active' not described in 'i915_active_fence_get'
../drivers/gpu/drm/i915/i915_active.h:122: warning: Function parameter or member 'active' not described in 'i915_active_fence_isset'
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu10_hwmgr.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgv100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmtu102.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/umem.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/pp_psm.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/ummu.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_processpptables.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mxm/base.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_hwmgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_thermal.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mxm/mxms.o
  HDRTEST drivers/gpu/drm/i915/i915_pci.h
  HDRTEST drivers/gpu/drm/i915/i915_perf.h
  HDRTEST drivers/gpu/drm/i915/i915_perf_oa_regs.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/mxm/nv50.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/pp_overdriver.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu_helper.o
  HDRTEST drivers/gpu/drm/i915/i915_perf_types.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.o
  HDRTEST drivers/gpu/drm/i915/i915_pmu.h
  HDRTEST drivers/gpu/drm/i915/i915_priolist_types.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_processpptables.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_hwmgr.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_powertune.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/nv04.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_thermal.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/common_baco.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/nv40.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_baco.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/nv46.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/nv4c.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_baco.o
  HDRTEST drivers/gpu/drm/i915/i915_pvinfo.h
  HDRTEST drivers/gpu/drm/i915/i915_query.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/g84.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/g92.o
  HDRTEST drivers/gpu/drm/i915/i915_reg.h
  HDRTEST drivers/gpu/drm/i915/i915_reg_defs.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/g94.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/gf100.o
  HDRTEST drivers/gpu/drm/i915/i915_request.h
  HDRTEST drivers/gpu/drm/i915/i915_scatterlist.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_baco.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu9_baco.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/tonga_baco.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/polaris_baco.o
  HDRTEST drivers/gpu/drm/i915/i915_scheduler.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/gf106.o
  HDRTEST drivers/gpu/drm/i915/i915_scheduler_types.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/fiji_baco.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pci/gp100.o
../drivers/gpu/drm/i915/i915_pmu.h:21: warning: cannot understand function prototype: 'enum i915_pmu_tracked_events '
../drivers/gpu/drm/i915/i915_pmu.h:32: warning: cannot understand function prototype: 'enum '
../drivers/gpu/drm/i915/i915_pmu.h:41: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * How many different events we track in the global PMU mask.
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.o
  HDRTEST drivers/gpu/drm/i915/i915_selftest.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.o
  HDRTEST drivers/gpu/drm/i915/i915_suspend.h
  HDRTEST drivers/gpu/drm/i915/i915_sw_fence.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ci_baco.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gt215.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gf100.o
  HDRTEST drivers/gpu/drm/i915/i915_sw_fence_work.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_baco.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gf119.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gk104.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gk110.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/powerplay/amd_powerplay.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/legacy_dpm.o
  HDRTEST drivers/gpu/drm/i915/i915_switcheroo.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gk208.o
  HDRTEST drivers/gpu/drm/i915/i915_syncmap.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_smc.o
../drivers/gpu/drm/i915/i915_scatterlist.h:160: warning: Incorrect use of kernel-doc format:          * release() - Free the memory of the struct i915_refct_sgt
../drivers/gpu/drm/i915/i915_scatterlist.h:164: warning: Function parameter or member 'release' not described in 'i915_refct_sgt_ops'
../drivers/gpu/drm/i915/i915_scatterlist.h:187: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_put'
../drivers/gpu/drm/i915/i915_scatterlist.h:198: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_get'
../drivers/gpu/drm/i915/i915_scatterlist.h:214: warning: Function parameter or member 'rsgt' not described in '__i915_refct_sgt_init'
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/si_dpm.o
  HDRTEST drivers/gpu/drm/i915/i915_sysfs.h
  HDRTEST drivers/gpu/drm/i915/i915_tasklet.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/si_smc.o
  HDRTEST drivers/gpu/drm/i915/i915_trace.h
  HDRTEST drivers/gpu/drm/i915/i915_ttm_buddy_manager.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gk20a.o
../drivers/gpu/drm/i915/i915_request.h:176: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Request queue structure.
../drivers/gpu/drm/i915/i915_request.h:477: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Returns true if seq1 is later than seq2.
  HDRTEST drivers/gpu/drm/i915/i915_user_extensions.h
  HDRTEST drivers/gpu/drm/i915/i915_utils.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/amdgpu_dpm.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm107.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/amdgpu_pm.o
  HDRTEST drivers/gpu/drm/i915/i915_vgpu.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/amdgpu_dpm_internal.o
  HDRTEST drivers/gpu/drm/i915/i915_vma.h
  HDRTEST drivers/gpu/drm/i915/i915_vma_resource.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.o
  HDRTEST drivers/gpu/drm/i915/i915_vma_types.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm200.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.o
  HDRTEST drivers/gpu/drm/i915/intel_clock_gating.h
  HDRTEST drivers/gpu/drm/i915/intel_device_info.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.o
  HDRTEST drivers/gpu/drm/i915/intel_gvt.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_crtc.o
  HDRTEST drivers/gpu/drm/i915/intel_mchbar_regs.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.o
  HDRTEST drivers/gpu/drm/i915/intel_memory_region.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/privring/gf100.o
  HDRTEST drivers/gpu/drm/i915/intel_pci_config.h
../drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'OP' not described in '__wait_for'
../drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'COND' not described in '__wait_for'
../drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'US' not described in '__wait_for'
../drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'Wmin' not described in '__wait_for'
../drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'Wmax' not described in '__wait_for'
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/privring/gf117.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/dc_fpu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_services.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/privring/gk104.o
  HDRTEST drivers/gpu/drm/i915/intel_pcode.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/privring/gk20a.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/privring/gm200.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/privring/gp10b.o
  HDRTEST drivers/gpu/drm/i915/intel_region_ttm.h
  HDRTEST drivers/gpu/drm/i915/intel_runtime_pm.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/fan.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_psr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.o
../drivers/gpu/drm/i915/i915_vma_resource.h:91: warning: Incorrect use of kernel-doc format:          * struct i915_vma_bindinfo - Information needed for async bind
../drivers/gpu/drm/i915/i915_vma_resource.h:129: warning: Function parameter or member 'wakeref' not described in 'i915_vma_resource'
../drivers/gpu/drm/i915/i915_vma_resource.h:129: warning: Function parameter or member 'bi' not described in 'i915_vma_resource'
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_crc.o
  HDRTEST drivers/gpu/drm/i915/intel_sbi.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/fannil.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.o
  HDRTEST drivers/gpu/drm/i915/intel_step.h
../drivers/gpu/drm/i915/i915_vma.h:145: warning: expecting prototype for i915_vma_offset(). Prototype was for i915_vma_size() instead
  HDRTEST drivers/gpu/drm/i915/intel_uncore.h
  HDRTEST drivers/gpu/drm/i915/intel_wakeref.h
  HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.o
  HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.o
  HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp_session.h
  HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
  HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.o
  HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.o
  HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp_types.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/nv40.o
  HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/basics/conversion.o
  HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
  HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/nv50.o
  HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
  HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
  HDRTEST drivers/gpu/drm/i915/selftests/igt_live_test.h
  HDRTEST drivers/gpu/drm/i915/selftests/igt_atomic.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/g84.o
  HDRTEST drivers/gpu/drm/i915/selftests/mock_gem_device.h
  HDRTEST drivers/gpu/drm/i915/selftests/mock_drm.h
  HDRTEST drivers/gpu/drm/i915/selftests/igt_reset.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/basics/fixpt31_32.o
  HDRTEST drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gt215.o
  HDRTEST drivers/gpu/drm/i915/selftests/lib_sw_fence.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.o
  HDRTEST drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.o
../drivers/gpu/drm/i915/pxp/intel_pxp_types.h:96: warning: Function parameter or member 'dev_link' not described in 'intel_pxp'
  HDRTEST drivers/gpu/drm/i915/selftests/mock_uncore.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/basics/vector.o
  HDRTEST drivers/gpu/drm/i915/selftests/mock_gtt.h
  HDRTEST drivers/gpu/drm/i915/selftests/i915_mock_selftests.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.o
  HDRTEST drivers/gpu/drm/i915/selftests/mock_request.h
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gm107.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gm200.o
  HDRTEST drivers/gpu/drm/i915/selftests/i915_random.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/basics/dc_common.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.o
  HDRTEST drivers/gpu/drm/i915/selftests/igt_spinner.h
  HDRTEST drivers/gpu/drm/i915/selftests/librapl.h
  HDRTEST drivers/gpu/drm/i915/selftests/mock_region.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser_interface.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser_helper.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.o
  HDRTEST drivers/gpu/drm/i915/selftests/i915_live_selftests.h
  HDRTEST drivers/gpu/drm/i915/selftests/igt_mmap.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.o
  HDRTEST drivers/gpu/drm/i915/selftests/igt_flush_test.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table_helper.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.o
  HDRTEST drivers/gpu/drm/i915/soc/intel_pch.h
  HDRTEST drivers/gpu/drm/i915/soc/intel_dram.h
  HDRTEST drivers/gpu/drm/i915/soc/intel_gmch.h
  HDRTEST drivers/gpu/drm/i915/vlv_sideband.h
  HDRTEST drivers/gpu/drm/i915/vlv_sideband_reg.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser_common.o
  HDRTEST drivers/gpu/drm/i915/vlv_suspend.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table2.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/timer/nv04.o
  LD [M]  drivers/gpu/drm/i915/i915.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table_helper2.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/timer/nv40.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/dce60/command_table_helper_dce60.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/dce80/command_table_helper_dce80.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/timer/nv41.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/dce110/command_table_helper_dce110.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/dce112/command_table_helper_dce112.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/bios/dce112/command_table_helper2_dce112.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/dce_calcs.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/custom_float.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/timer/gk20a.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/top/base.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/top/gk104.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/top/ga100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/vfn/base.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/vfn/uvfn.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/vfn/gv100.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/bw_fixed.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_rq_dlg_helpers.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dml1_display_rq_dlg_calc.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/vfn/tu102.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/vfn/ga100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/volt/base.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn10/dcn10_fpu.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/dcn20_fpu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_vba.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_rq_dlg_calc_20.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/volt/nv40.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gf100.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_rq_dlg_calc_20v2.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20v2.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_rq_dlg_calc_21.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/dcn30_fpu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gf117.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk104.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_rq_dlg_calc_30.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gm20b.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/falcon.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/xtensa.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_rq_dlg_calc_31.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/bsp/g84.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_rq_dlg_calc_314.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/ce/gt215.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/ce/gf100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/ce/gk104.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/ce/gm107.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/ce/gm200.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/ce/gp100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/ce/gp102.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/ce/gv100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/ce/tu102.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_rq_dlg_calc_32.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/ce/ga100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/ce/ga102.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/dcn31_fpu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/dcn32_fpu.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/cipher/g84.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn321/dcn321_fpu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn301/dcn301_fpu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn302/dcn302_fpu.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/device/acpi.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn303/dcn303_fpu.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/device/base.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/dcn314_fpu.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/device/pci.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/device/user.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/rc_calc_fpu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/dcn_calcs.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/base.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/dcn_calc_math.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/chan.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/conn.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/dcn_calc_auto.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce100/dce_clk_mgr.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmi.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/head.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce110/dce110_clk_mgr.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce112/dce112_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce120/dce120_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn10/rv1_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn10/rv2_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn20/dcn20_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn201/dcn201_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn30/dcn30_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn30/dcn30_clk_mgr_smu_msg.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn301/vg_clk_mgr.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/vga.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn301/dcn301_smu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn31/dcn31_smu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn31/dcn31_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn314/dcn314_smu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn314/dcn314_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn315/dcn315_smu.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn315/dcn315_clk_mgr.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/nv04.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/g84.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/gt200.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/mcp77.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn316/dcn316_smu.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/gt215.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn316/dcn316_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn32/dcn32_clk_mgr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn32/dcn32_clk_mgr_smu_msg.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_audio.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_stream_encoder.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_link_encoder.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_hwseq.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/mcp89.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_scl_filters.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/gf119.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/gk104.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_opp.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/gk110.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_dmcu.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/gm107.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_abm.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_ipp.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/gm200.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/gp100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/gp102.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_hw.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_i2c_sw.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_psr.o
  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engine/disp/tu102.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/engin



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-05-22 22:15 [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio Rodrigo Vivi
                   ` (2 preceding siblings ...)
  2023-05-22 22:23 ` [Intel-xe] ✓ CI.Build: " Patchwork
@ 2023-05-23  3:28 ` Matt Roper
  2023-05-23 13:56   ` Matthew Brost
  2023-05-24 17:06   ` Rodrigo Vivi
  3 siblings, 2 replies; 25+ messages in thread
From: Matt Roper @ 2023-05-23  3:28 UTC (permalink / raw)
  To: Rodrigo Vivi
  Cc: Jani Nikula, Lucas De Marchi, Ville Syrjälä,
	Matthew Auld, intel-xe

On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> It is the maximum protection we can do with the current infrastructure.
> 
> Cc: John Harrison <John.C.Harrison@Intel.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Francois Dugast <francois.dugast@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Matt Roper <matthew.d.roper@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
> 
> 
> RFC
> ===
> 
> Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> Xe than anything else.
> 
> On i915 the force_wake is built-in the mmio functions at uncore component.
> 
> With that approach we had few historical issues iirc:
> 
> 1. Display performance with vblank evasion that requested uncore to provide
> the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> the name suggests).

In i915 there were more differences between fw and non-fw variants
of register functions than just forcewake handling:

 * _fw() functions assumed that the caller was already holding
   forcewake, whereas the non-fw functions would obtain it themselves
 * _fw() functions also assumed that the caller was already holding
   uncore->lock, whereas the non-fw functions would obtain and release
   the lock around each register access
 * _fw() functions do no tracing and no debug assertions
 * _fw() functions do not check for unclaimed MMIO

I don't think the first bullet there (forcewake) really mattered much
from a performance perspective.  For display registers, a quick binary
search of the FW table (just a handful of CPU cycles) would quickly
determine that no forcewake domains were needed for those register
offsets, so we wouldn't be doing anything with forcewake at the hardware
level at all.  For display registers, the more performance-relevant
aspects of using the _fw() functions was doing all your register
accesses together without contention with other MMIO work.  I.e.,
holding the uncore lock over an entire set of registers rather than
grabbing/releasing it for each one, and (for vblank evasion
specifically) doing it all while interrupts were disabled.  For debug
drivers, there was also a bunch of other stuff that the _fw() functions
bypassed (e.g., tripling of the number of register accesses due to
reading FPGA_DBG before/after each register to look for unclaimed
accesses).

> 
> 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> other times that the spec was updated and we didn't get the notification, and
> there were cases that the BSpec had bugs.
> 
> For these reasons in Xe we have decided to let to the caller the
> responsibility to set the force_wake bits for their domains before doing
> the MMIO.

I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
bspec update (or the bspec itself having incorrect information) would
lead to even more mistakes if the caller has to explicitly grab the
appropriate domains than if the driver does it implicitly.  The explicit
handling only helps in the subset of cases where we blindly grab all of
the domains (as we do during part of init).


> 
> However I'm seeing many questions and doubts popping up:
> 
> 1. Are we confident that we are not missing any wake-up?
> 2. Are we confident that the domains are set correctly?
> 3. Are we not wasting power if we are waking up ALL the domains instead
>    of some specific one?

I think we're only holding ALL domains during init; for most of the
runtime MMIO accesses, I think the code is currently attempting to only
grab the domain(s) that it thinks the registers it's accessing will
need.  Although that might be working right now, I'm a little bit
worried about how that will scale in the long term when a single
register might be in several different domains depending on what
platform you're running on.  There have definitely been cases in the
past where groups of registers migrated from RENDER to GT or vice versa
between platforms, so the exact domain you needed for an operation
varied by platform.  And things are even more complicated if you're
doing any MMIO against the media, since the hardware seems to change
exactly how it splits up the media power wells somewhat often.

> 4. What about the display disconnection now because i915 and xe have different
>    mmio approaches but reusing i915-display?
> 
> It looks to me that the cons of the current approach are superseding the
> cons of the i915 approach. But I want to hear more thoughts here before
> we decide which route to take.
> 
> Maybe we have that domain as part of the mmio calls themselves? Maybe
> a double approach where the caller is responsible but mmio has the range
> information and double check it?

As noted above, part of the challenge with forcewake is that even if the
caller knows it wants to access register FOO, and even if it know FOO is
a GT register that likely needs forcewake, it's sometimes challenging to
make sure it's grabbing the correct domain(s) for every single platform
the Xe driver will eventually support if the power management handling
changes.  I think that was part of the motivation for encoding the
tables into the driver in i915.  It seems like GT power wells don't
change as much these days as they used to, but it's hard to say whether
that will continue in the future or not.  Who knows...maybe they'll
eventually start creating dedicated domains for stuff like blitters,
GuC, etc.  rather than lumping all of those into the "GT" catchall
domain.

If we do decide to go back to implicit forcewake handling with the table
encoded into the driver, it might be worth doing something sort of like
what Lucas is doing in the OOB workaround series --- drop the
per-platform tables into a human-readable text file that's more similar
to the format used by the bspec (exact ranges, forcewake domain, MCR
replication type, etc.) and then provide a small parser program that
will convert that into actual code (and do things like consolidating
adjacent ranges).

> 
> Any other idea? Thoughts?

Once the big GT vs tile refactor stuff I have in flight gets finalized,
I plan to follow up with another series that creates a more appropriate
MMIO target for register operations rather than using "xe_gt" as the
target (even for things completely unrelated to the small GT subset of
hardware).  My idea is that you'd grab an MMIO target structure for MMIO
operations against a specific hardware unit, and then the info inside
the MMIO structure would be able to figure out if there are additional
checks and/or operations it should perform.  E.g.,

 * mmio = xe_mmio_for_device(xe_device *xe);
    - Used to submit MMIO operations against the root tile of the PCI
      device.  Only used during init (e.g., to read the registers that
      tell us which tiles exist on the platform) and during top-level
      interrupt enable/disable (since all interrupts are routed through
      the root tile).
    - No forcewake needed for register accesses through a handle of this
      type since you'd only ever be accessing sgunit registers for these
      types of things.
    - Register accesses through mmio can warn on debug builds if the
      register appears to be in a GT-related MMIO range.

 * mmio = xe_mmio_for_display(xe_device *xe);
    - Pretty much the same as handles returned by xe_mmio_for_device(),
      but if a handle of this type is used to try to read/write
      registers outside the display range, we could have debug builds
      throw some extra warnings.
    - Unclaimed register detection could be confined to accesses through
      these handles.

 * mmio = xe_mmio_for_tile(xe_tile *tile);
    - Used to access non-GT registers that reside in a specific tile.
      I.e., sgunit/soc registers.
    - As above, no forcewake needed, can make MMIO operations warn
      if used to access a GT range.

 * mmio = xe_mmio_for_gt(xe_gt *gt);
    - Used to access GT registers in a specific GT
    - Does automatic GSI offset translation for media GTs
    - Can either do automatic forcewake like i915 does, or can do debug
      check+warn like you have here.
    - Can make MMIO operations warn if MMIO offset is outside GT range
    - Can also trigger warnings if a GT non-GSI, non-media engine
      register is accessed from an MMIO obtained from a media GT.

At some point we'll probably want to add some debug tracepoints for MMIO
access to assist with debugging; the mmio structure can also help
provide meaningful output for each type of MMIO handle as well.


One other MMIO-related thing:
At the moment Xe does no locking of MMIO access.  I know there were
hardware lockups on old platforms if simultaneous MMIO accesses
happened, but I've never seen that tied to a specific HSD ticket that
would let us know whether modern platforms are still susceptible or not.
If it turns out they are and that we need to bring in the equivalent of
i915's uncore lock (and figure out if any register access is
problematic, or only certain types/ranges).


Matt

> 
> Thanks,
> Rodrigo.
> 
>  drivers/gpu/drm/xe/xe_mmio.h | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xe/xe_mmio.h b/drivers/gpu/drm/xe/xe_mmio.h
> index 1407f1189b0d..6302ca85e3f4 100644
> --- a/drivers/gpu/drm/xe/xe_mmio.h
> +++ b/drivers/gpu/drm/xe/xe_mmio.h
> @@ -18,8 +18,26 @@ struct xe_device;
>  
>  int xe_mmio_init(struct xe_device *xe);
>  
> +static inline void xe_mmio_assert_forcewake(struct xe_gt *gt,
> +					    struct xe_reg reg)
> +{
> +	struct xe_force_wake *fw = &gt->mmio.fw;
> +
> +	/* No need for forcewake in this range */
> +	if (reg.addr >= 0x40000 && reg.addr < 0x116000)
> +		return;
> +
> +	/*
> +	 * XXX: Weak. It checks for some domain, but impossible to determine
> +	 * if the right one is selected, or if it was set by the same caller
> +	 */
> +	WARN_ON(!fw->awake_domains);
> +}
> +
>  static inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
>  {
> +	xe_mmio_assert_forcewake(gt, reg);
> +
>  	if (reg.addr < gt->mmio.adj_limit)
>  		reg.addr += gt->mmio.adj_offset;
>  
> @@ -29,6 +47,8 @@ static inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
>  static inline void xe_mmio_write32(struct xe_gt *gt,
>  				   struct xe_reg reg, u32 val)
>  {
> +	xe_mmio_assert_forcewake(gt, reg);
> +
>  	if (reg.addr < gt->mmio.adj_limit)
>  		reg.addr += gt->mmio.adj_offset;
>  
> @@ -37,6 +57,8 @@ static inline void xe_mmio_write32(struct xe_gt *gt,
>  
>  static inline u32 xe_mmio_read32(struct xe_gt *gt, struct xe_reg reg)
>  {
> +	xe_mmio_assert_forcewake(gt, reg);
> +
>  	if (reg.addr < gt->mmio.adj_limit)
>  		reg.addr += gt->mmio.adj_offset;
>  
> @@ -58,6 +80,8 @@ static inline u32 xe_mmio_rmw32(struct xe_gt *gt, struct xe_reg reg, u32 clr,
>  static inline void xe_mmio_write64(struct xe_gt *gt,
>  				   struct xe_reg reg, u64 val)
>  {
> +	xe_mmio_assert_forcewake(gt, reg);
> +
>  	if (reg.addr < gt->mmio.adj_limit)
>  		reg.addr += gt->mmio.adj_offset;
>  
> @@ -66,6 +90,8 @@ static inline void xe_mmio_write64(struct xe_gt *gt,
>  
>  static inline u64 xe_mmio_read64(struct xe_gt *gt, struct xe_reg reg)
>  {
> +	xe_mmio_assert_forcewake(gt, reg);
> +
>  	if (reg.addr < gt->mmio.adj_limit)
>  		reg.addr += gt->mmio.adj_offset;
>  
> -- 
> 2.39.2
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-05-23  3:28 ` [Intel-xe] [RFC] " Matt Roper
@ 2023-05-23 13:56   ` Matthew Brost
  2023-05-23 16:38     ` Matt Roper
  2023-05-24 17:06   ` Rodrigo Vivi
  1 sibling, 1 reply; 25+ messages in thread
From: Matthew Brost @ 2023-05-23 13:56 UTC (permalink / raw)
  To: Matt Roper
  Cc: Jani Nikula, Lucas De Marchi, Ville Syrjälä,
	Matthew Auld, Rodrigo Vivi, intel-xe

On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > It is the maximum protection we can do with the current infrastructure.
> > 
> > Cc: John Harrison <John.C.Harrison@Intel.com>
> > Cc: Matthew Auld <matthew.auld@intel.com>
> > Cc: Francois Dugast <francois.dugast@intel.com>
> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > Cc: Jani Nikula <jani.nikula@intel.com>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Cc: Matt Roper <matthew.d.roper@intel.com>
> > Cc: Matthew Brost <matthew.brost@intel.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > ---
> > 
> > 
> > RFC
> > ===
> > 
> > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > Xe than anything else.
> > 
> > On i915 the force_wake is built-in the mmio functions at uncore component.
> > 
> > With that approach we had few historical issues iirc:
> > 
> > 1. Display performance with vblank evasion that requested uncore to provide
> > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > the name suggests).
> 
> In i915 there were more differences between fw and non-fw variants
> of register functions than just forcewake handling:
> 
>  * _fw() functions assumed that the caller was already holding
>    forcewake, whereas the non-fw functions would obtain it themselves
>  * _fw() functions also assumed that the caller was already holding
>    uncore->lock, whereas the non-fw functions would obtain and release
>    the lock around each register access
>  * _fw() functions do no tracing and no debug assertions
>  * _fw() functions do not check for unclaimed MMIO
> 
> I don't think the first bullet there (forcewake) really mattered much
> from a performance perspective.  For display registers, a quick binary
> search of the FW table (just a handful of CPU cycles) would quickly
> determine that no forcewake domains were needed for those register
> offsets, so we wouldn't be doing anything with forcewake at the hardware
> level at all.  For display registers, the more performance-relevant
> aspects of using the _fw() functions was doing all your register
> accesses together without contention with other MMIO work.  I.e.,
> holding the uncore lock over an entire set of registers rather than
> grabbing/releasing it for each one, and (for vblank evasion
> specifically) doing it all while interrupts were disabled.  For debug
> drivers, there was also a bunch of other stuff that the _fw() functions
> bypassed (e.g., tripling of the number of register accesses due to
> reading FPGA_DBG before/after each register to look for unclaimed
> accesses).
> 
> > 
> > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > other times that the spec was updated and we didn't get the notification, and
> > there were cases that the BSpec had bugs.
> > 
> > For these reasons in Xe we have decided to let to the caller the
> > responsibility to set the force_wake bits for their domains before doing
> > the MMIO.
> 
> I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> bspec update (or the bspec itself having incorrect information) would
> lead to even more mistakes if the caller has to explicitly grab the
> appropriate domains than if the driver does it implicitly.  The explicit
> handling only helps in the subset of cases where we blindly grab all of
> the domains (as we do during part of init).
> 
> 

MMIO access that requires forcewakes really only should be in a few
places, off the top of my head:

1. Init
2. Reset
3. Sysfs / Debugfs

In all of these cases I think it fine to blindly grab all forcewakes.

Please chime in if I'm missing something.

> > 
> > However I'm seeing many questions and doubts popping up:
> > 
> > 1. Are we confident that we are not missing any wake-up?
> > 2. Are we confident that the domains are set correctly?
> > 3. Are we not wasting power if we are waking up ALL the domains instead
> >    of some specific one?
> 
> I think we're only holding ALL domains during init; for most of the
> runtime MMIO accesses, I think the code is currently attempting to only
> grab the domain(s) that it thinks the registers it's accessing will
> need.  Although that might be working right now, I'm a little bit
> worried about how that will scale in the long term when a single
> register might be in several different domains depending on what
> platform you're running on.  There have definitely been cases in the
> past where groups of registers migrated from RENDER to GT or vice versa
> between platforms, so the exact domain you needed for an operation
> varied by platform.  And things are even more complicated if you're
> doing any MMIO against the media, since the hardware seems to change
> exactly how it splits up the media power wells somewhat often.
>
> > 4. What about the display disconnection now because i915 and xe have different
> >    mmio approaches but reusing i915-display?
> > 
> > It looks to me that the cons of the current approach are superseding the
> > cons of the i915 approach. But I want to hear more thoughts here before
> > we decide which route to take.
> > 
> > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > a double approach where the caller is responsible but mmio has the range
> > information and double check it?
> 
> As noted above, part of the challenge with forcewake is that even if the
> caller knows it wants to access register FOO, and even if it know FOO is
> a GT register that likely needs forcewake, it's sometimes challenging to
> make sure it's grabbing the correct domain(s) for every single platform
> the Xe driver will eventually support if the power management handling
> changes.  I think that was part of the motivation for encoding the
> tables into the driver in i915.  It seems like GT power wells don't
> change as much these days as they used to, but it's hard to say whether
> that will continue in the future or not.  Who knows...maybe they'll
> eventually start creating dedicated domains for stuff like blitters,
> GuC, etc.  rather than lumping all of those into the "GT" catchall
> domain.
> 
> If we do decide to go back to implicit forcewake handling with the table
> encoded into the driver, it might be worth doing something sort of like

Let's not do this intel_uncore.c is an unreadable mess, I don't want
anything like this in Xe.

> what Lucas is doing in the OOB workaround series --- drop the
> per-platform tables into a human-readable text file that's more similar
> to the format used by the bspec (exact ranges, forcewake domain, MCR
> replication type, etc.) and then provide a small parser program that
> will convert that into actual code (and do things like consolidating
> adjacent ranges).
> 
> > 
> > Any other idea? Thoughts?
> 
> Once the big GT vs tile refactor stuff I have in flight gets finalized,
> I plan to follow up with another series that creates a more appropriate
> MMIO target for register operations rather than using "xe_gt" as the
> target (even for things completely unrelated to the small GT subset of
> hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> operations against a specific hardware unit, and then the info inside
> the MMIO structure would be able to figure out if there are additional
> checks and/or operations it should perform.  E.g.,
> 
>  * mmio = xe_mmio_for_device(xe_device *xe);
>     - Used to submit MMIO operations against the root tile of the PCI
>       device.  Only used during init (e.g., to read the registers that
>       tell us which tiles exist on the platform) and during top-level
>       interrupt enable/disable (since all interrupts are routed through
>       the root tile).
>     - No forcewake needed for register accesses through a handle of this
>       type since you'd only ever be accessing sgunit registers for these
>       types of things.
>     - Register accesses through mmio can warn on debug builds if the
>       register appears to be in a GT-related MMIO range.
> 
>  * mmio = xe_mmio_for_display(xe_device *xe);
>     - Pretty much the same as handles returned by xe_mmio_for_device(),
>       but if a handle of this type is used to try to read/write
>       registers outside the display range, we could have debug builds
>       throw some extra warnings.
>     - Unclaimed register detection could be confined to accesses through
>       these handles.
> 
>  * mmio = xe_mmio_for_tile(xe_tile *tile);
>     - Used to access non-GT registers that reside in a specific tile.
>       I.e., sgunit/soc registers.
>     - As above, no forcewake needed, can make MMIO operations warn
>       if used to access a GT range.
> 
>  * mmio = xe_mmio_for_gt(xe_gt *gt);
>     - Used to access GT registers in a specific GT
>     - Does automatic GSI offset translation for media GTs
>     - Can either do automatic forcewake like i915 does, or can do debug
>       check+warn like you have here.
>     - Can make MMIO operations warn if MMIO offset is outside GT range
>     - Can also trigger warnings if a GT non-GSI, non-media engine
>       register is accessed from an MMIO obtained from a media GT.
>

Ack on this if we keep in managable, worried code / feature bloat those
that will result in a similar file to intel_uncore.c in Xe.

Matt

> At some point we'll probably want to add some debug tracepoints for MMIO
> access to assist with debugging; the mmio structure can also help
> provide meaningful output for each type of MMIO handle as well.
> 
> 
> One other MMIO-related thing:
> At the moment Xe does no locking of MMIO access.  I know there were
> hardware lockups on old platforms if simultaneous MMIO accesses
> happened, but I've never seen that tied to a specific HSD ticket that
> would let us know whether modern platforms are still susceptible or not.
> If it turns out they are and that we need to bring in the equivalent of
> i915's uncore lock (and figure out if any register access is
> problematic, or only certain types/ranges).
> 
> 
> Matt
> 
> > 
> > Thanks,
> > Rodrigo.
> > 
> >  drivers/gpu/drm/xe/xe_mmio.h | 26 ++++++++++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_mmio.h b/drivers/gpu/drm/xe/xe_mmio.h
> > index 1407f1189b0d..6302ca85e3f4 100644
> > --- a/drivers/gpu/drm/xe/xe_mmio.h
> > +++ b/drivers/gpu/drm/xe/xe_mmio.h
> > @@ -18,8 +18,26 @@ struct xe_device;
> >  
> >  int xe_mmio_init(struct xe_device *xe);
> >  
> > +static inline void xe_mmio_assert_forcewake(struct xe_gt *gt,
> > +					    struct xe_reg reg)
> > +{
> > +	struct xe_force_wake *fw = &gt->mmio.fw;
> > +
> > +	/* No need for forcewake in this range */
> > +	if (reg.addr >= 0x40000 && reg.addr < 0x116000)
> > +		return;
> > +
> > +	/*
> > +	 * XXX: Weak. It checks for some domain, but impossible to determine
> > +	 * if the right one is selected, or if it was set by the same caller
> > +	 */
> > +	WARN_ON(!fw->awake_domains);
> > +}
> > +
> >  static inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
> >  {
> > +	xe_mmio_assert_forcewake(gt, reg);
> > +
> >  	if (reg.addr < gt->mmio.adj_limit)
> >  		reg.addr += gt->mmio.adj_offset;
> >  
> > @@ -29,6 +47,8 @@ static inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
> >  static inline void xe_mmio_write32(struct xe_gt *gt,
> >  				   struct xe_reg reg, u32 val)
> >  {
> > +	xe_mmio_assert_forcewake(gt, reg);
> > +
> >  	if (reg.addr < gt->mmio.adj_limit)
> >  		reg.addr += gt->mmio.adj_offset;
> >  
> > @@ -37,6 +57,8 @@ static inline void xe_mmio_write32(struct xe_gt *gt,
> >  
> >  static inline u32 xe_mmio_read32(struct xe_gt *gt, struct xe_reg reg)
> >  {
> > +	xe_mmio_assert_forcewake(gt, reg);
> > +
> >  	if (reg.addr < gt->mmio.adj_limit)
> >  		reg.addr += gt->mmio.adj_offset;
> >  
> > @@ -58,6 +80,8 @@ static inline u32 xe_mmio_rmw32(struct xe_gt *gt, struct xe_reg reg, u32 clr,
> >  static inline void xe_mmio_write64(struct xe_gt *gt,
> >  				   struct xe_reg reg, u64 val)
> >  {
> > +	xe_mmio_assert_forcewake(gt, reg);
> > +
> >  	if (reg.addr < gt->mmio.adj_limit)
> >  		reg.addr += gt->mmio.adj_offset;
> >  
> > @@ -66,6 +90,8 @@ static inline void xe_mmio_write64(struct xe_gt *gt,
> >  
> >  static inline u64 xe_mmio_read64(struct xe_gt *gt, struct xe_reg reg)
> >  {
> > +	xe_mmio_assert_forcewake(gt, reg);
> > +
> >  	if (reg.addr < gt->mmio.adj_limit)
> >  		reg.addr += gt->mmio.adj_offset;
> >  
> > -- 
> > 2.39.2
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-05-23 13:56   ` Matthew Brost
@ 2023-05-23 16:38     ` Matt Roper
  2023-05-23 23:52       ` Matthew Brost
  0 siblings, 1 reply; 25+ messages in thread
From: Matt Roper @ 2023-05-23 16:38 UTC (permalink / raw)
  To: Matthew Brost
  Cc: Jani Nikula, Lucas De Marchi, Ville Syrjälä,
	Matthew Auld, Rodrigo Vivi, intel-xe

On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > It is the maximum protection we can do with the current infrastructure.
> > > 
> > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > ---
> > > 
> > > 
> > > RFC
> > > ===
> > > 
> > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > Xe than anything else.
> > > 
> > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > 
> > > With that approach we had few historical issues iirc:
> > > 
> > > 1. Display performance with vblank evasion that requested uncore to provide
> > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > the name suggests).
> > 
> > In i915 there were more differences between fw and non-fw variants
> > of register functions than just forcewake handling:
> > 
> >  * _fw() functions assumed that the caller was already holding
> >    forcewake, whereas the non-fw functions would obtain it themselves
> >  * _fw() functions also assumed that the caller was already holding
> >    uncore->lock, whereas the non-fw functions would obtain and release
> >    the lock around each register access
> >  * _fw() functions do no tracing and no debug assertions
> >  * _fw() functions do not check for unclaimed MMIO
> > 
> > I don't think the first bullet there (forcewake) really mattered much
> > from a performance perspective.  For display registers, a quick binary
> > search of the FW table (just a handful of CPU cycles) would quickly
> > determine that no forcewake domains were needed for those register
> > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > level at all.  For display registers, the more performance-relevant
> > aspects of using the _fw() functions was doing all your register
> > accesses together without contention with other MMIO work.  I.e.,
> > holding the uncore lock over an entire set of registers rather than
> > grabbing/releasing it for each one, and (for vblank evasion
> > specifically) doing it all while interrupts were disabled.  For debug
> > drivers, there was also a bunch of other stuff that the _fw() functions
> > bypassed (e.g., tripling of the number of register accesses due to
> > reading FPGA_DBG before/after each register to look for unclaimed
> > accesses).
> > 
> > > 
> > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > other times that the spec was updated and we didn't get the notification, and
> > > there were cases that the BSpec had bugs.
> > > 
> > > For these reasons in Xe we have decided to let to the caller the
> > > responsibility to set the force_wake bits for their domains before doing
> > > the MMIO.
> > 
> > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > bspec update (or the bspec itself having incorrect information) would
> > lead to even more mistakes if the caller has to explicitly grab the
> > appropriate domains than if the driver does it implicitly.  The explicit
> > handling only helps in the subset of cases where we blindly grab all of
> > the domains (as we do during part of init).
> > 
> > 
> 
> MMIO access that requires forcewakes really only should be in a few
> places, off the top of my head:
> 
> 1. Init
> 2. Reset
> 3. Sysfs / Debugfs
> 
> In all of these cases I think it fine to blindly grab all forcewakes.
> 
> Please chime in if I'm missing something.

I think as we implement more features in the Xe driver we're going to
wind up with a lot more places where we need to access GT registers at
runtime.  A few examples off the top of my head:

 * EU stall sampling
 * Perf/OA
 * EU debugger
 * Various OOB workarounds that ask us to twiddle a register at certain
   times in the driver.

> 
> > > 
> > > However I'm seeing many questions and doubts popping up:
> > > 
> > > 1. Are we confident that we are not missing any wake-up?
> > > 2. Are we confident that the domains are set correctly?
> > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > >    of some specific one?
> > 
> > I think we're only holding ALL domains during init; for most of the
> > runtime MMIO accesses, I think the code is currently attempting to only
> > grab the domain(s) that it thinks the registers it's accessing will
> > need.  Although that might be working right now, I'm a little bit
> > worried about how that will scale in the long term when a single
> > register might be in several different domains depending on what
> > platform you're running on.  There have definitely been cases in the
> > past where groups of registers migrated from RENDER to GT or vice versa
> > between platforms, so the exact domain you needed for an operation
> > varied by platform.  And things are even more complicated if you're
> > doing any MMIO against the media, since the hardware seems to change
> > exactly how it splits up the media power wells somewhat often.
> >
> > > 4. What about the display disconnection now because i915 and xe have different
> > >    mmio approaches but reusing i915-display?
> > > 
> > > It looks to me that the cons of the current approach are superseding the
> > > cons of the i915 approach. But I want to hear more thoughts here before
> > > we decide which route to take.
> > > 
> > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > a double approach where the caller is responsible but mmio has the range
> > > information and double check it?
> > 
> > As noted above, part of the challenge with forcewake is that even if the
> > caller knows it wants to access register FOO, and even if it know FOO is
> > a GT register that likely needs forcewake, it's sometimes challenging to
> > make sure it's grabbing the correct domain(s) for every single platform
> > the Xe driver will eventually support if the power management handling
> > changes.  I think that was part of the motivation for encoding the
> > tables into the driver in i915.  It seems like GT power wells don't
> > change as much these days as they used to, but it's hard to say whether
> > that will continue in the future or not.  Who knows...maybe they'll
> > eventually start creating dedicated domains for stuff like blitters,
> > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > domain.
> > 
> > If we do decide to go back to implicit forcewake handling with the table
> > encoded into the driver, it might be worth doing something sort of like
> 
> Let's not do this intel_uncore.c is an unreadable mess, I don't want
> anything like this in Xe.

When you say unreadable, are you referring to the macros that generate
the table lookup functions?  I don't think that macro magic would be
needed for Xe since we don't have to support old platforms that have
very different forcewake behavior, and we also don't need to generate
separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
(since I think everything in the GT is 32-bits these days).

The forcewake and shadow tables themselves are pretty clean in i915
these days, and if we move to autogenerating them from a text file, they
can become even simpler since the text file will basically be a cleaned
up copy/paste of part of the bspec table.


Matt

> 
> > what Lucas is doing in the OOB workaround series --- drop the
> > per-platform tables into a human-readable text file that's more similar
> > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > replication type, etc.) and then provide a small parser program that
> > will convert that into actual code (and do things like consolidating
> > adjacent ranges).
> > 
> > > 
> > > Any other idea? Thoughts?
> > 
> > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > I plan to follow up with another series that creates a more appropriate
> > MMIO target for register operations rather than using "xe_gt" as the
> > target (even for things completely unrelated to the small GT subset of
> > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > operations against a specific hardware unit, and then the info inside
> > the MMIO structure would be able to figure out if there are additional
> > checks and/or operations it should perform.  E.g.,
> > 
> >  * mmio = xe_mmio_for_device(xe_device *xe);
> >     - Used to submit MMIO operations against the root tile of the PCI
> >       device.  Only used during init (e.g., to read the registers that
> >       tell us which tiles exist on the platform) and during top-level
> >       interrupt enable/disable (since all interrupts are routed through
> >       the root tile).
> >     - No forcewake needed for register accesses through a handle of this
> >       type since you'd only ever be accessing sgunit registers for these
> >       types of things.
> >     - Register accesses through mmio can warn on debug builds if the
> >       register appears to be in a GT-related MMIO range.
> > 
> >  * mmio = xe_mmio_for_display(xe_device *xe);
> >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> >       but if a handle of this type is used to try to read/write
> >       registers outside the display range, we could have debug builds
> >       throw some extra warnings.
> >     - Unclaimed register detection could be confined to accesses through
> >       these handles.
> > 
> >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> >     - Used to access non-GT registers that reside in a specific tile.
> >       I.e., sgunit/soc registers.
> >     - As above, no forcewake needed, can make MMIO operations warn
> >       if used to access a GT range.
> > 
> >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> >     - Used to access GT registers in a specific GT
> >     - Does automatic GSI offset translation for media GTs
> >     - Can either do automatic forcewake like i915 does, or can do debug
> >       check+warn like you have here.
> >     - Can make MMIO operations warn if MMIO offset is outside GT range
> >     - Can also trigger warnings if a GT non-GSI, non-media engine
> >       register is accessed from an MMIO obtained from a media GT.
> >
> 
> Ack on this if we keep in managable, worried code / feature bloat those
> that will result in a similar file to intel_uncore.c in Xe.
> 
> Matt
> 
> > At some point we'll probably want to add some debug tracepoints for MMIO
> > access to assist with debugging; the mmio structure can also help
> > provide meaningful output for each type of MMIO handle as well.
> > 
> > 
> > One other MMIO-related thing:
> > At the moment Xe does no locking of MMIO access.  I know there were
> > hardware lockups on old platforms if simultaneous MMIO accesses
> > happened, but I've never seen that tied to a specific HSD ticket that
> > would let us know whether modern platforms are still susceptible or not.
> > If it turns out they are and that we need to bring in the equivalent of
> > i915's uncore lock (and figure out if any register access is
> > problematic, or only certain types/ranges).
> > 
> > 
> > Matt
> > 
> > > 
> > > Thanks,
> > > Rodrigo.
> > > 
> > >  drivers/gpu/drm/xe/xe_mmio.h | 26 ++++++++++++++++++++++++++
> > >  1 file changed, 26 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_mmio.h b/drivers/gpu/drm/xe/xe_mmio.h
> > > index 1407f1189b0d..6302ca85e3f4 100644
> > > --- a/drivers/gpu/drm/xe/xe_mmio.h
> > > +++ b/drivers/gpu/drm/xe/xe_mmio.h
> > > @@ -18,8 +18,26 @@ struct xe_device;
> > >  
> > >  int xe_mmio_init(struct xe_device *xe);
> > >  
> > > +static inline void xe_mmio_assert_forcewake(struct xe_gt *gt,
> > > +					    struct xe_reg reg)
> > > +{
> > > +	struct xe_force_wake *fw = &gt->mmio.fw;
> > > +
> > > +	/* No need for forcewake in this range */
> > > +	if (reg.addr >= 0x40000 && reg.addr < 0x116000)
> > > +		return;
> > > +
> > > +	/*
> > > +	 * XXX: Weak. It checks for some domain, but impossible to determine
> > > +	 * if the right one is selected, or if it was set by the same caller
> > > +	 */
> > > +	WARN_ON(!fw->awake_domains);
> > > +}
> > > +
> > >  static inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
> > >  {
> > > +	xe_mmio_assert_forcewake(gt, reg);
> > > +
> > >  	if (reg.addr < gt->mmio.adj_limit)
> > >  		reg.addr += gt->mmio.adj_offset;
> > >  
> > > @@ -29,6 +47,8 @@ static inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
> > >  static inline void xe_mmio_write32(struct xe_gt *gt,
> > >  				   struct xe_reg reg, u32 val)
> > >  {
> > > +	xe_mmio_assert_forcewake(gt, reg);
> > > +
> > >  	if (reg.addr < gt->mmio.adj_limit)
> > >  		reg.addr += gt->mmio.adj_offset;
> > >  
> > > @@ -37,6 +57,8 @@ static inline void xe_mmio_write32(struct xe_gt *gt,
> > >  
> > >  static inline u32 xe_mmio_read32(struct xe_gt *gt, struct xe_reg reg)
> > >  {
> > > +	xe_mmio_assert_forcewake(gt, reg);
> > > +
> > >  	if (reg.addr < gt->mmio.adj_limit)
> > >  		reg.addr += gt->mmio.adj_offset;
> > >  
> > > @@ -58,6 +80,8 @@ static inline u32 xe_mmio_rmw32(struct xe_gt *gt, struct xe_reg reg, u32 clr,
> > >  static inline void xe_mmio_write64(struct xe_gt *gt,
> > >  				   struct xe_reg reg, u64 val)
> > >  {
> > > +	xe_mmio_assert_forcewake(gt, reg);
> > > +
> > >  	if (reg.addr < gt->mmio.adj_limit)
> > >  		reg.addr += gt->mmio.adj_offset;
> > >  
> > > @@ -66,6 +90,8 @@ static inline void xe_mmio_write64(struct xe_gt *gt,
> > >  
> > >  static inline u64 xe_mmio_read64(struct xe_gt *gt, struct xe_reg reg)
> > >  {
> > > +	xe_mmio_assert_forcewake(gt, reg);
> > > +
> > >  	if (reg.addr < gt->mmio.adj_limit)
> > >  		reg.addr += gt->mmio.adj_offset;
> > >  
> > > -- 
> > > 2.39.2
> > > 
> > 
> > -- 
> > Matt Roper
> > Graphics Software Engineer
> > Linux GPU Platform Enablement
> > Intel Corporation

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-05-23 16:38     ` Matt Roper
@ 2023-05-23 23:52       ` Matthew Brost
  2023-10-09  9:22         ` Luca Coelho
  0 siblings, 1 reply; 25+ messages in thread
From: Matthew Brost @ 2023-05-23 23:52 UTC (permalink / raw)
  To: Matt Roper
  Cc: Jani Nikula, Lucas De Marchi, Ville Syrjälä,
	Matthew Auld, Rodrigo Vivi, intel-xe

On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > It is the maximum protection we can do with the current infrastructure.
> > > > 
> > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > ---
> > > > 
> > > > 
> > > > RFC
> > > > ===
> > > > 
> > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > Xe than anything else.
> > > > 
> > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > 
> > > > With that approach we had few historical issues iirc:
> > > > 
> > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > the name suggests).
> > > 
> > > In i915 there were more differences between fw and non-fw variants
> > > of register functions than just forcewake handling:
> > > 
> > >  * _fw() functions assumed that the caller was already holding
> > >    forcewake, whereas the non-fw functions would obtain it themselves
> > >  * _fw() functions also assumed that the caller was already holding
> > >    uncore->lock, whereas the non-fw functions would obtain and release
> > >    the lock around each register access
> > >  * _fw() functions do no tracing and no debug assertions
> > >  * _fw() functions do not check for unclaimed MMIO
> > > 
> > > I don't think the first bullet there (forcewake) really mattered much
> > > from a performance perspective.  For display registers, a quick binary
> > > search of the FW table (just a handful of CPU cycles) would quickly
> > > determine that no forcewake domains were needed for those register
> > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > level at all.  For display registers, the more performance-relevant
> > > aspects of using the _fw() functions was doing all your register
> > > accesses together without contention with other MMIO work.  I.e.,
> > > holding the uncore lock over an entire set of registers rather than
> > > grabbing/releasing it for each one, and (for vblank evasion
> > > specifically) doing it all while interrupts were disabled.  For debug
> > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > bypassed (e.g., tripling of the number of register accesses due to
> > > reading FPGA_DBG before/after each register to look for unclaimed
> > > accesses).
> > > 
> > > > 
> > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > other times that the spec was updated and we didn't get the notification, and
> > > > there were cases that the BSpec had bugs.
> > > > 
> > > > For these reasons in Xe we have decided to let to the caller the
> > > > responsibility to set the force_wake bits for their domains before doing
> > > > the MMIO.
> > > 
> > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > bspec update (or the bspec itself having incorrect information) would
> > > lead to even more mistakes if the caller has to explicitly grab the
> > > appropriate domains than if the driver does it implicitly.  The explicit
> > > handling only helps in the subset of cases where we blindly grab all of
> > > the domains (as we do during part of init).
> > > 
> > > 
> > 
> > MMIO access that requires forcewakes really only should be in a few
> > places, off the top of my head:
> > 
> > 1. Init
> > 2. Reset
> > 3. Sysfs / Debugfs
> > 
> > In all of these cases I think it fine to blindly grab all forcewakes.
> > 
> > Please chime in if I'm missing something.
> 
> I think as we implement more features in the Xe driver we're going to
> wind up with a lot more places where we need to access GT registers at
> runtime.  A few examples off the top of my head:
> 
>  * EU stall sampling
>  * Perf/OA
>  * EU debugger
>  * Various OOB workarounds that ask us to twiddle a register at certain
>    times in the driver.

Hmm, ok a lot of these I could make the argument that these are not
normal operation so just grab everything and call it a day. If some of
these fall into the category of 'normal enough to be optimized' I can
also make the argument it is no more complex (perhaps less complex) to
explicitly grab the forcewake than having the logic auto-grab the
forcewake.

What a compromise of in a debug mode we auto-generate the asserts based
on a table but we still explicitly grab the forcewake?

> 
> > 
> > > > 
> > > > However I'm seeing many questions and doubts popping up:
> > > > 
> > > > 1. Are we confident that we are not missing any wake-up?
> > > > 2. Are we confident that the domains are set correctly?
> > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > >    of some specific one?
> > > 
> > > I think we're only holding ALL domains during init; for most of the
> > > runtime MMIO accesses, I think the code is currently attempting to only
> > > grab the domain(s) that it thinks the registers it's accessing will
> > > need.  Although that might be working right now, I'm a little bit
> > > worried about how that will scale in the long term when a single
> > > register might be in several different domains depending on what
> > > platform you're running on.  There have definitely been cases in the
> > > past where groups of registers migrated from RENDER to GT or vice versa
> > > between platforms, so the exact domain you needed for an operation
> > > varied by platform.  And things are even more complicated if you're
> > > doing any MMIO against the media, since the hardware seems to change
> > > exactly how it splits up the media power wells somewhat often.
> > >
> > > > 4. What about the display disconnection now because i915 and xe have different
> > > >    mmio approaches but reusing i915-display?
> > > > 
> > > > It looks to me that the cons of the current approach are superseding the
> > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > we decide which route to take.
> > > > 
> > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > a double approach where the caller is responsible but mmio has the range
> > > > information and double check it?
> > > 
> > > As noted above, part of the challenge with forcewake is that even if the
> > > caller knows it wants to access register FOO, and even if it know FOO is
> > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > make sure it's grabbing the correct domain(s) for every single platform
> > > the Xe driver will eventually support if the power management handling
> > > changes.  I think that was part of the motivation for encoding the
> > > tables into the driver in i915.  It seems like GT power wells don't
> > > change as much these days as they used to, but it's hard to say whether
> > > that will continue in the future or not.  Who knows...maybe they'll
> > > eventually start creating dedicated domains for stuff like blitters,
> > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > domain.
> > > 
> > > If we do decide to go back to implicit forcewake handling with the table
> > > encoded into the driver, it might be worth doing something sort of like
> > 
> > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > anything like this in Xe.
> 
> When you say unreadable, are you referring to the macros that generate
> the table lookup functions?  I don't think that macro magic would be
> needed for Xe since we don't have to support old platforms that have
> very different forcewake behavior, and we also don't need to generate
> separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> (since I think everything in the GT is 32-bits these days).
> 

Just the entire file is unreadable in general, trying to avoid these
types of files in Xe, avoid traps of the i915 did this so let's do it in
Xe, and over engineering our driver to avoid hypothetical future bugs.

Matt

> The forcewake and shadow tables themselves are pretty clean in i915
> these days, and if we move to autogenerating them from a text file, they
> can become even simpler since the text file will basically be a cleaned
> up copy/paste of part of the bspec table.
> 
> 
> Matt
> 
> > 
> > > what Lucas is doing in the OOB workaround series --- drop the
> > > per-platform tables into a human-readable text file that's more similar
> > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > replication type, etc.) and then provide a small parser program that
> > > will convert that into actual code (and do things like consolidating
> > > adjacent ranges).
> > > 
> > > > 
> > > > Any other idea? Thoughts?
> > > 
> > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > I plan to follow up with another series that creates a more appropriate
> > > MMIO target for register operations rather than using "xe_gt" as the
> > > target (even for things completely unrelated to the small GT subset of
> > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > operations against a specific hardware unit, and then the info inside
> > > the MMIO structure would be able to figure out if there are additional
> > > checks and/or operations it should perform.  E.g.,
> > > 
> > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > >     - Used to submit MMIO operations against the root tile of the PCI
> > >       device.  Only used during init (e.g., to read the registers that
> > >       tell us which tiles exist on the platform) and during top-level
> > >       interrupt enable/disable (since all interrupts are routed through
> > >       the root tile).
> > >     - No forcewake needed for register accesses through a handle of this
> > >       type since you'd only ever be accessing sgunit registers for these
> > >       types of things.
> > >     - Register accesses through mmio can warn on debug builds if the
> > >       register appears to be in a GT-related MMIO range.
> > > 
> > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > >       but if a handle of this type is used to try to read/write
> > >       registers outside the display range, we could have debug builds
> > >       throw some extra warnings.
> > >     - Unclaimed register detection could be confined to accesses through
> > >       these handles.
> > > 
> > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > >     - Used to access non-GT registers that reside in a specific tile.
> > >       I.e., sgunit/soc registers.
> > >     - As above, no forcewake needed, can make MMIO operations warn
> > >       if used to access a GT range.
> > > 
> > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > >     - Used to access GT registers in a specific GT
> > >     - Does automatic GSI offset translation for media GTs
> > >     - Can either do automatic forcewake like i915 does, or can do debug
> > >       check+warn like you have here.
> > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > >       register is accessed from an MMIO obtained from a media GT.
> > >
> > 
> > Ack on this if we keep in managable, worried code / feature bloat those
> > that will result in a similar file to intel_uncore.c in Xe.
> > 
> > Matt
> > 
> > > At some point we'll probably want to add some debug tracepoints for MMIO
> > > access to assist with debugging; the mmio structure can also help
> > > provide meaningful output for each type of MMIO handle as well.
> > > 
> > > 
> > > One other MMIO-related thing:
> > > At the moment Xe does no locking of MMIO access.  I know there were
> > > hardware lockups on old platforms if simultaneous MMIO accesses
> > > happened, but I've never seen that tied to a specific HSD ticket that
> > > would let us know whether modern platforms are still susceptible or not.
> > > If it turns out they are and that we need to bring in the equivalent of
> > > i915's uncore lock (and figure out if any register access is
> > > problematic, or only certain types/ranges).
> > > 
> > > 
> > > Matt
> > > 
> > > > 
> > > > Thanks,
> > > > Rodrigo.
> > > > 
> > > >  drivers/gpu/drm/xe/xe_mmio.h | 26 ++++++++++++++++++++++++++
> > > >  1 file changed, 26 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/xe/xe_mmio.h b/drivers/gpu/drm/xe/xe_mmio.h
> > > > index 1407f1189b0d..6302ca85e3f4 100644
> > > > --- a/drivers/gpu/drm/xe/xe_mmio.h
> > > > +++ b/drivers/gpu/drm/xe/xe_mmio.h
> > > > @@ -18,8 +18,26 @@ struct xe_device;
> > > >  
> > > >  int xe_mmio_init(struct xe_device *xe);
> > > >  
> > > > +static inline void xe_mmio_assert_forcewake(struct xe_gt *gt,
> > > > +					    struct xe_reg reg)
> > > > +{
> > > > +	struct xe_force_wake *fw = &gt->mmio.fw;
> > > > +
> > > > +	/* No need for forcewake in this range */
> > > > +	if (reg.addr >= 0x40000 && reg.addr < 0x116000)
> > > > +		return;
> > > > +
> > > > +	/*
> > > > +	 * XXX: Weak. It checks for some domain, but impossible to determine
> > > > +	 * if the right one is selected, or if it was set by the same caller
> > > > +	 */
> > > > +	WARN_ON(!fw->awake_domains);
> > > > +}
> > > > +
> > > >  static inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
> > > >  {
> > > > +	xe_mmio_assert_forcewake(gt, reg);
> > > > +
> > > >  	if (reg.addr < gt->mmio.adj_limit)
> > > >  		reg.addr += gt->mmio.adj_offset;
> > > >  
> > > > @@ -29,6 +47,8 @@ static inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
> > > >  static inline void xe_mmio_write32(struct xe_gt *gt,
> > > >  				   struct xe_reg reg, u32 val)
> > > >  {
> > > > +	xe_mmio_assert_forcewake(gt, reg);
> > > > +
> > > >  	if (reg.addr < gt->mmio.adj_limit)
> > > >  		reg.addr += gt->mmio.adj_offset;
> > > >  
> > > > @@ -37,6 +57,8 @@ static inline void xe_mmio_write32(struct xe_gt *gt,
> > > >  
> > > >  static inline u32 xe_mmio_read32(struct xe_gt *gt, struct xe_reg reg)
> > > >  {
> > > > +	xe_mmio_assert_forcewake(gt, reg);
> > > > +
> > > >  	if (reg.addr < gt->mmio.adj_limit)
> > > >  		reg.addr += gt->mmio.adj_offset;
> > > >  
> > > > @@ -58,6 +80,8 @@ static inline u32 xe_mmio_rmw32(struct xe_gt *gt, struct xe_reg reg, u32 clr,
> > > >  static inline void xe_mmio_write64(struct xe_gt *gt,
> > > >  				   struct xe_reg reg, u64 val)
> > > >  {
> > > > +	xe_mmio_assert_forcewake(gt, reg);
> > > > +
> > > >  	if (reg.addr < gt->mmio.adj_limit)
> > > >  		reg.addr += gt->mmio.adj_offset;
> > > >  
> > > > @@ -66,6 +90,8 @@ static inline void xe_mmio_write64(struct xe_gt *gt,
> > > >  
> > > >  static inline u64 xe_mmio_read64(struct xe_gt *gt, struct xe_reg reg)
> > > >  {
> > > > +	xe_mmio_assert_forcewake(gt, reg);
> > > > +
> > > >  	if (reg.addr < gt->mmio.adj_limit)
> > > >  		reg.addr += gt->mmio.adj_offset;
> > > >  
> > > > -- 
> > > > 2.39.2
> > > > 
> > > 
> > > -- 
> > > Matt Roper
> > > Graphics Software Engineer
> > > Linux GPU Platform Enablement
> > > Intel Corporation
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-05-23  3:28 ` [Intel-xe] [RFC] " Matt Roper
  2023-05-23 13:56   ` Matthew Brost
@ 2023-05-24 17:06   ` Rodrigo Vivi
  1 sibling, 0 replies; 25+ messages in thread
From: Rodrigo Vivi @ 2023-05-24 17:06 UTC (permalink / raw)
  To: Matt Roper
  Cc: Jani Nikula, Lucas De Marchi, Ville Syrjälä,
	Matthew Auld, Rodrigo Vivi, intel-xe

On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > It is the maximum protection we can do with the current infrastructure.
> > 
> > Cc: John Harrison <John.C.Harrison@Intel.com>
> > Cc: Matthew Auld <matthew.auld@intel.com>
> > Cc: Francois Dugast <francois.dugast@intel.com>
> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > Cc: Jani Nikula <jani.nikula@intel.com>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Cc: Matt Roper <matthew.d.roper@intel.com>
> > Cc: Matthew Brost <matthew.brost@intel.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > ---
> > 
> > 
> > RFC
> > ===
> > 
> > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > Xe than anything else.
> > 
> > On i915 the force_wake is built-in the mmio functions at uncore component.
> > 
> > With that approach we had few historical issues iirc:
> > 
> > 1. Display performance with vblank evasion that requested uncore to provide
> > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > the name suggests).
> 
> In i915 there were more differences between fw and non-fw variants
> of register functions than just forcewake handling:
> 
>  * _fw() functions assumed that the caller was already holding
>    forcewake, whereas the non-fw functions would obtain it themselves
>  * _fw() functions also assumed that the caller was already holding
>    uncore->lock, whereas the non-fw functions would obtain and release
>    the lock around each register access
>  * _fw() functions do no tracing and no debug assertions
>  * _fw() functions do not check for unclaimed MMIO
> 
> I don't think the first bullet there (forcewake) really mattered much
> from a performance perspective.  For display registers, a quick binary
> search of the FW table (just a handful of CPU cycles) would quickly
> determine that no forcewake domains were needed for those register
> offsets, so we wouldn't be doing anything with forcewake at the hardware
> level at all.  For display registers, the more performance-relevant
> aspects of using the _fw() functions was doing all your register
> accesses together without contention with other MMIO work.  I.e.,
> holding the uncore lock over an entire set of registers rather than
> grabbing/releasing it for each one, and (for vblank evasion
> specifically) doing it all while interrupts were disabled.  For debug
> drivers, there was also a bunch of other stuff that the _fw() functions
> bypassed (e.g., tripling of the number of register accesses due to
> reading FPGA_DBG before/after each register to look for unclaimed
> accesses).
> 
> > 
> > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > other times that the spec was updated and we didn't get the notification, and
> > there were cases that the BSpec had bugs.
> > 
> > For these reasons in Xe we have decided to let to the caller the
> > responsibility to set the force_wake bits for their domains before doing
> > the MMIO.
> 
> I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> bspec update (or the bspec itself having incorrect information) would
> lead to even more mistakes if the caller has to explicitly grab the
> appropriate domains than if the driver does it implicitly.  The explicit
> handling only helps in the subset of cases where we blindly grab all of
> the domains (as we do during part of init).
> 
> 
> > 
> > However I'm seeing many questions and doubts popping up:
> > 
> > 1. Are we confident that we are not missing any wake-up?
> > 2. Are we confident that the domains are set correctly?
> > 3. Are we not wasting power if we are waking up ALL the domains instead
> >    of some specific one?
> 
> I think we're only holding ALL domains during init; for most of the
> runtime MMIO accesses, I think the code is currently attempting to only
> grab the domain(s) that it thinks the registers it's accessing will
> need.  Although that might be working right now, I'm a little bit
> worried about how that will scale in the long term when a single
> register might be in several different domains depending on what
> platform you're running on.  There have definitely been cases in the
> past where groups of registers migrated from RENDER to GT or vice versa
> between platforms, so the exact domain you needed for an operation
> varied by platform.  And things are even more complicated if you're
> doing any MMIO against the media, since the hardware seems to change
> exactly how it splits up the media power wells somewhat often.
> 
> > 4. What about the display disconnection now because i915 and xe have different
> >    mmio approaches but reusing i915-display?
> > 
> > It looks to me that the cons of the current approach are superseding the
> > cons of the i915 approach. But I want to hear more thoughts here before
> > we decide which route to take.
> > 
> > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > a double approach where the caller is responsible but mmio has the range
> > information and double check it?
> 
> As noted above, part of the challenge with forcewake is that even if the
> caller knows it wants to access register FOO, and even if it know FOO is
> a GT register that likely needs forcewake, it's sometimes challenging to
> make sure it's grabbing the correct domain(s) for every single platform
> the Xe driver will eventually support if the power management handling
> changes.  I think that was part of the motivation for encoding the
> tables into the driver in i915.  It seems like GT power wells don't
> change as much these days as they used to, but it's hard to say whether
> that will continue in the future or not.  Who knows...maybe they'll
> eventually start creating dedicated domains for stuff like blitters,
> GuC, etc.  rather than lumping all of those into the "GT" catchall
> domain.
> 
> If we do decide to go back to implicit forcewake handling with the table
> encoded into the driver, it might be worth doing something sort of like
> what Lucas is doing in the OOB workaround series --- drop the
> per-platform tables into a human-readable text file that's more similar
> to the format used by the bspec (exact ranges, forcewake domain, MCR
> replication type, etc.) and then provide a small parser program that
> will convert that into actual code (and do things like consolidating
> adjacent ranges).

good idea!

> 
> > 
> > Any other idea? Thoughts?
> 
> Once the big GT vs tile refactor stuff I have in flight gets finalized,
> I plan to follow up with another series that creates a more appropriate
> MMIO target for register operations rather than using "xe_gt" as the
> target (even for things completely unrelated to the small GT subset of
> hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> operations against a specific hardware unit, and then the info inside
> the MMIO structure would be able to figure out if there are additional
> checks and/or operations it should perform.  E.g.,
> 
>  * mmio = xe_mmio_for_device(xe_device *xe);
>     - Used to submit MMIO operations against the root tile of the PCI
>       device.  Only used during init (e.g., to read the registers that
>       tell us which tiles exist on the platform) and during top-level
>       interrupt enable/disable (since all interrupts are routed through
>       the root tile).
>     - No forcewake needed for register accesses through a handle of this
>       type since you'd only ever be accessing sgunit registers for these
>       types of things.
>     - Register accesses through mmio can warn on debug builds if the
>       register appears to be in a GT-related MMIO range.
> 
>  * mmio = xe_mmio_for_display(xe_device *xe);
>     - Pretty much the same as handles returned by xe_mmio_for_device(),
>       but if a handle of this type is used to try to read/write
>       registers outside the display range, we could have debug builds
>       throw some extra warnings.
>     - Unclaimed register detection could be confined to accesses through
>       these handles.
> 
>  * mmio = xe_mmio_for_tile(xe_tile *tile);
>     - Used to access non-GT registers that reside in a specific tile.
>       I.e., sgunit/soc registers.
>     - As above, no forcewake needed, can make MMIO operations warn
>       if used to access a GT range.
> 
>  * mmio = xe_mmio_for_gt(xe_gt *gt);
>     - Used to access GT registers in a specific GT
>     - Does automatic GSI offset translation for media GTs
>     - Can either do automatic forcewake like i915 does, or can do debug
>       check+warn like you have here.
>     - Can make MMIO operations warn if MMIO offset is outside GT range
>     - Can also trigger warnings if a GT non-GSI, non-media engine
>       register is accessed from an MMIO obtained from a media GT.

Ack! This sounds like a great plan!
So this RFC discussion was much easier than I expected :)

> 
> At some point we'll probably want to add some debug tracepoints for MMIO
> access to assist with debugging; the mmio structure can also help
> provide meaningful output for each type of MMIO handle as well.
> 
> 
> One other MMIO-related thing:
> At the moment Xe does no locking of MMIO access.  I know there were
> hardware lockups on old platforms if simultaneous MMIO accesses
> happened, but I've never seen that tied to a specific HSD ticket that
> would let us know whether modern platforms are still susceptible or not.
> If it turns out they are and that we need to bring in the equivalent of
> i915's uncore lock (and figure out if any register access is
> problematic, or only certain types/ranges).
> 
> 
> Matt
> 
> > 
> > Thanks,
> > Rodrigo.
> > 
> >  drivers/gpu/drm/xe/xe_mmio.h | 26 ++++++++++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_mmio.h b/drivers/gpu/drm/xe/xe_mmio.h
> > index 1407f1189b0d..6302ca85e3f4 100644
> > --- a/drivers/gpu/drm/xe/xe_mmio.h
> > +++ b/drivers/gpu/drm/xe/xe_mmio.h
> > @@ -18,8 +18,26 @@ struct xe_device;
> >  
> >  int xe_mmio_init(struct xe_device *xe);
> >  
> > +static inline void xe_mmio_assert_forcewake(struct xe_gt *gt,
> > +					    struct xe_reg reg)
> > +{
> > +	struct xe_force_wake *fw = &gt->mmio.fw;
> > +
> > +	/* No need for forcewake in this range */
> > +	if (reg.addr >= 0x40000 && reg.addr < 0x116000)
> > +		return;
> > +
> > +	/*
> > +	 * XXX: Weak. It checks for some domain, but impossible to determine
> > +	 * if the right one is selected, or if it was set by the same caller
> > +	 */
> > +	WARN_ON(!fw->awake_domains);
> > +}
> > +
> >  static inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
> >  {
> > +	xe_mmio_assert_forcewake(gt, reg);
> > +
> >  	if (reg.addr < gt->mmio.adj_limit)
> >  		reg.addr += gt->mmio.adj_offset;
> >  
> > @@ -29,6 +47,8 @@ static inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
> >  static inline void xe_mmio_write32(struct xe_gt *gt,
> >  				   struct xe_reg reg, u32 val)
> >  {
> > +	xe_mmio_assert_forcewake(gt, reg);
> > +
> >  	if (reg.addr < gt->mmio.adj_limit)
> >  		reg.addr += gt->mmio.adj_offset;
> >  
> > @@ -37,6 +57,8 @@ static inline void xe_mmio_write32(struct xe_gt *gt,
> >  
> >  static inline u32 xe_mmio_read32(struct xe_gt *gt, struct xe_reg reg)
> >  {
> > +	xe_mmio_assert_forcewake(gt, reg);
> > +
> >  	if (reg.addr < gt->mmio.adj_limit)
> >  		reg.addr += gt->mmio.adj_offset;
> >  
> > @@ -58,6 +80,8 @@ static inline u32 xe_mmio_rmw32(struct xe_gt *gt, struct xe_reg reg, u32 clr,
> >  static inline void xe_mmio_write64(struct xe_gt *gt,
> >  				   struct xe_reg reg, u64 val)
> >  {
> > +	xe_mmio_assert_forcewake(gt, reg);
> > +
> >  	if (reg.addr < gt->mmio.adj_limit)
> >  		reg.addr += gt->mmio.adj_offset;
> >  
> > @@ -66,6 +90,8 @@ static inline void xe_mmio_write64(struct xe_gt *gt,
> >  
> >  static inline u64 xe_mmio_read64(struct xe_gt *gt, struct xe_reg reg)
> >  {
> > +	xe_mmio_assert_forcewake(gt, reg);
> > +
> >  	if (reg.addr < gt->mmio.adj_limit)
> >  		reg.addr += gt->mmio.adj_offset;
> >  
> > -- 
> > 2.39.2
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-05-23 23:52       ` Matthew Brost
@ 2023-10-09  9:22         ` Luca Coelho
  2023-10-09 21:15           ` Rodrigo Vivi
  0 siblings, 1 reply; 25+ messages in thread
From: Luca Coelho @ 2023-10-09  9:22 UTC (permalink / raw)
  To: Matthew Brost, Matt Roper
  Cc: Jani Nikula, Lucas De Marchi, Matthew Auld, Rodrigo Vivi, intel-xe

Hi everyone,

On Tue, 2023-05-23 at 23:52 +0000, Matthew Brost wrote:
> On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> > On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > > It is the maximum protection we can do with the current infrastructure.
> > > > > 
> > > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > ---
> > > > > 
> > > > > 
> > > > > RFC
> > > > > ===
> > > > > 
> > > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > > Xe than anything else.
> > > > > 
> > > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > > 
> > > > > With that approach we had few historical issues iirc:
> > > > > 
> > > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > > the name suggests).
> > > > 
> > > > In i915 there were more differences between fw and non-fw variants
> > > > of register functions than just forcewake handling:
> > > > 
> > > >  * _fw() functions assumed that the caller was already holding
> > > >    forcewake, whereas the non-fw functions would obtain it themselves
> > > >  * _fw() functions also assumed that the caller was already holding
> > > >    uncore->lock, whereas the non-fw functions would obtain and release
> > > >    the lock around each register access
> > > >  * _fw() functions do no tracing and no debug assertions
> > > >  * _fw() functions do not check for unclaimed MMIO
> > > > 
> > > > I don't think the first bullet there (forcewake) really mattered much
> > > > from a performance perspective.  For display registers, a quick binary
> > > > search of the FW table (just a handful of CPU cycles) would quickly
> > > > determine that no forcewake domains were needed for those register
> > > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > > level at all.  For display registers, the more performance-relevant
> > > > aspects of using the _fw() functions was doing all your register
> > > > accesses together without contention with other MMIO work.  I.e.,
> > > > holding the uncore lock over an entire set of registers rather than
> > > > grabbing/releasing it for each one, and (for vblank evasion
> > > > specifically) doing it all while interrupts were disabled.  For debug
> > > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > > bypassed (e.g., tripling of the number of register accesses due to
> > > > reading FPGA_DBG before/after each register to look for unclaimed
> > > > accesses).
> > > > 
> > > > > 
> > > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > > other times that the spec was updated and we didn't get the notification, and
> > > > > there were cases that the BSpec had bugs.
> > > > > 
> > > > > For these reasons in Xe we have decided to let to the caller the
> > > > > responsibility to set the force_wake bits for their domains before doing
> > > > > the MMIO.
> > > > 
> > > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > > bspec update (or the bspec itself having incorrect information) would
> > > > lead to even more mistakes if the caller has to explicitly grab the
> > > > appropriate domains than if the driver does it implicitly.  The explicit
> > > > handling only helps in the subset of cases where we blindly grab all of
> > > > the domains (as we do during part of init).
> > > > 
> > > > 
> > > 
> > > MMIO access that requires forcewakes really only should be in a few
> > > places, off the top of my head:
> > > 
> > > 1. Init
> > > 2. Reset
> > > 3. Sysfs / Debugfs
> > > 
> > > In all of these cases I think it fine to blindly grab all forcewakes.
> > > 
> > > Please chime in if I'm missing something.
> > 
> > I think as we implement more features in the Xe driver we're going to
> > wind up with a lot more places where we need to access GT registers at
> > runtime.  A few examples off the top of my head:
> > 
> >  * EU stall sampling
> >  * Perf/OA
> >  * EU debugger
> >  * Various OOB workarounds that ask us to twiddle a register at certain
> >    times in the driver.
> 
> Hmm, ok a lot of these I could make the argument that these are not
> normal operation so just grab everything and call it a day. If some of
> these fall into the category of 'normal enough to be optimized' I can
> also make the argument it is no more complex (perhaps less complex) to
> explicitly grab the forcewake than having the logic auto-grab the
> forcewake.
> 
> What a compromise of in a debug mode we auto-generate the asserts based
> on a table but we still explicitly grab the forcewake?
> 
> > 
> > > 
> > > > > 
> > > > > However I'm seeing many questions and doubts popping up:
> > > > > 
> > > > > 1. Are we confident that we are not missing any wake-up?
> > > > > 2. Are we confident that the domains are set correctly?
> > > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > > >    of some specific one?
> > > > 
> > > > I think we're only holding ALL domains during init; for most of the
> > > > runtime MMIO accesses, I think the code is currently attempting to only
> > > > grab the domain(s) that it thinks the registers it's accessing will
> > > > need.  Although that might be working right now, I'm a little bit
> > > > worried about how that will scale in the long term when a single
> > > > register might be in several different domains depending on what
> > > > platform you're running on.  There have definitely been cases in the
> > > > past where groups of registers migrated from RENDER to GT or vice versa
> > > > between platforms, so the exact domain you needed for an operation
> > > > varied by platform.  And things are even more complicated if you're
> > > > doing any MMIO against the media, since the hardware seems to change
> > > > exactly how it splits up the media power wells somewhat often.
> > > > 
> > > > > 4. What about the display disconnection now because i915 and xe have different
> > > > >    mmio approaches but reusing i915-display?
> > > > > 
> > > > > It looks to me that the cons of the current approach are superseding the
> > > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > > we decide which route to take.
> > > > > 
> > > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > > a double approach where the caller is responsible but mmio has the range
> > > > > information and double check it?
> > > > 
> > > > As noted above, part of the challenge with forcewake is that even if the
> > > > caller knows it wants to access register FOO, and even if it know FOO is
> > > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > > make sure it's grabbing the correct domain(s) for every single platform
> > > > the Xe driver will eventually support if the power management handling
> > > > changes.  I think that was part of the motivation for encoding the
> > > > tables into the driver in i915.  It seems like GT power wells don't
> > > > change as much these days as they used to, but it's hard to say whether
> > > > that will continue in the future or not.  Who knows...maybe they'll
> > > > eventually start creating dedicated domains for stuff like blitters,
> > > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > > domain.
> > > > 
> > > > If we do decide to go back to implicit forcewake handling with the table
> > > > encoded into the driver, it might be worth doing something sort of like
> > > 
> > > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > > anything like this in Xe.
> > 
> > When you say unreadable, are you referring to the macros that generate
> > the table lookup functions?  I don't think that macro magic would be
> > needed for Xe since we don't have to support old platforms that have
> > very different forcewake behavior, and we also don't need to generate
> > separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> > (since I think everything in the GT is 32-bits these days).
> > 
> 
> Just the entire file is unreadable in general, trying to avoid these
> types of files in Xe, avoid traps of the i915 did this so let's do it in
> Xe, and over engineering our driver to avoid hypothetical future bugs.
> 
> Matt
> 
> > The forcewake and shadow tables themselves are pretty clean in i915
> > these days, and if we move to autogenerating them from a text file, they
> > can become even simpler since the text file will basically be a cleaned
> > up copy/paste of part of the bspec table.
> > 
> > 
> > Matt
> > 
> > > 
> > > > what Lucas is doing in the OOB workaround series --- drop the
> > > > per-platform tables into a human-readable text file that's more similar
> > > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > > replication type, etc.) and then provide a small parser program that
> > > > will convert that into actual code (and do things like consolidating
> > > > adjacent ranges).
> > > > 
> > > > > 
> > > > > Any other idea? Thoughts?
> > > > 
> > > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > > I plan to follow up with another series that creates a more appropriate
> > > > MMIO target for register operations rather than using "xe_gt" as the
> > > > target (even for things completely unrelated to the small GT subset of
> > > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > > operations against a specific hardware unit, and then the info inside
> > > > the MMIO structure would be able to figure out if there are additional
> > > > checks and/or operations it should perform.  E.g.,
> > > > 
> > > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > > >     - Used to submit MMIO operations against the root tile of the PCI
> > > >       device.  Only used during init (e.g., to read the registers that
> > > >       tell us which tiles exist on the platform) and during top-level
> > > >       interrupt enable/disable (since all interrupts are routed through
> > > >       the root tile).
> > > >     - No forcewake needed for register accesses through a handle of this
> > > >       type since you'd only ever be accessing sgunit registers for these
> > > >       types of things.
> > > >     - Register accesses through mmio can warn on debug builds if the
> > > >       register appears to be in a GT-related MMIO range.
> > > > 
> > > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > > >       but if a handle of this type is used to try to read/write
> > > >       registers outside the display range, we could have debug builds
> > > >       throw some extra warnings.
> > > >     - Unclaimed register detection could be confined to accesses through
> > > >       these handles.
> > > > 
> > > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > > >     - Used to access non-GT registers that reside in a specific tile.
> > > >       I.e., sgunit/soc registers.
> > > >     - As above, no forcewake needed, can make MMIO operations warn
> > > >       if used to access a GT range.
> > > > 
> > > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > > >     - Used to access GT registers in a specific GT
> > > >     - Does automatic GSI offset translation for media GTs
> > > >     - Can either do automatic forcewake like i915 does, or can do debug
> > > >       check+warn like you have here.
> > > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > > >       register is accessed from an MMIO obtained from a media GT.
> > > > 
> > > 
> > > Ack on this if we keep in managable, worried code / feature bloat those
> > > that will result in a similar file to intel_uncore.c in Xe.

Just to revive this thread.

I've been discussing this proposal in the context of a change we need
to make in the display, which is to introduce a wakelock for some
registers access in order to be able to remove the DMC trap.

We came to the conclusion that this new implementation is very much the
same as the forcewake proposal here.  From the display point-of-view,
we could simply have a new domain and range of registers to protect.

We _could_ implement a separate "wakelock" mechanism for the display
part, but that would be mostly duplicating the entire forcewake
implementation.

So, are there any plans to implement the current proposal? Or any other
plans related to the forcewake implementation for Xe? As I see it, the
"wakelock" implementation in the display depends on this.

Any thoughts?

--
Cheers,
Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-09  9:22         ` Luca Coelho
@ 2023-10-09 21:15           ` Rodrigo Vivi
  2023-10-10  7:00             ` Luca Coelho
  0 siblings, 1 reply; 25+ messages in thread
From: Rodrigo Vivi @ 2023-10-09 21:15 UTC (permalink / raw)
  To: Luca Coelho, Lucas De Marchi, Matthew Brost, Jani Nikula,
	Ville Syrjälä,
	Matt Roper
  Cc: Jani Nikula, Lucas De Marchi, Matthew Auld, Matt Roper, intel-xe

On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> Hi everyone,
> 
> On Tue, 2023-05-23 at 23:52 +0000, Matthew Brost wrote:
> > On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> > > On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > > > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > > > It is the maximum protection we can do with the current infrastructure.
> > > > > > 
> > > > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > ---
> > > > > > 
> > > > > > 
> > > > > > RFC
> > > > > > ===
> > > > > > 
> > > > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > > > Xe than anything else.
> > > > > > 
> > > > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > > > 
> > > > > > With that approach we had few historical issues iirc:
> > > > > > 
> > > > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > > > the name suggests).
> > > > > 
> > > > > In i915 there were more differences between fw and non-fw variants
> > > > > of register functions than just forcewake handling:
> > > > > 
> > > > >  * _fw() functions assumed that the caller was already holding
> > > > >    forcewake, whereas the non-fw functions would obtain it themselves
> > > > >  * _fw() functions also assumed that the caller was already holding
> > > > >    uncore->lock, whereas the non-fw functions would obtain and release
> > > > >    the lock around each register access
> > > > >  * _fw() functions do no tracing and no debug assertions
> > > > >  * _fw() functions do not check for unclaimed MMIO
> > > > > 
> > > > > I don't think the first bullet there (forcewake) really mattered much
> > > > > from a performance perspective.  For display registers, a quick binary
> > > > > search of the FW table (just a handful of CPU cycles) would quickly
> > > > > determine that no forcewake domains were needed for those register
> > > > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > > > level at all.  For display registers, the more performance-relevant
> > > > > aspects of using the _fw() functions was doing all your register
> > > > > accesses together without contention with other MMIO work.  I.e.,
> > > > > holding the uncore lock over an entire set of registers rather than
> > > > > grabbing/releasing it for each one, and (for vblank evasion
> > > > > specifically) doing it all while interrupts were disabled.  For debug
> > > > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > > > bypassed (e.g., tripling of the number of register accesses due to
> > > > > reading FPGA_DBG before/after each register to look for unclaimed
> > > > > accesses).
> > > > > 
> > > > > > 
> > > > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > > > other times that the spec was updated and we didn't get the notification, and
> > > > > > there were cases that the BSpec had bugs.
> > > > > > 
> > > > > > For these reasons in Xe we have decided to let to the caller the
> > > > > > responsibility to set the force_wake bits for their domains before doing
> > > > > > the MMIO.
> > > > > 
> > > > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > > > bspec update (or the bspec itself having incorrect information) would
> > > > > lead to even more mistakes if the caller has to explicitly grab the
> > > > > appropriate domains than if the driver does it implicitly.  The explicit
> > > > > handling only helps in the subset of cases where we blindly grab all of
> > > > > the domains (as we do during part of init).
> > > > > 
> > > > > 
> > > > 
> > > > MMIO access that requires forcewakes really only should be in a few
> > > > places, off the top of my head:
> > > > 
> > > > 1. Init
> > > > 2. Reset
> > > > 3. Sysfs / Debugfs
> > > > 
> > > > In all of these cases I think it fine to blindly grab all forcewakes.
> > > > 
> > > > Please chime in if I'm missing something.
> > > 
> > > I think as we implement more features in the Xe driver we're going to
> > > wind up with a lot more places where we need to access GT registers at
> > > runtime.  A few examples off the top of my head:
> > > 
> > >  * EU stall sampling
> > >  * Perf/OA
> > >  * EU debugger
> > >  * Various OOB workarounds that ask us to twiddle a register at certain
> > >    times in the driver.
> > 
> > Hmm, ok a lot of these I could make the argument that these are not
> > normal operation so just grab everything and call it a day. If some of
> > these fall into the category of 'normal enough to be optimized' I can
> > also make the argument it is no more complex (perhaps less complex) to
> > explicitly grab the forcewake than having the logic auto-grab the
> > forcewake.
> > 
> > What a compromise of in a debug mode we auto-generate the asserts based
> > on a table but we still explicitly grab the forcewake?
> > 
> > > 
> > > > 
> > > > > > 
> > > > > > However I'm seeing many questions and doubts popping up:
> > > > > > 
> > > > > > 1. Are we confident that we are not missing any wake-up?
> > > > > > 2. Are we confident that the domains are set correctly?
> > > > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > > > >    of some specific one?
> > > > > 
> > > > > I think we're only holding ALL domains during init; for most of the
> > > > > runtime MMIO accesses, I think the code is currently attempting to only
> > > > > grab the domain(s) that it thinks the registers it's accessing will
> > > > > need.  Although that might be working right now, I'm a little bit
> > > > > worried about how that will scale in the long term when a single
> > > > > register might be in several different domains depending on what
> > > > > platform you're running on.  There have definitely been cases in the
> > > > > past where groups of registers migrated from RENDER to GT or vice versa
> > > > > between platforms, so the exact domain you needed for an operation
> > > > > varied by platform.  And things are even more complicated if you're
> > > > > doing any MMIO against the media, since the hardware seems to change
> > > > > exactly how it splits up the media power wells somewhat often.
> > > > > 
> > > > > > 4. What about the display disconnection now because i915 and xe have different
> > > > > >    mmio approaches but reusing i915-display?
> > > > > > 
> > > > > > It looks to me that the cons of the current approach are superseding the
> > > > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > > > we decide which route to take.
> > > > > > 
> > > > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > > > a double approach where the caller is responsible but mmio has the range
> > > > > > information and double check it?
> > > > > 
> > > > > As noted above, part of the challenge with forcewake is that even if the
> > > > > caller knows it wants to access register FOO, and even if it know FOO is
> > > > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > > > make sure it's grabbing the correct domain(s) for every single platform
> > > > > the Xe driver will eventually support if the power management handling
> > > > > changes.  I think that was part of the motivation for encoding the
> > > > > tables into the driver in i915.  It seems like GT power wells don't
> > > > > change as much these days as they used to, but it's hard to say whether
> > > > > that will continue in the future or not.  Who knows...maybe they'll
> > > > > eventually start creating dedicated domains for stuff like blitters,
> > > > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > > > domain.
> > > > > 
> > > > > If we do decide to go back to implicit forcewake handling with the table
> > > > > encoded into the driver, it might be worth doing something sort of like
> > > > 
> > > > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > > > anything like this in Xe.
> > > 
> > > When you say unreadable, are you referring to the macros that generate
> > > the table lookup functions?  I don't think that macro magic would be
> > > needed for Xe since we don't have to support old platforms that have
> > > very different forcewake behavior, and we also don't need to generate
> > > separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> > > (since I think everything in the GT is 32-bits these days).
> > > 
> > 
> > Just the entire file is unreadable in general, trying to avoid these
> > types of files in Xe, avoid traps of the i915 did this so let's do it in
> > Xe, and over engineering our driver to avoid hypothetical future bugs.
> > 
> > Matt
> > 
> > > The forcewake and shadow tables themselves are pretty clean in i915
> > > these days, and if we move to autogenerating them from a text file, they
> > > can become even simpler since the text file will basically be a cleaned
> > > up copy/paste of part of the bspec table.
> > > 
> > > 
> > > Matt
> > > 
> > > > 
> > > > > what Lucas is doing in the OOB workaround series --- drop the
> > > > > per-platform tables into a human-readable text file that's more similar
> > > > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > > > replication type, etc.) and then provide a small parser program that
> > > > > will convert that into actual code (and do things like consolidating
> > > > > adjacent ranges).
> > > > > 
> > > > > > 
> > > > > > Any other idea? Thoughts?
> > > > > 
> > > > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > > > I plan to follow up with another series that creates a more appropriate
> > > > > MMIO target for register operations rather than using "xe_gt" as the
> > > > > target (even for things completely unrelated to the small GT subset of
> > > > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > > > operations against a specific hardware unit, and then the info inside
> > > > > the MMIO structure would be able to figure out if there are additional
> > > > > checks and/or operations it should perform.  E.g.,
> > > > > 
> > > > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > > > >     - Used to submit MMIO operations against the root tile of the PCI
> > > > >       device.  Only used during init (e.g., to read the registers that
> > > > >       tell us which tiles exist on the platform) and during top-level
> > > > >       interrupt enable/disable (since all interrupts are routed through
> > > > >       the root tile).
> > > > >     - No forcewake needed for register accesses through a handle of this
> > > > >       type since you'd only ever be accessing sgunit registers for these
> > > > >       types of things.
> > > > >     - Register accesses through mmio can warn on debug builds if the
> > > > >       register appears to be in a GT-related MMIO range.
> > > > > 
> > > > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > > > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > > > >       but if a handle of this type is used to try to read/write
> > > > >       registers outside the display range, we could have debug builds
> > > > >       throw some extra warnings.
> > > > >     - Unclaimed register detection could be confined to accesses through
> > > > >       these handles.
> > > > > 
> > > > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > > > >     - Used to access non-GT registers that reside in a specific tile.
> > > > >       I.e., sgunit/soc registers.
> > > > >     - As above, no forcewake needed, can make MMIO operations warn
> > > > >       if used to access a GT range.
> > > > > 
> > > > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > > > >     - Used to access GT registers in a specific GT
> > > > >     - Does automatic GSI offset translation for media GTs
> > > > >     - Can either do automatic forcewake like i915 does, or can do debug
> > > > >       check+warn like you have here.
> > > > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > > > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > > > >       register is accessed from an MMIO obtained from a media GT.
> > > > > 
> > > > 
> > > > Ack on this if we keep in managable, worried code / feature bloat those
> > > > that will result in a similar file to intel_uncore.c in Xe.
> 
> Just to revive this thread.
> 
> I've been discussing this proposal in the context of a change we need
> to make in the display, which is to introduce a wakelock for some
> registers access in order to be able to remove the DMC trap.
> 
> We came to the conclusion that this new implementation is very much the
> same as the forcewake proposal here.  From the display point-of-view,
> we could simply have a new domain and range of registers to protect.
> 
> We _could_ implement a separate "wakelock" mechanism for the display
> part, but that would be mostly duplicating the entire forcewake
> implementation.
> 
> So, are there any plans to implement the current proposal? Or any other
> plans related to the forcewake implementation for Xe? As I see it, the
> "wakelock" implementation in the display depends on this.
> 
> Any thoughts?

Hi Luca, thanks for raising this again here.

So, as I said in the past, I don't have strong opinions regarding the
overall forcewake approach.

The since GT MMIO is not used very frequently, I don't see a problem of
leaving that up to the caller to take the right domain when needed, or even
the FORCEWAKE_ALL domain. Instead of forcing all the callers to
go through this extra steps and then have to opt-out with the '_fw' [sic]
alternatives for the cases where the forcewake cannot be checked underneath.

So, for the new display wakelocks, that's the problem of adding them to
the drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h where the converions
from i915's intel uncore are happening to xe_mmio? So, when using the
intel_uncore's '_fw' variant you skip the wakelock and when doing the regular
mmio calls you just add a wakelock_get/put around the xe_mmio call with
the display domain. And in i915 you implement inside the intel_uncore.

What's the downside of this approach?

Trying to understand all the pros and cons of different approaches, and
bringing some people to the discussion.

If we implement the forwareke underneath the mmio call, display needs
to anyway implement it twice on the i915's intel_uncore and on the
xe_forcewake, no?!

> 
> --
> Cheers,
> Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-09 21:15           ` Rodrigo Vivi
@ 2023-10-10  7:00             ` Luca Coelho
  2023-10-10  7:26               ` Luca Coelho
  2023-10-12 20:04               ` Rodrigo Vivi
  0 siblings, 2 replies; 25+ messages in thread
From: Luca Coelho @ 2023-10-10  7:00 UTC (permalink / raw)
  To: Rodrigo Vivi, Lucas De Marchi, Matthew Brost, Jani Nikula,
	Ville Syrjälä,
	Matt Roper
  Cc: Matthew Auld, intel-xe

On Mon, 2023-10-09 at 17:15 -0400, Rodrigo Vivi wrote:
> On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> > Hi everyone,
> > 
> > On Tue, 2023-05-23 at 23:52 +0000, Matthew Brost wrote:
> > > On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> > > > On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > > > > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > > > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > > > > It is the maximum protection we can do with the current infrastructure.
> > > > > > > 
> > > > > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > ---
> > > > > > > 
> > > > > > > 
> > > > > > > RFC
> > > > > > > ===
> > > > > > > 
> > > > > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > > > > Xe than anything else.
> > > > > > > 
> > > > > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > > > > 
> > > > > > > With that approach we had few historical issues iirc:
> > > > > > > 
> > > > > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > > > > the name suggests).
> > > > > > 
> > > > > > In i915 there were more differences between fw and non-fw variants
> > > > > > of register functions than just forcewake handling:
> > > > > > 
> > > > > >  * _fw() functions assumed that the caller was already holding
> > > > > >    forcewake, whereas the non-fw functions would obtain it themselves
> > > > > >  * _fw() functions also assumed that the caller was already holding
> > > > > >    uncore->lock, whereas the non-fw functions would obtain and release
> > > > > >    the lock around each register access
> > > > > >  * _fw() functions do no tracing and no debug assertions
> > > > > >  * _fw() functions do not check for unclaimed MMIO
> > > > > > 
> > > > > > I don't think the first bullet there (forcewake) really mattered much
> > > > > > from a performance perspective.  For display registers, a quick binary
> > > > > > search of the FW table (just a handful of CPU cycles) would quickly
> > > > > > determine that no forcewake domains were needed for those register
> > > > > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > > > > level at all.  For display registers, the more performance-relevant
> > > > > > aspects of using the _fw() functions was doing all your register
> > > > > > accesses together without contention with other MMIO work.  I.e.,
> > > > > > holding the uncore lock over an entire set of registers rather than
> > > > > > grabbing/releasing it for each one, and (for vblank evasion
> > > > > > specifically) doing it all while interrupts were disabled.  For debug
> > > > > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > > > > bypassed (e.g., tripling of the number of register accesses due to
> > > > > > reading FPGA_DBG before/after each register to look for unclaimed
> > > > > > accesses).
> > > > > > 
> > > > > > > 
> > > > > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > > > > other times that the spec was updated and we didn't get the notification, and
> > > > > > > there were cases that the BSpec had bugs.
> > > > > > > 
> > > > > > > For these reasons in Xe we have decided to let to the caller the
> > > > > > > responsibility to set the force_wake bits for their domains before doing
> > > > > > > the MMIO.
> > > > > > 
> > > > > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > > > > bspec update (or the bspec itself having incorrect information) would
> > > > > > lead to even more mistakes if the caller has to explicitly grab the
> > > > > > appropriate domains than if the driver does it implicitly.  The explicit
> > > > > > handling only helps in the subset of cases where we blindly grab all of
> > > > > > the domains (as we do during part of init).
> > > > > > 
> > > > > > 
> > > > > 
> > > > > MMIO access that requires forcewakes really only should be in a few
> > > > > places, off the top of my head:
> > > > > 
> > > > > 1. Init
> > > > > 2. Reset
> > > > > 3. Sysfs / Debugfs
> > > > > 
> > > > > In all of these cases I think it fine to blindly grab all forcewakes.
> > > > > 
> > > > > Please chime in if I'm missing something.
> > > > 
> > > > I think as we implement more features in the Xe driver we're going to
> > > > wind up with a lot more places where we need to access GT registers at
> > > > runtime.  A few examples off the top of my head:
> > > > 
> > > >  * EU stall sampling
> > > >  * Perf/OA
> > > >  * EU debugger
> > > >  * Various OOB workarounds that ask us to twiddle a register at certain
> > > >    times in the driver.
> > > 
> > > Hmm, ok a lot of these I could make the argument that these are not
> > > normal operation so just grab everything and call it a day. If some of
> > > these fall into the category of 'normal enough to be optimized' I can
> > > also make the argument it is no more complex (perhaps less complex) to
> > > explicitly grab the forcewake than having the logic auto-grab the
> > > forcewake.
> > > 
> > > What a compromise of in a debug mode we auto-generate the asserts based
> > > on a table but we still explicitly grab the forcewake?
> > > 
> > > > 
> > > > > 
> > > > > > > 
> > > > > > > However I'm seeing many questions and doubts popping up:
> > > > > > > 
> > > > > > > 1. Are we confident that we are not missing any wake-up?
> > > > > > > 2. Are we confident that the domains are set correctly?
> > > > > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > > > > >    of some specific one?
> > > > > > 
> > > > > > I think we're only holding ALL domains during init; for most of the
> > > > > > runtime MMIO accesses, I think the code is currently attempting to only
> > > > > > grab the domain(s) that it thinks the registers it's accessing will
> > > > > > need.  Although that might be working right now, I'm a little bit
> > > > > > worried about how that will scale in the long term when a single
> > > > > > register might be in several different domains depending on what
> > > > > > platform you're running on.  There have definitely been cases in the
> > > > > > past where groups of registers migrated from RENDER to GT or vice versa
> > > > > > between platforms, so the exact domain you needed for an operation
> > > > > > varied by platform.  And things are even more complicated if you're
> > > > > > doing any MMIO against the media, since the hardware seems to change
> > > > > > exactly how it splits up the media power wells somewhat often.
> > > > > > 
> > > > > > > 4. What about the display disconnection now because i915 and xe have different
> > > > > > >    mmio approaches but reusing i915-display?
> > > > > > > 
> > > > > > > It looks to me that the cons of the current approach are superseding the
> > > > > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > > > > we decide which route to take.
> > > > > > > 
> > > > > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > > > > a double approach where the caller is responsible but mmio has the range
> > > > > > > information and double check it?
> > > > > > 
> > > > > > As noted above, part of the challenge with forcewake is that even if the
> > > > > > caller knows it wants to access register FOO, and even if it know FOO is
> > > > > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > > > > make sure it's grabbing the correct domain(s) for every single platform
> > > > > > the Xe driver will eventually support if the power management handling
> > > > > > changes.  I think that was part of the motivation for encoding the
> > > > > > tables into the driver in i915.  It seems like GT power wells don't
> > > > > > change as much these days as they used to, but it's hard to say whether
> > > > > > that will continue in the future or not.  Who knows...maybe they'll
> > > > > > eventually start creating dedicated domains for stuff like blitters,
> > > > > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > > > > domain.
> > > > > > 
> > > > > > If we do decide to go back to implicit forcewake handling with the table
> > > > > > encoded into the driver, it might be worth doing something sort of like
> > > > > 
> > > > > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > > > > anything like this in Xe.
> > > > 
> > > > When you say unreadable, are you referring to the macros that generate
> > > > the table lookup functions?  I don't think that macro magic would be
> > > > needed for Xe since we don't have to support old platforms that have
> > > > very different forcewake behavior, and we also don't need to generate
> > > > separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> > > > (since I think everything in the GT is 32-bits these days).
> > > > 
> > > 
> > > Just the entire file is unreadable in general, trying to avoid these
> > > types of files in Xe, avoid traps of the i915 did this so let's do it in
> > > Xe, and over engineering our driver to avoid hypothetical future bugs.
> > > 
> > > Matt
> > > 
> > > > The forcewake and shadow tables themselves are pretty clean in i915
> > > > these days, and if we move to autogenerating them from a text file, they
> > > > can become even simpler since the text file will basically be a cleaned
> > > > up copy/paste of part of the bspec table.
> > > > 
> > > > 
> > > > Matt
> > > > 
> > > > > 
> > > > > > what Lucas is doing in the OOB workaround series --- drop the
> > > > > > per-platform tables into a human-readable text file that's more similar
> > > > > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > > > > replication type, etc.) and then provide a small parser program that
> > > > > > will convert that into actual code (and do things like consolidating
> > > > > > adjacent ranges).
> > > > > > 
> > > > > > > 
> > > > > > > Any other idea? Thoughts?
> > > > > > 
> > > > > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > > > > I plan to follow up with another series that creates a more appropriate
> > > > > > MMIO target for register operations rather than using "xe_gt" as the
> > > > > > target (even for things completely unrelated to the small GT subset of
> > > > > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > > > > operations against a specific hardware unit, and then the info inside
> > > > > > the MMIO structure would be able to figure out if there are additional
> > > > > > checks and/or operations it should perform.  E.g.,
> > > > > > 
> > > > > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > > > > >     - Used to submit MMIO operations against the root tile of the PCI
> > > > > >       device.  Only used during init (e.g., to read the registers that
> > > > > >       tell us which tiles exist on the platform) and during top-level
> > > > > >       interrupt enable/disable (since all interrupts are routed through
> > > > > >       the root tile).
> > > > > >     - No forcewake needed for register accesses through a handle of this
> > > > > >       type since you'd only ever be accessing sgunit registers for these
> > > > > >       types of things.
> > > > > >     - Register accesses through mmio can warn on debug builds if the
> > > > > >       register appears to be in a GT-related MMIO range.
> > > > > > 
> > > > > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > > > > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > > > > >       but if a handle of this type is used to try to read/write
> > > > > >       registers outside the display range, we could have debug builds
> > > > > >       throw some extra warnings.
> > > > > >     - Unclaimed register detection could be confined to accesses through
> > > > > >       these handles.
> > > > > > 
> > > > > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > > > > >     - Used to access non-GT registers that reside in a specific tile.
> > > > > >       I.e., sgunit/soc registers.
> > > > > >     - As above, no forcewake needed, can make MMIO operations warn
> > > > > >       if used to access a GT range.
> > > > > > 
> > > > > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > > > > >     - Used to access GT registers in a specific GT
> > > > > >     - Does automatic GSI offset translation for media GTs
> > > > > >     - Can either do automatic forcewake like i915 does, or can do debug
> > > > > >       check+warn like you have here.
> > > > > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > > > > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > > > > >       register is accessed from an MMIO obtained from a media GT.
> > > > > > 
> > > > > 
> > > > > Ack on this if we keep in managable, worried code / feature bloat those
> > > > > that will result in a similar file to intel_uncore.c in Xe.
> > 
> > Just to revive this thread.
> > 
> > I've been discussing this proposal in the context of a change we need
> > to make in the display, which is to introduce a wakelock for some
> > registers access in order to be able to remove the DMC trap.
> > 
> > We came to the conclusion that this new implementation is very much the
> > same as the forcewake proposal here.  From the display point-of-view,
> > we could simply have a new domain and range of registers to protect.
> > 
> > We _could_ implement a separate "wakelock" mechanism for the display
> > part, but that would be mostly duplicating the entire forcewake
> > implementation.
> > 
> > So, are there any plans to implement the current proposal? Or any other
> > plans related to the forcewake implementation for Xe? As I see it, the
> > "wakelock" implementation in the display depends on this.
> > 
> > Any thoughts?
> 
> Hi Luca, thanks for raising this again here.

Hi Lucas! Thanks for your comments.


> So, as I said in the past, I don't have strong opinions regarding the
> overall forcewake approach.
> 
> The since GT MMIO is not used very frequently, I don't see a problem of
> leaving that up to the caller to take the right domain when needed, or even
> the FORCEWAKE_ALL domain. Instead of forcing all the callers to
> go through this extra steps and then have to opt-out with the '_fw' [sic]
> alternatives for the cases where the forcewake cannot be checked underneath.
> 
> So, for the new display wakelocks, that's the problem of adding them to
> the drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h where the converions
> from i915's intel uncore are happening to xe_mmio? So, when using the
> intel_uncore's '_fw' variant you skip the wakelock and when doing the regular
> mmio calls you just add a wakelock_get/put around the xe_mmio call with
> the display domain. And in i915 you implement inside the intel_uncore.
> 
> What's the downside of this approach?

That's more or less what I was thinking.  I don't think there's any
problem on the display side in calling the same framework.


> Trying to understand all the pros and cons of different approaches, and
> bringing some people to the discussion.
> 
> If we implement the forwareke underneath the mmio call, display needs
> to anyway implement it twice on the i915's intel_uncore and on the
> xe_forcewake, no?!

Yes, IMHO we should start making Xe the base implementation and
backporting the new implementation into i915.

So,for this specific case, I think we can just make i915 call the new
functions in xe and have them backported in intel_uncore.h for i915.

What I was thinking was basically this:

1. Implement the xe_mmio_for_<hw_unit>() proposal in Xe​

2. Display code uses new APIs (xe_mmio_for_display ops)​

3. Update uncore to handle "wakelock domain"​

4. Wrappers for i915​, make an xe_mmio_for_display wrapper that calls
the old functions in uncore and add the necessary locking there.

In i915 we're most likely not going to need the wakelock stuff for DMC
trap, because it shouldn't be needed in older hardware anyway.  So the
backport can remain pretty simple.

Would this work?

--
Cheers,
Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-10  7:00             ` Luca Coelho
@ 2023-10-10  7:26               ` Luca Coelho
  2023-10-12 19:58                 ` Rodrigo Vivi
  2023-10-12 20:04               ` Rodrigo Vivi
  1 sibling, 1 reply; 25+ messages in thread
From: Luca Coelho @ 2023-10-10  7:26 UTC (permalink / raw)
  To: Rodrigo Vivi, Lucas De Marchi, Matthew Brost, Jani Nikula,
	Ville Syrjälä,
	Matt Roper
  Cc: Matthew Auld, intel-xe

On Tue, 2023-10-10 at 10:00 +0300, Luca Coelho wrote:
> On Mon, 2023-10-09 at 17:15 -0400, Rodrigo Vivi wrote:
> > On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> > > Any thoughts?
> > 
> > Hi Luca, thanks for raising this again here.
> 
> Hi Lucas! Thanks for your comments.

Sorry, I meant "Rodrigo", of course.  My brain probably somehow thought
that the plural version of my name was more aesthetically pleasing. :D

--
Cheers,
Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-10  7:26               ` Luca Coelho
@ 2023-10-12 19:58                 ` Rodrigo Vivi
  0 siblings, 0 replies; 25+ messages in thread
From: Rodrigo Vivi @ 2023-10-12 19:58 UTC (permalink / raw)
  To: Luca Coelho
  Cc: Ville Syrjälä,
	Jani Nikula, Lucas De Marchi, Matthew Auld, Matt Roper, intel-xe

On Tue, Oct 10, 2023 at 10:26:30AM +0300, Luca Coelho wrote:
> On Tue, 2023-10-10 at 10:00 +0300, Luca Coelho wrote:
> > On Mon, 2023-10-09 at 17:15 -0400, Rodrigo Vivi wrote:
> > > On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> > > > Any thoughts?
> > > 
> > > Hi Luca, thanks for raising this again here.
> > 
> > Hi Lucas! Thanks for your comments.
> 
> Sorry, I meant "Rodrigo", of course.  My brain probably somehow thought
> that the plural version of my name was more aesthetically pleasing. :D

hehe no worries! I thought it was some "writing accent" that had confused you :)

> 
> --
> Cheers,
> Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-10  7:00             ` Luca Coelho
  2023-10-10  7:26               ` Luca Coelho
@ 2023-10-12 20:04               ` Rodrigo Vivi
  2023-10-16 10:22                 ` Luca Coelho
  1 sibling, 1 reply; 25+ messages in thread
From: Rodrigo Vivi @ 2023-10-12 20:04 UTC (permalink / raw)
  To: Luca Coelho
  Cc: Ville Syrjälä,
	Jani Nikula, Lucas De Marchi, Matthew Auld, Matt Roper, intel-xe

On Tue, Oct 10, 2023 at 10:00:06AM +0300, Luca Coelho wrote:
> On Mon, 2023-10-09 at 17:15 -0400, Rodrigo Vivi wrote:
> > On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> > > Hi everyone,
> > > 
> > > On Tue, 2023-05-23 at 23:52 +0000, Matthew Brost wrote:
> > > > On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> > > > > On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > > > > > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > > > > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > > > > > It is the maximum protection we can do with the current infrastructure.
> > > > > > > > 
> > > > > > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > > > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > ---
> > > > > > > > 
> > > > > > > > 
> > > > > > > > RFC
> > > > > > > > ===
> > > > > > > > 
> > > > > > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > > > > > Xe than anything else.
> > > > > > > > 
> > > > > > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > > > > > 
> > > > > > > > With that approach we had few historical issues iirc:
> > > > > > > > 
> > > > > > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > > > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > > > > > the name suggests).
> > > > > > > 
> > > > > > > In i915 there were more differences between fw and non-fw variants
> > > > > > > of register functions than just forcewake handling:
> > > > > > > 
> > > > > > >  * _fw() functions assumed that the caller was already holding
> > > > > > >    forcewake, whereas the non-fw functions would obtain it themselves
> > > > > > >  * _fw() functions also assumed that the caller was already holding
> > > > > > >    uncore->lock, whereas the non-fw functions would obtain and release
> > > > > > >    the lock around each register access
> > > > > > >  * _fw() functions do no tracing and no debug assertions
> > > > > > >  * _fw() functions do not check for unclaimed MMIO
> > > > > > > 
> > > > > > > I don't think the first bullet there (forcewake) really mattered much
> > > > > > > from a performance perspective.  For display registers, a quick binary
> > > > > > > search of the FW table (just a handful of CPU cycles) would quickly
> > > > > > > determine that no forcewake domains were needed for those register
> > > > > > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > > > > > level at all.  For display registers, the more performance-relevant
> > > > > > > aspects of using the _fw() functions was doing all your register
> > > > > > > accesses together without contention with other MMIO work.  I.e.,
> > > > > > > holding the uncore lock over an entire set of registers rather than
> > > > > > > grabbing/releasing it for each one, and (for vblank evasion
> > > > > > > specifically) doing it all while interrupts were disabled.  For debug
> > > > > > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > > > > > bypassed (e.g., tripling of the number of register accesses due to
> > > > > > > reading FPGA_DBG before/after each register to look for unclaimed
> > > > > > > accesses).
> > > > > > > 
> > > > > > > > 
> > > > > > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > > > > > other times that the spec was updated and we didn't get the notification, and
> > > > > > > > there were cases that the BSpec had bugs.
> > > > > > > > 
> > > > > > > > For these reasons in Xe we have decided to let to the caller the
> > > > > > > > responsibility to set the force_wake bits for their domains before doing
> > > > > > > > the MMIO.
> > > > > > > 
> > > > > > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > > > > > bspec update (or the bspec itself having incorrect information) would
> > > > > > > lead to even more mistakes if the caller has to explicitly grab the
> > > > > > > appropriate domains than if the driver does it implicitly.  The explicit
> > > > > > > handling only helps in the subset of cases where we blindly grab all of
> > > > > > > the domains (as we do during part of init).
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > MMIO access that requires forcewakes really only should be in a few
> > > > > > places, off the top of my head:
> > > > > > 
> > > > > > 1. Init
> > > > > > 2. Reset
> > > > > > 3. Sysfs / Debugfs
> > > > > > 
> > > > > > In all of these cases I think it fine to blindly grab all forcewakes.
> > > > > > 
> > > > > > Please chime in if I'm missing something.
> > > > > 
> > > > > I think as we implement more features in the Xe driver we're going to
> > > > > wind up with a lot more places where we need to access GT registers at
> > > > > runtime.  A few examples off the top of my head:
> > > > > 
> > > > >  * EU stall sampling
> > > > >  * Perf/OA
> > > > >  * EU debugger
> > > > >  * Various OOB workarounds that ask us to twiddle a register at certain
> > > > >    times in the driver.
> > > > 
> > > > Hmm, ok a lot of these I could make the argument that these are not
> > > > normal operation so just grab everything and call it a day. If some of
> > > > these fall into the category of 'normal enough to be optimized' I can
> > > > also make the argument it is no more complex (perhaps less complex) to
> > > > explicitly grab the forcewake than having the logic auto-grab the
> > > > forcewake.
> > > > 
> > > > What a compromise of in a debug mode we auto-generate the asserts based
> > > > on a table but we still explicitly grab the forcewake?
> > > > 
> > > > > 
> > > > > > 
> > > > > > > > 
> > > > > > > > However I'm seeing many questions and doubts popping up:
> > > > > > > > 
> > > > > > > > 1. Are we confident that we are not missing any wake-up?
> > > > > > > > 2. Are we confident that the domains are set correctly?
> > > > > > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > > > > > >    of some specific one?
> > > > > > > 
> > > > > > > I think we're only holding ALL domains during init; for most of the
> > > > > > > runtime MMIO accesses, I think the code is currently attempting to only
> > > > > > > grab the domain(s) that it thinks the registers it's accessing will
> > > > > > > need.  Although that might be working right now, I'm a little bit
> > > > > > > worried about how that will scale in the long term when a single
> > > > > > > register might be in several different domains depending on what
> > > > > > > platform you're running on.  There have definitely been cases in the
> > > > > > > past where groups of registers migrated from RENDER to GT or vice versa
> > > > > > > between platforms, so the exact domain you needed for an operation
> > > > > > > varied by platform.  And things are even more complicated if you're
> > > > > > > doing any MMIO against the media, since the hardware seems to change
> > > > > > > exactly how it splits up the media power wells somewhat often.
> > > > > > > 
> > > > > > > > 4. What about the display disconnection now because i915 and xe have different
> > > > > > > >    mmio approaches but reusing i915-display?
> > > > > > > > 
> > > > > > > > It looks to me that the cons of the current approach are superseding the
> > > > > > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > > > > > we decide which route to take.
> > > > > > > > 
> > > > > > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > > > > > a double approach where the caller is responsible but mmio has the range
> > > > > > > > information and double check it?
> > > > > > > 
> > > > > > > As noted above, part of the challenge with forcewake is that even if the
> > > > > > > caller knows it wants to access register FOO, and even if it know FOO is
> > > > > > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > > > > > make sure it's grabbing the correct domain(s) for every single platform
> > > > > > > the Xe driver will eventually support if the power management handling
> > > > > > > changes.  I think that was part of the motivation for encoding the
> > > > > > > tables into the driver in i915.  It seems like GT power wells don't
> > > > > > > change as much these days as they used to, but it's hard to say whether
> > > > > > > that will continue in the future or not.  Who knows...maybe they'll
> > > > > > > eventually start creating dedicated domains for stuff like blitters,
> > > > > > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > > > > > domain.
> > > > > > > 
> > > > > > > If we do decide to go back to implicit forcewake handling with the table
> > > > > > > encoded into the driver, it might be worth doing something sort of like
> > > > > > 
> > > > > > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > > > > > anything like this in Xe.
> > > > > 
> > > > > When you say unreadable, are you referring to the macros that generate
> > > > > the table lookup functions?  I don't think that macro magic would be
> > > > > needed for Xe since we don't have to support old platforms that have
> > > > > very different forcewake behavior, and we also don't need to generate
> > > > > separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> > > > > (since I think everything in the GT is 32-bits these days).
> > > > > 
> > > > 
> > > > Just the entire file is unreadable in general, trying to avoid these
> > > > types of files in Xe, avoid traps of the i915 did this so let's do it in
> > > > Xe, and over engineering our driver to avoid hypothetical future bugs.
> > > > 
> > > > Matt
> > > > 
> > > > > The forcewake and shadow tables themselves are pretty clean in i915
> > > > > these days, and if we move to autogenerating them from a text file, they
> > > > > can become even simpler since the text file will basically be a cleaned
> > > > > up copy/paste of part of the bspec table.
> > > > > 
> > > > > 
> > > > > Matt
> > > > > 
> > > > > > 
> > > > > > > what Lucas is doing in the OOB workaround series --- drop the
> > > > > > > per-platform tables into a human-readable text file that's more similar
> > > > > > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > > > > > replication type, etc.) and then provide a small parser program that
> > > > > > > will convert that into actual code (and do things like consolidating
> > > > > > > adjacent ranges).
> > > > > > > 
> > > > > > > > 
> > > > > > > > Any other idea? Thoughts?
> > > > > > > 
> > > > > > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > > > > > I plan to follow up with another series that creates a more appropriate
> > > > > > > MMIO target for register operations rather than using "xe_gt" as the
> > > > > > > target (even for things completely unrelated to the small GT subset of
> > > > > > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > > > > > operations against a specific hardware unit, and then the info inside
> > > > > > > the MMIO structure would be able to figure out if there are additional
> > > > > > > checks and/or operations it should perform.  E.g.,
> > > > > > > 
> > > > > > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > > > > > >     - Used to submit MMIO operations against the root tile of the PCI
> > > > > > >       device.  Only used during init (e.g., to read the registers that
> > > > > > >       tell us which tiles exist on the platform) and during top-level
> > > > > > >       interrupt enable/disable (since all interrupts are routed through
> > > > > > >       the root tile).
> > > > > > >     - No forcewake needed for register accesses through a handle of this
> > > > > > >       type since you'd only ever be accessing sgunit registers for these
> > > > > > >       types of things.
> > > > > > >     - Register accesses through mmio can warn on debug builds if the
> > > > > > >       register appears to be in a GT-related MMIO range.
> > > > > > > 
> > > > > > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > > > > > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > > > > > >       but if a handle of this type is used to try to read/write
> > > > > > >       registers outside the display range, we could have debug builds
> > > > > > >       throw some extra warnings.
> > > > > > >     - Unclaimed register detection could be confined to accesses through
> > > > > > >       these handles.
> > > > > > > 
> > > > > > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > > > > > >     - Used to access non-GT registers that reside in a specific tile.
> > > > > > >       I.e., sgunit/soc registers.
> > > > > > >     - As above, no forcewake needed, can make MMIO operations warn
> > > > > > >       if used to access a GT range.
> > > > > > > 
> > > > > > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > > > > > >     - Used to access GT registers in a specific GT
> > > > > > >     - Does automatic GSI offset translation for media GTs
> > > > > > >     - Can either do automatic forcewake like i915 does, or can do debug
> > > > > > >       check+warn like you have here.
> > > > > > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > > > > > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > > > > > >       register is accessed from an MMIO obtained from a media GT.
> > > > > > > 
> > > > > > 
> > > > > > Ack on this if we keep in managable, worried code / feature bloat those
> > > > > > that will result in a similar file to intel_uncore.c in Xe.
> > > 
> > > Just to revive this thread.
> > > 
> > > I've been discussing this proposal in the context of a change we need
> > > to make in the display, which is to introduce a wakelock for some
> > > registers access in order to be able to remove the DMC trap.
> > > 
> > > We came to the conclusion that this new implementation is very much the
> > > same as the forcewake proposal here.  From the display point-of-view,
> > > we could simply have a new domain and range of registers to protect.
> > > 
> > > We _could_ implement a separate "wakelock" mechanism for the display
> > > part, but that would be mostly duplicating the entire forcewake
> > > implementation.
> > > 
> > > So, are there any plans to implement the current proposal? Or any other
> > > plans related to the forcewake implementation for Xe? As I see it, the
> > > "wakelock" implementation in the display depends on this.
> > > 
> > > Any thoughts?
> > 
> > Hi Luca, thanks for raising this again here.
> 
> Hi Lucas! Thanks for your comments.
> 
> 
> > So, as I said in the past, I don't have strong opinions regarding the
> > overall forcewake approach.
> > 
> > The since GT MMIO is not used very frequently, I don't see a problem of
> > leaving that up to the caller to take the right domain when needed, or even
> > the FORCEWAKE_ALL domain. Instead of forcing all the callers to
> > go through this extra steps and then have to opt-out with the '_fw' [sic]
> > alternatives for the cases where the forcewake cannot be checked underneath.
> > 
> > So, for the new display wakelocks, that's the problem of adding them to
> > the drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h where the converions
> > from i915's intel uncore are happening to xe_mmio? So, when using the
> > intel_uncore's '_fw' variant you skip the wakelock and when doing the regular
> > mmio calls you just add a wakelock_get/put around the xe_mmio call with
> > the display domain. And in i915 you implement inside the intel_uncore.
> > 
> > What's the downside of this approach?
> 
> That's more or less what I was thinking.  I don't think there's any
> problem on the display side in calling the same framework.
> 
> 
> > Trying to understand all the pros and cons of different approaches, and
> > bringing some people to the discussion.
> > 
> > If we implement the forwareke underneath the mmio call, display needs
> > to anyway implement it twice on the i915's intel_uncore and on the
> > xe_forcewake, no?!
> 
> Yes, IMHO we should start making Xe the base implementation and
> backporting the new implementation into i915.
> 
> So,for this specific case, I think we can just make i915 call the new
> functions in xe and have them backported in intel_uncore.h for i915.
> 
> What I was thinking was basically this:
> 
> 1. Implement the xe_mmio_for_<hw_unit>() proposal in Xe​

hmm probably a new component then?! xe_display_wakelock that
implements and export the get/put domain in a similar way
of xe_forcewake, and then on the wrapper you add the get/put
around the existing xe_mmio calls?!

> 
> 2. Display code uses new APIs (xe_mmio_for_display ops)​
> 
> 3. Update uncore to handle "wakelock domain"​

then on uncore you would need to parse the mmio range and then
call the get and puts, that in that case would be static inside
the uncore itself like the forcewakes ?!

> 
> 4. Wrappers for i915​, make an xe_mmio_for_display wrapper that calls
> the old functions in uncore and add the necessary locking there.
> 
> In i915 we're most likely not going to need the wakelock stuff for DMC
> trap, because it shouldn't be needed in older hardware anyway.  So the
> backport can remain pretty simple.
> 
> Would this work?
> 
> --
> Cheers,
> Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-12 20:04               ` Rodrigo Vivi
@ 2023-10-16 10:22                 ` Luca Coelho
  2023-10-16 18:09                   ` Rodrigo Vivi
  0 siblings, 1 reply; 25+ messages in thread
From: Luca Coelho @ 2023-10-16 10:22 UTC (permalink / raw)
  To: Rodrigo Vivi
  Cc: Ville Syrjälä,
	Jani Nikula, Lucas De Marchi, Matthew Auld, Matt Roper, intel-xe

On Thu, 2023-10-12 at 16:04 -0400, Rodrigo Vivi wrote:
> On Tue, Oct 10, 2023 at 10:00:06AM +0300, Luca Coelho wrote:
> > On Mon, 2023-10-09 at 17:15 -0400, Rodrigo Vivi wrote:
> > > On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> > > > Hi everyone,
> > > > 
> > > > On Tue, 2023-05-23 at 23:52 +0000, Matthew Brost wrote:
> > > > > On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> > > > > > On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > > > > > > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > > > > > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > > > > > > It is the maximum protection we can do with the current infrastructure.
> > > > > > > > > 
> > > > > > > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > > > > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > ---
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > RFC
> > > > > > > > > ===
> > > > > > > > > 
> > > > > > > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > > > > > > Xe than anything else.
> > > > > > > > > 
> > > > > > > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > > > > > > 
> > > > > > > > > With that approach we had few historical issues iirc:
> > > > > > > > > 
> > > > > > > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > > > > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > > > > > > the name suggests).
> > > > > > > > 
> > > > > > > > In i915 there were more differences between fw and non-fw variants
> > > > > > > > of register functions than just forcewake handling:
> > > > > > > > 
> > > > > > > >  * _fw() functions assumed that the caller was already holding
> > > > > > > >    forcewake, whereas the non-fw functions would obtain it themselves
> > > > > > > >  * _fw() functions also assumed that the caller was already holding
> > > > > > > >    uncore->lock, whereas the non-fw functions would obtain and release
> > > > > > > >    the lock around each register access
> > > > > > > >  * _fw() functions do no tracing and no debug assertions
> > > > > > > >  * _fw() functions do not check for unclaimed MMIO
> > > > > > > > 
> > > > > > > > I don't think the first bullet there (forcewake) really mattered much
> > > > > > > > from a performance perspective.  For display registers, a quick binary
> > > > > > > > search of the FW table (just a handful of CPU cycles) would quickly
> > > > > > > > determine that no forcewake domains were needed for those register
> > > > > > > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > > > > > > level at all.  For display registers, the more performance-relevant
> > > > > > > > aspects of using the _fw() functions was doing all your register
> > > > > > > > accesses together without contention with other MMIO work.  I.e.,
> > > > > > > > holding the uncore lock over an entire set of registers rather than
> > > > > > > > grabbing/releasing it for each one, and (for vblank evasion
> > > > > > > > specifically) doing it all while interrupts were disabled.  For debug
> > > > > > > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > > > > > > bypassed (e.g., tripling of the number of register accesses due to
> > > > > > > > reading FPGA_DBG before/after each register to look for unclaimed
> > > > > > > > accesses).
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > > > > > > other times that the spec was updated and we didn't get the notification, and
> > > > > > > > > there were cases that the BSpec had bugs.
> > > > > > > > > 
> > > > > > > > > For these reasons in Xe we have decided to let to the caller the
> > > > > > > > > responsibility to set the force_wake bits for their domains before doing
> > > > > > > > > the MMIO.
> > > > > > > > 
> > > > > > > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > > > > > > bspec update (or the bspec itself having incorrect information) would
> > > > > > > > lead to even more mistakes if the caller has to explicitly grab the
> > > > > > > > appropriate domains than if the driver does it implicitly.  The explicit
> > > > > > > > handling only helps in the subset of cases where we blindly grab all of
> > > > > > > > the domains (as we do during part of init).
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > MMIO access that requires forcewakes really only should be in a few
> > > > > > > places, off the top of my head:
> > > > > > > 
> > > > > > > 1. Init
> > > > > > > 2. Reset
> > > > > > > 3. Sysfs / Debugfs
> > > > > > > 
> > > > > > > In all of these cases I think it fine to blindly grab all forcewakes.
> > > > > > > 
> > > > > > > Please chime in if I'm missing something.
> > > > > > 
> > > > > > I think as we implement more features in the Xe driver we're going to
> > > > > > wind up with a lot more places where we need to access GT registers at
> > > > > > runtime.  A few examples off the top of my head:
> > > > > > 
> > > > > >  * EU stall sampling
> > > > > >  * Perf/OA
> > > > > >  * EU debugger
> > > > > >  * Various OOB workarounds that ask us to twiddle a register at certain
> > > > > >    times in the driver.
> > > > > 
> > > > > Hmm, ok a lot of these I could make the argument that these are not
> > > > > normal operation so just grab everything and call it a day. If some of
> > > > > these fall into the category of 'normal enough to be optimized' I can
> > > > > also make the argument it is no more complex (perhaps less complex) to
> > > > > explicitly grab the forcewake than having the logic auto-grab the
> > > > > forcewake.
> > > > > 
> > > > > What a compromise of in a debug mode we auto-generate the asserts based
> > > > > on a table but we still explicitly grab the forcewake?
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > > 
> > > > > > > > > However I'm seeing many questions and doubts popping up:
> > > > > > > > > 
> > > > > > > > > 1. Are we confident that we are not missing any wake-up?
> > > > > > > > > 2. Are we confident that the domains are set correctly?
> > > > > > > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > > > > > > >    of some specific one?
> > > > > > > > 
> > > > > > > > I think we're only holding ALL domains during init; for most of the
> > > > > > > > runtime MMIO accesses, I think the code is currently attempting to only
> > > > > > > > grab the domain(s) that it thinks the registers it's accessing will
> > > > > > > > need.  Although that might be working right now, I'm a little bit
> > > > > > > > worried about how that will scale in the long term when a single
> > > > > > > > register might be in several different domains depending on what
> > > > > > > > platform you're running on.  There have definitely been cases in the
> > > > > > > > past where groups of registers migrated from RENDER to GT or vice versa
> > > > > > > > between platforms, so the exact domain you needed for an operation
> > > > > > > > varied by platform.  And things are even more complicated if you're
> > > > > > > > doing any MMIO against the media, since the hardware seems to change
> > > > > > > > exactly how it splits up the media power wells somewhat often.
> > > > > > > > 
> > > > > > > > > 4. What about the display disconnection now because i915 and xe have different
> > > > > > > > >    mmio approaches but reusing i915-display?
> > > > > > > > > 
> > > > > > > > > It looks to me that the cons of the current approach are superseding the
> > > > > > > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > > > > > > we decide which route to take.
> > > > > > > > > 
> > > > > > > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > > > > > > a double approach where the caller is responsible but mmio has the range
> > > > > > > > > information and double check it?
> > > > > > > > 
> > > > > > > > As noted above, part of the challenge with forcewake is that even if the
> > > > > > > > caller knows it wants to access register FOO, and even if it know FOO is
> > > > > > > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > > > > > > make sure it's grabbing the correct domain(s) for every single platform
> > > > > > > > the Xe driver will eventually support if the power management handling
> > > > > > > > changes.  I think that was part of the motivation for encoding the
> > > > > > > > tables into the driver in i915.  It seems like GT power wells don't
> > > > > > > > change as much these days as they used to, but it's hard to say whether
> > > > > > > > that will continue in the future or not.  Who knows...maybe they'll
> > > > > > > > eventually start creating dedicated domains for stuff like blitters,
> > > > > > > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > > > > > > domain.
> > > > > > > > 
> > > > > > > > If we do decide to go back to implicit forcewake handling with the table
> > > > > > > > encoded into the driver, it might be worth doing something sort of like
> > > > > > > 
> > > > > > > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > > > > > > anything like this in Xe.
> > > > > > 
> > > > > > When you say unreadable, are you referring to the macros that generate
> > > > > > the table lookup functions?  I don't think that macro magic would be
> > > > > > needed for Xe since we don't have to support old platforms that have
> > > > > > very different forcewake behavior, and we also don't need to generate
> > > > > > separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> > > > > > (since I think everything in the GT is 32-bits these days).
> > > > > > 
> > > > > 
> > > > > Just the entire file is unreadable in general, trying to avoid these
> > > > > types of files in Xe, avoid traps of the i915 did this so let's do it in
> > > > > Xe, and over engineering our driver to avoid hypothetical future bugs.
> > > > > 
> > > > > Matt
> > > > > 
> > > > > > The forcewake and shadow tables themselves are pretty clean in i915
> > > > > > these days, and if we move to autogenerating them from a text file, they
> > > > > > can become even simpler since the text file will basically be a cleaned
> > > > > > up copy/paste of part of the bspec table.
> > > > > > 
> > > > > > 
> > > > > > Matt
> > > > > > 
> > > > > > > 
> > > > > > > > what Lucas is doing in the OOB workaround series --- drop the
> > > > > > > > per-platform tables into a human-readable text file that's more similar
> > > > > > > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > > > > > > replication type, etc.) and then provide a small parser program that
> > > > > > > > will convert that into actual code (and do things like consolidating
> > > > > > > > adjacent ranges).
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Any other idea? Thoughts?
> > > > > > > > 
> > > > > > > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > > > > > > I plan to follow up with another series that creates a more appropriate
> > > > > > > > MMIO target for register operations rather than using "xe_gt" as the
> > > > > > > > target (even for things completely unrelated to the small GT subset of
> > > > > > > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > > > > > > operations against a specific hardware unit, and then the info inside
> > > > > > > > the MMIO structure would be able to figure out if there are additional
> > > > > > > > checks and/or operations it should perform.  E.g.,
> > > > > > > > 
> > > > > > > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > > > > > > >     - Used to submit MMIO operations against the root tile of the PCI
> > > > > > > >       device.  Only used during init (e.g., to read the registers that
> > > > > > > >       tell us which tiles exist on the platform) and during top-level
> > > > > > > >       interrupt enable/disable (since all interrupts are routed through
> > > > > > > >       the root tile).
> > > > > > > >     - No forcewake needed for register accesses through a handle of this
> > > > > > > >       type since you'd only ever be accessing sgunit registers for these
> > > > > > > >       types of things.
> > > > > > > >     - Register accesses through mmio can warn on debug builds if the
> > > > > > > >       register appears to be in a GT-related MMIO range.
> > > > > > > > 
> > > > > > > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > > > > > > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > > > > > > >       but if a handle of this type is used to try to read/write
> > > > > > > >       registers outside the display range, we could have debug builds
> > > > > > > >       throw some extra warnings.
> > > > > > > >     - Unclaimed register detection could be confined to accesses through
> > > > > > > >       these handles.
> > > > > > > > 
> > > > > > > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > > > > > > >     - Used to access non-GT registers that reside in a specific tile.
> > > > > > > >       I.e., sgunit/soc registers.
> > > > > > > >     - As above, no forcewake needed, can make MMIO operations warn
> > > > > > > >       if used to access a GT range.
> > > > > > > > 
> > > > > > > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > > > > > > >     - Used to access GT registers in a specific GT
> > > > > > > >     - Does automatic GSI offset translation for media GTs
> > > > > > > >     - Can either do automatic forcewake like i915 does, or can do debug
> > > > > > > >       check+warn like you have here.
> > > > > > > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > > > > > > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > > > > > > >       register is accessed from an MMIO obtained from a media GT.
> > > > > > > > 
> > > > > > > 
> > > > > > > Ack on this if we keep in managable, worried code / feature bloat those
> > > > > > > that will result in a similar file to intel_uncore.c in Xe.
> > > > 
> > > > Just to revive this thread.
> > > > 
> > > > I've been discussing this proposal in the context of a change we need
> > > > to make in the display, which is to introduce a wakelock for some
> > > > registers access in order to be able to remove the DMC trap.
> > > > 
> > > > We came to the conclusion that this new implementation is very much the
> > > > same as the forcewake proposal here.  From the display point-of-view,
> > > > we could simply have a new domain and range of registers to protect.
> > > > 
> > > > We _could_ implement a separate "wakelock" mechanism for the display
> > > > part, but that would be mostly duplicating the entire forcewake
> > > > implementation.
> > > > 
> > > > So, are there any plans to implement the current proposal? Or any other
> > > > plans related to the forcewake implementation for Xe? As I see it, the
> > > > "wakelock" implementation in the display depends on this.
> > > > 
> > > > Any thoughts?
> > > 
> > > Hi Luca, thanks for raising this again here.
> > 
> > Hi Lucas! Thanks for your comments.
> > 
> > 
> > > So, as I said in the past, I don't have strong opinions regarding the
> > > overall forcewake approach.
> > > 
> > > The since GT MMIO is not used very frequently, I don't see a problem of
> > > leaving that up to the caller to take the right domain when needed, or even
> > > the FORCEWAKE_ALL domain. Instead of forcing all the callers to
> > > go through this extra steps and then have to opt-out with the '_fw' [sic]
> > > alternatives for the cases where the forcewake cannot be checked underneath.
> > > 
> > > So, for the new display wakelocks, that's the problem of adding them to
> > > the drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h where the converions
> > > from i915's intel uncore are happening to xe_mmio? So, when using the
> > > intel_uncore's '_fw' variant you skip the wakelock and when doing the regular
> > > mmio calls you just add a wakelock_get/put around the xe_mmio call with
> > > the display domain. And in i915 you implement inside the intel_uncore.
> > > 
> > > What's the downside of this approach?
> > 
> > That's more or less what I was thinking.  I don't think there's any
> > problem on the display side in calling the same framework.
> > 
> > 
> > > Trying to understand all the pros and cons of different approaches, and
> > > bringing some people to the discussion.
> > > 
> > > If we implement the forwareke underneath the mmio call, display needs
> > > to anyway implement it twice on the i915's intel_uncore and on the
> > > xe_forcewake, no?!
> > 
> > Yes, IMHO we should start making Xe the base implementation and
> > backporting the new implementation into i915.
> > 
> > So,for this specific case, I think we can just make i915 call the new
> > functions in xe and have them backported in intel_uncore.h for i915.
> > 
> > What I was thinking was basically this:
> > 
> > 1. Implement the xe_mmio_for_<hw_unit>() proposal in Xe​
> 
> hmm probably a new component then?! xe_display_wakelock that
> implements and export the get/put domain in a similar way
> of xe_forcewake, and then on the wrapper you add the get/put
> around the existing xe_mmio calls?!

Yes, I guess a new component, but part of Xe.  I don't exactly know
what you mean with "xe_forcewake", but it's the same as Matt proposed
with the different functions for different domains.  These functions
would do everything that is needed for the specific domain, such as
keeping it awake, checking if the registers are in the right range etc.


> > 2. Display code uses new APIs (xe_mmio_for_display ops)​
> > 
> > 3. Update uncore to handle "wakelock domain"​
> 
> then on uncore you would need to parse the mmio range and then
> call the get and puts, that in that case would be static inside
> the uncore itself like the forcewakes ?!

The callers will use the new Xe APIs, so in i915, the display code (and
probably GT and others too) will be the same as in Xe.  I see it as a
backport.  We can create wrappers that call the uncore APIs to achieve
the same functionality as before.

There are things that we may not need to be backported, for instance,
we don't really need the new wakelock that is needed in LNL (and future
HW), because i915 may not need to support it.  So we can just make a
dummy wrapper for this.  And it should still be easy to properly
backport if needed.

Do you see any problem with this approach?

--
Cheers,
Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-16 10:22                 ` Luca Coelho
@ 2023-10-16 18:09                   ` Rodrigo Vivi
  2023-10-16 19:40                     ` Luca Coelho
  0 siblings, 1 reply; 25+ messages in thread
From: Rodrigo Vivi @ 2023-10-16 18:09 UTC (permalink / raw)
  To: Luca Coelho
  Cc: Ville Syrjälä,
	Jani Nikula, Lucas De Marchi, Matthew Auld, Matt Roper, intel-xe

On Mon, Oct 16, 2023 at 01:22:32PM +0300, Luca Coelho wrote:
> On Thu, 2023-10-12 at 16:04 -0400, Rodrigo Vivi wrote:
> > On Tue, Oct 10, 2023 at 10:00:06AM +0300, Luca Coelho wrote:
> > > On Mon, 2023-10-09 at 17:15 -0400, Rodrigo Vivi wrote:
> > > > On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> > > > > Hi everyone,
> > > > > 
> > > > > On Tue, 2023-05-23 at 23:52 +0000, Matthew Brost wrote:
> > > > > > On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> > > > > > > On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > > > > > > > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > > > > > > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > > > > > > > It is the maximum protection we can do with the current infrastructure.
> > > > > > > > > > 
> > > > > > > > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > > > > > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > > > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > > ---
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > RFC
> > > > > > > > > > ===
> > > > > > > > > > 
> > > > > > > > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > > > > > > > Xe than anything else.
> > > > > > > > > > 
> > > > > > > > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > > > > > > > 
> > > > > > > > > > With that approach we had few historical issues iirc:
> > > > > > > > > > 
> > > > > > > > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > > > > > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > > > > > > > the name suggests).
> > > > > > > > > 
> > > > > > > > > In i915 there were more differences between fw and non-fw variants
> > > > > > > > > of register functions than just forcewake handling:
> > > > > > > > > 
> > > > > > > > >  * _fw() functions assumed that the caller was already holding
> > > > > > > > >    forcewake, whereas the non-fw functions would obtain it themselves
> > > > > > > > >  * _fw() functions also assumed that the caller was already holding
> > > > > > > > >    uncore->lock, whereas the non-fw functions would obtain and release
> > > > > > > > >    the lock around each register access
> > > > > > > > >  * _fw() functions do no tracing and no debug assertions
> > > > > > > > >  * _fw() functions do not check for unclaimed MMIO
> > > > > > > > > 
> > > > > > > > > I don't think the first bullet there (forcewake) really mattered much
> > > > > > > > > from a performance perspective.  For display registers, a quick binary
> > > > > > > > > search of the FW table (just a handful of CPU cycles) would quickly
> > > > > > > > > determine that no forcewake domains were needed for those register
> > > > > > > > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > > > > > > > level at all.  For display registers, the more performance-relevant
> > > > > > > > > aspects of using the _fw() functions was doing all your register
> > > > > > > > > accesses together without contention with other MMIO work.  I.e.,
> > > > > > > > > holding the uncore lock over an entire set of registers rather than
> > > > > > > > > grabbing/releasing it for each one, and (for vblank evasion
> > > > > > > > > specifically) doing it all while interrupts were disabled.  For debug
> > > > > > > > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > > > > > > > bypassed (e.g., tripling of the number of register accesses due to
> > > > > > > > > reading FPGA_DBG before/after each register to look for unclaimed
> > > > > > > > > accesses).
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > > > > > > > other times that the spec was updated and we didn't get the notification, and
> > > > > > > > > > there were cases that the BSpec had bugs.
> > > > > > > > > > 
> > > > > > > > > > For these reasons in Xe we have decided to let to the caller the
> > > > > > > > > > responsibility to set the force_wake bits for their domains before doing
> > > > > > > > > > the MMIO.
> > > > > > > > > 
> > > > > > > > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > > > > > > > bspec update (or the bspec itself having incorrect information) would
> > > > > > > > > lead to even more mistakes if the caller has to explicitly grab the
> > > > > > > > > appropriate domains than if the driver does it implicitly.  The explicit
> > > > > > > > > handling only helps in the subset of cases where we blindly grab all of
> > > > > > > > > the domains (as we do during part of init).
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > MMIO access that requires forcewakes really only should be in a few
> > > > > > > > places, off the top of my head:
> > > > > > > > 
> > > > > > > > 1. Init
> > > > > > > > 2. Reset
> > > > > > > > 3. Sysfs / Debugfs
> > > > > > > > 
> > > > > > > > In all of these cases I think it fine to blindly grab all forcewakes.
> > > > > > > > 
> > > > > > > > Please chime in if I'm missing something.
> > > > > > > 
> > > > > > > I think as we implement more features in the Xe driver we're going to
> > > > > > > wind up with a lot more places where we need to access GT registers at
> > > > > > > runtime.  A few examples off the top of my head:
> > > > > > > 
> > > > > > >  * EU stall sampling
> > > > > > >  * Perf/OA
> > > > > > >  * EU debugger
> > > > > > >  * Various OOB workarounds that ask us to twiddle a register at certain
> > > > > > >    times in the driver.
> > > > > > 
> > > > > > Hmm, ok a lot of these I could make the argument that these are not
> > > > > > normal operation so just grab everything and call it a day. If some of
> > > > > > these fall into the category of 'normal enough to be optimized' I can
> > > > > > also make the argument it is no more complex (perhaps less complex) to
> > > > > > explicitly grab the forcewake than having the logic auto-grab the
> > > > > > forcewake.
> > > > > > 
> > > > > > What a compromise of in a debug mode we auto-generate the asserts based
> > > > > > on a table but we still explicitly grab the forcewake?
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > However I'm seeing many questions and doubts popping up:
> > > > > > > > > > 
> > > > > > > > > > 1. Are we confident that we are not missing any wake-up?
> > > > > > > > > > 2. Are we confident that the domains are set correctly?
> > > > > > > > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > > > > > > > >    of some specific one?
> > > > > > > > > 
> > > > > > > > > I think we're only holding ALL domains during init; for most of the
> > > > > > > > > runtime MMIO accesses, I think the code is currently attempting to only
> > > > > > > > > grab the domain(s) that it thinks the registers it's accessing will
> > > > > > > > > need.  Although that might be working right now, I'm a little bit
> > > > > > > > > worried about how that will scale in the long term when a single
> > > > > > > > > register might be in several different domains depending on what
> > > > > > > > > platform you're running on.  There have definitely been cases in the
> > > > > > > > > past where groups of registers migrated from RENDER to GT or vice versa
> > > > > > > > > between platforms, so the exact domain you needed for an operation
> > > > > > > > > varied by platform.  And things are even more complicated if you're
> > > > > > > > > doing any MMIO against the media, since the hardware seems to change
> > > > > > > > > exactly how it splits up the media power wells somewhat often.
> > > > > > > > > 
> > > > > > > > > > 4. What about the display disconnection now because i915 and xe have different
> > > > > > > > > >    mmio approaches but reusing i915-display?
> > > > > > > > > > 
> > > > > > > > > > It looks to me that the cons of the current approach are superseding the
> > > > > > > > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > > > > > > > we decide which route to take.
> > > > > > > > > > 
> > > > > > > > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > > > > > > > a double approach where the caller is responsible but mmio has the range
> > > > > > > > > > information and double check it?
> > > > > > > > > 
> > > > > > > > > As noted above, part of the challenge with forcewake is that even if the
> > > > > > > > > caller knows it wants to access register FOO, and even if it know FOO is
> > > > > > > > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > > > > > > > make sure it's grabbing the correct domain(s) for every single platform
> > > > > > > > > the Xe driver will eventually support if the power management handling
> > > > > > > > > changes.  I think that was part of the motivation for encoding the
> > > > > > > > > tables into the driver in i915.  It seems like GT power wells don't
> > > > > > > > > change as much these days as they used to, but it's hard to say whether
> > > > > > > > > that will continue in the future or not.  Who knows...maybe they'll
> > > > > > > > > eventually start creating dedicated domains for stuff like blitters,
> > > > > > > > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > > > > > > > domain.
> > > > > > > > > 
> > > > > > > > > If we do decide to go back to implicit forcewake handling with the table
> > > > > > > > > encoded into the driver, it might be worth doing something sort of like
> > > > > > > > 
> > > > > > > > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > > > > > > > anything like this in Xe.
> > > > > > > 
> > > > > > > When you say unreadable, are you referring to the macros that generate
> > > > > > > the table lookup functions?  I don't think that macro magic would be
> > > > > > > needed for Xe since we don't have to support old platforms that have
> > > > > > > very different forcewake behavior, and we also don't need to generate
> > > > > > > separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> > > > > > > (since I think everything in the GT is 32-bits these days).
> > > > > > > 
> > > > > > 
> > > > > > Just the entire file is unreadable in general, trying to avoid these
> > > > > > types of files in Xe, avoid traps of the i915 did this so let's do it in
> > > > > > Xe, and over engineering our driver to avoid hypothetical future bugs.
> > > > > > 
> > > > > > Matt
> > > > > > 
> > > > > > > The forcewake and shadow tables themselves are pretty clean in i915
> > > > > > > these days, and if we move to autogenerating them from a text file, they
> > > > > > > can become even simpler since the text file will basically be a cleaned
> > > > > > > up copy/paste of part of the bspec table.
> > > > > > > 
> > > > > > > 
> > > > > > > Matt
> > > > > > > 
> > > > > > > > 
> > > > > > > > > what Lucas is doing in the OOB workaround series --- drop the
> > > > > > > > > per-platform tables into a human-readable text file that's more similar
> > > > > > > > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > > > > > > > replication type, etc.) and then provide a small parser program that
> > > > > > > > > will convert that into actual code (and do things like consolidating
> > > > > > > > > adjacent ranges).
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Any other idea? Thoughts?
> > > > > > > > > 
> > > > > > > > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > > > > > > > I plan to follow up with another series that creates a more appropriate
> > > > > > > > > MMIO target for register operations rather than using "xe_gt" as the
> > > > > > > > > target (even for things completely unrelated to the small GT subset of
> > > > > > > > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > > > > > > > operations against a specific hardware unit, and then the info inside
> > > > > > > > > the MMIO structure would be able to figure out if there are additional
> > > > > > > > > checks and/or operations it should perform.  E.g.,
> > > > > > > > > 
> > > > > > > > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > > > > > > > >     - Used to submit MMIO operations against the root tile of the PCI
> > > > > > > > >       device.  Only used during init (e.g., to read the registers that
> > > > > > > > >       tell us which tiles exist on the platform) and during top-level
> > > > > > > > >       interrupt enable/disable (since all interrupts are routed through
> > > > > > > > >       the root tile).
> > > > > > > > >     - No forcewake needed for register accesses through a handle of this
> > > > > > > > >       type since you'd only ever be accessing sgunit registers for these
> > > > > > > > >       types of things.
> > > > > > > > >     - Register accesses through mmio can warn on debug builds if the
> > > > > > > > >       register appears to be in a GT-related MMIO range.
> > > > > > > > > 
> > > > > > > > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > > > > > > > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > > > > > > > >       but if a handle of this type is used to try to read/write
> > > > > > > > >       registers outside the display range, we could have debug builds
> > > > > > > > >       throw some extra warnings.
> > > > > > > > >     - Unclaimed register detection could be confined to accesses through
> > > > > > > > >       these handles.
> > > > > > > > > 
> > > > > > > > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > > > > > > > >     - Used to access non-GT registers that reside in a specific tile.
> > > > > > > > >       I.e., sgunit/soc registers.
> > > > > > > > >     - As above, no forcewake needed, can make MMIO operations warn
> > > > > > > > >       if used to access a GT range.
> > > > > > > > > 
> > > > > > > > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > > > > > > > >     - Used to access GT registers in a specific GT
> > > > > > > > >     - Does automatic GSI offset translation for media GTs
> > > > > > > > >     - Can either do automatic forcewake like i915 does, or can do debug
> > > > > > > > >       check+warn like you have here.
> > > > > > > > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > > > > > > > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > > > > > > > >       register is accessed from an MMIO obtained from a media GT.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Ack on this if we keep in managable, worried code / feature bloat those
> > > > > > > > that will result in a similar file to intel_uncore.c in Xe.
> > > > > 
> > > > > Just to revive this thread.
> > > > > 
> > > > > I've been discussing this proposal in the context of a change we need
> > > > > to make in the display, which is to introduce a wakelock for some
> > > > > registers access in order to be able to remove the DMC trap.
> > > > > 
> > > > > We came to the conclusion that this new implementation is very much the
> > > > > same as the forcewake proposal here.  From the display point-of-view,
> > > > > we could simply have a new domain and range of registers to protect.
> > > > > 
> > > > > We _could_ implement a separate "wakelock" mechanism for the display
> > > > > part, but that would be mostly duplicating the entire forcewake
> > > > > implementation.
> > > > > 
> > > > > So, are there any plans to implement the current proposal? Or any other
> > > > > plans related to the forcewake implementation for Xe? As I see it, the
> > > > > "wakelock" implementation in the display depends on this.
> > > > > 
> > > > > Any thoughts?
> > > > 
> > > > Hi Luca, thanks for raising this again here.
> > > 
> > > Hi Lucas! Thanks for your comments.
> > > 
> > > 
> > > > So, as I said in the past, I don't have strong opinions regarding the
> > > > overall forcewake approach.
> > > > 
> > > > The since GT MMIO is not used very frequently, I don't see a problem of
> > > > leaving that up to the caller to take the right domain when needed, or even
> > > > the FORCEWAKE_ALL domain. Instead of forcing all the callers to
> > > > go through this extra steps and then have to opt-out with the '_fw' [sic]
> > > > alternatives for the cases where the forcewake cannot be checked underneath.
> > > > 
> > > > So, for the new display wakelocks, that's the problem of adding them to
> > > > the drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h where the converions
> > > > from i915's intel uncore are happening to xe_mmio? So, when using the
> > > > intel_uncore's '_fw' variant you skip the wakelock and when doing the regular
> > > > mmio calls you just add a wakelock_get/put around the xe_mmio call with
> > > > the display domain. And in i915 you implement inside the intel_uncore.
> > > > 
> > > > What's the downside of this approach?
> > > 
> > > That's more or less what I was thinking.  I don't think there's any
> > > problem on the display side in calling the same framework.
> > > 
> > > 
> > > > Trying to understand all the pros and cons of different approaches, and
> > > > bringing some people to the discussion.
> > > > 
> > > > If we implement the forwareke underneath the mmio call, display needs
> > > > to anyway implement it twice on the i915's intel_uncore and on the
> > > > xe_forcewake, no?!
> > > 
> > > Yes, IMHO we should start making Xe the base implementation and
> > > backporting the new implementation into i915.
> > > 
> > > So,for this specific case, I think we can just make i915 call the new
> > > functions in xe and have them backported in intel_uncore.h for i915.
> > > 
> > > What I was thinking was basically this:
> > > 
> > > 1. Implement the xe_mmio_for_<hw_unit>() proposal in Xe​
> > 
> > hmm probably a new component then?! xe_display_wakelock that
> > implements and export the get/put domain in a similar way
> > of xe_forcewake, and then on the wrapper you add the get/put
> > around the existing xe_mmio calls?!
> 
> Yes, I guess a new component, but part of Xe.  I don't exactly know
> what you mean with "xe_forcewake", but it's the same as Matt proposed
> with the different functions for different domains.  These functions
> would do everything that is needed for the specific domain, such as
> keeping it awake, checking if the registers are in the right range etc.
> 
> 
> > > 2. Display code uses new APIs (xe_mmio_for_display ops)​
> > > 
> > > 3. Update uncore to handle "wakelock domain"​
> > 
> > then on uncore you would need to parse the mmio range and then
> > call the get and puts, that in that case would be static inside
> > the uncore itself like the forcewakes ?!
> 
> The callers will use the new Xe APIs, so in i915, the display code (and
> probably GT and others too) will be the same as in Xe. 

I confess a got a bit lost now. What's GT need here? Does GT need this
new wakelock or is it a display only thing?

if it is a display only thing, we have a new xe_display_wakelock component.
The mmio wrappers that translate intel_de mmio calls to xe_mmio would make
usage of the xe_display_wakelock functions. And no body else. no need to
disrupt the working GT code.

But maybe I'm completely misunderstanding what the wakelock is about.

>  I see it as a
> backport.  We can create wrappers that call the uncore APIs to achieve
> the same functionality as before.
> 
> There are things that we may not need to be backported, for instance,
> we don't really need the new wakelock that is needed in LNL (and future
> HW), because i915 may not need to support it.  So we can just make a
> dummy wrapper for this.  And it should still be easy to properly
> backport if needed.
> 
> Do you see any problem with this approach?
> 
> --
> Cheers,
> Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-16 18:09                   ` Rodrigo Vivi
@ 2023-10-16 19:40                     ` Luca Coelho
  2023-10-16 20:08                       ` Rodrigo Vivi
  0 siblings, 1 reply; 25+ messages in thread
From: Luca Coelho @ 2023-10-16 19:40 UTC (permalink / raw)
  To: Rodrigo Vivi
  Cc: Ville Syrjälä,
	Jani Nikula, Lucas De Marchi, Matthew Auld, Matt Roper, intel-xe

On Mon, 2023-10-16 at 14:09 -0400, Rodrigo Vivi wrote:
> On Mon, Oct 16, 2023 at 01:22:32PM +0300, Luca Coelho wrote:
> > On Thu, 2023-10-12 at 16:04 -0400, Rodrigo Vivi wrote:
> > > On Tue, Oct 10, 2023 at 10:00:06AM +0300, Luca Coelho wrote:
> > > > On Mon, 2023-10-09 at 17:15 -0400, Rodrigo Vivi wrote:
> > > > > On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> > > > > > Hi everyone,
> > > > > > 
> > > > > > On Tue, 2023-05-23 at 23:52 +0000, Matthew Brost wrote:
> > > > > > > On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> > > > > > > > On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > > > > > > > > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > > > > > > > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > > > > > > > > It is the maximum protection we can do with the current infrastructure.
> > > > > > > > > > > 
> > > > > > > > > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > > > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > > > > > > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > > > > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > > > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > > > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > > > ---
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > RFC
> > > > > > > > > > > ===
> > > > > > > > > > > 
> > > > > > > > > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > > > > > > > > Xe than anything else.
> > > > > > > > > > > 
> > > > > > > > > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > > > > > > > > 
> > > > > > > > > > > With that approach we had few historical issues iirc:
> > > > > > > > > > > 
> > > > > > > > > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > > > > > > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > > > > > > > > the name suggests).
> > > > > > > > > > 
> > > > > > > > > > In i915 there were more differences between fw and non-fw variants
> > > > > > > > > > of register functions than just forcewake handling:
> > > > > > > > > > 
> > > > > > > > > >  * _fw() functions assumed that the caller was already holding
> > > > > > > > > >    forcewake, whereas the non-fw functions would obtain it themselves
> > > > > > > > > >  * _fw() functions also assumed that the caller was already holding
> > > > > > > > > >    uncore->lock, whereas the non-fw functions would obtain and release
> > > > > > > > > >    the lock around each register access
> > > > > > > > > >  * _fw() functions do no tracing and no debug assertions
> > > > > > > > > >  * _fw() functions do not check for unclaimed MMIO
> > > > > > > > > > 
> > > > > > > > > > I don't think the first bullet there (forcewake) really mattered much
> > > > > > > > > > from a performance perspective.  For display registers, a quick binary
> > > > > > > > > > search of the FW table (just a handful of CPU cycles) would quickly
> > > > > > > > > > determine that no forcewake domains were needed for those register
> > > > > > > > > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > > > > > > > > level at all.  For display registers, the more performance-relevant
> > > > > > > > > > aspects of using the _fw() functions was doing all your register
> > > > > > > > > > accesses together without contention with other MMIO work.  I.e.,
> > > > > > > > > > holding the uncore lock over an entire set of registers rather than
> > > > > > > > > > grabbing/releasing it for each one, and (for vblank evasion
> > > > > > > > > > specifically) doing it all while interrupts were disabled.  For debug
> > > > > > > > > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > > > > > > > > bypassed (e.g., tripling of the number of register accesses due to
> > > > > > > > > > reading FPGA_DBG before/after each register to look for unclaimed
> > > > > > > > > > accesses).
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > > > > > > > > other times that the spec was updated and we didn't get the notification, and
> > > > > > > > > > > there were cases that the BSpec had bugs.
> > > > > > > > > > > 
> > > > > > > > > > > For these reasons in Xe we have decided to let to the caller the
> > > > > > > > > > > responsibility to set the force_wake bits for their domains before doing
> > > > > > > > > > > the MMIO.
> > > > > > > > > > 
> > > > > > > > > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > > > > > > > > bspec update (or the bspec itself having incorrect information) would
> > > > > > > > > > lead to even more mistakes if the caller has to explicitly grab the
> > > > > > > > > > appropriate domains than if the driver does it implicitly.  The explicit
> > > > > > > > > > handling only helps in the subset of cases where we blindly grab all of
> > > > > > > > > > the domains (as we do during part of init).
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > MMIO access that requires forcewakes really only should be in a few
> > > > > > > > > places, off the top of my head:
> > > > > > > > > 
> > > > > > > > > 1. Init
> > > > > > > > > 2. Reset
> > > > > > > > > 3. Sysfs / Debugfs
> > > > > > > > > 
> > > > > > > > > In all of these cases I think it fine to blindly grab all forcewakes.
> > > > > > > > > 
> > > > > > > > > Please chime in if I'm missing something.
> > > > > > > > 
> > > > > > > > I think as we implement more features in the Xe driver we're going to
> > > > > > > > wind up with a lot more places where we need to access GT registers at
> > > > > > > > runtime.  A few examples off the top of my head:
> > > > > > > > 
> > > > > > > >  * EU stall sampling
> > > > > > > >  * Perf/OA
> > > > > > > >  * EU debugger
> > > > > > > >  * Various OOB workarounds that ask us to twiddle a register at certain
> > > > > > > >    times in the driver.
> > > > > > > 
> > > > > > > Hmm, ok a lot of these I could make the argument that these are not
> > > > > > > normal operation so just grab everything and call it a day. If some of
> > > > > > > these fall into the category of 'normal enough to be optimized' I can
> > > > > > > also make the argument it is no more complex (perhaps less complex) to
> > > > > > > explicitly grab the forcewake than having the logic auto-grab the
> > > > > > > forcewake.
> > > > > > > 
> > > > > > > What a compromise of in a debug mode we auto-generate the asserts based
> > > > > > > on a table but we still explicitly grab the forcewake?
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > However I'm seeing many questions and doubts popping up:
> > > > > > > > > > > 
> > > > > > > > > > > 1. Are we confident that we are not missing any wake-up?
> > > > > > > > > > > 2. Are we confident that the domains are set correctly?
> > > > > > > > > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > > > > > > > > >    of some specific one?
> > > > > > > > > > 
> > > > > > > > > > I think we're only holding ALL domains during init; for most of the
> > > > > > > > > > runtime MMIO accesses, I think the code is currently attempting to only
> > > > > > > > > > grab the domain(s) that it thinks the registers it's accessing will
> > > > > > > > > > need.  Although that might be working right now, I'm a little bit
> > > > > > > > > > worried about how that will scale in the long term when a single
> > > > > > > > > > register might be in several different domains depending on what
> > > > > > > > > > platform you're running on.  There have definitely been cases in the
> > > > > > > > > > past where groups of registers migrated from RENDER to GT or vice versa
> > > > > > > > > > between platforms, so the exact domain you needed for an operation
> > > > > > > > > > varied by platform.  And things are even more complicated if you're
> > > > > > > > > > doing any MMIO against the media, since the hardware seems to change
> > > > > > > > > > exactly how it splits up the media power wells somewhat often.
> > > > > > > > > > 
> > > > > > > > > > > 4. What about the display disconnection now because i915 and xe have different
> > > > > > > > > > >    mmio approaches but reusing i915-display?
> > > > > > > > > > > 
> > > > > > > > > > > It looks to me that the cons of the current approach are superseding the
> > > > > > > > > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > > > > > > > > we decide which route to take.
> > > > > > > > > > > 
> > > > > > > > > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > > > > > > > > a double approach where the caller is responsible but mmio has the range
> > > > > > > > > > > information and double check it?
> > > > > > > > > > 
> > > > > > > > > > As noted above, part of the challenge with forcewake is that even if the
> > > > > > > > > > caller knows it wants to access register FOO, and even if it know FOO is
> > > > > > > > > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > > > > > > > > make sure it's grabbing the correct domain(s) for every single platform
> > > > > > > > > > the Xe driver will eventually support if the power management handling
> > > > > > > > > > changes.  I think that was part of the motivation for encoding the
> > > > > > > > > > tables into the driver in i915.  It seems like GT power wells don't
> > > > > > > > > > change as much these days as they used to, but it's hard to say whether
> > > > > > > > > > that will continue in the future or not.  Who knows...maybe they'll
> > > > > > > > > > eventually start creating dedicated domains for stuff like blitters,
> > > > > > > > > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > > > > > > > > domain.
> > > > > > > > > > 
> > > > > > > > > > If we do decide to go back to implicit forcewake handling with the table
> > > > > > > > > > encoded into the driver, it might be worth doing something sort of like
> > > > > > > > > 
> > > > > > > > > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > > > > > > > > anything like this in Xe.
> > > > > > > > 
> > > > > > > > When you say unreadable, are you referring to the macros that generate
> > > > > > > > the table lookup functions?  I don't think that macro magic would be
> > > > > > > > needed for Xe since we don't have to support old platforms that have
> > > > > > > > very different forcewake behavior, and we also don't need to generate
> > > > > > > > separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> > > > > > > > (since I think everything in the GT is 32-bits these days).
> > > > > > > > 
> > > > > > > 
> > > > > > > Just the entire file is unreadable in general, trying to avoid these
> > > > > > > types of files in Xe, avoid traps of the i915 did this so let's do it in
> > > > > > > Xe, and over engineering our driver to avoid hypothetical future bugs.
> > > > > > > 
> > > > > > > Matt
> > > > > > > 
> > > > > > > > The forcewake and shadow tables themselves are pretty clean in i915
> > > > > > > > these days, and if we move to autogenerating them from a text file, they
> > > > > > > > can become even simpler since the text file will basically be a cleaned
> > > > > > > > up copy/paste of part of the bspec table.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Matt
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > what Lucas is doing in the OOB workaround series --- drop the
> > > > > > > > > > per-platform tables into a human-readable text file that's more similar
> > > > > > > > > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > > > > > > > > replication type, etc.) and then provide a small parser program that
> > > > > > > > > > will convert that into actual code (and do things like consolidating
> > > > > > > > > > adjacent ranges).
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Any other idea? Thoughts?
> > > > > > > > > > 
> > > > > > > > > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > > > > > > > > I plan to follow up with another series that creates a more appropriate
> > > > > > > > > > MMIO target for register operations rather than using "xe_gt" as the
> > > > > > > > > > target (even for things completely unrelated to the small GT subset of
> > > > > > > > > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > > > > > > > > operations against a specific hardware unit, and then the info inside
> > > > > > > > > > the MMIO structure would be able to figure out if there are additional
> > > > > > > > > > checks and/or operations it should perform.  E.g.,
> > > > > > > > > > 
> > > > > > > > > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > > > > > > > > >     - Used to submit MMIO operations against the root tile of the PCI
> > > > > > > > > >       device.  Only used during init (e.g., to read the registers that
> > > > > > > > > >       tell us which tiles exist on the platform) and during top-level
> > > > > > > > > >       interrupt enable/disable (since all interrupts are routed through
> > > > > > > > > >       the root tile).
> > > > > > > > > >     - No forcewake needed for register accesses through a handle of this
> > > > > > > > > >       type since you'd only ever be accessing sgunit registers for these
> > > > > > > > > >       types of things.
> > > > > > > > > >     - Register accesses through mmio can warn on debug builds if the
> > > > > > > > > >       register appears to be in a GT-related MMIO range.
> > > > > > > > > > 
> > > > > > > > > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > > > > > > > > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > > > > > > > > >       but if a handle of this type is used to try to read/write
> > > > > > > > > >       registers outside the display range, we could have debug builds
> > > > > > > > > >       throw some extra warnings.
> > > > > > > > > >     - Unclaimed register detection could be confined to accesses through
> > > > > > > > > >       these handles.
> > > > > > > > > > 
> > > > > > > > > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > > > > > > > > >     - Used to access non-GT registers that reside in a specific tile.
> > > > > > > > > >       I.e., sgunit/soc registers.
> > > > > > > > > >     - As above, no forcewake needed, can make MMIO operations warn
> > > > > > > > > >       if used to access a GT range.
> > > > > > > > > > 
> > > > > > > > > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > > > > > > > > >     - Used to access GT registers in a specific GT
> > > > > > > > > >     - Does automatic GSI offset translation for media GTs
> > > > > > > > > >     - Can either do automatic forcewake like i915 does, or can do debug
> > > > > > > > > >       check+warn like you have here.
> > > > > > > > > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > > > > > > > > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > > > > > > > > >       register is accessed from an MMIO obtained from a media GT.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Ack on this if we keep in managable, worried code / feature bloat those
> > > > > > > > > that will result in a similar file to intel_uncore.c in Xe.
> > > > > > 
> > > > > > Just to revive this thread.
> > > > > > 
> > > > > > I've been discussing this proposal in the context of a change we need
> > > > > > to make in the display, which is to introduce a wakelock for some
> > > > > > registers access in order to be able to remove the DMC trap.
> > > > > > 
> > > > > > We came to the conclusion that this new implementation is very much the
> > > > > > same as the forcewake proposal here.  From the display point-of-view,
> > > > > > we could simply have a new domain and range of registers to protect.
> > > > > > 
> > > > > > We _could_ implement a separate "wakelock" mechanism for the display
> > > > > > part, but that would be mostly duplicating the entire forcewake
> > > > > > implementation.
> > > > > > 
> > > > > > So, are there any plans to implement the current proposal? Or any other
> > > > > > plans related to the forcewake implementation for Xe? As I see it, the
> > > > > > "wakelock" implementation in the display depends on this.
> > > > > > 
> > > > > > Any thoughts?
> > > > > 
> > > > > Hi Luca, thanks for raising this again here.
> > > > 
> > > > Hi Lucas! Thanks for your comments.
> > > > 
> > > > 
> > > > > So, as I said in the past, I don't have strong opinions regarding the
> > > > > overall forcewake approach.
> > > > > 
> > > > > The since GT MMIO is not used very frequently, I don't see a problem of
> > > > > leaving that up to the caller to take the right domain when needed, or even
> > > > > the FORCEWAKE_ALL domain. Instead of forcing all the callers to
> > > > > go through this extra steps and then have to opt-out with the '_fw' [sic]
> > > > > alternatives for the cases where the forcewake cannot be checked underneath.
> > > > > 
> > > > > So, for the new display wakelocks, that's the problem of adding them to
> > > > > the drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h where the converions
> > > > > from i915's intel uncore are happening to xe_mmio? So, when using the
> > > > > intel_uncore's '_fw' variant you skip the wakelock and when doing the regular
> > > > > mmio calls you just add a wakelock_get/put around the xe_mmio call with
> > > > > the display domain. And in i915 you implement inside the intel_uncore.
> > > > > 
> > > > > What's the downside of this approach?
> > > > 
> > > > That's more or less what I was thinking.  I don't think there's any
> > > > problem on the display side in calling the same framework.
> > > > 
> > > > 
> > > > > Trying to understand all the pros and cons of different approaches, and
> > > > > bringing some people to the discussion.
> > > > > 
> > > > > If we implement the forwareke underneath the mmio call, display needs
> > > > > to anyway implement it twice on the i915's intel_uncore and on the
> > > > > xe_forcewake, no?!
> > > > 
> > > > Yes, IMHO we should start making Xe the base implementation and
> > > > backporting the new implementation into i915.
> > > > 
> > > > So,for this specific case, I think we can just make i915 call the new
> > > > functions in xe and have them backported in intel_uncore.h for i915.
> > > > 
> > > > What I was thinking was basically this:
> > > > 
> > > > 1. Implement the xe_mmio_for_<hw_unit>() proposal in Xe​
> > > 
> > > hmm probably a new component then?! xe_display_wakelock that
> > > implements and export the get/put domain in a similar way
> > > of xe_forcewake, and then on the wrapper you add the get/put
> > > around the existing xe_mmio calls?!
> > 
> > Yes, I guess a new component, but part of Xe.  I don't exactly know
> > what you mean with "xe_forcewake", but it's the same as Matt proposed
> > with the different functions for different domains.  These functions
> > would do everything that is needed for the specific domain, such as
> > keeping it awake, checking if the registers are in the right range etc.
> > 
> > 
> > > > 2. Display code uses new APIs (xe_mmio_for_display ops)​
> > > > 
> > > > 3. Update uncore to handle "wakelock domain"​
> > > 
> > > then on uncore you would need to parse the mmio range and then
> > > call the get and puts, that in that case would be static inside
> > > the uncore itself like the forcewakes ?!
> > 
> > The callers will use the new Xe APIs, so in i915, the display code (and
> > probably GT and others too) will be the same as in Xe. 
> 
> I confess a got a bit lost now. What's GT need here? Does GT need this
> new wakelock or is it a display only thing?
> 
> if it is a display only thing, we have a new xe_display_wakelock component.
> The mmio wrappers that translate intel_de mmio calls to xe_mmio would make
> usage of the xe_display_wakelock functions. And no body else. no need to
> disrupt the working GT code.
> 
> But maybe I'm completely misunderstanding what the wakelock is about.

Sorry if I was not clear.

First of all, I don't think the new "wakelock" mechanism is any
different than the forcewake implementation we need in Xe (which we
have in uncore for i915).  AFAIU, we don't have this forcewake
implementation in Xe yet (which was the original discussion in this
thread), right?

So, my proposal is that we should implement the forcewake stuff in Xe
as Matt proposed, with the different APIs for different components
(e.g. xe_mmio_for_display()).  When this is done, we can add a new
"domain" (or maybe even reuse the xe_mmio_for_display() one) for the
new ranges that need a "wakelock" (which IMHO is the same as the
existing forcewake mechanisms).  If we do this, the implementation in
Xe is solved.

But, of course, we need to make sure that the display code will remain
the same in i915.  To do so, I'm proposing that we make the display
code use the new xe_forcewake APIs, even though they won't exist in
i915.  So, for i915, we provide wrappers for these new APIs so we can
convert the calls into calls to uncore.  So functionally, the display
code in i915 will remain the same.  We don't need to implement the
"wakelock" part for i915, but we convert i915 to use the new
xe_forcewake APIs where it currently uses the uncore's version.

We won't disrupt the existing GT forcewake usage in i915.  That will
remain the same.  But we will need to implement forcewake in Xe, which
GT will use.  But the GT from Xe is not shared with i915, so no need to
create wrappers for that.

Makes sense?

--
Cheers,
Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-16 19:40                     ` Luca Coelho
@ 2023-10-16 20:08                       ` Rodrigo Vivi
  2023-10-16 21:33                         ` Luca Coelho
  0 siblings, 1 reply; 25+ messages in thread
From: Rodrigo Vivi @ 2023-10-16 20:08 UTC (permalink / raw)
  To: Luca Coelho
  Cc: Ville Syrjälä,
	Jani Nikula, Lucas De Marchi, Matthew Auld, Matt Roper, intel-xe

On Mon, Oct 16, 2023 at 10:40:12PM +0300, Luca Coelho wrote:
> On Mon, 2023-10-16 at 14:09 -0400, Rodrigo Vivi wrote:
> > On Mon, Oct 16, 2023 at 01:22:32PM +0300, Luca Coelho wrote:
> > > On Thu, 2023-10-12 at 16:04 -0400, Rodrigo Vivi wrote:
> > > > On Tue, Oct 10, 2023 at 10:00:06AM +0300, Luca Coelho wrote:
> > > > > On Mon, 2023-10-09 at 17:15 -0400, Rodrigo Vivi wrote:
> > > > > > On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> > > > > > > Hi everyone,
> > > > > > > 
> > > > > > > On Tue, 2023-05-23 at 23:52 +0000, Matthew Brost wrote:
> > > > > > > > On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> > > > > > > > > On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > > > > > > > > > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > > > > > > > > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > > > > > > > > > It is the maximum protection we can do with the current infrastructure.
> > > > > > > > > > > > 
> > > > > > > > > > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > > > > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > > > > > > > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > > > > > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > > > > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > > > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > > > > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > > > > ---
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > RFC
> > > > > > > > > > > > ===
> > > > > > > > > > > > 
> > > > > > > > > > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > > > > > > > > > Xe than anything else.
> > > > > > > > > > > > 
> > > > > > > > > > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > > > > > > > > > 
> > > > > > > > > > > > With that approach we had few historical issues iirc:
> > > > > > > > > > > > 
> > > > > > > > > > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > > > > > > > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > > > > > > > > > the name suggests).
> > > > > > > > > > > 
> > > > > > > > > > > In i915 there were more differences between fw and non-fw variants
> > > > > > > > > > > of register functions than just forcewake handling:
> > > > > > > > > > > 
> > > > > > > > > > >  * _fw() functions assumed that the caller was already holding
> > > > > > > > > > >    forcewake, whereas the non-fw functions would obtain it themselves
> > > > > > > > > > >  * _fw() functions also assumed that the caller was already holding
> > > > > > > > > > >    uncore->lock, whereas the non-fw functions would obtain and release
> > > > > > > > > > >    the lock around each register access
> > > > > > > > > > >  * _fw() functions do no tracing and no debug assertions
> > > > > > > > > > >  * _fw() functions do not check for unclaimed MMIO
> > > > > > > > > > > 
> > > > > > > > > > > I don't think the first bullet there (forcewake) really mattered much
> > > > > > > > > > > from a performance perspective.  For display registers, a quick binary
> > > > > > > > > > > search of the FW table (just a handful of CPU cycles) would quickly
> > > > > > > > > > > determine that no forcewake domains were needed for those register
> > > > > > > > > > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > > > > > > > > > level at all.  For display registers, the more performance-relevant
> > > > > > > > > > > aspects of using the _fw() functions was doing all your register
> > > > > > > > > > > accesses together without contention with other MMIO work.  I.e.,
> > > > > > > > > > > holding the uncore lock over an entire set of registers rather than
> > > > > > > > > > > grabbing/releasing it for each one, and (for vblank evasion
> > > > > > > > > > > specifically) doing it all while interrupts were disabled.  For debug
> > > > > > > > > > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > > > > > > > > > bypassed (e.g., tripling of the number of register accesses due to
> > > > > > > > > > > reading FPGA_DBG before/after each register to look for unclaimed
> > > > > > > > > > > accesses).
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > > > > > > > > > other times that the spec was updated and we didn't get the notification, and
> > > > > > > > > > > > there were cases that the BSpec had bugs.
> > > > > > > > > > > > 
> > > > > > > > > > > > For these reasons in Xe we have decided to let to the caller the
> > > > > > > > > > > > responsibility to set the force_wake bits for their domains before doing
> > > > > > > > > > > > the MMIO.
> > > > > > > > > > > 
> > > > > > > > > > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > > > > > > > > > bspec update (or the bspec itself having incorrect information) would
> > > > > > > > > > > lead to even more mistakes if the caller has to explicitly grab the
> > > > > > > > > > > appropriate domains than if the driver does it implicitly.  The explicit
> > > > > > > > > > > handling only helps in the subset of cases where we blindly grab all of
> > > > > > > > > > > the domains (as we do during part of init).
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > MMIO access that requires forcewakes really only should be in a few
> > > > > > > > > > places, off the top of my head:
> > > > > > > > > > 
> > > > > > > > > > 1. Init
> > > > > > > > > > 2. Reset
> > > > > > > > > > 3. Sysfs / Debugfs
> > > > > > > > > > 
> > > > > > > > > > In all of these cases I think it fine to blindly grab all forcewakes.
> > > > > > > > > > 
> > > > > > > > > > Please chime in if I'm missing something.
> > > > > > > > > 
> > > > > > > > > I think as we implement more features in the Xe driver we're going to
> > > > > > > > > wind up with a lot more places where we need to access GT registers at
> > > > > > > > > runtime.  A few examples off the top of my head:
> > > > > > > > > 
> > > > > > > > >  * EU stall sampling
> > > > > > > > >  * Perf/OA
> > > > > > > > >  * EU debugger
> > > > > > > > >  * Various OOB workarounds that ask us to twiddle a register at certain
> > > > > > > > >    times in the driver.
> > > > > > > > 
> > > > > > > > Hmm, ok a lot of these I could make the argument that these are not
> > > > > > > > normal operation so just grab everything and call it a day. If some of
> > > > > > > > these fall into the category of 'normal enough to be optimized' I can
> > > > > > > > also make the argument it is no more complex (perhaps less complex) to
> > > > > > > > explicitly grab the forcewake than having the logic auto-grab the
> > > > > > > > forcewake.
> > > > > > > > 
> > > > > > > > What a compromise of in a debug mode we auto-generate the asserts based
> > > > > > > > on a table but we still explicitly grab the forcewake?
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > However I'm seeing many questions and doubts popping up:
> > > > > > > > > > > > 
> > > > > > > > > > > > 1. Are we confident that we are not missing any wake-up?
> > > > > > > > > > > > 2. Are we confident that the domains are set correctly?
> > > > > > > > > > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > > > > > > > > > >    of some specific one?
> > > > > > > > > > > 
> > > > > > > > > > > I think we're only holding ALL domains during init; for most of the
> > > > > > > > > > > runtime MMIO accesses, I think the code is currently attempting to only
> > > > > > > > > > > grab the domain(s) that it thinks the registers it's accessing will
> > > > > > > > > > > need.  Although that might be working right now, I'm a little bit
> > > > > > > > > > > worried about how that will scale in the long term when a single
> > > > > > > > > > > register might be in several different domains depending on what
> > > > > > > > > > > platform you're running on.  There have definitely been cases in the
> > > > > > > > > > > past where groups of registers migrated from RENDER to GT or vice versa
> > > > > > > > > > > between platforms, so the exact domain you needed for an operation
> > > > > > > > > > > varied by platform.  And things are even more complicated if you're
> > > > > > > > > > > doing any MMIO against the media, since the hardware seems to change
> > > > > > > > > > > exactly how it splits up the media power wells somewhat often.
> > > > > > > > > > > 
> > > > > > > > > > > > 4. What about the display disconnection now because i915 and xe have different
> > > > > > > > > > > >    mmio approaches but reusing i915-display?
> > > > > > > > > > > > 
> > > > > > > > > > > > It looks to me that the cons of the current approach are superseding the
> > > > > > > > > > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > > > > > > > > > we decide which route to take.
> > > > > > > > > > > > 
> > > > > > > > > > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > > > > > > > > > a double approach where the caller is responsible but mmio has the range
> > > > > > > > > > > > information and double check it?
> > > > > > > > > > > 
> > > > > > > > > > > As noted above, part of the challenge with forcewake is that even if the
> > > > > > > > > > > caller knows it wants to access register FOO, and even if it know FOO is
> > > > > > > > > > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > > > > > > > > > make sure it's grabbing the correct domain(s) for every single platform
> > > > > > > > > > > the Xe driver will eventually support if the power management handling
> > > > > > > > > > > changes.  I think that was part of the motivation for encoding the
> > > > > > > > > > > tables into the driver in i915.  It seems like GT power wells don't
> > > > > > > > > > > change as much these days as they used to, but it's hard to say whether
> > > > > > > > > > > that will continue in the future or not.  Who knows...maybe they'll
> > > > > > > > > > > eventually start creating dedicated domains for stuff like blitters,
> > > > > > > > > > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > > > > > > > > > domain.
> > > > > > > > > > > 
> > > > > > > > > > > If we do decide to go back to implicit forcewake handling with the table
> > > > > > > > > > > encoded into the driver, it might be worth doing something sort of like
> > > > > > > > > > 
> > > > > > > > > > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > > > > > > > > > anything like this in Xe.
> > > > > > > > > 
> > > > > > > > > When you say unreadable, are you referring to the macros that generate
> > > > > > > > > the table lookup functions?  I don't think that macro magic would be
> > > > > > > > > needed for Xe since we don't have to support old platforms that have
> > > > > > > > > very different forcewake behavior, and we also don't need to generate
> > > > > > > > > separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> > > > > > > > > (since I think everything in the GT is 32-bits these days).
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Just the entire file is unreadable in general, trying to avoid these
> > > > > > > > types of files in Xe, avoid traps of the i915 did this so let's do it in
> > > > > > > > Xe, and over engineering our driver to avoid hypothetical future bugs.
> > > > > > > > 
> > > > > > > > Matt
> > > > > > > > 
> > > > > > > > > The forcewake and shadow tables themselves are pretty clean in i915
> > > > > > > > > these days, and if we move to autogenerating them from a text file, they
> > > > > > > > > can become even simpler since the text file will basically be a cleaned
> > > > > > > > > up copy/paste of part of the bspec table.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Matt
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > what Lucas is doing in the OOB workaround series --- drop the
> > > > > > > > > > > per-platform tables into a human-readable text file that's more similar
> > > > > > > > > > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > > > > > > > > > replication type, etc.) and then provide a small parser program that
> > > > > > > > > > > will convert that into actual code (and do things like consolidating
> > > > > > > > > > > adjacent ranges).
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Any other idea? Thoughts?
> > > > > > > > > > > 
> > > > > > > > > > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > > > > > > > > > I plan to follow up with another series that creates a more appropriate
> > > > > > > > > > > MMIO target for register operations rather than using "xe_gt" as the
> > > > > > > > > > > target (even for things completely unrelated to the small GT subset of
> > > > > > > > > > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > > > > > > > > > operations against a specific hardware unit, and then the info inside
> > > > > > > > > > > the MMIO structure would be able to figure out if there are additional
> > > > > > > > > > > checks and/or operations it should perform.  E.g.,
> > > > > > > > > > > 
> > > > > > > > > > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > > > > > > > > > >     - Used to submit MMIO operations against the root tile of the PCI
> > > > > > > > > > >       device.  Only used during init (e.g., to read the registers that
> > > > > > > > > > >       tell us which tiles exist on the platform) and during top-level
> > > > > > > > > > >       interrupt enable/disable (since all interrupts are routed through
> > > > > > > > > > >       the root tile).
> > > > > > > > > > >     - No forcewake needed for register accesses through a handle of this
> > > > > > > > > > >       type since you'd only ever be accessing sgunit registers for these
> > > > > > > > > > >       types of things.
> > > > > > > > > > >     - Register accesses through mmio can warn on debug builds if the
> > > > > > > > > > >       register appears to be in a GT-related MMIO range.
> > > > > > > > > > > 
> > > > > > > > > > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > > > > > > > > > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > > > > > > > > > >       but if a handle of this type is used to try to read/write
> > > > > > > > > > >       registers outside the display range, we could have debug builds
> > > > > > > > > > >       throw some extra warnings.
> > > > > > > > > > >     - Unclaimed register detection could be confined to accesses through
> > > > > > > > > > >       these handles.
> > > > > > > > > > > 
> > > > > > > > > > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > > > > > > > > > >     - Used to access non-GT registers that reside in a specific tile.
> > > > > > > > > > >       I.e., sgunit/soc registers.
> > > > > > > > > > >     - As above, no forcewake needed, can make MMIO operations warn
> > > > > > > > > > >       if used to access a GT range.
> > > > > > > > > > > 
> > > > > > > > > > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > > > > > > > > > >     - Used to access GT registers in a specific GT
> > > > > > > > > > >     - Does automatic GSI offset translation for media GTs
> > > > > > > > > > >     - Can either do automatic forcewake like i915 does, or can do debug
> > > > > > > > > > >       check+warn like you have here.
> > > > > > > > > > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > > > > > > > > > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > > > > > > > > > >       register is accessed from an MMIO obtained from a media GT.
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Ack on this if we keep in managable, worried code / feature bloat those
> > > > > > > > > > that will result in a similar file to intel_uncore.c in Xe.
> > > > > > > 
> > > > > > > Just to revive this thread.
> > > > > > > 
> > > > > > > I've been discussing this proposal in the context of a change we need
> > > > > > > to make in the display, which is to introduce a wakelock for some
> > > > > > > registers access in order to be able to remove the DMC trap.
> > > > > > > 
> > > > > > > We came to the conclusion that this new implementation is very much the
> > > > > > > same as the forcewake proposal here.  From the display point-of-view,
> > > > > > > we could simply have a new domain and range of registers to protect.
> > > > > > > 
> > > > > > > We _could_ implement a separate "wakelock" mechanism for the display
> > > > > > > part, but that would be mostly duplicating the entire forcewake
> > > > > > > implementation.
> > > > > > > 
> > > > > > > So, are there any plans to implement the current proposal? Or any other
> > > > > > > plans related to the forcewake implementation for Xe? As I see it, the
> > > > > > > "wakelock" implementation in the display depends on this.
> > > > > > > 
> > > > > > > Any thoughts?
> > > > > > 
> > > > > > Hi Luca, thanks for raising this again here.
> > > > > 
> > > > > Hi Lucas! Thanks for your comments.
> > > > > 
> > > > > 
> > > > > > So, as I said in the past, I don't have strong opinions regarding the
> > > > > > overall forcewake approach.
> > > > > > 
> > > > > > The since GT MMIO is not used very frequently, I don't see a problem of
> > > > > > leaving that up to the caller to take the right domain when needed, or even
> > > > > > the FORCEWAKE_ALL domain. Instead of forcing all the callers to
> > > > > > go through this extra steps and then have to opt-out with the '_fw' [sic]
> > > > > > alternatives for the cases where the forcewake cannot be checked underneath.
> > > > > > 
> > > > > > So, for the new display wakelocks, that's the problem of adding them to
> > > > > > the drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h where the converions
> > > > > > from i915's intel uncore are happening to xe_mmio? So, when using the
> > > > > > intel_uncore's '_fw' variant you skip the wakelock and when doing the regular
> > > > > > mmio calls you just add a wakelock_get/put around the xe_mmio call with
> > > > > > the display domain. And in i915 you implement inside the intel_uncore.
> > > > > > 
> > > > > > What's the downside of this approach?
> > > > > 
> > > > > That's more or less what I was thinking.  I don't think there's any
> > > > > problem on the display side in calling the same framework.
> > > > > 
> > > > > 
> > > > > > Trying to understand all the pros and cons of different approaches, and
> > > > > > bringing some people to the discussion.
> > > > > > 
> > > > > > If we implement the forwareke underneath the mmio call, display needs
> > > > > > to anyway implement it twice on the i915's intel_uncore and on the
> > > > > > xe_forcewake, no?!
> > > > > 
> > > > > Yes, IMHO we should start making Xe the base implementation and
> > > > > backporting the new implementation into i915.
> > > > > 
> > > > > So,for this specific case, I think we can just make i915 call the new
> > > > > functions in xe and have them backported in intel_uncore.h for i915.
> > > > > 
> > > > > What I was thinking was basically this:
> > > > > 
> > > > > 1. Implement the xe_mmio_for_<hw_unit>() proposal in Xe​
> > > > 
> > > > hmm probably a new component then?! xe_display_wakelock that
> > > > implements and export the get/put domain in a similar way
> > > > of xe_forcewake, and then on the wrapper you add the get/put
> > > > around the existing xe_mmio calls?!
> > > 
> > > Yes, I guess a new component, but part of Xe.  I don't exactly know
> > > what you mean with "xe_forcewake", but it's the same as Matt proposed
> > > with the different functions for different domains.  These functions
> > > would do everything that is needed for the specific domain, such as
> > > keeping it awake, checking if the registers are in the right range etc.
> > > 
> > > 
> > > > > 2. Display code uses new APIs (xe_mmio_for_display ops)​
> > > > > 
> > > > > 3. Update uncore to handle "wakelock domain"​
> > > > 
> > > > then on uncore you would need to parse the mmio range and then
> > > > call the get and puts, that in that case would be static inside
> > > > the uncore itself like the forcewakes ?!
> > > 
> > > The callers will use the new Xe APIs, so in i915, the display code (and
> > > probably GT and others too) will be the same as in Xe. 
> > 
> > I confess a got a bit lost now. What's GT need here? Does GT need this
> > new wakelock or is it a display only thing?
> > 
> > if it is a display only thing, we have a new xe_display_wakelock component.
> > The mmio wrappers that translate intel_de mmio calls to xe_mmio would make
> > usage of the xe_display_wakelock functions. And no body else. no need to
> > disrupt the working GT code.
> > 
> > But maybe I'm completely misunderstanding what the wakelock is about.
> 
> Sorry if I was not clear.
> 
> First of all, I don't think the new "wakelock" mechanism is any
> different than the forcewake implementation we need in Xe (which we
> have in uncore for i915).  AFAIU, we don't have this forcewake
> implementation in Xe yet (which was the original discussion in this
> thread), right?

wrong. we have xe_forcewake. But it is up to the caller of the xe_mmio
to decide if it needs to forcewake certain domain or not.

What we don't have is the xe_mmio calling the xe_forcewake based on
some pre defined mmio range, like i915 does.

What is this wakelock about? is it only a new display range of forcewake
with a new display domain? or is it a new sequence of display mmios
that needs to be executed before and after display mmio calls?

or even before and after gt mmio calls besides the forcewake domains?

> 
> So, my proposal is that we should implement the forcewake stuff in Xe
> as Matt proposed, with the different APIs for different components
> (e.g. xe_mmio_for_display()).  When this is done, we can add a new
> "domain" (or maybe even reuse the xe_mmio_for_display() one) for the
> new ranges that need a "wakelock" (which IMHO is the same as the
> existing forcewake mechanisms).  If we do this, the implementation in
> Xe is solved.

I really believe the wakelock should be totally orthogonal to Matt's
proposal on the mmio split for device vs tile vs gt...
To me, mmio_display is mmio_device anyway...

We already have a wrapper for translating intel_de calls to xe_mmio,
why that cannot be used to implement this display wakelock sequences
anyway and regarless?

> 
> But, of course, we need to make sure that the display code will remain
> the same in i915.  To do so, I'm proposing that we make the display
> code use the new xe_forcewake APIs, even though they won't exist in
> i915.  So, for i915, we provide wrappers for these new APIs so we can
> convert the calls into calls to uncore.  So functionally, the display
> code in i915 will remain the same.  We don't need to implement the
> "wakelock" part for i915, but we convert i915 to use the new
> xe_forcewake APIs where it currently uses the uncore's version.

i915-display should only call intel_de functions this should be a wrapper
to i915's intel_uncore or xe's xe_mmio... maybe intel_de itself is the
right place to implement this display wakelock?

But i915 should never call xe functions directly.

> 
> We won't disrupt the existing GT forcewake usage in i915.  That will
> remain the same.  But we will need to implement forcewake in Xe, which
> GT will use.  But the GT from Xe is not shared with i915, so no need to
> create wrappers for that.

The big question that nobody could ever answer yet, is why do we need
the intrinsic forcewake underneath xe_mmio, that is not already covered
by the xe_forcewake call by the xe_mmio callers?

Looking to the '_fw' variantes of the i915, we see that there are many
cases out there that we don't want the intrinsic forcewake and then
we had to create this bypass option, which name is extremely confusing.
Opposite of what it currently does and means.

GT MMIO operations are very limited to small usage during init, reset
and resume. And the underneath range seems like an overkill and historically
brought us many trouble.

Again, I could be easily pursued to the opposite direction of the intrinsic
forcewake, but so far with the current arguments that we have at the table
I prefer to stick with the caller's responsibility on the forcewake.

If this 'wakelock' is something new that is bigger than display and that
maybe justifies the intrinsic forcewake, then we probably need more
information and details on the wakelock.

But if it is a display only thing as it looks like, I don't see why it
couldn't simply live in the inte_de wrapper that calls xe_mmio...

> 
> Makes sense?
> 
> --
> Cheers,
> Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-16 20:08                       ` Rodrigo Vivi
@ 2023-10-16 21:33                         ` Luca Coelho
  2023-10-16 22:10                           ` Rodrigo Vivi
  0 siblings, 1 reply; 25+ messages in thread
From: Luca Coelho @ 2023-10-16 21:33 UTC (permalink / raw)
  To: Rodrigo Vivi
  Cc: Ville Syrjälä,
	Jani Nikula, Lucas De Marchi, Matthew Auld, Matt Roper, intel-xe

On Mon, 2023-10-16 at 16:08 -0400, Rodrigo Vivi wrote:
> On Mon, Oct 16, 2023 at 10:40:12PM +0300, Luca Coelho wrote:
> > On Mon, 2023-10-16 at 14:09 -0400, Rodrigo Vivi wrote:
> > > On Mon, Oct 16, 2023 at 01:22:32PM +0300, Luca Coelho wrote:
> > > > On Thu, 2023-10-12 at 16:04 -0400, Rodrigo Vivi wrote:
> > > > > On Tue, Oct 10, 2023 at 10:00:06AM +0300, Luca Coelho wrote:
> > > > > > On Mon, 2023-10-09 at 17:15 -0400, Rodrigo Vivi wrote:
> > > > > > > On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> > > > > > > > Hi everyone,
> > > > > > > > 
> > > > > > > > On Tue, 2023-05-23 at 23:52 +0000, Matthew Brost wrote:
> > > > > > > > > On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> > > > > > > > > > On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > > > > > > > > > > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > > > > > > > > > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > > > > > > > > > > It is the maximum protection we can do with the current infrastructure.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > > > > > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > > > > > > > > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > > > > > > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > > > > > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > > > > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > > > > > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > RFC
> > > > > > > > > > > > > ===
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > > > > > > > > > > Xe than anything else.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > With that approach we had few historical issues iirc:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > > > > > > > > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > > > > > > > > > > the name suggests).
> > > > > > > > > > > > 
> > > > > > > > > > > > In i915 there were more differences between fw and non-fw variants
> > > > > > > > > > > > of register functions than just forcewake handling:
> > > > > > > > > > > > 
> > > > > > > > > > > >  * _fw() functions assumed that the caller was already holding
> > > > > > > > > > > >    forcewake, whereas the non-fw functions would obtain it themselves
> > > > > > > > > > > >  * _fw() functions also assumed that the caller was already holding
> > > > > > > > > > > >    uncore->lock, whereas the non-fw functions would obtain and release
> > > > > > > > > > > >    the lock around each register access
> > > > > > > > > > > >  * _fw() functions do no tracing and no debug assertions
> > > > > > > > > > > >  * _fw() functions do not check for unclaimed MMIO
> > > > > > > > > > > > 
> > > > > > > > > > > > I don't think the first bullet there (forcewake) really mattered much
> > > > > > > > > > > > from a performance perspective.  For display registers, a quick binary
> > > > > > > > > > > > search of the FW table (just a handful of CPU cycles) would quickly
> > > > > > > > > > > > determine that no forcewake domains were needed for those register
> > > > > > > > > > > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > > > > > > > > > > level at all.  For display registers, the more performance-relevant
> > > > > > > > > > > > aspects of using the _fw() functions was doing all your register
> > > > > > > > > > > > accesses together without contention with other MMIO work.  I.e.,
> > > > > > > > > > > > holding the uncore lock over an entire set of registers rather than
> > > > > > > > > > > > grabbing/releasing it for each one, and (for vblank evasion
> > > > > > > > > > > > specifically) doing it all while interrupts were disabled.  For debug
> > > > > > > > > > > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > > > > > > > > > > bypassed (e.g., tripling of the number of register accesses due to
> > > > > > > > > > > > reading FPGA_DBG before/after each register to look for unclaimed
> > > > > > > > > > > > accesses).
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > > > > > > > > > > other times that the spec was updated and we didn't get the notification, and
> > > > > > > > > > > > > there were cases that the BSpec had bugs.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > For these reasons in Xe we have decided to let to the caller the
> > > > > > > > > > > > > responsibility to set the force_wake bits for their domains before doing
> > > > > > > > > > > > > the MMIO.
> > > > > > > > > > > > 
> > > > > > > > > > > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > > > > > > > > > > bspec update (or the bspec itself having incorrect information) would
> > > > > > > > > > > > lead to even more mistakes if the caller has to explicitly grab the
> > > > > > > > > > > > appropriate domains than if the driver does it implicitly.  The explicit
> > > > > > > > > > > > handling only helps in the subset of cases where we blindly grab all of
> > > > > > > > > > > > the domains (as we do during part of init).
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > MMIO access that requires forcewakes really only should be in a few
> > > > > > > > > > > places, off the top of my head:
> > > > > > > > > > > 
> > > > > > > > > > > 1. Init
> > > > > > > > > > > 2. Reset
> > > > > > > > > > > 3. Sysfs / Debugfs
> > > > > > > > > > > 
> > > > > > > > > > > In all of these cases I think it fine to blindly grab all forcewakes.
> > > > > > > > > > > 
> > > > > > > > > > > Please chime in if I'm missing something.
> > > > > > > > > > 
> > > > > > > > > > I think as we implement more features in the Xe driver we're going to
> > > > > > > > > > wind up with a lot more places where we need to access GT registers at
> > > > > > > > > > runtime.  A few examples off the top of my head:
> > > > > > > > > > 
> > > > > > > > > >  * EU stall sampling
> > > > > > > > > >  * Perf/OA
> > > > > > > > > >  * EU debugger
> > > > > > > > > >  * Various OOB workarounds that ask us to twiddle a register at certain
> > > > > > > > > >    times in the driver.
> > > > > > > > > 
> > > > > > > > > Hmm, ok a lot of these I could make the argument that these are not
> > > > > > > > > normal operation so just grab everything and call it a day. If some of
> > > > > > > > > these fall into the category of 'normal enough to be optimized' I can
> > > > > > > > > also make the argument it is no more complex (perhaps less complex) to
> > > > > > > > > explicitly grab the forcewake than having the logic auto-grab the
> > > > > > > > > forcewake.
> > > > > > > > > 
> > > > > > > > > What a compromise of in a debug mode we auto-generate the asserts based
> > > > > > > > > on a table but we still explicitly grab the forcewake?
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > However I'm seeing many questions and doubts popping up:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 1. Are we confident that we are not missing any wake-up?
> > > > > > > > > > > > > 2. Are we confident that the domains are set correctly?
> > > > > > > > > > > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > > > > > > > > > > >    of some specific one?
> > > > > > > > > > > > 
> > > > > > > > > > > > I think we're only holding ALL domains during init; for most of the
> > > > > > > > > > > > runtime MMIO accesses, I think the code is currently attempting to only
> > > > > > > > > > > > grab the domain(s) that it thinks the registers it's accessing will
> > > > > > > > > > > > need.  Although that might be working right now, I'm a little bit
> > > > > > > > > > > > worried about how that will scale in the long term when a single
> > > > > > > > > > > > register might be in several different domains depending on what
> > > > > > > > > > > > platform you're running on.  There have definitely been cases in the
> > > > > > > > > > > > past where groups of registers migrated from RENDER to GT or vice versa
> > > > > > > > > > > > between platforms, so the exact domain you needed for an operation
> > > > > > > > > > > > varied by platform.  And things are even more complicated if you're
> > > > > > > > > > > > doing any MMIO against the media, since the hardware seems to change
> > > > > > > > > > > > exactly how it splits up the media power wells somewhat often.
> > > > > > > > > > > > 
> > > > > > > > > > > > > 4. What about the display disconnection now because i915 and xe have different
> > > > > > > > > > > > >    mmio approaches but reusing i915-display?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > It looks to me that the cons of the current approach are superseding the
> > > > > > > > > > > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > > > > > > > > > > we decide which route to take.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > > > > > > > > > > a double approach where the caller is responsible but mmio has the range
> > > > > > > > > > > > > information and double check it?
> > > > > > > > > > > > 
> > > > > > > > > > > > As noted above, part of the challenge with forcewake is that even if the
> > > > > > > > > > > > caller knows it wants to access register FOO, and even if it know FOO is
> > > > > > > > > > > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > > > > > > > > > > make sure it's grabbing the correct domain(s) for every single platform
> > > > > > > > > > > > the Xe driver will eventually support if the power management handling
> > > > > > > > > > > > changes.  I think that was part of the motivation for encoding the
> > > > > > > > > > > > tables into the driver in i915.  It seems like GT power wells don't
> > > > > > > > > > > > change as much these days as they used to, but it's hard to say whether
> > > > > > > > > > > > that will continue in the future or not.  Who knows...maybe they'll
> > > > > > > > > > > > eventually start creating dedicated domains for stuff like blitters,
> > > > > > > > > > > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > > > > > > > > > > domain.
> > > > > > > > > > > > 
> > > > > > > > > > > > If we do decide to go back to implicit forcewake handling with the table
> > > > > > > > > > > > encoded into the driver, it might be worth doing something sort of like
> > > > > > > > > > > 
> > > > > > > > > > > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > > > > > > > > > > anything like this in Xe.
> > > > > > > > > > 
> > > > > > > > > > When you say unreadable, are you referring to the macros that generate
> > > > > > > > > > the table lookup functions?  I don't think that macro magic would be
> > > > > > > > > > needed for Xe since we don't have to support old platforms that have
> > > > > > > > > > very different forcewake behavior, and we also don't need to generate
> > > > > > > > > > separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> > > > > > > > > > (since I think everything in the GT is 32-bits these days).
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Just the entire file is unreadable in general, trying to avoid these
> > > > > > > > > types of files in Xe, avoid traps of the i915 did this so let's do it in
> > > > > > > > > Xe, and over engineering our driver to avoid hypothetical future bugs.
> > > > > > > > > 
> > > > > > > > > Matt
> > > > > > > > > 
> > > > > > > > > > The forcewake and shadow tables themselves are pretty clean in i915
> > > > > > > > > > these days, and if we move to autogenerating them from a text file, they
> > > > > > > > > > can become even simpler since the text file will basically be a cleaned
> > > > > > > > > > up copy/paste of part of the bspec table.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Matt
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > what Lucas is doing in the OOB workaround series --- drop the
> > > > > > > > > > > > per-platform tables into a human-readable text file that's more similar
> > > > > > > > > > > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > > > > > > > > > > replication type, etc.) and then provide a small parser program that
> > > > > > > > > > > > will convert that into actual code (and do things like consolidating
> > > > > > > > > > > > adjacent ranges).
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Any other idea? Thoughts?
> > > > > > > > > > > > 
> > > > > > > > > > > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > > > > > > > > > > I plan to follow up with another series that creates a more appropriate
> > > > > > > > > > > > MMIO target for register operations rather than using "xe_gt" as the
> > > > > > > > > > > > target (even for things completely unrelated to the small GT subset of
> > > > > > > > > > > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > > > > > > > > > > operations against a specific hardware unit, and then the info inside
> > > > > > > > > > > > the MMIO structure would be able to figure out if there are additional
> > > > > > > > > > > > checks and/or operations it should perform.  E.g.,
> > > > > > > > > > > > 
> > > > > > > > > > > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > > > > > > > > > > >     - Used to submit MMIO operations against the root tile of the PCI
> > > > > > > > > > > >       device.  Only used during init (e.g., to read the registers that
> > > > > > > > > > > >       tell us which tiles exist on the platform) and during top-level
> > > > > > > > > > > >       interrupt enable/disable (since all interrupts are routed through
> > > > > > > > > > > >       the root tile).
> > > > > > > > > > > >     - No forcewake needed for register accesses through a handle of this
> > > > > > > > > > > >       type since you'd only ever be accessing sgunit registers for these
> > > > > > > > > > > >       types of things.
> > > > > > > > > > > >     - Register accesses through mmio can warn on debug builds if the
> > > > > > > > > > > >       register appears to be in a GT-related MMIO range.
> > > > > > > > > > > > 
> > > > > > > > > > > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > > > > > > > > > > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > > > > > > > > > > >       but if a handle of this type is used to try to read/write
> > > > > > > > > > > >       registers outside the display range, we could have debug builds
> > > > > > > > > > > >       throw some extra warnings.
> > > > > > > > > > > >     - Unclaimed register detection could be confined to accesses through
> > > > > > > > > > > >       these handles.
> > > > > > > > > > > > 
> > > > > > > > > > > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > > > > > > > > > > >     - Used to access non-GT registers that reside in a specific tile.
> > > > > > > > > > > >       I.e., sgunit/soc registers.
> > > > > > > > > > > >     - As above, no forcewake needed, can make MMIO operations warn
> > > > > > > > > > > >       if used to access a GT range.
> > > > > > > > > > > > 
> > > > > > > > > > > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > > > > > > > > > > >     - Used to access GT registers in a specific GT
> > > > > > > > > > > >     - Does automatic GSI offset translation for media GTs
> > > > > > > > > > > >     - Can either do automatic forcewake like i915 does, or can do debug
> > > > > > > > > > > >       check+warn like you have here.
> > > > > > > > > > > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > > > > > > > > > > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > > > > > > > > > > >       register is accessed from an MMIO obtained from a media GT.
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Ack on this if we keep in managable, worried code / feature bloat those
> > > > > > > > > > > that will result in a similar file to intel_uncore.c in Xe.
> > > > > > > > 
> > > > > > > > Just to revive this thread.
> > > > > > > > 
> > > > > > > > I've been discussing this proposal in the context of a change we need
> > > > > > > > to make in the display, which is to introduce a wakelock for some
> > > > > > > > registers access in order to be able to remove the DMC trap.
> > > > > > > > 
> > > > > > > > We came to the conclusion that this new implementation is very much the
> > > > > > > > same as the forcewake proposal here.  From the display point-of-view,
> > > > > > > > we could simply have a new domain and range of registers to protect.
> > > > > > > > 
> > > > > > > > We _could_ implement a separate "wakelock" mechanism for the display
> > > > > > > > part, but that would be mostly duplicating the entire forcewake
> > > > > > > > implementation.
> > > > > > > > 
> > > > > > > > So, are there any plans to implement the current proposal? Or any other
> > > > > > > > plans related to the forcewake implementation for Xe? As I see it, the
> > > > > > > > "wakelock" implementation in the display depends on this.
> > > > > > > > 
> > > > > > > > Any thoughts?
> > > > > > > 
> > > > > > > Hi Luca, thanks for raising this again here.
> > > > > > 
> > > > > > Hi Lucas! Thanks for your comments.
> > > > > > 
> > > > > > 
> > > > > > > So, as I said in the past, I don't have strong opinions regarding the
> > > > > > > overall forcewake approach.
> > > > > > > 
> > > > > > > The since GT MMIO is not used very frequently, I don't see a problem of
> > > > > > > leaving that up to the caller to take the right domain when needed, or even
> > > > > > > the FORCEWAKE_ALL domain. Instead of forcing all the callers to
> > > > > > > go through this extra steps and then have to opt-out with the '_fw' [sic]
> > > > > > > alternatives for the cases where the forcewake cannot be checked underneath.
> > > > > > > 
> > > > > > > So, for the new display wakelocks, that's the problem of adding them to
> > > > > > > the drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h where the converions
> > > > > > > from i915's intel uncore are happening to xe_mmio? So, when using the
> > > > > > > intel_uncore's '_fw' variant you skip the wakelock and when doing the regular
> > > > > > > mmio calls you just add a wakelock_get/put around the xe_mmio call with
> > > > > > > the display domain. And in i915 you implement inside the intel_uncore.
> > > > > > > 
> > > > > > > What's the downside of this approach?
> > > > > > 
> > > > > > That's more or less what I was thinking.  I don't think there's any
> > > > > > problem on the display side in calling the same framework.
> > > > > > 
> > > > > > 
> > > > > > > Trying to understand all the pros and cons of different approaches, and
> > > > > > > bringing some people to the discussion.
> > > > > > > 
> > > > > > > If we implement the forwareke underneath the mmio call, display needs
> > > > > > > to anyway implement it twice on the i915's intel_uncore and on the
> > > > > > > xe_forcewake, no?!
> > > > > > 
> > > > > > Yes, IMHO we should start making Xe the base implementation and
> > > > > > backporting the new implementation into i915.
> > > > > > 
> > > > > > So,for this specific case, I think we can just make i915 call the new
> > > > > > functions in xe and have them backported in intel_uncore.h for i915.
> > > > > > 
> > > > > > What I was thinking was basically this:
> > > > > > 
> > > > > > 1. Implement the xe_mmio_for_<hw_unit>() proposal in Xe​
> > > > > 
> > > > > hmm probably a new component then?! xe_display_wakelock that
> > > > > implements and export the get/put domain in a similar way
> > > > > of xe_forcewake, and then on the wrapper you add the get/put
> > > > > around the existing xe_mmio calls?!
> > > > 
> > > > Yes, I guess a new component, but part of Xe.  I don't exactly know
> > > > what you mean with "xe_forcewake", but it's the same as Matt proposed
> > > > with the different functions for different domains.  These functions
> > > > would do everything that is needed for the specific domain, such as
> > > > keeping it awake, checking if the registers are in the right range etc.
> > > > 
> > > > 
> > > > > > 2. Display code uses new APIs (xe_mmio_for_display ops)​
> > > > > > 
> > > > > > 3. Update uncore to handle "wakelock domain"​
> > > > > 
> > > > > then on uncore you would need to parse the mmio range and then
> > > > > call the get and puts, that in that case would be static inside
> > > > > the uncore itself like the forcewakes ?!
> > > > 
> > > > The callers will use the new Xe APIs, so in i915, the display code (and
> > > > probably GT and others too) will be the same as in Xe. 
> > > 
> > > I confess a got a bit lost now. What's GT need here? Does GT need this
> > > new wakelock or is it a display only thing?
> > > 
> > > if it is a display only thing, we have a new xe_display_wakelock component.
> > > The mmio wrappers that translate intel_de mmio calls to xe_mmio would make
> > > usage of the xe_display_wakelock functions. And no body else. no need to
> > > disrupt the working GT code.
> > > 
> > > But maybe I'm completely misunderstanding what the wakelock is about.
> > 
> > Sorry if I was not clear.
> > 
> > First of all, I don't think the new "wakelock" mechanism is any
> > different than the forcewake implementation we need in Xe (which we
> > have in uncore for i915).  AFAIU, we don't have this forcewake
> > implementation in Xe yet (which was the original discussion in this
> > thread), right?
> 
> wrong. we have xe_forcewake. But it is up to the caller of the xe_mmio
> to decide if it needs to forcewake certain domain or not.

Right, this I have seen...


> What we don't have is the xe_mmio calling the xe_forcewake based on
> some pre defined mmio range, like i915 does.

...but this is what I meant that was missing.


> What is this wakelock about? is it only a new display range of forcewake
> with a new display domain?

For some reason, it's not just a new display domain.  But it's a new
range (or set of ranges) that need to be protected by setting a bit in
DMC.


> or is it a new sequence of display mmios that needs to be executed
> before and after display mmio calls?

This is the case.  We need to set the "wakelock bit" before making MMIO
operations on specific ranges.


> or even before and after gt mmio calls besides the forcewake domains?

No, AFAICT there's not direct relation to GT.


> > So, my proposal is that we should implement the forcewake stuff in Xe
> > as Matt proposed, with the different APIs for different components
> > (e.g. xe_mmio_for_display()).  When this is done, we can add a new
> > "domain" (or maybe even reuse the xe_mmio_for_display() one) for the
> > new ranges that need a "wakelock" (which IMHO is the same as the
> > existing forcewake mechanisms).  If we do this, the implementation in
> > Xe is solved.
> 
> I really believe the wakelock should be totally orthogonal to Matt's
> proposal on the mmio split for device vs tile vs gt...
> To me, mmio_display is mmio_device anyway...

And couldn't the wakelock stuff be handled in the same way? My point is
that it would be good to abstract this HW intricacies from the caller
(in this case, the display).


> We already have a wrapper for translating intel_de calls to xe_mmio,
> why that cannot be used to implement this display wakelock sequences
> anyway and regarless?

It can, but adding this logic inside the wrappers doesn't sound right
to me.


> > But, of course, we need to make sure that the display code will remain
> > the same in i915.  To do so, I'm proposing that we make the display
> > code use the new xe_forcewake APIs, even though they won't exist in
> > i915.  So, for i915, we provide wrappers for these new APIs so we can
> > convert the calls into calls to uncore.  So functionally, the display
> > code in i915 will remain the same.  We don't need to implement the
> > "wakelock" part for i915, but we convert i915 to use the new
> > xe_forcewake APIs where it currently uses the uncore's version.
> 
> i915-display should only call intel_de functions this should be a wrapper
> to i915's intel_uncore or xe's xe_mmio... maybe intel_de itself is the
> right place to implement this display wakelock?

Again, I don't think a wrapper would be the right place to add this
functionality, but it could, technically, be there.


> But i915 should never call xe functions directly.
> 

Okay, I missed this rule.  I thought Xe would be the main driver and
i915 would start becoming obsolete and all the current wrappers were
just temporary, for the transition period.

IMHO the display code in Xe should become the main version of it while
the display code in i915 should be frozen and become obsolete (or
legacy, with updates only when needed, for old HW).  But I digress.


> > We won't disrupt the existing GT forcewake usage in i915.  That will
> > remain the same.  But we will need to implement forcewake in Xe, which
> > GT will use.  But the GT from Xe is not shared with i915, so no need to
> > create wrappers for that.
> 
> The big question that nobody could ever answer yet, is why do we need
> the intrinsic forcewake underneath xe_mmio, that is not already covered
> by the xe_forcewake call by the xe_mmio callers?

I think implicit handling of all this would make things simpler (or at
least more localized).  But it's a matter of style (and most likely
details I'm missing)


> Looking to the '_fw' variantes of the i915, we see that there are many
> cases out there that we don't want the intrinsic forcewake and then
> we had to create this bypass option, which name is extremely confusing.
> Opposite of what it currently does and means.

What are these cases exactly? I had understood that this was only the
case because we didn't want to thrash the forcewake when we're
accessing ranges that need it several times in a row.  Though this kind
of thing could be done by using a timer to add quiescence.


> GT MMIO operations are very limited to small usage during init, reset
> and resume. And the underneath range seems like an overkill and historically
> brought us many trouble.

I think the implicit handling could also take care of the state (i.e.
whether the HW is "initialized enough" to need the forcewake) and use
it only when needed.


> Again, I could be easily pursued to the opposite direction of the intrinsic
> forcewake, but so far with the current arguments that we have at the table
> I prefer to stick with the caller's responsibility on the forcewake.
> 
> If this 'wakelock' is something new that is bigger than display and that
> maybe justifies the intrinsic forcewake, then we probably need more
> information and details on the wakelock.
> 
> But if it is a display only thing as it looks like, I don't see why it
> couldn't simply live in the inte_de wrapper that calls xe_mmio...

Okay, so there seems to be a lot of history, complications and legacy
in the forecewake implementation that I have overlooked.  Though I tend
to disagree that the callers should know and take care of all this.  To
me, there should be a component that provides all this hardware access
without the callers having to know all the intricacies and details of
the HW implementation, such as what and when we need to have forcewake
protection, which domains to use etc.

And this is what I had understood from Matt's proposal.  The caller
would just say "I'm display" (with an xe_mmio_for_display() call or
whatever the wrapper would be called) and then access registers or make
larger MMIO operations using function pointers that were assigned by
this initial "identification" call.  These ops could then take care of
whatever is needed for these operations.

If we had this, then the wakelock implementation would be handled
inside these ops for display, without the display itself having to know
about access details.

But maybe I misunderstood the proposal.  And, if this is not the plan,
then the only way to do it is to add the "wakelock" logic to the
display orthogonally to the general MMIO access operations, which I
wanted to avoid.

--
Cheers,
Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-16 21:33                         ` Luca Coelho
@ 2023-10-16 22:10                           ` Rodrigo Vivi
  2023-10-17  0:58                             ` Matt Roper
  0 siblings, 1 reply; 25+ messages in thread
From: Rodrigo Vivi @ 2023-10-16 22:10 UTC (permalink / raw)
  To: Luca Coelho
  Cc: Ville Syrjälä,
	Jani Nikula, Lucas De Marchi, Matthew Auld, Matt Roper, intel-xe

On Tue, Oct 17, 2023 at 12:33:39AM +0300, Luca Coelho wrote:
> On Mon, 2023-10-16 at 16:08 -0400, Rodrigo Vivi wrote:
> > On Mon, Oct 16, 2023 at 10:40:12PM +0300, Luca Coelho wrote:
> > > On Mon, 2023-10-16 at 14:09 -0400, Rodrigo Vivi wrote:
> > > > On Mon, Oct 16, 2023 at 01:22:32PM +0300, Luca Coelho wrote:
> > > > > On Thu, 2023-10-12 at 16:04 -0400, Rodrigo Vivi wrote:
> > > > > > On Tue, Oct 10, 2023 at 10:00:06AM +0300, Luca Coelho wrote:
> > > > > > > On Mon, 2023-10-09 at 17:15 -0400, Rodrigo Vivi wrote:
> > > > > > > > On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> > > > > > > > > Hi everyone,
> > > > > > > > > 
> > > > > > > > > On Tue, 2023-05-23 at 23:52 +0000, Matthew Brost wrote:
> > > > > > > > > > On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> > > > > > > > > > > On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > > > > > > > > > > > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > > > > > > > > > > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > > > > > > > > > > > It is the maximum protection we can do with the current infrastructure.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > > > > > > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > > > > > > > > > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > > > > > > > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > > > > > > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > > > > > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > > > > > > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > > > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > RFC
> > > > > > > > > > > > > > ===
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > > > > > > > > > > > Xe than anything else.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > With that approach we had few historical issues iirc:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > > > > > > > > > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > > > > > > > > > > > the name suggests).
> > > > > > > > > > > > > 
> > > > > > > > > > > > > In i915 there were more differences between fw and non-fw variants
> > > > > > > > > > > > > of register functions than just forcewake handling:
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  * _fw() functions assumed that the caller was already holding
> > > > > > > > > > > > >    forcewake, whereas the non-fw functions would obtain it themselves
> > > > > > > > > > > > >  * _fw() functions also assumed that the caller was already holding
> > > > > > > > > > > > >    uncore->lock, whereas the non-fw functions would obtain and release
> > > > > > > > > > > > >    the lock around each register access
> > > > > > > > > > > > >  * _fw() functions do no tracing and no debug assertions
> > > > > > > > > > > > >  * _fw() functions do not check for unclaimed MMIO
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I don't think the first bullet there (forcewake) really mattered much
> > > > > > > > > > > > > from a performance perspective.  For display registers, a quick binary
> > > > > > > > > > > > > search of the FW table (just a handful of CPU cycles) would quickly
> > > > > > > > > > > > > determine that no forcewake domains were needed for those register
> > > > > > > > > > > > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > > > > > > > > > > > level at all.  For display registers, the more performance-relevant
> > > > > > > > > > > > > aspects of using the _fw() functions was doing all your register
> > > > > > > > > > > > > accesses together without contention with other MMIO work.  I.e.,
> > > > > > > > > > > > > holding the uncore lock over an entire set of registers rather than
> > > > > > > > > > > > > grabbing/releasing it for each one, and (for vblank evasion
> > > > > > > > > > > > > specifically) doing it all while interrupts were disabled.  For debug
> > > > > > > > > > > > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > > > > > > > > > > > bypassed (e.g., tripling of the number of register accesses due to
> > > > > > > > > > > > > reading FPGA_DBG before/after each register to look for unclaimed
> > > > > > > > > > > > > accesses).
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > > > > > > > > > > > other times that the spec was updated and we didn't get the notification, and
> > > > > > > > > > > > > > there were cases that the BSpec had bugs.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > For these reasons in Xe we have decided to let to the caller the
> > > > > > > > > > > > > > responsibility to set the force_wake bits for their domains before doing
> > > > > > > > > > > > > > the MMIO.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > > > > > > > > > > > bspec update (or the bspec itself having incorrect information) would
> > > > > > > > > > > > > lead to even more mistakes if the caller has to explicitly grab the
> > > > > > > > > > > > > appropriate domains than if the driver does it implicitly.  The explicit
> > > > > > > > > > > > > handling only helps in the subset of cases where we blindly grab all of
> > > > > > > > > > > > > the domains (as we do during part of init).
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > MMIO access that requires forcewakes really only should be in a few
> > > > > > > > > > > > places, off the top of my head:
> > > > > > > > > > > > 
> > > > > > > > > > > > 1. Init
> > > > > > > > > > > > 2. Reset
> > > > > > > > > > > > 3. Sysfs / Debugfs
> > > > > > > > > > > > 
> > > > > > > > > > > > In all of these cases I think it fine to blindly grab all forcewakes.
> > > > > > > > > > > > 
> > > > > > > > > > > > Please chime in if I'm missing something.
> > > > > > > > > > > 
> > > > > > > > > > > I think as we implement more features in the Xe driver we're going to
> > > > > > > > > > > wind up with a lot more places where we need to access GT registers at
> > > > > > > > > > > runtime.  A few examples off the top of my head:
> > > > > > > > > > > 
> > > > > > > > > > >  * EU stall sampling
> > > > > > > > > > >  * Perf/OA
> > > > > > > > > > >  * EU debugger
> > > > > > > > > > >  * Various OOB workarounds that ask us to twiddle a register at certain
> > > > > > > > > > >    times in the driver.
> > > > > > > > > > 
> > > > > > > > > > Hmm, ok a lot of these I could make the argument that these are not
> > > > > > > > > > normal operation so just grab everything and call it a day. If some of
> > > > > > > > > > these fall into the category of 'normal enough to be optimized' I can
> > > > > > > > > > also make the argument it is no more complex (perhaps less complex) to
> > > > > > > > > > explicitly grab the forcewake than having the logic auto-grab the
> > > > > > > > > > forcewake.
> > > > > > > > > > 
> > > > > > > > > > What a compromise of in a debug mode we auto-generate the asserts based
> > > > > > > > > > on a table but we still explicitly grab the forcewake?
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > However I'm seeing many questions and doubts popping up:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 1. Are we confident that we are not missing any wake-up?
> > > > > > > > > > > > > > 2. Are we confident that the domains are set correctly?
> > > > > > > > > > > > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > > > > > > > > > > > >    of some specific one?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I think we're only holding ALL domains during init; for most of the
> > > > > > > > > > > > > runtime MMIO accesses, I think the code is currently attempting to only
> > > > > > > > > > > > > grab the domain(s) that it thinks the registers it's accessing will
> > > > > > > > > > > > > need.  Although that might be working right now, I'm a little bit
> > > > > > > > > > > > > worried about how that will scale in the long term when a single
> > > > > > > > > > > > > register might be in several different domains depending on what
> > > > > > > > > > > > > platform you're running on.  There have definitely been cases in the
> > > > > > > > > > > > > past where groups of registers migrated from RENDER to GT or vice versa
> > > > > > > > > > > > > between platforms, so the exact domain you needed for an operation
> > > > > > > > > > > > > varied by platform.  And things are even more complicated if you're
> > > > > > > > > > > > > doing any MMIO against the media, since the hardware seems to change
> > > > > > > > > > > > > exactly how it splits up the media power wells somewhat often.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > 4. What about the display disconnection now because i915 and xe have different
> > > > > > > > > > > > > >    mmio approaches but reusing i915-display?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > It looks to me that the cons of the current approach are superseding the
> > > > > > > > > > > > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > > > > > > > > > > > we decide which route to take.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > > > > > > > > > > > a double approach where the caller is responsible but mmio has the range
> > > > > > > > > > > > > > information and double check it?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > As noted above, part of the challenge with forcewake is that even if the
> > > > > > > > > > > > > caller knows it wants to access register FOO, and even if it know FOO is
> > > > > > > > > > > > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > > > > > > > > > > > make sure it's grabbing the correct domain(s) for every single platform
> > > > > > > > > > > > > the Xe driver will eventually support if the power management handling
> > > > > > > > > > > > > changes.  I think that was part of the motivation for encoding the
> > > > > > > > > > > > > tables into the driver in i915.  It seems like GT power wells don't
> > > > > > > > > > > > > change as much these days as they used to, but it's hard to say whether
> > > > > > > > > > > > > that will continue in the future or not.  Who knows...maybe they'll
> > > > > > > > > > > > > eventually start creating dedicated domains for stuff like blitters,
> > > > > > > > > > > > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > > > > > > > > > > > domain.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > If we do decide to go back to implicit forcewake handling with the table
> > > > > > > > > > > > > encoded into the driver, it might be worth doing something sort of like
> > > > > > > > > > > > 
> > > > > > > > > > > > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > > > > > > > > > > > anything like this in Xe.
> > > > > > > > > > > 
> > > > > > > > > > > When you say unreadable, are you referring to the macros that generate
> > > > > > > > > > > the table lookup functions?  I don't think that macro magic would be
> > > > > > > > > > > needed for Xe since we don't have to support old platforms that have
> > > > > > > > > > > very different forcewake behavior, and we also don't need to generate
> > > > > > > > > > > separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> > > > > > > > > > > (since I think everything in the GT is 32-bits these days).
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Just the entire file is unreadable in general, trying to avoid these
> > > > > > > > > > types of files in Xe, avoid traps of the i915 did this so let's do it in
> > > > > > > > > > Xe, and over engineering our driver to avoid hypothetical future bugs.
> > > > > > > > > > 
> > > > > > > > > > Matt
> > > > > > > > > > 
> > > > > > > > > > > The forcewake and shadow tables themselves are pretty clean in i915
> > > > > > > > > > > these days, and if we move to autogenerating them from a text file, they
> > > > > > > > > > > can become even simpler since the text file will basically be a cleaned
> > > > > > > > > > > up copy/paste of part of the bspec table.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Matt
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > > what Lucas is doing in the OOB workaround series --- drop the
> > > > > > > > > > > > > per-platform tables into a human-readable text file that's more similar
> > > > > > > > > > > > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > > > > > > > > > > > replication type, etc.) and then provide a small parser program that
> > > > > > > > > > > > > will convert that into actual code (and do things like consolidating
> > > > > > > > > > > > > adjacent ranges).
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Any other idea? Thoughts?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > > > > > > > > > > > I plan to follow up with another series that creates a more appropriate
> > > > > > > > > > > > > MMIO target for register operations rather than using "xe_gt" as the
> > > > > > > > > > > > > target (even for things completely unrelated to the small GT subset of
> > > > > > > > > > > > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > > > > > > > > > > > operations against a specific hardware unit, and then the info inside
> > > > > > > > > > > > > the MMIO structure would be able to figure out if there are additional
> > > > > > > > > > > > > checks and/or operations it should perform.  E.g.,
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > > > > > > > > > > > >     - Used to submit MMIO operations against the root tile of the PCI
> > > > > > > > > > > > >       device.  Only used during init (e.g., to read the registers that
> > > > > > > > > > > > >       tell us which tiles exist on the platform) and during top-level
> > > > > > > > > > > > >       interrupt enable/disable (since all interrupts are routed through
> > > > > > > > > > > > >       the root tile).
> > > > > > > > > > > > >     - No forcewake needed for register accesses through a handle of this
> > > > > > > > > > > > >       type since you'd only ever be accessing sgunit registers for these
> > > > > > > > > > > > >       types of things.
> > > > > > > > > > > > >     - Register accesses through mmio can warn on debug builds if the
> > > > > > > > > > > > >       register appears to be in a GT-related MMIO range.
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > > > > > > > > > > > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > > > > > > > > > > > >       but if a handle of this type is used to try to read/write
> > > > > > > > > > > > >       registers outside the display range, we could have debug builds
> > > > > > > > > > > > >       throw some extra warnings.
> > > > > > > > > > > > >     - Unclaimed register detection could be confined to accesses through
> > > > > > > > > > > > >       these handles.
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > > > > > > > > > > > >     - Used to access non-GT registers that reside in a specific tile.
> > > > > > > > > > > > >       I.e., sgunit/soc registers.
> > > > > > > > > > > > >     - As above, no forcewake needed, can make MMIO operations warn
> > > > > > > > > > > > >       if used to access a GT range.
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > > > > > > > > > > > >     - Used to access GT registers in a specific GT
> > > > > > > > > > > > >     - Does automatic GSI offset translation for media GTs
> > > > > > > > > > > > >     - Can either do automatic forcewake like i915 does, or can do debug
> > > > > > > > > > > > >       check+warn like you have here.
> > > > > > > > > > > > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > > > > > > > > > > > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > > > > > > > > > > > >       register is accessed from an MMIO obtained from a media GT.
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Ack on this if we keep in managable, worried code / feature bloat those
> > > > > > > > > > > > that will result in a similar file to intel_uncore.c in Xe.
> > > > > > > > > 
> > > > > > > > > Just to revive this thread.
> > > > > > > > > 
> > > > > > > > > I've been discussing this proposal in the context of a change we need
> > > > > > > > > to make in the display, which is to introduce a wakelock for some
> > > > > > > > > registers access in order to be able to remove the DMC trap.
> > > > > > > > > 
> > > > > > > > > We came to the conclusion that this new implementation is very much the
> > > > > > > > > same as the forcewake proposal here.  From the display point-of-view,
> > > > > > > > > we could simply have a new domain and range of registers to protect.
> > > > > > > > > 
> > > > > > > > > We _could_ implement a separate "wakelock" mechanism for the display
> > > > > > > > > part, but that would be mostly duplicating the entire forcewake
> > > > > > > > > implementation.
> > > > > > > > > 
> > > > > > > > > So, are there any plans to implement the current proposal? Or any other
> > > > > > > > > plans related to the forcewake implementation for Xe? As I see it, the
> > > > > > > > > "wakelock" implementation in the display depends on this.
> > > > > > > > > 
> > > > > > > > > Any thoughts?
> > > > > > > > 
> > > > > > > > Hi Luca, thanks for raising this again here.
> > > > > > > 
> > > > > > > Hi Lucas! Thanks for your comments.
> > > > > > > 
> > > > > > > 
> > > > > > > > So, as I said in the past, I don't have strong opinions regarding the
> > > > > > > > overall forcewake approach.
> > > > > > > > 
> > > > > > > > The since GT MMIO is not used very frequently, I don't see a problem of
> > > > > > > > leaving that up to the caller to take the right domain when needed, or even
> > > > > > > > the FORCEWAKE_ALL domain. Instead of forcing all the callers to
> > > > > > > > go through this extra steps and then have to opt-out with the '_fw' [sic]
> > > > > > > > alternatives for the cases where the forcewake cannot be checked underneath.
> > > > > > > > 
> > > > > > > > So, for the new display wakelocks, that's the problem of adding them to
> > > > > > > > the drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h where the converions
> > > > > > > > from i915's intel uncore are happening to xe_mmio? So, when using the
> > > > > > > > intel_uncore's '_fw' variant you skip the wakelock and when doing the regular
> > > > > > > > mmio calls you just add a wakelock_get/put around the xe_mmio call with
> > > > > > > > the display domain. And in i915 you implement inside the intel_uncore.
> > > > > > > > 
> > > > > > > > What's the downside of this approach?
> > > > > > > 
> > > > > > > That's more or less what I was thinking.  I don't think there's any
> > > > > > > problem on the display side in calling the same framework.
> > > > > > > 
> > > > > > > 
> > > > > > > > Trying to understand all the pros and cons of different approaches, and
> > > > > > > > bringing some people to the discussion.
> > > > > > > > 
> > > > > > > > If we implement the forwareke underneath the mmio call, display needs
> > > > > > > > to anyway implement it twice on the i915's intel_uncore and on the
> > > > > > > > xe_forcewake, no?!
> > > > > > > 
> > > > > > > Yes, IMHO we should start making Xe the base implementation and
> > > > > > > backporting the new implementation into i915.
> > > > > > > 
> > > > > > > So,for this specific case, I think we can just make i915 call the new
> > > > > > > functions in xe and have them backported in intel_uncore.h for i915.
> > > > > > > 
> > > > > > > What I was thinking was basically this:
> > > > > > > 
> > > > > > > 1. Implement the xe_mmio_for_<hw_unit>() proposal in Xe​
> > > > > > 
> > > > > > hmm probably a new component then?! xe_display_wakelock that
> > > > > > implements and export the get/put domain in a similar way
> > > > > > of xe_forcewake, and then on the wrapper you add the get/put
> > > > > > around the existing xe_mmio calls?!
> > > > > 
> > > > > Yes, I guess a new component, but part of Xe.  I don't exactly know
> > > > > what you mean with "xe_forcewake", but it's the same as Matt proposed
> > > > > with the different functions for different domains.  These functions
> > > > > would do everything that is needed for the specific domain, such as
> > > > > keeping it awake, checking if the registers are in the right range etc.
> > > > > 
> > > > > 
> > > > > > > 2. Display code uses new APIs (xe_mmio_for_display ops)​
> > > > > > > 
> > > > > > > 3. Update uncore to handle "wakelock domain"​
> > > > > > 
> > > > > > then on uncore you would need to parse the mmio range and then
> > > > > > call the get and puts, that in that case would be static inside
> > > > > > the uncore itself like the forcewakes ?!
> > > > > 
> > > > > The callers will use the new Xe APIs, so in i915, the display code (and
> > > > > probably GT and others too) will be the same as in Xe. 
> > > > 
> > > > I confess a got a bit lost now. What's GT need here? Does GT need this
> > > > new wakelock or is it a display only thing?
> > > > 
> > > > if it is a display only thing, we have a new xe_display_wakelock component.
> > > > The mmio wrappers that translate intel_de mmio calls to xe_mmio would make
> > > > usage of the xe_display_wakelock functions. And no body else. no need to
> > > > disrupt the working GT code.
> > > > 
> > > > But maybe I'm completely misunderstanding what the wakelock is about.
> > > 
> > > Sorry if I was not clear.
> > > 
> > > First of all, I don't think the new "wakelock" mechanism is any
> > > different than the forcewake implementation we need in Xe (which we
> > > have in uncore for i915).  AFAIU, we don't have this forcewake
> > > implementation in Xe yet (which was the original discussion in this
> > > thread), right?
> > 
> > wrong. we have xe_forcewake. But it is up to the caller of the xe_mmio
> > to decide if it needs to forcewake certain domain or not.
> 
> Right, this I have seen...
> 
> 
> > What we don't have is the xe_mmio calling the xe_forcewake based on
> > some pre defined mmio range, like i915 does.
> 
> ...but this is what I meant that was missing.
> 
> 
> > What is this wakelock about? is it only a new display range of forcewake
> > with a new display domain?
> 
> For some reason, it's not just a new display domain.  But it's a new
> range (or set of ranges) that need to be protected by setting a bit in
> DMC.
> 
> 
> > or is it a new sequence of display mmios that needs to be executed
> > before and after display mmio calls?
> 
> This is the case.  We need to set the "wakelock bit" before making MMIO
> operations on specific ranges.
> 
> 
> > or even before and after gt mmio calls besides the forcewake domains?
> 
> No, AFAICT there's not direct relation to GT.
> 
> 
> > > So, my proposal is that we should implement the forcewake stuff in Xe
> > > as Matt proposed, with the different APIs for different components
> > > (e.g. xe_mmio_for_display()).  When this is done, we can add a new
> > > "domain" (or maybe even reuse the xe_mmio_for_display() one) for the
> > > new ranges that need a "wakelock" (which IMHO is the same as the
> > > existing forcewake mechanisms).  If we do this, the implementation in
> > > Xe is solved.
> > 
> > I really believe the wakelock should be totally orthogonal to Matt's
> > proposal on the mmio split for device vs tile vs gt...
> > To me, mmio_display is mmio_device anyway...
> 
> And couldn't the wakelock stuff be handled in the same way? My point is
> that it would be good to abstract this HW intricacies from the caller
> (in this case, the display).
> 
> 
> > We already have a wrapper for translating intel_de calls to xe_mmio,
> > why that cannot be used to implement this display wakelock sequences
> > anyway and regarless?
> 
> It can, but adding this logic inside the wrappers doesn't sound right
> to me.
> 
> 
> > > But, of course, we need to make sure that the display code will remain
> > > the same in i915.  To do so, I'm proposing that we make the display
> > > code use the new xe_forcewake APIs, even though they won't exist in
> > > i915.  So, for i915, we provide wrappers for these new APIs so we can
> > > convert the calls into calls to uncore.  So functionally, the display
> > > code in i915 will remain the same.  We don't need to implement the
> > > "wakelock" part for i915, but we convert i915 to use the new
> > > xe_forcewake APIs where it currently uses the uncore's version.
> > 
> > i915-display should only call intel_de functions this should be a wrapper
> > to i915's intel_uncore or xe's xe_mmio... maybe intel_de itself is the
> > right place to implement this display wakelock?
> 
> Again, I don't think a wrapper would be the right place to add this
> functionality, but it could, technically, be there.

Agreed. I had never told to implement in the wrapper. But the wrapper
would call the implementation in the new xe_display_wakelock besides
the call of xe_mmio. And then the implementation of xe_display_wakelock
ported to i915's intel_uncore.

However I don't believe this is needed as well. As more as I understand
this, more I believe the right place to add it is inside the
intel_de_{read, write, rmw) inside intel_de.h

You implement there once and you don't need to call anything in Xe and
you also don't need to backport anywhere. A single place and you are
covered on both drivers.

If it does not affect GT it shouldn't go inside intel_uncore. And definitely
not needed inside xe_mmio itself as well.

> 
> 
> > But i915 should never call xe functions directly.
> > 
> 
> Okay, I missed this rule.  I thought Xe would be the main driver and
> i915 would start becoming obsolete and all the current wrappers were
> just temporary, for the transition period.
> 
> IMHO the display code in Xe should become the main version of it while
> the display code in i915 should be frozen and become obsolete (or
> legacy, with updates only when needed, for old HW).  But I digress.

The work that Jani is leading is to make the display code independent,
and not replace one dependency by another.

> 
> 
> > > We won't disrupt the existing GT forcewake usage in i915.  That will
> > > remain the same.  But we will need to implement forcewake in Xe, which
> > > GT will use.  But the GT from Xe is not shared with i915, so no need to
> > > create wrappers for that.
> > 
> > The big question that nobody could ever answer yet, is why do we need
> > the intrinsic forcewake underneath xe_mmio, that is not already covered
> > by the xe_forcewake call by the xe_mmio callers?
> 
> I think implicit handling of all this would make things simpler (or at
> least more localized).  But it's a matter of style (and most likely
> details I'm missing)
> 
> 
> > Looking to the '_fw' variantes of the i915, we see that there are many
> > cases out there that we don't want the intrinsic forcewake and then
> > we had to create this bypass option, which name is extremely confusing.
> > Opposite of what it currently does and means.
> 
> What are these cases exactly?

They are mmio functions that doesn't take care of the forcewake.
Basically they are like the xe_mmio functions.

It is up to the caller using the '_fw' functions to take care of
the forcewake.

> I had understood that this was only the
> case because we didn't want to thrash the forcewake when we're
> accessing ranges that need it several times in a row.  Though this kind
> of thing could be done by using a timer to add quiescence.

so we already have the need for the case where forcewake is not needed
underneath, so the simplicity here might be to have just one single kind
of mmio functions and not 2.

> 
> 
> > GT MMIO operations are very limited to small usage during init, reset
> > and resume. And the underneath range seems like an overkill and historically
> > brought us many trouble.
> 
> I think the implicit handling could also take care of the state (i.e.
> whether the HW is "initialized enough" to need the forcewake) and use
> it only when needed.

not possible. Because we don't know who or what woke up that block. It might
be a firmware underneath. So if we trust that the block is enabled and avoid
getting the forcewake, then we are at risk of the domain get shut off in the
middle of the operation.

> 
> 
> > Again, I could be easily pursued to the opposite direction of the intrinsic
> > forcewake, but so far with the current arguments that we have at the table
> > I prefer to stick with the caller's responsibility on the forcewake.
> > 
> > If this 'wakelock' is something new that is bigger than display and that
> > maybe justifies the intrinsic forcewake, then we probably need more
> > information and details on the wakelock.
> > 
> > But if it is a display only thing as it looks like, I don't see why it
> > couldn't simply live in the inte_de wrapper that calls xe_mmio...
> 
> Okay, so there seems to be a lot of history, complications and legacy
> in the forecewake implementation that I have overlooked.  Though I tend
> to disagree that the callers should know and take care of all this.  To
> me, there should be a component that provides all this hardware access
> without the callers having to know all the intricacies and details of
> the HW implementation, such as what and when we need to have forcewake
> protection, which domains to use etc.

In general this is the part that I pretty much agree with you.
But this hidden magic underneath already brought us many trouble with
missing cases, only because the ranges implementation or even the bspec
were outdated. While if we had a simple wake all domain or we were used
to think about domain when implementing new mmio calls for new hw, we
would had saved a lot of time.

> 
> And this is what I had understood from Matt's proposal.  The caller
> would just say "I'm display" (with an xe_mmio_for_display() call or
> whatever the wrapper would be called) and then access registers or make
> larger MMIO operations using function pointers that were assigned by
> this initial "identification" call.  These ops could then take care of
> whatever is needed for these operations.

no no, his idea was simply to avoid display code or even display wrapper
have to have to think about the GT at all. But for me the 'device' portion
of his proposal should be enough to cover the display and the display
won't be needed.

In general, if caller know that the MMIO is for a given GT it calls the
xe_mmio_gt(gt, ...). If the caller knows that it is MMIO for a given Tile it calls
the xe_mmio_tile(tile, ...) if it knows that it is for the device it calls
xe_mmio_device(xe, ...)

But those have nothing to do with the forcewake anyway. Likely for all the
GTs and maybe even for some Tile ones you would still need to grab the forcewake
and orthogonal to the discussion if it is inside or outside...

The device likely doesn't have to grab any forcewake, but if it is display
apparently you would need the wakelock, but that it could be outside that
as well anyway.

> 
> If we had this, then the wakelock implementation would be handled
> inside these ops for display, without the display itself having to know
> about access details.

But it is a display thing, why do you need to abstract the display thing
underneath the MMIO accesses?

> 
> But maybe I misunderstood the proposal.  And, if this is not the plan,
> then the only way to do it is to add the "wakelock" logic to the
> display orthogonally to the general MMIO access operations, which I
> wanted to avoid.

well, let's have it inside intel_de_ and we have only one implementation.
no port needed. Regardless of the future of the xe_mmio or the future
of xe_forcewake.

> 
> --
> Cheers,
> Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-16 22:10                           ` Rodrigo Vivi
@ 2023-10-17  0:58                             ` Matt Roper
  2023-10-17 15:12                               ` Rodrigo Vivi
  0 siblings, 1 reply; 25+ messages in thread
From: Matt Roper @ 2023-10-17  0:58 UTC (permalink / raw)
  To: Rodrigo Vivi
  Cc: Ville Syrjälä,
	Jani Nikula, Lucas De Marchi, Matthew Auld, intel-xe

On Mon, Oct 16, 2023 at 06:10:14PM -0400, Rodrigo Vivi wrote:
> On Tue, Oct 17, 2023 at 12:33:39AM +0300, Luca Coelho wrote:
> > On Mon, 2023-10-16 at 16:08 -0400, Rodrigo Vivi wrote:
> > > On Mon, Oct 16, 2023 at 10:40:12PM +0300, Luca Coelho wrote:
> > > > On Mon, 2023-10-16 at 14:09 -0400, Rodrigo Vivi wrote:
> > > > > On Mon, Oct 16, 2023 at 01:22:32PM +0300, Luca Coelho wrote:
> > > > > > On Thu, 2023-10-12 at 16:04 -0400, Rodrigo Vivi wrote:
> > > > > > > On Tue, Oct 10, 2023 at 10:00:06AM +0300, Luca Coelho wrote:
> > > > > > > > On Mon, 2023-10-09 at 17:15 -0400, Rodrigo Vivi wrote:
> > > > > > > > > On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> > > > > > > > > > Hi everyone,
> > > > > > > > > > 
> > > > > > > > > > On Tue, 2023-05-23 at 23:52 +0000, Matthew Brost wrote:
> > > > > > > > > > > On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> > > > > > > > > > > > On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > > > > > > > > > > > > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > > > > > > > > > > > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > > > > > > > > > > > > It is the maximum protection we can do with the current infrastructure.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > > > > > > > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > > > > > > > > > > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > > > > > > > > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > > > > > > > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > > > > > > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > > > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > > > > > > > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > > > > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > RFC
> > > > > > > > > > > > > > > ===
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > > > > > > > > > > > > Xe than anything else.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > With that approach we had few historical issues iirc:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > > > > > > > > > > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > > > > > > > > > > > > the name suggests).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > In i915 there were more differences between fw and non-fw variants
> > > > > > > > > > > > > > of register functions than just forcewake handling:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >  * _fw() functions assumed that the caller was already holding
> > > > > > > > > > > > > >    forcewake, whereas the non-fw functions would obtain it themselves
> > > > > > > > > > > > > >  * _fw() functions also assumed that the caller was already holding
> > > > > > > > > > > > > >    uncore->lock, whereas the non-fw functions would obtain and release
> > > > > > > > > > > > > >    the lock around each register access
> > > > > > > > > > > > > >  * _fw() functions do no tracing and no debug assertions
> > > > > > > > > > > > > >  * _fw() functions do not check for unclaimed MMIO
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I don't think the first bullet there (forcewake) really mattered much
> > > > > > > > > > > > > > from a performance perspective.  For display registers, a quick binary
> > > > > > > > > > > > > > search of the FW table (just a handful of CPU cycles) would quickly
> > > > > > > > > > > > > > determine that no forcewake domains were needed for those register
> > > > > > > > > > > > > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > > > > > > > > > > > > level at all.  For display registers, the more performance-relevant
> > > > > > > > > > > > > > aspects of using the _fw() functions was doing all your register
> > > > > > > > > > > > > > accesses together without contention with other MMIO work.  I.e.,
> > > > > > > > > > > > > > holding the uncore lock over an entire set of registers rather than
> > > > > > > > > > > > > > grabbing/releasing it for each one, and (for vblank evasion
> > > > > > > > > > > > > > specifically) doing it all while interrupts were disabled.  For debug
> > > > > > > > > > > > > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > > > > > > > > > > > > bypassed (e.g., tripling of the number of register accesses due to
> > > > > > > > > > > > > > reading FPGA_DBG before/after each register to look for unclaimed
> > > > > > > > > > > > > > accesses).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > > > > > > > > > > > > other times that the spec was updated and we didn't get the notification, and
> > > > > > > > > > > > > > > there were cases that the BSpec had bugs.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > For these reasons in Xe we have decided to let to the caller the
> > > > > > > > > > > > > > > responsibility to set the force_wake bits for their domains before doing
> > > > > > > > > > > > > > > the MMIO.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > > > > > > > > > > > > bspec update (or the bspec itself having incorrect information) would
> > > > > > > > > > > > > > lead to even more mistakes if the caller has to explicitly grab the
> > > > > > > > > > > > > > appropriate domains than if the driver does it implicitly.  The explicit
> > > > > > > > > > > > > > handling only helps in the subset of cases where we blindly grab all of
> > > > > > > > > > > > > > the domains (as we do during part of init).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > MMIO access that requires forcewakes really only should be in a few
> > > > > > > > > > > > > places, off the top of my head:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 1. Init
> > > > > > > > > > > > > 2. Reset
> > > > > > > > > > > > > 3. Sysfs / Debugfs
> > > > > > > > > > > > > 
> > > > > > > > > > > > > In all of these cases I think it fine to blindly grab all forcewakes.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Please chime in if I'm missing something.
> > > > > > > > > > > > 
> > > > > > > > > > > > I think as we implement more features in the Xe driver we're going to
> > > > > > > > > > > > wind up with a lot more places where we need to access GT registers at
> > > > > > > > > > > > runtime.  A few examples off the top of my head:
> > > > > > > > > > > > 
> > > > > > > > > > > >  * EU stall sampling
> > > > > > > > > > > >  * Perf/OA
> > > > > > > > > > > >  * EU debugger
> > > > > > > > > > > >  * Various OOB workarounds that ask us to twiddle a register at certain
> > > > > > > > > > > >    times in the driver.
> > > > > > > > > > > 
> > > > > > > > > > > Hmm, ok a lot of these I could make the argument that these are not
> > > > > > > > > > > normal operation so just grab everything and call it a day. If some of
> > > > > > > > > > > these fall into the category of 'normal enough to be optimized' I can
> > > > > > > > > > > also make the argument it is no more complex (perhaps less complex) to
> > > > > > > > > > > explicitly grab the forcewake than having the logic auto-grab the
> > > > > > > > > > > forcewake.
> > > > > > > > > > > 
> > > > > > > > > > > What a compromise of in a debug mode we auto-generate the asserts based
> > > > > > > > > > > on a table but we still explicitly grab the forcewake?
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > However I'm seeing many questions and doubts popping up:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 1. Are we confident that we are not missing any wake-up?
> > > > > > > > > > > > > > > 2. Are we confident that the domains are set correctly?
> > > > > > > > > > > > > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > > > > > > > > > > > > >    of some specific one?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I think we're only holding ALL domains during init; for most of the
> > > > > > > > > > > > > > runtime MMIO accesses, I think the code is currently attempting to only
> > > > > > > > > > > > > > grab the domain(s) that it thinks the registers it's accessing will
> > > > > > > > > > > > > > need.  Although that might be working right now, I'm a little bit
> > > > > > > > > > > > > > worried about how that will scale in the long term when a single
> > > > > > > > > > > > > > register might be in several different domains depending on what
> > > > > > > > > > > > > > platform you're running on.  There have definitely been cases in the
> > > > > > > > > > > > > > past where groups of registers migrated from RENDER to GT or vice versa
> > > > > > > > > > > > > > between platforms, so the exact domain you needed for an operation
> > > > > > > > > > > > > > varied by platform.  And things are even more complicated if you're
> > > > > > > > > > > > > > doing any MMIO against the media, since the hardware seems to change
> > > > > > > > > > > > > > exactly how it splits up the media power wells somewhat often.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 4. What about the display disconnection now because i915 and xe have different
> > > > > > > > > > > > > > >    mmio approaches but reusing i915-display?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > It looks to me that the cons of the current approach are superseding the
> > > > > > > > > > > > > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > > > > > > > > > > > > we decide which route to take.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > > > > > > > > > > > > a double approach where the caller is responsible but mmio has the range
> > > > > > > > > > > > > > > information and double check it?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > As noted above, part of the challenge with forcewake is that even if the
> > > > > > > > > > > > > > caller knows it wants to access register FOO, and even if it know FOO is
> > > > > > > > > > > > > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > > > > > > > > > > > > make sure it's grabbing the correct domain(s) for every single platform
> > > > > > > > > > > > > > the Xe driver will eventually support if the power management handling
> > > > > > > > > > > > > > changes.  I think that was part of the motivation for encoding the
> > > > > > > > > > > > > > tables into the driver in i915.  It seems like GT power wells don't
> > > > > > > > > > > > > > change as much these days as they used to, but it's hard to say whether
> > > > > > > > > > > > > > that will continue in the future or not.  Who knows...maybe they'll
> > > > > > > > > > > > > > eventually start creating dedicated domains for stuff like blitters,
> > > > > > > > > > > > > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > > > > > > > > > > > > domain.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > If we do decide to go back to implicit forcewake handling with the table
> > > > > > > > > > > > > > encoded into the driver, it might be worth doing something sort of like
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > > > > > > > > > > > > anything like this in Xe.
> > > > > > > > > > > > 
> > > > > > > > > > > > When you say unreadable, are you referring to the macros that generate
> > > > > > > > > > > > the table lookup functions?  I don't think that macro magic would be
> > > > > > > > > > > > needed for Xe since we don't have to support old platforms that have
> > > > > > > > > > > > very different forcewake behavior, and we also don't need to generate
> > > > > > > > > > > > separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> > > > > > > > > > > > (since I think everything in the GT is 32-bits these days).
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Just the entire file is unreadable in general, trying to avoid these
> > > > > > > > > > > types of files in Xe, avoid traps of the i915 did this so let's do it in
> > > > > > > > > > > Xe, and over engineering our driver to avoid hypothetical future bugs.
> > > > > > > > > > > 
> > > > > > > > > > > Matt
> > > > > > > > > > > 
> > > > > > > > > > > > The forcewake and shadow tables themselves are pretty clean in i915
> > > > > > > > > > > > these days, and if we move to autogenerating them from a text file, they
> > > > > > > > > > > > can become even simpler since the text file will basically be a cleaned
> > > > > > > > > > > > up copy/paste of part of the bspec table.
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Matt
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > what Lucas is doing in the OOB workaround series --- drop the
> > > > > > > > > > > > > > per-platform tables into a human-readable text file that's more similar
> > > > > > > > > > > > > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > > > > > > > > > > > > replication type, etc.) and then provide a small parser program that
> > > > > > > > > > > > > > will convert that into actual code (and do things like consolidating
> > > > > > > > > > > > > > adjacent ranges).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Any other idea? Thoughts?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > > > > > > > > > > > > I plan to follow up with another series that creates a more appropriate
> > > > > > > > > > > > > > MMIO target for register operations rather than using "xe_gt" as the
> > > > > > > > > > > > > > target (even for things completely unrelated to the small GT subset of
> > > > > > > > > > > > > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > > > > > > > > > > > > operations against a specific hardware unit, and then the info inside
> > > > > > > > > > > > > > the MMIO structure would be able to figure out if there are additional
> > > > > > > > > > > > > > checks and/or operations it should perform.  E.g.,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > > > > > > > > > > > > >     - Used to submit MMIO operations against the root tile of the PCI
> > > > > > > > > > > > > >       device.  Only used during init (e.g., to read the registers that
> > > > > > > > > > > > > >       tell us which tiles exist on the platform) and during top-level
> > > > > > > > > > > > > >       interrupt enable/disable (since all interrupts are routed through
> > > > > > > > > > > > > >       the root tile).
> > > > > > > > > > > > > >     - No forcewake needed for register accesses through a handle of this
> > > > > > > > > > > > > >       type since you'd only ever be accessing sgunit registers for these
> > > > > > > > > > > > > >       types of things.
> > > > > > > > > > > > > >     - Register accesses through mmio can warn on debug builds if the
> > > > > > > > > > > > > >       register appears to be in a GT-related MMIO range.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > > > > > > > > > > > > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > > > > > > > > > > > > >       but if a handle of this type is used to try to read/write
> > > > > > > > > > > > > >       registers outside the display range, we could have debug builds
> > > > > > > > > > > > > >       throw some extra warnings.
> > > > > > > > > > > > > >     - Unclaimed register detection could be confined to accesses through
> > > > > > > > > > > > > >       these handles.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > > > > > > > > > > > > >     - Used to access non-GT registers that reside in a specific tile.
> > > > > > > > > > > > > >       I.e., sgunit/soc registers.
> > > > > > > > > > > > > >     - As above, no forcewake needed, can make MMIO operations warn
> > > > > > > > > > > > > >       if used to access a GT range.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > > > > > > > > > > > > >     - Used to access GT registers in a specific GT
> > > > > > > > > > > > > >     - Does automatic GSI offset translation for media GTs
> > > > > > > > > > > > > >     - Can either do automatic forcewake like i915 does, or can do debug
> > > > > > > > > > > > > >       check+warn like you have here.
> > > > > > > > > > > > > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > > > > > > > > > > > > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > > > > > > > > > > > > >       register is accessed from an MMIO obtained from a media GT.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Ack on this if we keep in managable, worried code / feature bloat those
> > > > > > > > > > > > > that will result in a similar file to intel_uncore.c in Xe.
> > > > > > > > > > 
> > > > > > > > > > Just to revive this thread.
> > > > > > > > > > 
> > > > > > > > > > I've been discussing this proposal in the context of a change we need
> > > > > > > > > > to make in the display, which is to introduce a wakelock for some
> > > > > > > > > > registers access in order to be able to remove the DMC trap.
> > > > > > > > > > 
> > > > > > > > > > We came to the conclusion that this new implementation is very much the
> > > > > > > > > > same as the forcewake proposal here.  From the display point-of-view,
> > > > > > > > > > we could simply have a new domain and range of registers to protect.
> > > > > > > > > > 
> > > > > > > > > > We _could_ implement a separate "wakelock" mechanism for the display
> > > > > > > > > > part, but that would be mostly duplicating the entire forcewake
> > > > > > > > > > implementation.
> > > > > > > > > > 
> > > > > > > > > > So, are there any plans to implement the current proposal? Or any other
> > > > > > > > > > plans related to the forcewake implementation for Xe? As I see it, the
> > > > > > > > > > "wakelock" implementation in the display depends on this.
> > > > > > > > > > 
> > > > > > > > > > Any thoughts?
> > > > > > > > > 
> > > > > > > > > Hi Luca, thanks for raising this again here.
> > > > > > > > 
> > > > > > > > Hi Lucas! Thanks for your comments.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > So, as I said in the past, I don't have strong opinions regarding the
> > > > > > > > > overall forcewake approach.
> > > > > > > > > 
> > > > > > > > > The since GT MMIO is not used very frequently, I don't see a problem of
> > > > > > > > > leaving that up to the caller to take the right domain when needed, or even
> > > > > > > > > the FORCEWAKE_ALL domain. Instead of forcing all the callers to
> > > > > > > > > go through this extra steps and then have to opt-out with the '_fw' [sic]
> > > > > > > > > alternatives for the cases where the forcewake cannot be checked underneath.
> > > > > > > > > 
> > > > > > > > > So, for the new display wakelocks, that's the problem of adding them to
> > > > > > > > > the drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h where the converions
> > > > > > > > > from i915's intel uncore are happening to xe_mmio? So, when using the
> > > > > > > > > intel_uncore's '_fw' variant you skip the wakelock and when doing the regular
> > > > > > > > > mmio calls you just add a wakelock_get/put around the xe_mmio call with
> > > > > > > > > the display domain. And in i915 you implement inside the intel_uncore.
> > > > > > > > > 
> > > > > > > > > What's the downside of this approach?
> > > > > > > > 
> > > > > > > > That's more or less what I was thinking.  I don't think there's any
> > > > > > > > problem on the display side in calling the same framework.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > Trying to understand all the pros and cons of different approaches, and
> > > > > > > > > bringing some people to the discussion.
> > > > > > > > > 
> > > > > > > > > If we implement the forwareke underneath the mmio call, display needs
> > > > > > > > > to anyway implement it twice on the i915's intel_uncore and on the
> > > > > > > > > xe_forcewake, no?!
> > > > > > > > 
> > > > > > > > Yes, IMHO we should start making Xe the base implementation and
> > > > > > > > backporting the new implementation into i915.
> > > > > > > > 
> > > > > > > > So,for this specific case, I think we can just make i915 call the new
> > > > > > > > functions in xe and have them backported in intel_uncore.h for i915.
> > > > > > > > 
> > > > > > > > What I was thinking was basically this:
> > > > > > > > 
> > > > > > > > 1. Implement the xe_mmio_for_<hw_unit>() proposal in Xe​
> > > > > > > 
> > > > > > > hmm probably a new component then?! xe_display_wakelock that
> > > > > > > implements and export the get/put domain in a similar way
> > > > > > > of xe_forcewake, and then on the wrapper you add the get/put
> > > > > > > around the existing xe_mmio calls?!
> > > > > > 
> > > > > > Yes, I guess a new component, but part of Xe.  I don't exactly know
> > > > > > what you mean with "xe_forcewake", but it's the same as Matt proposed
> > > > > > with the different functions for different domains.  These functions
> > > > > > would do everything that is needed for the specific domain, such as
> > > > > > keeping it awake, checking if the registers are in the right range etc.
> > > > > > 
> > > > > > 
> > > > > > > > 2. Display code uses new APIs (xe_mmio_for_display ops)​
> > > > > > > > 
> > > > > > > > 3. Update uncore to handle "wakelock domain"​
> > > > > > > 
> > > > > > > then on uncore you would need to parse the mmio range and then
> > > > > > > call the get and puts, that in that case would be static inside
> > > > > > > the uncore itself like the forcewakes ?!
> > > > > > 
> > > > > > The callers will use the new Xe APIs, so in i915, the display code (and
> > > > > > probably GT and others too) will be the same as in Xe. 
> > > > > 
> > > > > I confess a got a bit lost now. What's GT need here? Does GT need this
> > > > > new wakelock or is it a display only thing?
> > > > > 
> > > > > if it is a display only thing, we have a new xe_display_wakelock component.
> > > > > The mmio wrappers that translate intel_de mmio calls to xe_mmio would make
> > > > > usage of the xe_display_wakelock functions. And no body else. no need to
> > > > > disrupt the working GT code.
> > > > > 
> > > > > But maybe I'm completely misunderstanding what the wakelock is about.
> > > > 
> > > > Sorry if I was not clear.
> > > > 
> > > > First of all, I don't think the new "wakelock" mechanism is any
> > > > different than the forcewake implementation we need in Xe (which we
> > > > have in uncore for i915).  AFAIU, we don't have this forcewake
> > > > implementation in Xe yet (which was the original discussion in this
> > > > thread), right?
> > > 
> > > wrong. we have xe_forcewake. But it is up to the caller of the xe_mmio
> > > to decide if it needs to forcewake certain domain or not.
> > 
> > Right, this I have seen...
> > 
> > 
> > > What we don't have is the xe_mmio calling the xe_forcewake based on
> > > some pre defined mmio range, like i915 does.
> > 
> > ...but this is what I meant that was missing.
> > 
> > 
> > > What is this wakelock about? is it only a new display range of forcewake
> > > with a new display domain?
> > 
> > For some reason, it's not just a new display domain.  But it's a new
> > range (or set of ranges) that need to be protected by setting a bit in
> > DMC.
> > 
> > 
> > > or is it a new sequence of display mmios that needs to be executed
> > > before and after display mmio calls?
> > 
> > This is the case.  We need to set the "wakelock bit" before making MMIO
> > operations on specific ranges.
> > 
> > 
> > > or even before and after gt mmio calls besides the forcewake domains?
> > 
> > No, AFAICT there's not direct relation to GT.
> > 
> > 
> > > > So, my proposal is that we should implement the forcewake stuff in Xe
> > > > as Matt proposed, with the different APIs for different components
> > > > (e.g. xe_mmio_for_display()).  When this is done, we can add a new
> > > > "domain" (or maybe even reuse the xe_mmio_for_display() one) for the
> > > > new ranges that need a "wakelock" (which IMHO is the same as the
> > > > existing forcewake mechanisms).  If we do this, the implementation in
> > > > Xe is solved.
> > > 
> > > I really believe the wakelock should be totally orthogonal to Matt's
> > > proposal on the mmio split for device vs tile vs gt...
> > > To me, mmio_display is mmio_device anyway...
> > 
> > And couldn't the wakelock stuff be handled in the same way? My point is
> > that it would be good to abstract this HW intricacies from the caller
> > (in this case, the display).
> > 
> > 
> > > We already have a wrapper for translating intel_de calls to xe_mmio,
> > > why that cannot be used to implement this display wakelock sequences
> > > anyway and regarless?
> > 
> > It can, but adding this logic inside the wrappers doesn't sound right
> > to me.
> > 
> > 
> > > > But, of course, we need to make sure that the display code will remain
> > > > the same in i915.  To do so, I'm proposing that we make the display
> > > > code use the new xe_forcewake APIs, even though they won't exist in
> > > > i915.  So, for i915, we provide wrappers for these new APIs so we can
> > > > convert the calls into calls to uncore.  So functionally, the display
> > > > code in i915 will remain the same.  We don't need to implement the
> > > > "wakelock" part for i915, but we convert i915 to use the new
> > > > xe_forcewake APIs where it currently uses the uncore's version.
> > > 
> > > i915-display should only call intel_de functions this should be a wrapper
> > > to i915's intel_uncore or xe's xe_mmio... maybe intel_de itself is the
> > > right place to implement this display wakelock?
> > 
> > Again, I don't think a wrapper would be the right place to add this
> > functionality, but it could, technically, be there.
> 
> Agreed. I had never told to implement in the wrapper. But the wrapper
> would call the implementation in the new xe_display_wakelock besides
> the call of xe_mmio. And then the implementation of xe_display_wakelock
> ported to i915's intel_uncore.
> 
> However I don't believe this is needed as well. As more as I understand
> this, more I believe the right place to add it is inside the
> intel_de_{read, write, rmw) inside intel_de.h
> 
> You implement there once and you don't need to call anything in Xe and
> you also don't need to backport anywhere. A single place and you are
> covered on both drivers.
> 
> If it does not affect GT it shouldn't go inside intel_uncore. And definitely
> not needed inside xe_mmio itself as well.
> 
> > 
> > 
> > > But i915 should never call xe functions directly.
> > > 
> > 
> > Okay, I missed this rule.  I thought Xe would be the main driver and
> > i915 would start becoming obsolete and all the current wrappers were
> > just temporary, for the transition period.
> > 
> > IMHO the display code in Xe should become the main version of it while
> > the display code in i915 should be frozen and become obsolete (or
> > legacy, with updates only when needed, for old HW).  But I digress.
> 
> The work that Jani is leading is to make the display code independent,
> and not replace one dependency by another.
> 
> > 
> > 
> > > > We won't disrupt the existing GT forcewake usage in i915.  That will
> > > > remain the same.  But we will need to implement forcewake in Xe, which
> > > > GT will use.  But the GT from Xe is not shared with i915, so no need to
> > > > create wrappers for that.
> > > 
> > > The big question that nobody could ever answer yet, is why do we need
> > > the intrinsic forcewake underneath xe_mmio, that is not already covered
> > > by the xe_forcewake call by the xe_mmio callers?
> > 
> > I think implicit handling of all this would make things simpler (or at
> > least more localized).  But it's a matter of style (and most likely
> > details I'm missing)
> > 
> > 
> > > Looking to the '_fw' variantes of the i915, we see that there are many
> > > cases out there that we don't want the intrinsic forcewake and then
> > > we had to create this bypass option, which name is extremely confusing.
> > > Opposite of what it currently does and means.
> > 
> > What are these cases exactly?
> 
> They are mmio functions that doesn't take care of the forcewake.
> Basically they are like the xe_mmio functions.

i915's _fw functions were intended for tight critical sections (e.g.,
interrupt handlers and other hot path code) where we want to explicitly
grab forcewake once, perform multiple register read/write operations,
and then release it.  Using the _fw variants in places that aren't
performance-critical is heavily discouraged.

> 
> It is up to the caller using the '_fw' functions to take care of
> the forcewake.
> 
> > I had understood that this was only the
> > case because we didn't want to thrash the forcewake when we're
> > accessing ranges that need it several times in a row.  Though this kind
> > of thing could be done by using a timer to add quiescence.
> 
> so we already have the need for the case where forcewake is not needed
> underneath, so the simplicity here might be to have just one single kind
> of mmio functions and not 2.
> 
> > 
> > 
> > > GT MMIO operations are very limited to small usage during init, reset
> > > and resume. And the underneath range seems like an overkill and historically
> > > brought us many trouble.
> > 
> > I think the implicit handling could also take care of the state (i.e.
> > whether the HW is "initialized enough" to need the forcewake) and use
> > it only when needed.
> 
> not possible. Because we don't know who or what woke up that block. It might
> be a firmware underneath. So if we trust that the block is enabled and avoid
> getting the forcewake, then we are at risk of the domain get shut off in the
> middle of the operation.
> 
> > 
> > 
> > > Again, I could be easily pursued to the opposite direction of the intrinsic
> > > forcewake, but so far with the current arguments that we have at the table
> > > I prefer to stick with the caller's responsibility on the forcewake.
> > > 
> > > If this 'wakelock' is something new that is bigger than display and that
> > > maybe justifies the intrinsic forcewake, then we probably need more
> > > information and details on the wakelock.
> > > 
> > > But if it is a display only thing as it looks like, I don't see why it
> > > couldn't simply live in the inte_de wrapper that calls xe_mmio...
> > 
> > Okay, so there seems to be a lot of history, complications and legacy
> > in the forecewake implementation that I have overlooked.  Though I tend
> > to disagree that the callers should know and take care of all this.  To
> > me, there should be a component that provides all this hardware access
> > without the callers having to know all the intricacies and details of
> > the HW implementation, such as what and when we need to have forcewake
> > protection, which domains to use etc.
> 
> In general this is the part that I pretty much agree with you.
> But this hidden magic underneath already brought us many trouble with
> missing cases, only because the ranges implementation or even the bspec
> were outdated. While if we had a simple wake all domain or we were used
> to think about domain when implementing new mmio calls for new hw, we
> would had saved a lot of time.

No, this is backwards.  Although the cpp macros are a bit ugly (and
could probably be replaced by regular non-macro functions at this
point), the range table approach has been an absolute life saver for
maintaing the i915 driver.  

The bspec being wrong is not a concern here.  If the bspec is wrong,
then you're going to get the wrong behavior regardless of whether you
handle it explicitly (at callsite) or implicitly (in table).  The
difference is that once the problem is identified and the bspec fixed,
you can make one very simple change to a table rather than needing to
audit every single register access in the driver looking for callsites
that need to be updated.

The real concern is that in the long term it's pretty much impossible
for the callsites to know what forcewake domain(s) are appropriate for a
given register access since register ranges move between domains from
platform to platform.  It's more of an issue for the media engines than
for render vs gt domains, but in general just because some register is
in the "GT" domain today doesn't mean that it won't move to "RENDER" or
"NEWDOMAIN" on the next platform down the road.  When you enable that
new platform in the future, it's much easier to create (and review) one
centralized table that matches the bspec rather than needing to go
through every single register read/write in the entire driver to see if
any of them need to grab additional/different forcewake domains.

Honestly I think the decision to not use forcewake tables in Xe is
pretty crazy.  It may work out okay at the moment because we're only
actively working on a small handful of platforms with few forcewake
deltas, but over time that's going to change.  Also, right now there are
places where Xe is just being lazy and grabbing all domains because it's
too much of a hassle to figure out the platform-appropriate domains, but
if we wind up doing stuff like that at runtime it's going to mean we're
needlessly powering up unused hardware units which will be bad for
real-world power usage.

> 
> > 
> > And this is what I had understood from Matt's proposal.  The caller
> > would just say "I'm display" (with an xe_mmio_for_display() call or
> > whatever the wrapper would be called) and then access registers or make
> > larger MMIO operations using function pointers that were assigned by
> > this initial "identification" call.  These ops could then take care of
> > whatever is needed for these operations.
> 
> no no, his idea was simply to avoid display code or even display wrapper
> have to have to think about the GT at all. But for me the 'device' portion
> of his proposal should be enough to cover the display and the display
> won't be needed.
> 
> In general, if caller know that the MMIO is for a given GT it calls the
> xe_mmio_gt(gt, ...). If the caller knows that it is MMIO for a given Tile it calls
> the xe_mmio_tile(tile, ...) if it knows that it is for the device it calls
> xe_mmio_device(xe, ...)
> 
> But those have nothing to do with the forcewake anyway. Likely for all the
> GTs and maybe even for some Tile ones you would still need to grab the forcewake
> and orthogonal to the discussion if it is inside or outside...
> 
> The device likely doesn't have to grab any forcewake, but if it is display
> apparently you would need the wakelock, but that it could be outside that
> as well anyway.

Yeah, it sounds like the direction we're going now is that display code
is either going to remain part of i915, or maybe become its own
standalone thing at some point, so I don't think we'll actually have
display MMIO accesses from within drivers/gpu/drm/xe itself.  The non-GT
register accesses in the Xe code will be sgunit registers, so the
tile-centric accessor should be sufficient (or device-centric in rare
cases).

> 
> > 
> > If we had this, then the wakelock implementation would be handled
> > inside these ops for display, without the display itself having to know
> > about access details.
> 
> But it is a display thing, why do you need to abstract the display thing
> underneath the MMIO accesses?
> 
> > 
> > But maybe I misunderstood the proposal.  And, if this is not the plan,
> > then the only way to do it is to add the "wakelock" logic to the
> > display orthogonally to the general MMIO access operations, which I
> > wanted to avoid.
> 
> well, let's have it inside intel_de_ and we have only one implementation.
> no port needed. Regardless of the future of the xe_mmio or the future
> of xe_forcewake.

Implementing it solely at the intel_de layer sounds reasonable to me as
well.


Matt

> 
> > 
> > --
> > Cheers,
> > Luca.

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-17  0:58                             ` Matt Roper
@ 2023-10-17 15:12                               ` Rodrigo Vivi
  2023-10-19  8:43                                 ` Luca Coelho
  0 siblings, 1 reply; 25+ messages in thread
From: Rodrigo Vivi @ 2023-10-17 15:12 UTC (permalink / raw)
  To: Matt Roper
  Cc: Ville Syrjälä,
	Jani Nikula, Lucas De Marchi, Matthew Auld, intel-xe

On Mon, Oct 16, 2023 at 05:58:41PM -0700, Matt Roper wrote:
> On Mon, Oct 16, 2023 at 06:10:14PM -0400, Rodrigo Vivi wrote:
> > On Tue, Oct 17, 2023 at 12:33:39AM +0300, Luca Coelho wrote:
> > > On Mon, 2023-10-16 at 16:08 -0400, Rodrigo Vivi wrote:
> > > > On Mon, Oct 16, 2023 at 10:40:12PM +0300, Luca Coelho wrote:
> > > > > On Mon, 2023-10-16 at 14:09 -0400, Rodrigo Vivi wrote:
> > > > > > On Mon, Oct 16, 2023 at 01:22:32PM +0300, Luca Coelho wrote:
> > > > > > > On Thu, 2023-10-12 at 16:04 -0400, Rodrigo Vivi wrote:
> > > > > > > > On Tue, Oct 10, 2023 at 10:00:06AM +0300, Luca Coelho wrote:
> > > > > > > > > On Mon, 2023-10-09 at 17:15 -0400, Rodrigo Vivi wrote:
> > > > > > > > > > On Mon, Oct 09, 2023 at 12:22:44PM +0300, Luca Coelho wrote:
> > > > > > > > > > > Hi everyone,
> > > > > > > > > > > 
> > > > > > > > > > > On Tue, 2023-05-23 at 23:52 +0000, Matthew Brost wrote:
> > > > > > > > > > > > On Tue, May 23, 2023 at 09:38:49AM -0700, Matt Roper wrote:
> > > > > > > > > > > > > On Tue, May 23, 2023 at 01:56:53PM +0000, Matthew Brost wrote:
> > > > > > > > > > > > > > On Mon, May 22, 2023 at 08:28:05PM -0700, Matt Roper wrote:
> > > > > > > > > > > > > > > On Mon, May 22, 2023 at 06:15:27PM -0400, Rodrigo Vivi wrote:
> > > > > > > > > > > > > > > > It is the maximum protection we can do with the current infrastructure.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Cc: John Harrison <John.C.Harrison@Intel.com>
> > > > > > > > > > > > > > > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > > > > > > > > > > > > > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > > > > > > > > > > > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > > > > > > > > > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > > > > > > > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > > > > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > > > > > > > > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > > > > > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > RFC
> > > > > > > > > > > > > > > > ===
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Okay, so, this is more an RFC to brainstorm the future of the force_wake in
> > > > > > > > > > > > > > > > Xe than anything else.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > On i915 the force_wake is built-in the mmio functions at uncore component.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > With that approach we had few historical issues iirc:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 1. Display performance with vblank evasion that requested uncore to provide
> > > > > > > > > > > > > > > > the 'fw' variantes that are actually the ones that avoid fw (contrary to what
> > > > > > > > > > > > > > > > the name suggests).
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > In i915 there were more differences between fw and non-fw variants
> > > > > > > > > > > > > > > of register functions than just forcewake handling:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >  * _fw() functions assumed that the caller was already holding
> > > > > > > > > > > > > > >    forcewake, whereas the non-fw functions would obtain it themselves
> > > > > > > > > > > > > > >  * _fw() functions also assumed that the caller was already holding
> > > > > > > > > > > > > > >    uncore->lock, whereas the non-fw functions would obtain and release
> > > > > > > > > > > > > > >    the lock around each register access
> > > > > > > > > > > > > > >  * _fw() functions do no tracing and no debug assertions
> > > > > > > > > > > > > > >  * _fw() functions do not check for unclaimed MMIO
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I don't think the first bullet there (forcewake) really mattered much
> > > > > > > > > > > > > > > from a performance perspective.  For display registers, a quick binary
> > > > > > > > > > > > > > > search of the FW table (just a handful of CPU cycles) would quickly
> > > > > > > > > > > > > > > determine that no forcewake domains were needed for those register
> > > > > > > > > > > > > > > offsets, so we wouldn't be doing anything with forcewake at the hardware
> > > > > > > > > > > > > > > level at all.  For display registers, the more performance-relevant
> > > > > > > > > > > > > > > aspects of using the _fw() functions was doing all your register
> > > > > > > > > > > > > > > accesses together without contention with other MMIO work.  I.e.,
> > > > > > > > > > > > > > > holding the uncore lock over an entire set of registers rather than
> > > > > > > > > > > > > > > grabbing/releasing it for each one, and (for vblank evasion
> > > > > > > > > > > > > > > specifically) doing it all while interrupts were disabled.  For debug
> > > > > > > > > > > > > > > drivers, there was also a bunch of other stuff that the _fw() functions
> > > > > > > > > > > > > > > bypassed (e.g., tripling of the number of register accesses due to
> > > > > > > > > > > > > > > reading FPGA_DBG before/after each register to look for unclaimed
> > > > > > > > > > > > > > > accesses).
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 2. Missed ranges updates. Sometimes we messed up with the ranges, there were
> > > > > > > > > > > > > > > > other times that the spec was updated and we didn't get the notification, and
> > > > > > > > > > > > > > > > there were cases that the BSpec had bugs.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > For these reasons in Xe we have decided to let to the caller the
> > > > > > > > > > > > > > > > responsibility to set the force_wake bits for their domains before doing
> > > > > > > > > > > > > > > > the MMIO.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I don't think #2 was a reason to skip forcewake in Xe.  Not noticing a
> > > > > > > > > > > > > > > bspec update (or the bspec itself having incorrect information) would
> > > > > > > > > > > > > > > lead to even more mistakes if the caller has to explicitly grab the
> > > > > > > > > > > > > > > appropriate domains than if the driver does it implicitly.  The explicit
> > > > > > > > > > > > > > > handling only helps in the subset of cases where we blindly grab all of
> > > > > > > > > > > > > > > the domains (as we do during part of init).
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > MMIO access that requires forcewakes really only should be in a few
> > > > > > > > > > > > > > places, off the top of my head:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 1. Init
> > > > > > > > > > > > > > 2. Reset
> > > > > > > > > > > > > > 3. Sysfs / Debugfs
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > In all of these cases I think it fine to blindly grab all forcewakes.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Please chime in if I'm missing something.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I think as we implement more features in the Xe driver we're going to
> > > > > > > > > > > > > wind up with a lot more places where we need to access GT registers at
> > > > > > > > > > > > > runtime.  A few examples off the top of my head:
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  * EU stall sampling
> > > > > > > > > > > > >  * Perf/OA
> > > > > > > > > > > > >  * EU debugger
> > > > > > > > > > > > >  * Various OOB workarounds that ask us to twiddle a register at certain
> > > > > > > > > > > > >    times in the driver.
> > > > > > > > > > > > 
> > > > > > > > > > > > Hmm, ok a lot of these I could make the argument that these are not
> > > > > > > > > > > > normal operation so just grab everything and call it a day. If some of
> > > > > > > > > > > > these fall into the category of 'normal enough to be optimized' I can
> > > > > > > > > > > > also make the argument it is no more complex (perhaps less complex) to
> > > > > > > > > > > > explicitly grab the forcewake than having the logic auto-grab the
> > > > > > > > > > > > forcewake.
> > > > > > > > > > > > 
> > > > > > > > > > > > What a compromise of in a debug mode we auto-generate the asserts based
> > > > > > > > > > > > on a table but we still explicitly grab the forcewake?
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > However I'm seeing many questions and doubts popping up:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 1. Are we confident that we are not missing any wake-up?
> > > > > > > > > > > > > > > > 2. Are we confident that the domains are set correctly?
> > > > > > > > > > > > > > > > 3. Are we not wasting power if we are waking up ALL the domains instead
> > > > > > > > > > > > > > > >    of some specific one?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I think we're only holding ALL domains during init; for most of the
> > > > > > > > > > > > > > > runtime MMIO accesses, I think the code is currently attempting to only
> > > > > > > > > > > > > > > grab the domain(s) that it thinks the registers it's accessing will
> > > > > > > > > > > > > > > need.  Although that might be working right now, I'm a little bit
> > > > > > > > > > > > > > > worried about how that will scale in the long term when a single
> > > > > > > > > > > > > > > register might be in several different domains depending on what
> > > > > > > > > > > > > > > platform you're running on.  There have definitely been cases in the
> > > > > > > > > > > > > > > past where groups of registers migrated from RENDER to GT or vice versa
> > > > > > > > > > > > > > > between platforms, so the exact domain you needed for an operation
> > > > > > > > > > > > > > > varied by platform.  And things are even more complicated if you're
> > > > > > > > > > > > > > > doing any MMIO against the media, since the hardware seems to change
> > > > > > > > > > > > > > > exactly how it splits up the media power wells somewhat often.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 4. What about the display disconnection now because i915 and xe have different
> > > > > > > > > > > > > > > >    mmio approaches but reusing i915-display?
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > It looks to me that the cons of the current approach are superseding the
> > > > > > > > > > > > > > > > cons of the i915 approach. But I want to hear more thoughts here before
> > > > > > > > > > > > > > > > we decide which route to take.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Maybe we have that domain as part of the mmio calls themselves? Maybe
> > > > > > > > > > > > > > > > a double approach where the caller is responsible but mmio has the range
> > > > > > > > > > > > > > > > information and double check it?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > As noted above, part of the challenge with forcewake is that even if the
> > > > > > > > > > > > > > > caller knows it wants to access register FOO, and even if it know FOO is
> > > > > > > > > > > > > > > a GT register that likely needs forcewake, it's sometimes challenging to
> > > > > > > > > > > > > > > make sure it's grabbing the correct domain(s) for every single platform
> > > > > > > > > > > > > > > the Xe driver will eventually support if the power management handling
> > > > > > > > > > > > > > > changes.  I think that was part of the motivation for encoding the
> > > > > > > > > > > > > > > tables into the driver in i915.  It seems like GT power wells don't
> > > > > > > > > > > > > > > change as much these days as they used to, but it's hard to say whether
> > > > > > > > > > > > > > > that will continue in the future or not.  Who knows...maybe they'll
> > > > > > > > > > > > > > > eventually start creating dedicated domains for stuff like blitters,
> > > > > > > > > > > > > > > GuC, etc.  rather than lumping all of those into the "GT" catchall
> > > > > > > > > > > > > > > domain.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > If we do decide to go back to implicit forcewake handling with the table
> > > > > > > > > > > > > > > encoded into the driver, it might be worth doing something sort of like
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Let's not do this intel_uncore.c is an unreadable mess, I don't want
> > > > > > > > > > > > > > anything like this in Xe.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > When you say unreadable, are you referring to the macros that generate
> > > > > > > > > > > > > the table lookup functions?  I don't think that macro magic would be
> > > > > > > > > > > > > needed for Xe since we don't have to support old platforms that have
> > > > > > > > > > > > > very different forcewake behavior, and we also don't need to generate
> > > > > > > > > > > > > separate 8-bit, 16-bit, and 32-bit versions of each operation anymore
> > > > > > > > > > > > > (since I think everything in the GT is 32-bits these days).
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Just the entire file is unreadable in general, trying to avoid these
> > > > > > > > > > > > types of files in Xe, avoid traps of the i915 did this so let's do it in
> > > > > > > > > > > > Xe, and over engineering our driver to avoid hypothetical future bugs.
> > > > > > > > > > > > 
> > > > > > > > > > > > Matt
> > > > > > > > > > > > 
> > > > > > > > > > > > > The forcewake and shadow tables themselves are pretty clean in i915
> > > > > > > > > > > > > these days, and if we move to autogenerating them from a text file, they
> > > > > > > > > > > > > can become even simpler since the text file will basically be a cleaned
> > > > > > > > > > > > > up copy/paste of part of the bspec table.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Matt
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > what Lucas is doing in the OOB workaround series --- drop the
> > > > > > > > > > > > > > > per-platform tables into a human-readable text file that's more similar
> > > > > > > > > > > > > > > to the format used by the bspec (exact ranges, forcewake domain, MCR
> > > > > > > > > > > > > > > replication type, etc.) and then provide a small parser program that
> > > > > > > > > > > > > > > will convert that into actual code (and do things like consolidating
> > > > > > > > > > > > > > > adjacent ranges).
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Any other idea? Thoughts?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Once the big GT vs tile refactor stuff I have in flight gets finalized,
> > > > > > > > > > > > > > > I plan to follow up with another series that creates a more appropriate
> > > > > > > > > > > > > > > MMIO target for register operations rather than using "xe_gt" as the
> > > > > > > > > > > > > > > target (even for things completely unrelated to the small GT subset of
> > > > > > > > > > > > > > > hardware).  My idea is that you'd grab an MMIO target structure for MMIO
> > > > > > > > > > > > > > > operations against a specific hardware unit, and then the info inside
> > > > > > > > > > > > > > > the MMIO structure would be able to figure out if there are additional
> > > > > > > > > > > > > > > checks and/or operations it should perform.  E.g.,
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >  * mmio = xe_mmio_for_device(xe_device *xe);
> > > > > > > > > > > > > > >     - Used to submit MMIO operations against the root tile of the PCI
> > > > > > > > > > > > > > >       device.  Only used during init (e.g., to read the registers that
> > > > > > > > > > > > > > >       tell us which tiles exist on the platform) and during top-level
> > > > > > > > > > > > > > >       interrupt enable/disable (since all interrupts are routed through
> > > > > > > > > > > > > > >       the root tile).
> > > > > > > > > > > > > > >     - No forcewake needed for register accesses through a handle of this
> > > > > > > > > > > > > > >       type since you'd only ever be accessing sgunit registers for these
> > > > > > > > > > > > > > >       types of things.
> > > > > > > > > > > > > > >     - Register accesses through mmio can warn on debug builds if the
> > > > > > > > > > > > > > >       register appears to be in a GT-related MMIO range.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >  * mmio = xe_mmio_for_display(xe_device *xe);
> > > > > > > > > > > > > > >     - Pretty much the same as handles returned by xe_mmio_for_device(),
> > > > > > > > > > > > > > >       but if a handle of this type is used to try to read/write
> > > > > > > > > > > > > > >       registers outside the display range, we could have debug builds
> > > > > > > > > > > > > > >       throw some extra warnings.
> > > > > > > > > > > > > > >     - Unclaimed register detection could be confined to accesses through
> > > > > > > > > > > > > > >       these handles.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >  * mmio = xe_mmio_for_tile(xe_tile *tile);
> > > > > > > > > > > > > > >     - Used to access non-GT registers that reside in a specific tile.
> > > > > > > > > > > > > > >       I.e., sgunit/soc registers.
> > > > > > > > > > > > > > >     - As above, no forcewake needed, can make MMIO operations warn
> > > > > > > > > > > > > > >       if used to access a GT range.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >  * mmio = xe_mmio_for_gt(xe_gt *gt);
> > > > > > > > > > > > > > >     - Used to access GT registers in a specific GT
> > > > > > > > > > > > > > >     - Does automatic GSI offset translation for media GTs
> > > > > > > > > > > > > > >     - Can either do automatic forcewake like i915 does, or can do debug
> > > > > > > > > > > > > > >       check+warn like you have here.
> > > > > > > > > > > > > > >     - Can make MMIO operations warn if MMIO offset is outside GT range
> > > > > > > > > > > > > > >     - Can also trigger warnings if a GT non-GSI, non-media engine
> > > > > > > > > > > > > > >       register is accessed from an MMIO obtained from a media GT.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Ack on this if we keep in managable, worried code / feature bloat those
> > > > > > > > > > > > > > that will result in a similar file to intel_uncore.c in Xe.
> > > > > > > > > > > 
> > > > > > > > > > > Just to revive this thread.
> > > > > > > > > > > 
> > > > > > > > > > > I've been discussing this proposal in the context of a change we need
> > > > > > > > > > > to make in the display, which is to introduce a wakelock for some
> > > > > > > > > > > registers access in order to be able to remove the DMC trap.
> > > > > > > > > > > 
> > > > > > > > > > > We came to the conclusion that this new implementation is very much the
> > > > > > > > > > > same as the forcewake proposal here.  From the display point-of-view,
> > > > > > > > > > > we could simply have a new domain and range of registers to protect.
> > > > > > > > > > > 
> > > > > > > > > > > We _could_ implement a separate "wakelock" mechanism for the display
> > > > > > > > > > > part, but that would be mostly duplicating the entire forcewake
> > > > > > > > > > > implementation.
> > > > > > > > > > > 
> > > > > > > > > > > So, are there any plans to implement the current proposal? Or any other
> > > > > > > > > > > plans related to the forcewake implementation for Xe? As I see it, the
> > > > > > > > > > > "wakelock" implementation in the display depends on this.
> > > > > > > > > > > 
> > > > > > > > > > > Any thoughts?
> > > > > > > > > > 
> > > > > > > > > > Hi Luca, thanks for raising this again here.
> > > > > > > > > 
> > > > > > > > > Hi Lucas! Thanks for your comments.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > So, as I said in the past, I don't have strong opinions regarding the
> > > > > > > > > > overall forcewake approach.
> > > > > > > > > > 
> > > > > > > > > > The since GT MMIO is not used very frequently, I don't see a problem of
> > > > > > > > > > leaving that up to the caller to take the right domain when needed, or even
> > > > > > > > > > the FORCEWAKE_ALL domain. Instead of forcing all the callers to
> > > > > > > > > > go through this extra steps and then have to opt-out with the '_fw' [sic]
> > > > > > > > > > alternatives for the cases where the forcewake cannot be checked underneath.
> > > > > > > > > > 
> > > > > > > > > > So, for the new display wakelocks, that's the problem of adding them to
> > > > > > > > > > the drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h where the converions
> > > > > > > > > > from i915's intel uncore are happening to xe_mmio? So, when using the
> > > > > > > > > > intel_uncore's '_fw' variant you skip the wakelock and when doing the regular
> > > > > > > > > > mmio calls you just add a wakelock_get/put around the xe_mmio call with
> > > > > > > > > > the display domain. And in i915 you implement inside the intel_uncore.
> > > > > > > > > > 
> > > > > > > > > > What's the downside of this approach?
> > > > > > > > > 
> > > > > > > > > That's more or less what I was thinking.  I don't think there's any
> > > > > > > > > problem on the display side in calling the same framework.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > Trying to understand all the pros and cons of different approaches, and
> > > > > > > > > > bringing some people to the discussion.
> > > > > > > > > > 
> > > > > > > > > > If we implement the forwareke underneath the mmio call, display needs
> > > > > > > > > > to anyway implement it twice on the i915's intel_uncore and on the
> > > > > > > > > > xe_forcewake, no?!
> > > > > > > > > 
> > > > > > > > > Yes, IMHO we should start making Xe the base implementation and
> > > > > > > > > backporting the new implementation into i915.
> > > > > > > > > 
> > > > > > > > > So,for this specific case, I think we can just make i915 call the new
> > > > > > > > > functions in xe and have them backported in intel_uncore.h for i915.
> > > > > > > > > 
> > > > > > > > > What I was thinking was basically this:
> > > > > > > > > 
> > > > > > > > > 1. Implement the xe_mmio_for_<hw_unit>() proposal in Xe​
> > > > > > > > 
> > > > > > > > hmm probably a new component then?! xe_display_wakelock that
> > > > > > > > implements and export the get/put domain in a similar way
> > > > > > > > of xe_forcewake, and then on the wrapper you add the get/put
> > > > > > > > around the existing xe_mmio calls?!
> > > > > > > 
> > > > > > > Yes, I guess a new component, but part of Xe.  I don't exactly know
> > > > > > > what you mean with "xe_forcewake", but it's the same as Matt proposed
> > > > > > > with the different functions for different domains.  These functions
> > > > > > > would do everything that is needed for the specific domain, such as
> > > > > > > keeping it awake, checking if the registers are in the right range etc.
> > > > > > > 
> > > > > > > 
> > > > > > > > > 2. Display code uses new APIs (xe_mmio_for_display ops)​
> > > > > > > > > 
> > > > > > > > > 3. Update uncore to handle "wakelock domain"​
> > > > > > > > 
> > > > > > > > then on uncore you would need to parse the mmio range and then
> > > > > > > > call the get and puts, that in that case would be static inside
> > > > > > > > the uncore itself like the forcewakes ?!
> > > > > > > 
> > > > > > > The callers will use the new Xe APIs, so in i915, the display code (and
> > > > > > > probably GT and others too) will be the same as in Xe. 
> > > > > > 
> > > > > > I confess a got a bit lost now. What's GT need here? Does GT need this
> > > > > > new wakelock or is it a display only thing?
> > > > > > 
> > > > > > if it is a display only thing, we have a new xe_display_wakelock component.
> > > > > > The mmio wrappers that translate intel_de mmio calls to xe_mmio would make
> > > > > > usage of the xe_display_wakelock functions. And no body else. no need to
> > > > > > disrupt the working GT code.
> > > > > > 
> > > > > > But maybe I'm completely misunderstanding what the wakelock is about.
> > > > > 
> > > > > Sorry if I was not clear.
> > > > > 
> > > > > First of all, I don't think the new "wakelock" mechanism is any
> > > > > different than the forcewake implementation we need in Xe (which we
> > > > > have in uncore for i915).  AFAIU, we don't have this forcewake
> > > > > implementation in Xe yet (which was the original discussion in this
> > > > > thread), right?
> > > > 
> > > > wrong. we have xe_forcewake. But it is up to the caller of the xe_mmio
> > > > to decide if it needs to forcewake certain domain or not.
> > > 
> > > Right, this I have seen...
> > > 
> > > 
> > > > What we don't have is the xe_mmio calling the xe_forcewake based on
> > > > some pre defined mmio range, like i915 does.
> > > 
> > > ...but this is what I meant that was missing.
> > > 
> > > 
> > > > What is this wakelock about? is it only a new display range of forcewake
> > > > with a new display domain?
> > > 
> > > For some reason, it's not just a new display domain.  But it's a new
> > > range (or set of ranges) that need to be protected by setting a bit in
> > > DMC.
> > > 
> > > 
> > > > or is it a new sequence of display mmios that needs to be executed
> > > > before and after display mmio calls?
> > > 
> > > This is the case.  We need to set the "wakelock bit" before making MMIO
> > > operations on specific ranges.
> > > 
> > > 
> > > > or even before and after gt mmio calls besides the forcewake domains?
> > > 
> > > No, AFAICT there's not direct relation to GT.
> > > 
> > > 
> > > > > So, my proposal is that we should implement the forcewake stuff in Xe
> > > > > as Matt proposed, with the different APIs for different components
> > > > > (e.g. xe_mmio_for_display()).  When this is done, we can add a new
> > > > > "domain" (or maybe even reuse the xe_mmio_for_display() one) for the
> > > > > new ranges that need a "wakelock" (which IMHO is the same as the
> > > > > existing forcewake mechanisms).  If we do this, the implementation in
> > > > > Xe is solved.
> > > > 
> > > > I really believe the wakelock should be totally orthogonal to Matt's
> > > > proposal on the mmio split for device vs tile vs gt...
> > > > To me, mmio_display is mmio_device anyway...
> > > 
> > > And couldn't the wakelock stuff be handled in the same way? My point is
> > > that it would be good to abstract this HW intricacies from the caller
> > > (in this case, the display).
> > > 
> > > 
> > > > We already have a wrapper for translating intel_de calls to xe_mmio,
> > > > why that cannot be used to implement this display wakelock sequences
> > > > anyway and regarless?
> > > 
> > > It can, but adding this logic inside the wrappers doesn't sound right
> > > to me.
> > > 
> > > 
> > > > > But, of course, we need to make sure that the display code will remain
> > > > > the same in i915.  To do so, I'm proposing that we make the display
> > > > > code use the new xe_forcewake APIs, even though they won't exist in
> > > > > i915.  So, for i915, we provide wrappers for these new APIs so we can
> > > > > convert the calls into calls to uncore.  So functionally, the display
> > > > > code in i915 will remain the same.  We don't need to implement the
> > > > > "wakelock" part for i915, but we convert i915 to use the new
> > > > > xe_forcewake APIs where it currently uses the uncore's version.
> > > > 
> > > > i915-display should only call intel_de functions this should be a wrapper
> > > > to i915's intel_uncore or xe's xe_mmio... maybe intel_de itself is the
> > > > right place to implement this display wakelock?
> > > 
> > > Again, I don't think a wrapper would be the right place to add this
> > > functionality, but it could, technically, be there.
> > 
> > Agreed. I had never told to implement in the wrapper. But the wrapper
> > would call the implementation in the new xe_display_wakelock besides
> > the call of xe_mmio. And then the implementation of xe_display_wakelock
> > ported to i915's intel_uncore.
> > 
> > However I don't believe this is needed as well. As more as I understand
> > this, more I believe the right place to add it is inside the
> > intel_de_{read, write, rmw) inside intel_de.h
> > 
> > You implement there once and you don't need to call anything in Xe and
> > you also don't need to backport anywhere. A single place and you are
> > covered on both drivers.
> > 
> > If it does not affect GT it shouldn't go inside intel_uncore. And definitely
> > not needed inside xe_mmio itself as well.
> > 
> > > 
> > > 
> > > > But i915 should never call xe functions directly.
> > > > 
> > > 
> > > Okay, I missed this rule.  I thought Xe would be the main driver and
> > > i915 would start becoming obsolete and all the current wrappers were
> > > just temporary, for the transition period.
> > > 
> > > IMHO the display code in Xe should become the main version of it while
> > > the display code in i915 should be frozen and become obsolete (or
> > > legacy, with updates only when needed, for old HW).  But I digress.
> > 
> > The work that Jani is leading is to make the display code independent,
> > and not replace one dependency by another.
> > 
> > > 
> > > 
> > > > > We won't disrupt the existing GT forcewake usage in i915.  That will
> > > > > remain the same.  But we will need to implement forcewake in Xe, which
> > > > > GT will use.  But the GT from Xe is not shared with i915, so no need to
> > > > > create wrappers for that.
> > > > 
> > > > The big question that nobody could ever answer yet, is why do we need
> > > > the intrinsic forcewake underneath xe_mmio, that is not already covered
> > > > by the xe_forcewake call by the xe_mmio callers?
> > > 
> > > I think implicit handling of all this would make things simpler (or at
> > > least more localized).  But it's a matter of style (and most likely
> > > details I'm missing)
> > > 
> > > 
> > > > Looking to the '_fw' variantes of the i915, we see that there are many
> > > > cases out there that we don't want the intrinsic forcewake and then
> > > > we had to create this bypass option, which name is extremely confusing.
> > > > Opposite of what it currently does and means.
> > > 
> > > What are these cases exactly?
> > 
> > They are mmio functions that doesn't take care of the forcewake.
> > Basically they are like the xe_mmio functions.
> 
> i915's _fw functions were intended for tight critical sections (e.g.,
> interrupt handlers and other hot path code) where we want to explicitly
> grab forcewake once, perform multiple register read/write operations,
> and then release it.  Using the _fw variants in places that aren't
> performance-critical is heavily discouraged.

yes, but the point is that if you take the path of intrinsic forcewake,
you immediately need to also support the path of non-forcewake, that is
what it is currently already there.

well, if we take that path, we should at least choose a better naming
then '_fw'!

> 
> > 
> > It is up to the caller using the '_fw' functions to take care of
> > the forcewake.
> > 
> > > I had understood that this was only the
> > > case because we didn't want to thrash the forcewake when we're
> > > accessing ranges that need it several times in a row.  Though this kind
> > > of thing could be done by using a timer to add quiescence.
> > 
> > so we already have the need for the case where forcewake is not needed
> > underneath, so the simplicity here might be to have just one single kind
> > of mmio functions and not 2.
> > 
> > > 
> > > 
> > > > GT MMIO operations are very limited to small usage during init, reset
> > > > and resume. And the underneath range seems like an overkill and historically
> > > > brought us many trouble.
> > > 
> > > I think the implicit handling could also take care of the state (i.e.
> > > whether the HW is "initialized enough" to need the forcewake) and use
> > > it only when needed.
> > 
> > not possible. Because we don't know who or what woke up that block. It might
> > be a firmware underneath. So if we trust that the block is enabled and avoid
> > getting the forcewake, then we are at risk of the domain get shut off in the
> > middle of the operation.
> > 
> > > 
> > > 
> > > > Again, I could be easily pursued to the opposite direction of the intrinsic
> > > > forcewake, but so far with the current arguments that we have at the table
> > > > I prefer to stick with the caller's responsibility on the forcewake.
> > > > 
> > > > If this 'wakelock' is something new that is bigger than display and that
> > > > maybe justifies the intrinsic forcewake, then we probably need more
> > > > information and details on the wakelock.
> > > > 
> > > > But if it is a display only thing as it looks like, I don't see why it
> > > > couldn't simply live in the inte_de wrapper that calls xe_mmio...
> > > 
> > > Okay, so there seems to be a lot of history, complications and legacy
> > > in the forecewake implementation that I have overlooked.  Though I tend
> > > to disagree that the callers should know and take care of all this.  To
> > > me, there should be a component that provides all this hardware access
> > > without the callers having to know all the intricacies and details of
> > > the HW implementation, such as what and when we need to have forcewake
> > > protection, which domains to use etc.
> > 
> > In general this is the part that I pretty much agree with you.
> > But this hidden magic underneath already brought us many trouble with
> > missing cases, only because the ranges implementation or even the bspec
> > were outdated. While if we had a simple wake all domain or we were used
> > to think about domain when implementing new mmio calls for new hw, we
> > would had saved a lot of time.
> 
> No, this is backwards.  Although the cpp macros are a bit ugly (and
> could probably be replaced by regular non-macro functions at this
> point), the range table approach has been an absolute life saver for
> maintaing the i915 driver.  

now we are talking about the right points in this thread :)

> 
> The bspec being wrong is not a concern here.  If the bspec is wrong,
> then you're going to get the wrong behavior regardless of whether you
> handle it explicitly (at callsite) or implicitly (in table).  The
> difference is that once the problem is identified and the bspec fixed,
> you can make one very simple change to a table rather than needing to
> audit every single register access in the driver looking for callsites
> that need to be updated.

good point!

> 
> The real concern is that in the long term it's pretty much impossible
> for the callsites to know what forcewake domain(s) are appropriate for a
> given register access since register ranges move between domains from
> platform to platform.  It's more of an issue for the media engines than
> for render vs gt domains, but in general just because some register is
> in the "GT" domain today doesn't mean that it won't move to "RENDER" or
> "NEWDOMAIN" on the next platform down the road.  When you enable that
> new platform in the future, it's much easier to create (and review) one
> centralized table that matches the bspec rather than needing to go
> through every single register read/write in the entire driver to see if
> any of them need to grab additional/different forcewake domains.

another good point.

> 
> Honestly I think the decision to not use forcewake tables in Xe is
> pretty crazy.  It may work out okay at the moment because we're only
> actively working on a small handful of platforms with few forcewake
> deltas, but over time that's going to change.  Also, right now there are
> places where Xe is just being lazy and grabbing all domains because it's
> too much of a hassle to figure out the platform-appropriate domains, but
> if we wind up doing stuff like that at runtime it's going to mean we're
> needlessly powering up unused hardware units which will be bad for
> real-world power usage.

Since our usage is so limited on that, there shouldn't be a big power
impact. Specially in the long run or in the certification scenarios.
However, we might be thoughtful about power consumption. Every single
Watt means, right?! If we can save even a little bit, let's save.

> 
> > 
> > > 
> > > And this is what I had understood from Matt's proposal.  The caller
> > > would just say "I'm display" (with an xe_mmio_for_display() call or
> > > whatever the wrapper would be called) and then access registers or make
> > > larger MMIO operations using function pointers that were assigned by
> > > this initial "identification" call.  These ops could then take care of
> > > whatever is needed for these operations.
> > 
> > no no, his idea was simply to avoid display code or even display wrapper
> > have to have to think about the GT at all. But for me the 'device' portion
> > of his proposal should be enough to cover the display and the display
> > won't be needed.
> > 
> > In general, if caller know that the MMIO is for a given GT it calls the
> > xe_mmio_gt(gt, ...). If the caller knows that it is MMIO for a given Tile it calls
> > the xe_mmio_tile(tile, ...) if it knows that it is for the device it calls
> > xe_mmio_device(xe, ...)
> > 
> > But those have nothing to do with the forcewake anyway. Likely for all the
> > GTs and maybe even for some Tile ones you would still need to grab the forcewake
> > and orthogonal to the discussion if it is inside or outside...
> > 
> > The device likely doesn't have to grab any forcewake, but if it is display
> > apparently you would need the wakelock, but that it could be outside that
> > as well anyway.
> 
> Yeah, it sounds like the direction we're going now is that display code
> is either going to remain part of i915, or maybe become its own
> standalone thing at some point, so I don't think we'll actually have
> display MMIO accesses from within drivers/gpu/drm/xe itself.  The non-GT
> register accesses in the Xe code will be sgunit registers, so the
> tile-centric accessor should be sufficient (or device-centric in rare
> cases).
> 
> > 
> > > 
> > > If we had this, then the wakelock implementation would be handled
> > > inside these ops for display, without the display itself having to know
> > > about access details.
> > 
> > But it is a display thing, why do you need to abstract the display thing
> > underneath the MMIO accesses?
> > 
> > > 
> > > But maybe I misunderstood the proposal.  And, if this is not the plan,
> > > then the only way to do it is to add the "wakelock" logic to the
> > > display orthogonally to the general MMIO access operations, which I
> > > wanted to avoid.
> > 
> > well, let's have it inside intel_de_ and we have only one implementation.
> > no port needed. Regardless of the future of the xe_mmio or the future
> > of xe_forcewake.
> 
> Implementing it solely at the intel_de layer sounds reasonable to me as
> well.

yeap, they appear to be orthogonal discussions. Even going with the
intrinsic forcewake inside xe_mmio, I still believe that the right place
for this wakelock is inside intel_de anyway.

> 
> 
> Matt
> 
> > 
> > > 
> > > --
> > > Cheers,
> > > Luca.
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-17 15:12                               ` Rodrigo Vivi
@ 2023-10-19  8:43                                 ` Luca Coelho
  2023-10-19 13:50                                   ` Rodrigo Vivi
  0 siblings, 1 reply; 25+ messages in thread
From: Luca Coelho @ 2023-10-19  8:43 UTC (permalink / raw)
  To: Rodrigo Vivi, Matt Roper
  Cc: Ville Syrjälä,
	Jani Nikula, Lucas De Marchi, Matthew Auld, intel-xe

On Tue, 2023-10-17 at 11:12 -0400, Rodrigo Vivi wrote:
> On Mon, Oct 16, 2023 at 05:58:41PM -0700, Matt Roper wrote:
> > On Mon, Oct 16, 2023 at 06:10:14PM -0400, Rodrigo Vivi wrote:
> > > On Tue, Oct 17, 2023 at 12:33:39AM +0300, Luca Coelho wrote:
> > > 
> > > > But maybe I misunderstood the proposal.  And, if this is not the plan,
> > > > then the only way to do it is to add the "wakelock" logic to the
> > > > display orthogonally to the general MMIO access operations, which I
> > > > wanted to avoid.
> > > 
> > > well, let's have it inside intel_de_ and we have only one implementation.
> > > no port needed. Regardless of the future of the xe_mmio or the future
> > > of xe_forcewake.
> > 
> > Implementing it solely at the intel_de layer sounds reasonable to me as
> > well.
> 
> yeap, they appear to be orthogonal discussions. Even going with the
> intrinsic forcewake inside xe_mmio, I still believe that the right place
> for this wakelock is inside intel_de anyway.

Thanks for all the comments and helping me understand this a bit
better.  The way I saw it was that Xe would be where underlying HW
access is implemented, so to me it would make sense to have this HW
access restriction (regardless of being used only by the display)
there.  I don't think it's a "display thing", but a HW limitation that
affects only the display.

In any case, doing it entirely in intel_de is probably the easiest
thing to do, so let's go with that.

--
Cheers,
Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio.
  2023-10-19  8:43                                 ` Luca Coelho
@ 2023-10-19 13:50                                   ` Rodrigo Vivi
  0 siblings, 0 replies; 25+ messages in thread
From: Rodrigo Vivi @ 2023-10-19 13:50 UTC (permalink / raw)
  To: Luca Coelho
  Cc: Ville Syrjälä,
	Jani Nikula, Lucas De Marchi, Matthew Auld, Matt Roper, intel-xe

On Thu, Oct 19, 2023 at 11:43:10AM +0300, Luca Coelho wrote:
> On Tue, 2023-10-17 at 11:12 -0400, Rodrigo Vivi wrote:
> > On Mon, Oct 16, 2023 at 05:58:41PM -0700, Matt Roper wrote:
> > > On Mon, Oct 16, 2023 at 06:10:14PM -0400, Rodrigo Vivi wrote:
> > > > On Tue, Oct 17, 2023 at 12:33:39AM +0300, Luca Coelho wrote:
> > > > 
> > > > > But maybe I misunderstood the proposal.  And, if this is not the plan,
> > > > > then the only way to do it is to add the "wakelock" logic to the
> > > > > display orthogonally to the general MMIO access operations, which I
> > > > > wanted to avoid.
> > > > 
> > > > well, let's have it inside intel_de_ and we have only one implementation.
> > > > no port needed. Regardless of the future of the xe_mmio or the future
> > > > of xe_forcewake.
> > > 
> > > Implementing it solely at the intel_de layer sounds reasonable to me as
> > > well.
> > 
> > yeap, they appear to be orthogonal discussions. Even going with the
> > intrinsic forcewake inside xe_mmio, I still believe that the right place
> > for this wakelock is inside intel_de anyway.
> 
> Thanks for all the comments and helping me understand this a bit
> better.  The way I saw it was that Xe would be where underlying HW
> access is implemented, so to me it would make sense to have this HW
> access restriction (regardless of being used only by the display)
> there.  I don't think it's a "display thing", but a HW limitation that
> affects only the display.

I believe the best way to see this is the display driver driving the
display IP block, regardless of which driver it is 'paired' with.

So, it drives the hardware...  at least the display block of the hardware.

Then, the side driver provides a path to the basic hw *access* and
basic *resouces*, only because we are in the same pci card and share
some of the resources.

> 
> In any case, doing it entirely in intel_de is probably the easiest
> thing to do, so let's go with that.
> 
> --
> Cheers,
> Luca.

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2023-10-19 13:51 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-22 22:15 [Intel-xe] [RFC] drm/xe: A minimal assert for some forcewake domain on xe_mmio Rodrigo Vivi
2023-05-22 22:17 ` [Intel-xe] ✓ CI.Patch_applied: success for " Patchwork
2023-05-22 22:19 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-05-22 22:23 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-05-23  3:28 ` [Intel-xe] [RFC] " Matt Roper
2023-05-23 13:56   ` Matthew Brost
2023-05-23 16:38     ` Matt Roper
2023-05-23 23:52       ` Matthew Brost
2023-10-09  9:22         ` Luca Coelho
2023-10-09 21:15           ` Rodrigo Vivi
2023-10-10  7:00             ` Luca Coelho
2023-10-10  7:26               ` Luca Coelho
2023-10-12 19:58                 ` Rodrigo Vivi
2023-10-12 20:04               ` Rodrigo Vivi
2023-10-16 10:22                 ` Luca Coelho
2023-10-16 18:09                   ` Rodrigo Vivi
2023-10-16 19:40                     ` Luca Coelho
2023-10-16 20:08                       ` Rodrigo Vivi
2023-10-16 21:33                         ` Luca Coelho
2023-10-16 22:10                           ` Rodrigo Vivi
2023-10-17  0:58                             ` Matt Roper
2023-10-17 15:12                               ` Rodrigo Vivi
2023-10-19  8:43                                 ` Luca Coelho
2023-10-19 13:50                                   ` Rodrigo Vivi
2023-05-24 17:06   ` Rodrigo Vivi

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.