Re: [Intel-gfx] [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Hi, On 2023/9/5 23:05, Thomas Zimmermann wrote: You might have found a bug in the ast driver. Ast has means to detect if the device has been POSTed and maybe do that. If this doesn't work correctly, it needs a fix. That sounds fine. The bug is not a big deal, I'm just take it as an example and report it to you. But a real fix can be complex, because there are quite a lot of servers ship with ASpeed BMC hardware. Honestly I don't have the time fix it on formal way. I have already tons patches in pending and I will focus on solve VGAARB related problem. Because I want to test your patch occasionally. So this series is useful for myself at corner cases.
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: Drop force_probe requirement
== Series Details == Series: drm/i915/mtl: Drop force_probe requirement URL : https://patchwork.freedesktop.org/series/123303/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13599_full -> Patchwork_123303v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_123303v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_123303v1_full, please notify your bug team (lgci.bug.fil...@intel.com) to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 10) -- Additional (1): shard-rkl0 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_123303v1_full: ### IGT changes ### Possible regressions * igt@gem_create@create-ext-cpu-access-big: - shard-dg2: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123303v1/shard-dg2-11/igt@gem_cre...@create-ext-cpu-access-big.html * igt@gen9_exec_parse@allowed-single: - shard-apl: [PASS][2] -> [INCOMPLETE][3] +1 other test incomplete [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-apl1/igt@gen9_exec_pa...@allowed-single.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123303v1/shard-apl1/igt@gen9_exec_pa...@allowed-single.html New tests - New tests have been introduced between CI_DRM_13599_full and Patchwork_123303v1_full: ### New IGT tests (107) ### * igt@kms_cursor_crc@cursor-offscreen-128x128@pipe-a-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-offscreen-128x128@pipe-d-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-offscreen-256x85@pipe-d-hdmi-a-2: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-offscreen-64x21@pipe-a-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-offscreen-64x21@pipe-d-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-offscreen-64x64@pipe-a-hdmi-a-2: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-offscreen-64x64@pipe-a-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-offscreen-64x64@pipe-b-hdmi-a-2: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-offscreen-64x64@pipe-d-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-onscreen-256x85@pipe-a-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-onscreen-256x85@pipe-d-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-onscreen-64x21@pipe-a-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-onscreen-64x21@pipe-d-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-random-128x42@pipe-a-hdmi-a-2: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-random-128x42@pipe-a-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-random-128x42@pipe-b-hdmi-a-2: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-random-128x42@pipe-d-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-random-256x256@pipe-a-hdmi-a-3: - Statuses : 2 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-random-256x256@pipe-d-hdmi-a-3: - Statuses : 2 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-random-256x85@pipe-d-hdmi-a-2: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-random-64x64@pipe-a-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-random-64x64@pipe-d-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-rapid-movement-128x128@pipe-a-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-rapid-movement-128x128@pipe-d-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-rapid-movement-256x256@pipe-a-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-rapid-movement-256x256@pipe-d-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-rapid-movement-256x85@pipe-a-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_cursor_crc@cursor-rapid-movement-256x85@pipe-d-hdmi-a-3: - Statuses : 1 pass(s) - Exec time: [0.0] s *
Re: [Intel-gfx] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Hi, On 2023/9/5 22:52, Alex Williamson wrote: On Tue, 5 Sep 2023 03:57:15 +0800 Sui Jingfeng wrote: From: Sui Jingfeng On a machine with multiple GPUs, a Linux user has no control over which one is primary at boot time. This series tries to solve above mentioned problem by introduced the ->be_primary() function stub. The specific device drivers can provide an implementation to hook up with this stub by calling the vga_client_register() function. Once the driver bound the device successfully, VGAARB will call back to the device driver. To query if the device drivers want to be primary or not. Device drivers can just pass NULL if have no such needs. Please note that: 1) The ARM64, Loongarch, Mips servers have a lot PCIe slot, and I would like to mount at least three video cards. 2) Typically, those non-86 machines don't have a good UEFI firmware support, which doesn't support select primary GPU as firmware stage. Even on x86, there are old UEFI firmwares which already made undesired decision for you. 3) This series is attempt to solve the remain problems at the driver level, while another series[1] of me is target to solve the majority of the problems at device level. Tested (limited) on x86 with four video card mounted, Intel UHD Graphics 630 is the default boot VGA, successfully override by ast2400 with ast.modeset=10 append at the kernel cmd line. $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] In all my previous experiments with VGA routing and IGD I found that IGD can't actually release VGA routing and Intel confirmed the hardware doesn't have the ability to do so. Which model of the IGD you are using? even for the IGD in Atom D2550, the legacy 128KB VGA memory range can be tuned to be mapped to IGD or to the DMI Interface. See the 1.7.3.2 section of the N2000 datasheet[1]. If a specific model of Intel has a bug in the VGA routing hardware logic unit, I would like to ignore it. Or switch to the UEFI firmware on such hardware. It is the hardware engineer's responsibility, I will not worry about it. Thanks for you tell this. [1] https://www.intel.com/content/dam/doc/datasheet/atom-d2000-n2000-vol-2-datasheet.pdf It will always be primary from a VGA routing perspective. Was this actually tested with non-UEFI? As you already said, the generous Intel already have confirmed that the hardware defect. So probably this is a good chance to switch to UEFI to solve the problem. Then, no testing for legacy is needed. I suspect it might only work in UEFI mode where we probably don't actually have a dependency on VGA routing. This is essentially why vfio requires UEFI ROMs when assigning GPUs to VMs, VGA routing is too broken to use on Intel systems with IGD. Thanks, Thanks for you tell me this. To be honest, I have only tested my patch on machines with UEFI firmware. Since UEFI because the main stream, but if this patch is really useful for majority machine, I'm satisfied. The results is not too bad. Thanks. Alex
Re: [Intel-gfx] [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Hi, On 2023/9/5 23:05, Thomas Zimmermann wrote: However, on modern Linux systems the primary display does not really exist. 'Primary' is the device that is available via VGA, VESA or EFI. I may miss the point, what do you means by choose the word "modern"? Are you trying to tell me that X server is too old and Wayland is the modern display server? Our drivers don't use these interfaces, but the native registers. Yes and no? Yes for the machine with the UEFI firmware, but I not sure if this statement is true for the machine with the legacy firmware. As the display controller in the ASpeed BMC is VGA compatible. Therefore, in theory, it should works with the VGA console on the machine with another VGA compatible video card. So the ast_vga_set_decode() function provided in the 0007 patch probably useful on legacy firmware environment. To be honest, I have tested this on various machine with UEFI firmware. But I didn't realized that I should do the testing on legacy firmware environment before sending this patch. It seems that the testing effort needed are quite exhausting, since all my machines come with the UEFI firmware. So is it OK to leave the legacy part to someone else who interested in it? Probably Alex is more professional at legacy VGA routing stuff? :-)
Re: [Intel-gfx] [PATCH v4 0/4] drm/i915/tc: some clean-ups in max lane count handling code
On Fri, Aug 25, 2023 at 11:16:34AM +0300, Luca Coelho wrote: Hi, Here are four patches with some clean-ups in the code that handles the max lane count of Type-C connections. This is done mostly in preparation for a new way to read the pin assignments and lane count in future devices. In v2: * Fix some rebasing damage. In v3: * Fixed "assigment" typo, as reported by checkpatch. In v4: * Rebased; * Renamed port_max to lane_max (Lucas' comment). Please review. All patches are reviewed. I looked to the CI results and none of the regressions seem related. Pushed. Thanks Lucas De Marchi
[Intel-gfx] ✗ Fi.CI.BAT: failure for Apply Wa_16018031267 / Wa_16018063123
== Series Details == Series: Apply Wa_16018031267 / Wa_16018063123 URL : https://patchwork.freedesktop.org/series/123306/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13599 -> Patchwork_123306v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_123306v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_123306v1, please notify your bug team (lgci.bug.fil...@intel.com) to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/index.html Participating hosts (38 -> 38) -- Additional (1): bat-dg2-8 Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_123306v1: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s0@smem: - bat-jsl-3: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@gem_contexts: - bat-mtlp-8: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-mtlp-8/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-mtlp-8/igt@i915_selftest@live@gem_contexts.html Known issues Here are the changes found in Patchwork_123306v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0@smem: - bat-dg2-9: [PASS][5] -> [INCOMPLETE][6] ([i915#6311]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html * igt@gem_mmap@basic: - bat-dg2-8: NOTRUN -> [SKIP][7] ([i915#4083]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-dg2-8/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-dg2-8: NOTRUN -> [SKIP][8] ([i915#4077]) +2 other tests skip [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-dg2-8/igt@gem_mmap_...@basic.html * igt@gem_tiled_pread_basic: - bat-dg2-8: NOTRUN -> [SKIP][9] ([i915#4079]) +1 other test skip [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-dg2-8/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg2-8: NOTRUN -> [SKIP][10] ([i915#5354] / [i915#7561]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-dg2-8/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg2-8: NOTRUN -> [SKIP][11] ([i915#6621]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-dg2-8/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gem_contexts: - bat-atsm-1: [PASS][12] -> [DMESG-FAIL][13] ([i915#7913]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html - bat-dg2-9: [PASS][14] -> [DMESG-FAIL][15] ([i915#7913]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg2-9/igt@i915_selftest@live@gem_contexts.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-dg2-9/igt@i915_selftest@live@gem_contexts.html - bat-dg2-11: [PASS][16] -> [DMESG-FAIL][17] ([i915#7913]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg2-11/igt@i915_selftest@live@gem_contexts.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-dg2-11/igt@i915_selftest@live@gem_contexts.html - bat-dg2-8: NOTRUN -> [DMESG-FAIL][18] ([i915#7913]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-dg2-8/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@live@hangcheck: - bat-dg2-8: NOTRUN -> [ABORT][19] ([i915#7913]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123306v1/bat-dg2-8/igt@i915_selftest@l...@hangcheck.html * igt@i915_suspend@basic-s3-without-i915: - bat-jsl-3: [PASS][20] -> [FAIL][21] ([fdo#103375]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html [21]:
Re: [Intel-gfx] [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
On 2023/9/5 23:05, Thomas Zimmermann wrote: Hi Am 05.09.23 um 15:30 schrieb suijingfeng: Hi, On 2023/9/5 18:45, Thomas Zimmermann wrote: Hi Am 04.09.23 um 21:57 schrieb Sui Jingfeng: From: Sui Jingfeng On a machine with multiple GPUs, a Linux user has no control over which one is primary at boot time. This series tries to solve above mentioned If anything, the primary graphics adapter is the one initialized by the firmware. I think our boot-up graphics also make this assumption implicitly. Yes, but by the time of DRM drivers get loaded successfully,the boot-up graphics already finished. Firmware framebuffer device already get killed by the drm_aperture_remove_conflicting_pci_framebuffers() function (or its siblings). So, this series is definitely not to interact with the firmware framebuffer Yes and no. The helpers you mention will attempt to remove the firmware framebuffer on the given PCI device. If you have multiple PCI devices, the other devices would not be affected. Yes and no. For the yes part: drm_aperture_remove_conflicting_pci_framebuffers() only kill the conflict one. But for a specific machine with the modern UEFI firmware, there should be only one firmware framebuffer driver. That shoudd be the EFIFB(UEFI GOP). I do have multiple PCI devices, but I don't understand when and why a system will have more than one firmware framebuffer. Even for the machines with the legacy BIOS, the fixed VGA aperture address range can only be owned by one firmware driver. It is just that we need to handle the routing, the ->set_decode() callback of vga_client_register() is used to do such work. Am I correct?
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Apply Wa_16018031267 / Wa_16018063123
== Series Details == Series: Apply Wa_16018031267 / Wa_16018063123 URL : https://patchwork.freedesktop.org/series/123306/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Apply Wa_16018031267 / Wa_16018063123
== Series Details == Series: Apply Wa_16018031267 / Wa_16018063123 URL : https://patchwork.freedesktop.org/series/123306/ State : warning == Summary == Error: dim checkpatch failed dfea335bb6dc drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123 -:10: WARNING:BAD_SIGN_OFF: Co-developed-by and Signed-off-by: name/email do not match #10: Co-developed-by: Nirmoy Das Signed-off-by: Jonathan Cavitt -:35: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'engine' - possible side-effects? #35: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:86: +#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \ + IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \ + engine->class == COPY_ENGINE_CLASS) -:35: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'engine' may be better as '(engine)' to avoid precedence issues #35: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:86: +#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \ + IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \ + engine->class == COPY_ENGINE_CLASS) -:68: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #68: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:836: + GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1); -:184: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #184: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:1462: + GEM_BUG_ON(cs - start > I915_GTT_PAGE_SIZE / sizeof(*cs)); total: 0 errors, 3 warnings, 2 checks, 317 lines checked 9db977171e14 drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsc: cleanups
== Series Details == Series: drm/i915/dsc: cleanups URL : https://patchwork.freedesktop.org/series/123291/ State : success == Summary == CI Bug Log - changes from CI_DRM_13599_full -> Patchwork_123291v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_123291v1_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@blit-reloc-keep-cache: - shard-dg2: NOTRUN -> [SKIP][1] ([i915#8411]) +1 other test skip [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-dg2-11/igt@api_intel...@blit-reloc-keep-cache.html * igt@gem_ccs@suspend-resume@tile4-compressed-compfmt0-lmem0-lmem0: - shard-dg2: [PASS][2] -> [INCOMPLETE][3] ([i915#6311]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-dg2-11/igt@gem_ccs@suspend-res...@tile4-compressed-compfmt0-lmem0-lmem0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-dg2-2/igt@gem_ccs@suspend-res...@tile4-compressed-compfmt0-lmem0-lmem0.html * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-snb: NOTRUN -> [DMESG-WARN][4] ([i915#8841]) +5 other tests dmesg-warn [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-snb6/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_ctx_persistence@engines-mixed: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +1 other test skip [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-snb6/igt@gem_ctx_persiste...@engines-mixed.html * igt@gem_ctx_persistence@heartbeat-hostile: - shard-dg2: NOTRUN -> [SKIP][6] ([i915#8555]) +2 other tests skip [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-dg2-1/igt@gem_ctx_persiste...@heartbeat-hostile.html * igt@gem_ctx_sseu@mmap-args: - shard-dg2: NOTRUN -> [SKIP][7] ([i915#280]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-dg2-11/igt@gem_ctx_s...@mmap-args.html * igt@gem_eio@hibernate: - shard-dg2: [PASS][8] -> [ABORT][9] ([i915#7975] / [i915#8213]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-dg2-11/igt@gem_...@hibernate.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-dg2-6/igt@gem_...@hibernate.html * igt@gem_eio@reset-stress: - shard-snb: NOTRUN -> [FAIL][10] ([i915#8898]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-snb7/igt@gem_...@reset-stress.html * igt@gem_eio@unwedge-stress: - shard-dg1: [PASS][11] -> [FAIL][12] ([i915#5784]) +1 other test fail [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-dg1-14/igt@gem_...@unwedge-stress.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-dg1-15/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@bonded-false-hang: - shard-dg2: NOTRUN -> [SKIP][13] ([i915#4812]) +1 other test skip [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-dg2-5/igt@gem_exec_balan...@bonded-false-hang.html * igt@gem_exec_capture@capture-invisible@lmem0: - shard-dg2: NOTRUN -> [SKIP][14] ([i915#6334]) +1 other test skip [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-dg2-5/igt@gem_exec_capture@capture-invisi...@lmem0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-rkl: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-rkl-7/igt@gem_exec_fair@basic-p...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-rkl-2/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fence@syncobj-backward-timeline-chain-engines: - shard-snb: NOTRUN -> [SKIP][17] ([fdo#109271]) +297 other tests skip [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-snb4/igt@gem_exec_fe...@syncobj-backward-timeline-chain-engines.html * igt@gem_exec_flush@basic-wb-prw-default: - shard-dg2: NOTRUN -> [SKIP][18] ([i915#3539] / [i915#4852]) +3 other tests skip [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-dg2-11/igt@gem_exec_fl...@basic-wb-prw-default.html * igt@gem_exec_gttfill@multigpu-basic: - shard-dg2: NOTRUN -> [SKIP][19] ([i915#7697]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/shard-dg2-1/igt@gem_exec_gttf...@multigpu-basic.html * igt@gem_exec_reloc@basic-write-read-active: - shard-dg2: NOTRUN -> [SKIP][20] ([i915#3281]) +8 other tests skip [20]:
Re: [Intel-gfx] [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Hi, On 2023/9/5 23:05, Thomas Zimmermann wrote: However, on modern Linux systems the primary display does not really exist. No, it do exist. X server need to know which one is the primary GPU. The '*' character at the of (4@0:0:0) PCI device is the Primary. The '*' denote primary, see the log below. (II) xfree86: Adding drm device (/dev/dri/card2) (II) xfree86: Adding drm device (/dev/dri/card0) (II) Platform probe for /sys/devices/pci:00/:00:1c.5/:003:00.0/:04:00.0/drm/card0 (II) xfree86: Adding drm device (/dev/dri/card3) (II) Platform probe for /sys/devices/pci:00/:00:1c.6/:005:00.0/drm/card3 (--) PCI: (0@0:2:0) 8086:3e91:8086:3e91 rev 0, Mem @ 0xdb00/16216, 0xa000/536870912, I/O @ 0xf000/64, BIOS @ 0x/131072 (--) PCI: (1@0:0:0) 1002:6771:1043:8636 rev 0, Mem @ 0xc000/2688435456, 0xdf22/131072, I/O @ 0xe000/256, BIOS @ 0x/131072 (--) PCI:*(4@0:0:0) 1a03:2000:1a03:2000 rev 48, Mem @ 0xde00/166777216, 0xdf02/131072, I/O @ 0xc000/128, BIOS @ 0x/131072 (--) PCI: (5@0:0:0) 10de:1288:174b:b324 rev 161, Mem @ 0xdc00/116777216, 0xd000/134217728, 0xd800/33554432, I/O @ 0xb000/128, BIOS @@0x/524288 The modesetting driver of X server will create framebuffer on the primary video adapter. If a 2D video adapter (like the aspeed BMC) is not the primary, then it probably will not be used. The only chance to be able to display something is to functional as a output slave. But the output slave technology need the PRIME support for cross driver buffer sharing. So, there do have some difference between the primary and non-primary video adapters. 'Primary' is the device that is available via VGA, VESA or EFI. Our drivers don't use these interfaces, but the native registers. As you said yourself, these firmware devices (VGA, VESA, EFI) are removed ASAP by the native drivers.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Drop force_probe requirement
== Series Details ==
Series: drm/i915/mtl: Drop force_probe requirement
URL : https://patchwork.freedesktop.org/series/123303/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13599 -> Patchwork_123303v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123303v1/index.html
Participating hosts (38 -> 37)
--
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_123303v1 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-hsw-4770:[PASS][1] -> [FAIL][2] ([i915#8293])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-hsw-4770/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123303v1/fi-hsw-4770/boot.html
### IGT changes ###
Issues hit
* igt@kms_psr@sprite_plane_onoff:
- bat-rplp-1: NOTRUN -> [ABORT][3] ([i915#8442] / [i915#8668] /
[i915#8712])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123303v1/bat-rplp-1/igt@kms_psr@sprite_plane_onoff.html
Possible fixes
* igt@kms_chamelium_frames@dp-crc-fast:
- {bat-dg2-13}: [DMESG-WARN][4] ([Intel XE#485]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg2-13/igt@kms_chamelium_fra...@dp-crc-fast.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123303v1/bat-dg2-13/igt@kms_chamelium_fra...@dp-crc-fast.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-dp6:
- bat-adlp-11:[FAIL][6] ([i915#6121]) -> [PASS][7] +4 other tests
pass
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp6.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123303v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp6.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-dp5:
- bat-adlp-11:[DMESG-WARN][8] ([i915#6868]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp5.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123303v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp5.html
Warnings
* igt@kms_psr@cursor_plane_move:
- bat-rplp-1: [ABORT][10] ([i915#9243]) -> [SKIP][11] ([i915#1072])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123303v1/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[Intel XE#485]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/485
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#6121]: https://gitlab.freedesktop.org/drm/intel/issues/6121
[i915#6868]: https://gitlab.freedesktop.org/drm/intel/issues/6868
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
[i915#8442]: https://gitlab.freedesktop.org/drm/intel/issues/8442
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
[i915#8712]: https://gitlab.freedesktop.org/drm/intel/issues/8712
[i915#9243]: https://gitlab.freedesktop.org/drm/intel/issues/9243
Build changes
-
* Linux: CI_DRM_13599 -> Patchwork_123303v1
CI-20190529: 20190529
CI_DRM_13599: 58fe10f34e80d0eeb5609128faa135260623a715 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7468: 7468
Patchwork_123303v1: 58fe10f34e80d0eeb5609128faa135260623a715 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
a2451f29836d drm/i915/mtl: Drop force_probe requirement
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123303v1/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for Drop caches per GT
== Series Details ==
Series: Drop caches per GT
URL : https://patchwork.freedesktop.org/series/123301/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13599 -> Patchwork_123301v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/index.html
Participating hosts (38 -> 38)
--
Additional (1): fi-kbl-soraka
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_123301v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
other tests skip
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][3] ([i915#5334] / [i915#7872])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][4] ([i915#1886] / [i915#7913])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271]) +8 other tests skip
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- bat-adlp-11:[PASS][6] -> [DMESG-WARN][7] ([i915#6868])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/bat-adlp-11/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
* igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: NOTRUN -> [ABORT][8] ([i915#8442] / [i915#8469] /
[i915#8668])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html
* igt@kms_psr@sprite_plane_onoff:
- bat-rplp-1: NOTRUN -> [SKIP][9] ([i915#1072])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/bat-rplp-1/igt@kms_psr@sprite_plane_onoff.html
Possible fixes
* igt@kms_chamelium_edid@hdmi-edid-read:
- {bat-dg2-13}: [DMESG-WARN][10] ([i915#7952]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html
* igt@kms_chamelium_frames@dp-crc-fast:
- {bat-dg2-13}: [DMESG-WARN][12] ([Intel XE#485]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg2-13/igt@kms_chamelium_fra...@dp-crc-fast.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/bat-dg2-13/igt@kms_chamelium_fra...@dp-crc-fast.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-dp6:
- bat-adlp-11:[FAIL][14] ([i915#6121]) -> [PASS][15] +4 other tests
pass
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp6.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp6.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-dp5:
- bat-adlp-11:[DMESG-WARN][16] ([i915#6868]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp5.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp5.html
* igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [FAIL][18] ([IGT#3] / [i915#6121]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
Warnings
* igt@kms_psr@cursor_plane_move:
- bat-rplp-1: [ABORT][20] ([i915#9243]) -> [SKIP][21] ([i915#1072])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123301v1/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top (rev2)
== Series Details == Series: drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top (rev2) URL : https://patchwork.freedesktop.org/series/122970/ State : success == Summary == CI Bug Log - changes from CI_DRM_13599_full -> Patchwork_122970v2_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_122970v2_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_122970v2_full, please notify your bug team (lgci.bug.fil...@intel.com) to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 9) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_122970v2_full: ### IGT changes ### Warnings * igt@gem_eio@in-flight-suspend: - shard-rkl: [FAIL][1] ([fdo#103375]) -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-rkl-6/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-rkl-6/igt@gem_...@in-flight-suspend.html Known issues Here are the changes found in Patchwork_122970v2_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@blit-reloc-keep-cache: - shard-dg2: NOTRUN -> [SKIP][3] ([i915#8411]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-dg2-6/igt@api_intel...@blit-reloc-keep-cache.html * igt@drm_fdinfo@virtual-busy-all: - shard-dg2: NOTRUN -> [SKIP][4] ([i915#8414]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-dg2-6/igt@drm_fdi...@virtual-busy-all.html * igt@gem_ccs@suspend-resume@linear-compressed-compfmt0-smem-lmem0: - shard-dg2: [PASS][5] -> [INCOMPLETE][6] ([i915#6311] / [i915#7297]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-dg2-11/igt@gem_ccs@suspend-res...@linear-compressed-compfmt0-smem-lmem0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-dg2-10/igt@gem_ccs@suspend-res...@linear-compressed-compfmt0-smem-lmem0.html * igt@gem_ctx_persistence@heartbeat-hang: - shard-dg2: NOTRUN -> [SKIP][7] ([i915#8555]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-dg2-6/igt@gem_ctx_persiste...@heartbeat-hang.html * igt@gem_ctx_persistence@idempotent: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-snb2/igt@gem_ctx_persiste...@idempotent.html * igt@gem_ctx_sseu@mmap-args: - shard-dg2: NOTRUN -> [SKIP][9] ([i915#280]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-dg2-6/igt@gem_ctx_s...@mmap-args.html * igt@gem_eio@in-flight-contexts-immediate: - shard-mtlp: [PASS][10] -> [INCOMPLETE][11] ([i915#8503]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-mtlp-2/igt@gem_...@in-flight-contexts-immediate.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-mtlp-4/igt@gem_...@in-flight-contexts-immediate.html * igt@gem_eio@reset-stress: - shard-snb: NOTRUN -> [FAIL][12] ([i915#8898]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-snb2/igt@gem_...@reset-stress.html * igt@gem_eio@unwedge-stress: - shard-dg1: [PASS][13] -> [FAIL][14] ([i915#5784]) +1 other test fail [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-dg1-14/igt@gem_...@unwedge-stress.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-dg1-19/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@bonded-true-hang: - shard-dg2: NOTRUN -> [SKIP][15] ([i915#4812]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-dg2-6/igt@gem_exec_balan...@bonded-true-hang.html * igt@gem_exec_capture@pi@vecs0: - shard-mtlp: [PASS][16] -> [FAIL][17] ([i915#4475] / [i915#7765]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-mtlp-1/igt@gem_exec_capture@p...@vecs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-mtlp-5/igt@gem_exec_capture@p...@vecs0.html * igt@gem_exec_fair@basic-pace: - shard-dg2: NOTRUN -> [SKIP][18] ([i915#3539]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/shard-dg2-6/igt@gem_exec_f...@basic-pace.html * igt@gem_exec_fence@syncobj-backward-timeline-chain-engines: - shard-snb: NOTRUN -> [SKIP][19] ([fdo#109271]) +191 other tests skip [19]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsc: cleanups
== Series Details == Series: drm/i915/dsc: cleanups URL : https://patchwork.freedesktop.org/series/123291/ State : success == Summary == CI Bug Log - changes from CI_DRM_13599 -> Patchwork_123291v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/index.html Participating hosts (38 -> 38) -- Additional (1): bat-dg2-8 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_123291v1 that come from known issues: ### CI changes ### Issues hit * boot: - fi-hsw-4770:[PASS][1] -> [FAIL][2] ([i915#8293]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-hsw-4770/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/fi-hsw-4770/boot.html ### IGT changes ### Issues hit * igt@gem_mmap@basic: - bat-dg2-8: NOTRUN -> [SKIP][3] ([i915#4083]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-8/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-dg2-8: NOTRUN -> [SKIP][4] ([i915#4077]) +2 other tests skip [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-8/igt@gem_mmap_...@basic.html * igt@gem_tiled_pread_basic: - bat-dg2-8: NOTRUN -> [SKIP][5] ([i915#4079]) +1 other test skip [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-8/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg2-8: NOTRUN -> [SKIP][6] ([i915#5354] / [i915#7561]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-8/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg2-8: NOTRUN -> [SKIP][7] ([i915#6621]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-8/igt@i915_pm_...@basic-api.html * igt@i915_suspend@basic-s3-without-i915: - bat-dg2-8: NOTRUN -> [SKIP][8] ([i915#6645]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - bat-dg2-8: NOTRUN -> [SKIP][9] ([i915#5190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg2-8: NOTRUN -> [SKIP][10] ([i915#4215] / [i915#5190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@framebuffer-vs-set-tiling: - bat-dg2-8: NOTRUN -> [SKIP][11] ([i915#4212]) +7 other tests skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-8/igt@kms_addfb_ba...@framebuffer-vs-set-tiling.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-dg2-8: NOTRUN -> [SKIP][12] ([i915#4103] / [i915#4213]) +1 other test skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - bat-dg2-8: NOTRUN -> [SKIP][13] ([fdo#109285]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-8/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-dg2-8: NOTRUN -> [SKIP][14] ([i915#5274]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-8/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-xr24@pipe-c-dp-5: - bat-adlp-11:[PASS][15] -> [DMESG-WARN][16] ([i915#4309]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-x...@pipe-c-dp-5.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-adlp-11/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-x...@pipe-c-dp-5.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-adlp-9: NOTRUN -> [SKIP][17] ([i915#3546]) +2 other tests skip [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html - bat-dg2-11: NOTRUN -> [SKIP][18] ([i915#1845]) +3 other tests skip [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123291v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-c-dp-5: - bat-adlp-11:[PASS][19] -> [ABORT][20] ([i915#8668]) [19]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for PCI/VGA: Allowing the user to select the primary video adapter at boot time (rev2)
== Series Details == Series: PCI/VGA: Allowing the user to select the primary video adapter at boot time (rev2) URL : https://patchwork.freedesktop.org/series/123258/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/123258/revisions/2/mbox/ not applied Applying: PCI/VGA: Allowing the user to select the primary video adapter at boot time Applying: drm/nouveau: Implement .be_primary() callback Applying: drm/radeon: Implement .be_primary() callback error: corrupt patch at line 4 error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 drm/radeon: Implement .be_primary() callback When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Build failed, no error log produced
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dsc: cleanups
== Series Details == Series: drm/i915/dsc: cleanups URL : https://patchwork.freedesktop.org/series/123291/ State : warning == Summary == Error: dim checkpatch failed 485ced3f5bf8 drm/i915/dsc: improve clarify of the pps reg read/write helpers 21be8697dfba drm/i915/dsc: have intel_dsc_pps_read_and_verify() return the value 97b57a727048 drm/i915/dsc: have intel_dsc_pps_read() return the value 76972ba1a5e1 drm/i915/dsc: rename pps write to intel_dsc_pps_write() 8fbce99af540 drm/i915/dsc: drop redundant = 0 assignments 2f5aa6719445 drm/i915/dsc: clean up pps comments f0a412705ae1 drm/i915/dsc: add the PPS number to the register content macros -:236: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #236: FILE: drivers/gpu/drm/i915/display/intel_vdsc.c:908: + vdsc_cfg->first_line_bpg_offset = REG_FIELD_GET(DSC_PPS6_FIRST_LINE_BPG_OFFSET_MASK, pps_temp); -:267: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #267: FILE: drivers/gpu/drm/i915/display/intel_vdsc.c:932: + vdsc_cfg->rc_quant_incr_limit0 = REG_FIELD_GET(DSC_PPS10_RC_QUANT_INC_LIMIT0_MASK, pps_temp); -:268: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #268: FILE: drivers/gpu/drm/i915/display/intel_vdsc.c:933: + vdsc_cfg->rc_quant_incr_limit1 = REG_FIELD_GET(DSC_PPS10_RC_QUANT_INC_LIMIT1_MASK, pps_temp); -:281: WARNING:LONG_LINE: line length of 105 exceeds 100 columns #281: FILE: drivers/gpu/drm/i915/display/intel_vdsc.c:944: + vdsc_cfg->second_line_bpg_offset = REG_FIELD_GET(DSC_PPS17_SL_BPG_OFFSET_MASK, pps_temp); -:289: WARNING:LONG_LINE: line length of 105 exceeds 100 columns #289: FILE: drivers/gpu/drm/i915/display/intel_vdsc.c:950: + vdsc_cfg->second_line_offset_adj = REG_FIELD_GET(DSC_PPS18_SL_OFFSET_ADJ_MASK, pps_temp); -:349: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #349: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:102: +#define DSC_PPS3_SLICE_WIDTH(slice_width) REG_FIELD_PREP(DSC_PPS3_SLICE_WIDTH_MASK, slice_width) -:350: WARNING:LONG_LINE: line length of 104 exceeds 100 columns #350: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:103: +#define DSC_PPS3_SLICE_HEIGHT(slice_height) REG_FIELD_PREP(DSC_PPS3_SLICE_HEIGHT_MASK, slice_height) -:362: WARNING:LONG_LINE: line length of 106 exceeds 100 columns #362: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:110: +#define DSC_PPS4_INITIAL_XMIT_DELAY(xmit_delay) REG_FIELD_PREP(DSC_PPS4_INITIAL_XMIT_DELAY_MASK, \ -:372: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #372: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:116: +#define DSC_PPS5_SCALE_DEC_INT(scale_dec) REG_FIELD_PREP(DSC_PPS5_SCALE_DEC_INT_MASK, scale_dec) -:373: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #373: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:117: +#define DSC_PPS5_SCALE_INC_INT(scale_inc) REG_FIELD_PREP(DSC_PPS5_SCALE_INC_INT_MASK, scale_inc) -:389: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #389: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:124: +#define DSC_PPS6_FLATNESS_MAX_QP(max_qp) REG_FIELD_PREP(DSC_PPS6_FLATNESS_MAX_QP_MASK, max_qp) -:390: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #390: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:125: +#define DSC_PPS6_FLATNESS_MIN_QP(min_qp) REG_FIELD_PREP(DSC_PPS6_FLATNESS_MIN_QP_MASK, min_qp) -:391: WARNING:LONG_LINE: line length of 109 exceeds 100 columns #391: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:126: +#define DSC_PPS6_FIRST_LINE_BPG_OFFSET(offset) REG_FIELD_PREP(DSC_PPS6_FIRST_LINE_BPG_OFFSET_MASK, \ -:403: WARNING:LONG_LINE: line length of 104 exceeds 100 columns #403: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:134: +#define DSC_PPS7_NFL_BPG_OFFSET(bpg_offset) REG_FIELD_PREP(DSC_PPS7_NFL_BPG_OFFSET_MASK, bpg_offset) -:414: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #414: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:140: +#define DSC_PPS8_INITIAL_OFFSET(initial_offset) REG_FIELD_PREP(DSC_PPS8_INITIAL_OFFSET_MASK, \ -:441: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #441: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:158: +#define DSC_PPS10_RC_TARGET_OFF_LOW(rc_tgt_off_low) REG_FIELD_PREP(DSC_PPS10_RC_TGT_OFF_LOW_MASK, \ -:444: WARNING:LONG_LINE: line length of 104 exceeds 100 columns #444: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:160: +#define DSC_PPS10_RC_TARGET_OFF_HIGH(rc_tgt_off_high) REG_FIELD_PREP(DSC_PPS10_RC_TGT_OFF_HIGH_MASK, \ -:448: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #448: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:162: +#define DSC_PPS10_RC_QUANT_INC_LIMIT1(lim) REG_FIELD_PREP(DSC_PPS10_RC_QUANT_INC_LIMIT1_MASK, lim) -:449: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #449: FILE: drivers/gpu/drm/i915/display/intel_vdsc_regs.h:163:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: fix rb-tree/llist/list confusion
== Series Details ==
Series: drm/i915: fix rb-tree/llist/list confusion
URL : https://patchwork.freedesktop.org/series/123282/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13599 -> Patchwork_123282v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_123282v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_123282v1, please notify your bug team
(lgci.bug.fil...@intel.com) to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123282v1/index.html
Participating hosts (38 -> 36)
--
Missing(2): fi-bsw-nick fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_123282v1:
### IGT changes ###
Possible regressions
* igt@gem_huc_copy@huc-copy:
- bat-mtlp-8: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-mtlp-8/igt@gem_huc_c...@huc-copy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123282v1/bat-mtlp-8/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@requests:
- bat-mtlp-8: [PASS][3] -> [ABORT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-mtlp-8/igt@i915_selftest@l...@requests.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123282v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html
* igt@kms_pipe_crc_basic@read-crc@pipe-d-dp-5:
- bat-adlp-11:[PASS][5] -> [ABORT][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_pipe_crc_basic@read-...@pipe-d-dp-5.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123282v1/bat-adlp-11/igt@kms_pipe_crc_basic@read-...@pipe-d-dp-5.html
Known issues
Here are the changes found in Patchwork_123282v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@workarounds:
- bat-adlm-1: [PASS][7] -> [INCOMPLETE][8] ([i915#4983] /
[i915#7677])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlm-1/igt@i915_selftest@l...@workarounds.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123282v1/bat-adlm-1/igt@i915_selftest@l...@workarounds.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][9] ([i915#1845]) +3 other tests skip
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123282v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][10] -> [ABORT][11] ([i915#8442] / [i915#8668])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123282v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
Possible fixes
* igt@kms_chamelium_edid@hdmi-edid-read:
- {bat-dg2-13}: [DMESG-WARN][12] ([i915#7952]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123282v1/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html
* igt@kms_chamelium_frames@dp-crc-fast:
- {bat-dg2-13}: [DMESG-WARN][14] ([Intel XE#485]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg2-13/igt@kms_chamelium_fra...@dp-crc-fast.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123282v1/bat-dg2-13/igt@kms_chamelium_fra...@dp-crc-fast.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-dp6:
- bat-adlp-11:[FAIL][16] ([i915#6121]) -> [PASS][17] +4 other tests
pass
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp6.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123282v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp6.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-dp5:
- bat-adlp-11:[DMESG-WARN][18] ([i915#6868]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp5.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123282v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp5.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[Intel XE#485]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/485
[i915#1845]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: fix rb-tree/llist/list confusion
== Series Details == Series: drm/i915: fix rb-tree/llist/list confusion URL : https://patchwork.freedesktop.org/series/123282/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: fix rb-tree/llist/list confusion
== Series Details ==
Series: drm/i915: fix rb-tree/llist/list confusion
URL : https://patchwork.freedesktop.org/series/123282/
State : warning
== Summary ==
Error: dim checkpatch failed
f1aa77045061 Revert "drm/i915: Use uabi engines for the default engine map"
-:41: ERROR:BAD_SIGN_OFF: Unrecognized email address: 'sanitiy checks in
grsecurity'
#41:
Reported-by: sanitiy checks in grsecurity
-:41: WARNING:BAD_REPORTED_BY_LINK: Reported-by: should be immediately followed
by Closes: with a URL to the report
#41:
Reported-by: sanitiy checks in grsecurity
Fixes: 1ec23ed7126e ("drm/i915: Use uabi engines for the default engine map")
-:76: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of
BUG() or variants
#76: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:1120:
+ GEM_BUG_ON(engine->legacy_idx >= I915_NUM_ENGINES);
total: 1 errors, 2 warnings, 0 checks, 27 lines checked
ca8889ed26b0 drm/i915: Clarify type evolution of uabi_node/uabi_engines
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top (rev2)
== Series Details ==
Series: drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top (rev2)
URL : https://patchwork.freedesktop.org/series/122970/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13599 -> Patchwork_122970v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/index.html
Participating hosts (38 -> 38)
--
Additional (1): fi-kbl-soraka
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_122970v2 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-hsw-4770:[PASS][1] -> [FAIL][2] ([i915#8293])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-hsw-4770/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/fi-hsw-4770/boot.html
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
other tests skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][5] ([i915#1886] / [i915#7913])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@workarounds:
- bat-rpls-1: [PASS][6] -> [INCOMPLETE][7] ([i915#4983] /
[i915#7677])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-rpls-1/igt@i915_selftest@l...@workarounds.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/bat-rpls-1/igt@i915_selftest@l...@workarounds.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271]) +8 other tests skip
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: NOTRUN -> [SKIP][9] ([i915#1072]) +1 other test skip
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: NOTRUN -> [ABORT][10] ([i915#8260] / [i915#8668])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
Possible fixes
* igt@kms_chamelium_edid@hdmi-edid-read:
- {bat-dg2-13}: [DMESG-WARN][11] ([i915#7952]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html
* igt@kms_chamelium_frames@dp-crc-fast:
- {bat-dg2-13}: [DMESG-WARN][13] ([Intel XE#485]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg2-13/igt@kms_chamelium_fra...@dp-crc-fast.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/bat-dg2-13/igt@kms_chamelium_fra...@dp-crc-fast.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-dp6:
- bat-adlp-11:[FAIL][15] ([i915#6121]) -> [PASS][16] +4 other tests
pass
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp6.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp6.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-dp5:
- bat-adlp-11:[DMESG-WARN][17] ([i915#6868]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp5.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp5.html
Warnings
* igt@kms_psr@cursor_plane_move:
- bat-rplp-1: [ABORT][19] ([i915#9243]) -> [SKIP][20] ([i915#1072])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v2/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[Intel XE#485]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/485
[fdo#109271]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top (rev2)
== Series Details == Series: drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top (rev2) URL : https://patchwork.freedesktop.org/series/122970/ State : warning == Summary == Error: dim checkpatch failed 824eede2a92d drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top -:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #14: i915 :00:02.0: [drm:i915_init_ggtt [i915]] Failed to reserve top of GGTT for GuC -:65: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #65: FILE: drivers/gpu/drm/i915/gt/intel_ggtt.c:533: + GEM_BUG_ON(ggtt->vm.total <= GUC_TOP_RESERVE_SIZE); total: 0 errors, 2 warnings, 0 checks, 37 lines checked
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tc: some clean-ups in max lane count handling code (rev5)
== Series Details == Series: drm/i915/tc: some clean-ups in max lane count handling code (rev5) URL : https://patchwork.freedesktop.org/series/120980/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13599_full -> Patchwork_120980v5_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_120980v5_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_120980v5_full, please notify your bug team (lgci.bug.fil...@intel.com) to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 9) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_120980v5_full: ### IGT changes ### Possible regressions * igt@gem_create@create-ext-cpu-access-big: - shard-dg2: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-dg2-6/igt@gem_cre...@create-ext-cpu-access-big.html * igt@gen9_exec_parse@allowed-single: - shard-glk: [PASS][2] -> [INCOMPLETE][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-glk4/igt@gen9_exec_pa...@allowed-single.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-glk1/igt@gen9_exec_pa...@allowed-single.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-dp-1: - shard-apl: NOTRUN -> [INCOMPLETE][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-apl6/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-dp-1.html Known issues Here are the changes found in Patchwork_120980v5_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@blit-reloc-keep-cache: - shard-dg2: NOTRUN -> [SKIP][5] ([i915#8411]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-dg2-5/igt@api_intel...@blit-reloc-keep-cache.html * igt@drm_fdinfo@virtual-busy-all: - shard-dg2: NOTRUN -> [SKIP][6] ([i915#8414]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-dg2-11/igt@drm_fdi...@virtual-busy-all.html * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-snb: NOTRUN -> [DMESG-WARN][7] ([i915#8841]) +3 other tests dmesg-warn [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-snb4/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_ctx_isolation@preservation-s3@vcs1: - shard-mtlp: [PASS][8] -> [FAIL][9] ([fdo#103375]) +4 other tests fail [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-mtlp-8/igt@gem_ctx_isolation@preservation...@vcs1.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-mtlp-5/igt@gem_ctx_isolation@preservation...@vcs1.html * igt@gem_ctx_param@invalid-size-set: - shard-mtlp: [PASS][10] -> [DMESG-WARN][11] ([i915#2017]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-mtlp-1/igt@gem_ctx_pa...@invalid-size-set.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-mtlp-2/igt@gem_ctx_pa...@invalid-size-set.html * igt@gem_ctx_persistence@engines-mixed: - shard-snb: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1099]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-snb4/igt@gem_ctx_persiste...@engines-mixed.html * igt@gem_ctx_persistence@heartbeat-hostile: - shard-dg2: NOTRUN -> [SKIP][13] ([i915#8555]) +2 other tests skip [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-dg2-2/igt@gem_ctx_persiste...@heartbeat-hostile.html * igt@gem_ctx_sseu@mmap-args: - shard-dg2: NOTRUN -> [SKIP][14] ([i915#280]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-dg2-5/igt@gem_ctx_s...@mmap-args.html * igt@gem_eio@suspend: - shard-mtlp: [PASS][15] -> [FAIL][16] ([i915#6121] / [i915#7052]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-mtlp-8/igt@gem_...@suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-mtlp-5/igt@gem_...@suspend.html * igt@gem_eio@unwedge-stress: - shard-dg1: [PASS][17] -> [FAIL][18] ([i915#5784]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/shard-dg1-14/igt@gem_...@unwedge-stress.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-dg1-18/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@bonded-true-hang: - shard-dg2: NOTRUN -> [SKIP][19] ([i915#4812]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/shard-dg2-5/igt@gem_exec_balan...@bonded-true-hang.html
[Intel-gfx] ✗ Fi.CI.BAT: failure for Apply Wa_16018031267 / Wa_16018063123 (rev2)
== Series Details == Series: Apply Wa_16018031267 / Wa_16018063123 (rev2) URL : https://patchwork.freedesktop.org/series/123182/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13599 -> Patchwork_123182v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_123182v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_123182v2, please notify your bug team (lgci.bug.fil...@intel.com) to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/index.html Participating hosts (38 -> 39) -- Additional (2): fi-kbl-soraka bat-dg2-8 Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_123182v2: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gt_lrc: - bat-dg1-5: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg1-5/igt@i915_selftest@live@gt_lrc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/bat-dg1-5/igt@i915_selftest@live@gt_lrc.html - fi-rkl-11600: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-rkl-11600/igt@i915_selftest@live@gt_lrc.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/fi-rkl-11600/igt@i915_selftest@live@gt_lrc.html - bat-mtlp-8: [PASS][5] -> [ABORT][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-mtlp-8/igt@i915_selftest@live@gt_lrc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/bat-mtlp-8/igt@i915_selftest@live@gt_lrc.html - bat-adlm-1: [PASS][7] -> [ABORT][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlm-1/igt@i915_selftest@live@gt_lrc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/bat-adlm-1/igt@i915_selftest@live@gt_lrc.html - fi-tgl-1115g4: [PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-tgl-1115g4/igt@i915_selftest@live@gt_lrc.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/fi-tgl-1115g4/igt@i915_selftest@live@gt_lrc.html - bat-rpls-1: [PASS][11] -> [ABORT][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html Known issues Here are the changes found in Patchwork_123182v2 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2190]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +3 other tests skip [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_mmap@basic: - bat-dg2-8: NOTRUN -> [SKIP][15] ([i915#4083]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/bat-dg2-8/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-dg2-8: NOTRUN -> [SKIP][16] ([i915#4077]) +2 other tests skip [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/bat-dg2-8/igt@gem_mmap_...@basic.html * igt@gem_tiled_pread_basic: - bat-dg2-8: NOTRUN -> [SKIP][17] ([i915#4079]) +1 other test skip [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/bat-dg2-8/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg2-8: NOTRUN -> [SKIP][18] ([i915#5354] / [i915#7561]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/bat-dg2-8/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg2-8: NOTRUN -> [SKIP][19] ([i915#6621]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/bat-dg2-8/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [PASS][20] -> [DMESG-FAIL][21] ([i915#5334]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123182v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_lrc: - bat-adlp-9: [PASS][22] -> [ABORT][23] ([i915#7913]) [22]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Apply Wa_16018031267 / Wa_16018063123 (rev2)
== Series Details == Series: Apply Wa_16018031267 / Wa_16018063123 (rev2) URL : https://patchwork.freedesktop.org/series/123182/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Apply Wa_16018031267 / Wa_16018063123 (rev2)
== Series Details == Series: Apply Wa_16018031267 / Wa_16018063123 (rev2) URL : https://patchwork.freedesktop.org/series/123182/ State : warning == Summary == Error: dim checkpatch failed f68c376c1650 drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123 -:10: WARNING:BAD_SIGN_OFF: Co-developed-by and Signed-off-by: name/email do not match #10: Co-developed-by: Nirmoy Das Signed-off-by: Jonathan Cavitt -:35: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'engine' - possible side-effects? #35: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:86: +#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \ + IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \ + engine->class == COPY_ENGINE_CLASS) -:35: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'engine' may be better as '(engine)' to avoid precedence issues #35: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:86: +#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \ + IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \ + engine->class == COPY_ENGINE_CLASS) -:68: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #68: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:836: + GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1); -:187: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #187: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:1465: + GEM_BUG_ON(cs - start > I915_GTT_PAGE_SIZE / sizeof(*cs)); total: 0 errors, 3 warnings, 2 checks, 323 lines checked 02741bdb605f drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123
[Intel-gfx] ✗ Fi.CI.BAT: failure for Panel replay phase1 implementation (rev7)
== Series Details == Series: Panel replay phase1 implementation (rev7) URL : https://patchwork.freedesktop.org/series/94470/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13599 -> Patchwork_94470v7 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_94470v7 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_94470v7, please notify your bug team (lgci.bug.fil...@intel.com) to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/index.html Participating hosts (38 -> 37) -- Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_94470v7: ### IGT changes ### Possible regressions * igt@debugfs_test@read_all_entries: - fi-hsw-4770:[PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-hsw-4770/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/fi-hsw-4770/igt@debugfs_test@read_all_entries.html - fi-ivb-3770:[PASS][3] -> [ABORT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-ivb-3770/igt@debugfs_test@read_all_entries.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/fi-ivb-3770/igt@debugfs_test@read_all_entries.html - fi-elk-e7500: [PASS][5] -> [ABORT][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-elk-e7500/igt@debugfs_test@read_all_entries.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/fi-elk-e7500/igt@debugfs_test@read_all_entries.html - fi-ilk-650: [PASS][7] -> [ABORT][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-ilk-650/igt@debugfs_test@read_all_entries.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/fi-ilk-650/igt@debugfs_test@read_all_entries.html - fi-blb-e6850: [PASS][9] -> [ABORT][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-blb-e6850/igt@debugfs_test@read_all_entries.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/fi-blb-e6850/igt@debugfs_test@read_all_entries.html * igt@gem_exec_suspend@basic-s0@smem: - bat-jsl-3: [PASS][11] -> [INCOMPLETE][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html Known issues Here are the changes found in Patchwork_94470v7 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_backlight@basic-brightness@edp-1: - bat-adlp-6: NOTRUN -> [ABORT][13] ([i915#8668]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/bat-adlp-6/igt@i915_pm_backlight@basic-brightn...@edp-1.html * igt@i915_pm_rpm@basic-pci-d3-state: - bat-adln-1: NOTRUN -> [ABORT][14] ([i915#7977] / [i915#8469] / [i915#8668]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/bat-adln-1/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_suspend@basic-s3-without-i915: - bat-jsl-3: [PASS][15] -> [FAIL][16] ([fdo#103375]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_psr@cursor_plane_move: - bat-adln-1: [PASS][17] -> [SKIP][18] ([i915#1072]) +1 other test skip [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adln-1/igt@kms_psr@cursor_plane_move.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/bat-adln-1/igt@kms_psr@cursor_plane_move.html - fi-skl-6600u: [PASS][19] -> [SKIP][20] ([fdo#109271]) +3 other tests skip [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-skl-6600u/igt@kms_psr@cursor_plane_move.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/fi-skl-6600u/igt@kms_psr@cursor_plane_move.html * igt@kms_psr@primary_mmap_gtt: - bat-adln-1: NOTRUN -> [SKIP][21] ([i915#1072]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_94470v7/bat-adln-1/igt@kms_psr@primary_mmap_gtt.html * igt@kms_psr@sprite_plane_onoff: - bat-mtlp-8: [PASS][22] -> [SKIP][23] ([i915#1072]) +2 other tests skip [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-mtlp-8/igt@kms_psr@sprite_plane_onoff.html [23]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Panel replay phase1 implementation (rev7)
== Series Details ==
Series: Panel replay phase1 implementation (rev7)
URL : https://patchwork.freedesktop.org/series/94470/
State : warning
== Summary ==
Error: dim checkpatch failed
df46f8fc2937 drm/panelreplay: dpcd register definition for panelreplay
a4cfe5eb05ad drm/i915/psr: Move psr specific dpcd init into own function
-:55: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED'
#55: FILE: drivers/gpu/drm/i915/display/intel_psr.c:500:
+ if (DISPLAY_VER(i915) >= 9 &&
(intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
total: 0 errors, 0 warnings, 1 checks, 70 lines checked
c3af614a25dd drm/i915/panelreplay: Initializaton and compute config for panel
replay
-:362: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'intel_dp' - possible
side-effects?
#362: FILE: drivers/gpu/drm/i915/display/intel_psr.h:24:
+#define CAN_PSR(intel_dp) ((intel_dp)->psr.sink_support && \
+ (intel_dp)->psr.source_support)
-:365: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'intel_dp' - possible
side-effects?
#365: FILE: drivers/gpu/drm/i915/display/intel_psr.h:27:
+#define CAN_PANEL_REPLAY(intel_dp) ((intel_dp)->psr.sink_panel_replay_support
&& \
+ (intel_dp)->psr.source_panel_replay_support)
total: 0 errors, 0 warnings, 2 checks, 290 lines checked
a5ed631e2878 drm/i915/panelreplay: Enable panel replay dpcd initialization for
DP
2d8dc819debf drm/i915/panelreplay: enable/disable panel replay
a12bb3cdd5f6 drm/i915/panelreplay: Debugfs support for panel replay
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Panel replay phase1 implementation (rev7)
== Series Details == Series: Panel replay phase1 implementation (rev7) URL : https://patchwork.freedesktop.org/series/94470/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tc: some clean-ups in max lane count handling code (rev5)
== Series Details ==
Series: drm/i915/tc: some clean-ups in max lane count handling code (rev5)
URL : https://patchwork.freedesktop.org/series/120980/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13599 -> Patchwork_120980v5
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/index.html
Participating hosts (38 -> 38)
--
Additional (1): fi-kbl-soraka
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_120980v5 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-hsw-4770:[PASS][1] -> [FAIL][2] ([i915#8293])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/fi-hsw-4770/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/fi-hsw-4770/boot.html
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3@smem:
- bat-mtlp-8: [PASS][3] -> [FAIL][4] ([fdo#103375]) +6 other tests
fail
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3
other tests skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886] / [i915#7913])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271]) +8 other tests skip
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][9] ([i915#1845]) +3 other tests skip
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][10] -> [ABORT][11] ([i915#8442] / [i915#8668])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
Possible fixes
* igt@kms_chamelium_edid@hdmi-edid-read:
- {bat-dg2-13}: [DMESG-WARN][12] ([i915#7952]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html
* igt@kms_chamelium_frames@dp-crc-fast:
- {bat-dg2-13}: [DMESG-WARN][14] ([Intel XE#485]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-dg2-13/igt@kms_chamelium_fra...@dp-crc-fast.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/bat-dg2-13/igt@kms_chamelium_fra...@dp-crc-fast.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-dp6:
- bat-adlp-11:[FAIL][16] ([i915#6121]) -> [PASS][17] +4 other tests
pass
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp6.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp6.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-dp5:
- bat-adlp-11:[DMESG-WARN][18] ([i915#6868]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13599/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp5.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v5/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp5.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[Intel XE#485]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/485
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1845]:
[Intel-gfx] [PATCH v6 0/2] Apply Wa_16018031267 / Wa_16018063123
Apply Wa_16018031267 / Wa_16018063123. This necessitates submitting a fastcolor blit as WABB and setting the copy engine arbitration to round-robin mode. v2: - Rename old platform check in second patch to match declaration in first patch. - Refactor second patch name to match first patch. v3: - Move NEEDS_FASTCOLOR_BLT_WABB to intel_gt.h. - Refactor NEEDS_FASTCOLOR_BLT_WABB to make it more streamlined to use. - Stop dividing PAGE_SIZE by sizeof(u32) when computing ctx_bb_ggtt_addr for lrc_setup_bb_per_ctx. - Reduce comment complexity. - Fix several checkpatch warnings. v4: - Actually stop dividing PAGE_SIZE by sizeof(u32) when computing ctx_bb_ggtt_addr for lrc_setup_bb_per_ctx. v5: - Stop dividing PAGE_SIZE by sizeof(u32) in check_ring_start during lrc live selftest. v6: - Append MI_BATCH_BUFFER_END to end of all PER_CTX_BB command streams. - No longer skip on empty, as command stream will never be empty (always contains at least MI_BATCH_BUFFER_END). - No longer append MI_NOOP until cachline aligned (was a fragment from INDIRECT_CTX setup). Signed-off-by: Nirmoy Das Signed-off-by: Jonathan Cavitt CC: Joonas Lahtinen CC: Rodrigo Vivi CC: Tomasz Mistat CC: Gregory F Germano CC: Matt Roper CC: James Ausmus Jonathan Cavitt (2): drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123 drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123 drivers/gpu/drm/i915/gt/intel_engine_regs.h | 6 ++ drivers/gpu/drm/i915/gt/intel_gt.h | 4 + drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 + drivers/gpu/drm/i915/gt/intel_lrc.c | 101 +++- drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 + drivers/gpu/drm/i915/gt/selftest_lrc.c | 65 + 6 files changed, 162 insertions(+), 21 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH v6 1/2] drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123
Apply WABB blit for Wa_16018031267 / Wa_16018063123.
Additionally, update the lrc selftest to exercise the new
WABB changes.
Co-developed-by: Nirmoy Das
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 3 +
drivers/gpu/drm/i915/gt/intel_gt.h | 4 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 101 +++-
drivers/gpu/drm/i915/gt/selftest_lrc.c | 65 +
5 files changed, 154 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index 6b9d9f8376692..2e06bea73297a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -118,6 +118,9 @@
#define CCID_EXTENDED_STATE_RESTORE BIT(2)
#define CCID_EXTENDED_STATE_SAVE BIT(3)
#define RING_BB_PER_CTX_PTR(base) _MMIO((base) + 0x1c0) /* gen8+
*/
+#define PER_CTX_BB_FORCE BIT(2)
+#define PER_CTX_BB_VALID BIT(0)
+
#define RING_INDIRECT_CTX(base)_MMIO((base) + 0x1c4)
/* gen8+ */
#define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8) /* gen8+
*/
#define ECOSKPD(base) _MMIO((base) + 0x1d0)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 239848bcb2a42..40cc0005dd735 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -83,6 +83,10 @@ struct drm_printer;
##__VA_ARGS__); \
} while (0)
+#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \
+ IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
+ engine->class == COPY_ENGINE_CLASS)
+
static inline bool gt_is_root(struct intel_gt *gt)
{
return !gt->info.id;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index def7dd0eb6f19..4917633f299dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -307,6 +307,8 @@ enum intel_gt_scratch_field {
/* 8 bytes */
INTEL_GT_SCRATCH_FIELD_COHERENTL3_WA = 256,
+
+ INTEL_GT_SCRATCH_FIELD_DUMMY_BLIT = 384,
};
#define intel_gt_support_legacy_fencing(gt) ((gt)->ggtt->num_fences > 0)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 967fe4d77a874..08783e2631ced 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -828,6 +828,18 @@ lrc_ring_indirect_offset_default(const struct
intel_engine_cs *engine)
return 0;
}
+static void
+lrc_setup_bb_per_ctx(u32 *regs,
+const struct intel_engine_cs *engine,
+u32 ctx_bb_ggtt_addr)
+{
+ GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1);
+ regs[lrc_ring_wa_bb_per_ctx(engine) + 1] =
+ ctx_bb_ggtt_addr |
+ PER_CTX_BB_FORCE |
+ PER_CTX_BB_VALID;
+}
+
static void
lrc_setup_indirect_ctx(u32 *regs,
const struct intel_engine_cs *engine,
@@ -997,7 +1009,13 @@ static u32 context_wa_bb_offset(const struct
intel_context *ce)
return PAGE_SIZE * ce->wa_bb_page;
}
-static u32 *context_indirect_bb(const struct intel_context *ce)
+/*
+ * per_ctx below determines which WABB section is used.
+ * When true, the function returns the location of the
+ * PER_CTX_BB. When false, the function returns the
+ * location of the INDIRECT_CTX.
+ */
+static u32 *context_wabb(const struct intel_context *ce, bool per_ctx)
{
void *ptr;
@@ -1006,6 +1024,7 @@ static u32 *context_indirect_bb(const struct
intel_context *ce)
ptr = ce->lrc_reg_state;
ptr -= LRC_STATE_OFFSET; /* back to start of context image */
ptr += context_wa_bb_offset(ce);
+ ptr += per_ctx ? PAGE_SIZE : 0;
return ptr;
}
@@ -1082,7 +1101,8 @@ __lrc_alloc_state(struct intel_context *ce, struct
intel_engine_cs *engine)
if (GRAPHICS_VER(engine->i915) >= 12) {
ce->wa_bb_page = context_size / PAGE_SIZE;
- context_size += PAGE_SIZE;
+ /* INDIRECT_CTX and PER_CTX_BB need separate pages. */
+ context_size += PAGE_SIZE * 2;
}
if (intel_context_is_parent(ce) && intel_engine_uses_guc(engine)) {
@@ -1370,12 +1390,86 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context
*ce, u32 *cs)
return gen12_emit_aux_table_inv(ce->engine, cs);
}
+static u32 *xehp_emit_fastcolor_blt_wabb(const struct intel_context *ce, u32
*cs)
+{
+ struct intel_gt *gt = ce->engine->gt;
+ int mocs = gt->mocs.uc_index << 1;
+ u32 addr = intel_gt_scratch_offset(gt,
INTEL_GT_SCRATCH_FIELD_DUMMY_BLIT);
+
+ /**
+* Wa_16018031267 / Wa_16018063123 requires that SW
[Intel-gfx] [PATCH v6 2/2] drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123
Set copy engine arbitration into round robin mode for part of Wa_16018031267 / Wa_16018063123 mitigation. Signed-off-by: Nirmoy Das Signed-off-by: Jonathan Cavitt --- drivers/gpu/drm/i915/gt/intel_engine_regs.h | 3 +++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 + 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h b/drivers/gpu/drm/i915/gt/intel_engine_regs.h index 2e06bea73297a..823c6c40213f5 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h @@ -124,6 +124,9 @@ #define RING_INDIRECT_CTX(base)_MMIO((base) + 0x1c4) /* gen8+ */ #define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8) /* gen8+ */ #define ECOSKPD(base) _MMIO((base) + 0x1d0) +#define XEHP_BLITTER_SCHEDULING_MODE_MASKREG_GENMASK(12, 11) +#define XEHP_BLITTER_ROUND_ROBIN_MODE\ + REG_FIELD_PREP(XEHP_BLITTER_SCHEDULING_MODE_MASK, 1) #define ECO_CONSTANT_BUFFER_SR_DISABLE REG_BIT(4) #define ECO_GATING_CX_ONLY REG_BIT(3) #define GEN6_BLITTER_FBC_NOTIFY REG_BIT(3) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 864d41bcf6bbe..e891e7c8c0787 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -2769,6 +2769,11 @@ xcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal) RING_SEMA_WAIT_POLL(engine->mmio_base), 1); } + /* Wa_16018031267, Wa_16018063123 */ + if (NEEDS_FASTCOLOR_BLT_WABB(engine)) + wa_masked_field_set(wal, ECOSKPD(engine->mmio_base), + XEHP_BLITTER_SCHEDULING_MODE_MASK, + XEHP_BLITTER_ROUND_ROBIN_MODE); } static void -- 2.25.1
[Intel-gfx] [PATCH] drm/i915/mtl: Drop force_probe requirement
Meteorlake has been very usable for a while now, all of uapi changes
related to fundamental platform usage have been finalized and all
required firmware blobs are available. Recent CI results have also
been healthy, so we're ready to drop the force_probe requirement and
enable the platform by default.
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Jani Nikula
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/i915_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index df7c261410f7..fe748906c06f 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -836,7 +836,6 @@ static const struct intel_device_info mtl_info = {
.has_pxp = 1,
.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
- .require_force_probe = 1,
MTL_CACHELEVEL,
};
--
2.34.1
[Intel-gfx] [PATCH 2/2] drm/i915: When asked to drop the cache, do it per GT
When the user sends the drop caches command through the debugfs
interface, do it on all the GT's, rather than just the root GT.
Based on a patch by Tvrtko.
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3dfe8a8b7cdfe..60cdfb3e45e2a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -750,21 +750,27 @@ static int
i915_drop_caches_set(void *data, u64 val)
{
struct drm_i915_private *i915 = data;
+ struct intel_gt *gt;
unsigned int flags;
+ unsigned int i;
int ret;
drm_dbg(>drm, "Dropping caches: 0x%08llx [0x%08llx]\n",
val, val & DROP_ALL);
/* Flush all the active requests across both GT ... */
- ret = gt_drop_caches(to_gt(i915), val);
- if (ret)
- return ret;
+ for_each_gt(gt, i915, i) {
+ ret = gt_drop_caches(gt, val);
+ if (ret)
+ return ret;
+ }
/* ... then wait for idle as there may be cross-gt wakerefs. */
- ret = gt_idle(to_gt(i915), val);
- if (ret)
- return ret;
+ for_each_gt(gt, i915, i) {
+ ret = gt_idle(gt, val);
+ if (ret)
+ return ret;
+ }
fs_reclaim_acquire(GFP_KERNEL);
flags = memalloc_noreclaim_save();
--
2.40.1
[Intel-gfx] [PATCH 1/2] drm/i915: Split gt cache flushing and gt idling functions
In preparation for multi-gt cache flushing debugfs interface,
split the cache dropping function and gt idling.
Based on a patch by Tvrtko.
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 32 +
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7a90a2e32c9f1..3dfe8a8b7cdfe 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -703,11 +703,25 @@ i915_drop_caches_get(void *data, u64 *val)
return 0;
}
+static int gt_idle(struct intel_gt *gt, u64 val)
+{
+ if (val & (DROP_RETIRE | DROP_IDLE))
+ intel_gt_retire_requests(gt);
+
+ if (val & DROP_IDLE) {
+ int ret;
+
+ ret = intel_gt_pm_wait_for_idle(gt);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int
gt_drop_caches(struct intel_gt *gt, u64 val)
{
- int ret;
-
if (val & DROP_RESET_ACTIVE &&
wait_for(intel_engines_are_idle(gt), 200))
intel_gt_set_wedged(gt);
@@ -716,13 +730,9 @@ gt_drop_caches(struct intel_gt *gt, u64 val)
intel_gt_retire_requests(gt);
if (val & (DROP_IDLE | DROP_ACTIVE)) {
- ret = intel_gt_wait_for_idle(gt, MAX_SCHEDULE_TIMEOUT);
- if (ret)
- return ret;
- }
+ int ret;
- if (val & DROP_IDLE) {
- ret = intel_gt_pm_wait_for_idle(gt);
+ ret = intel_gt_wait_for_idle(gt, MAX_SCHEDULE_TIMEOUT);
if (ret)
return ret;
}
@@ -746,10 +756,16 @@ i915_drop_caches_set(void *data, u64 val)
drm_dbg(>drm, "Dropping caches: 0x%08llx [0x%08llx]\n",
val, val & DROP_ALL);
+ /* Flush all the active requests across both GT ... */
ret = gt_drop_caches(to_gt(i915), val);
if (ret)
return ret;
+ /* ... then wait for idle as there may be cross-gt wakerefs. */
+ ret = gt_idle(to_gt(i915), val);
+ if (ret)
+ return ret;
+
fs_reclaim_acquire(GFP_KERNEL);
flags = memalloc_noreclaim_save();
if (val & DROP_BOUND)
--
2.40.1
[Intel-gfx] [PATCH 0/2] Drop caches per GT
Hi, this bit of code escaped the multi-gt wave from a couple of years ago. Andi Andi Shyti (2): drm/i915: Split gt cache flushing and gt idling functions drm/i915: When asked to drop the cache, do it per GT drivers/gpu/drm/i915/i915_debugfs.c | 44 + 1 file changed, 33 insertions(+), 11 deletions(-) -- 2.40.1
Re: [Intel-gfx] [RFC, drm-misc-next v4 3/9] drm/radeon: Implement .be_primary() callback
Hi,
On 2023/9/5 13:50, Christian König wrote:
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which one
is primary at boot time.
Question is why is that useful? Should we give users the ability to
control that?
I don't see an use case for this.
On a specific machine with multiple GPUs mounted, only the
primary graphics get POST-ed (initialized) by the firmware.
Therefore the DRM drivers for the rest video cards have to
work without the prerequisite setups done by firmware, This
is called as POST.
One of the use cases is to test if a specific DRM driver
would works properly, under the circumstance of not being
POST-ed, The ast drm driver is the first one which refused
to work if not being POST-ed by the firmware.
Before apply this series, I was unable make drm/ast as the
primary video card easily. The problem is that on a multiple
video card configuration, the monitor connected with my
AST2400 card not light up. While confusing, a naive programmer
may suspect the PRIME is not working.
After applied this series and passing ast.modeset=10 on the
kernel cmd line, I found that the monitor connected with my
ast2400 video card still black, It doesn't display and It
doesn't show image to me.
While in the process of study drm/ast, I know that drm/ast
driver has the POST code shipped, See the ast_post_gpu() function.
Then, I was wondering why this function doesn't works.
After a short-time (hasty) debugging, I found that the ast_post_gpu()
function didn't get run. Because it have something to do with the
ast->config_mode. Without thinking too much, I hardcoded the
ast->config_mode as ast_use_p2a, the key point is to force the
ast_post_gpu() function to run.
```
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -132,6 +132,8 @@ static int ast_device_config_init(struct ast_device
*ast)
}
}
+ ast->config_mode = ast_use_p2a;
+
switch (ast->config_mode) {
case ast_use_defaults:
drm_info(dev, "Using default configuration\n");
```
Then, the monitor light up, it display the Ubuntu greeter to me. Therefore
my patch is useful, at least for the Linux drm driver tester and developer.
It allow programmers to test the specific part of a specific driver without
changing a line of the source code and without the need of sudo authority.
It improves the efficiency of the testing and patch verification. I know
the PrimaryGPU option of Xorg conf, but this approach will remember the
setup have been made, you need modify it with root authority each time
you want to switch the primary. But on the process of rapid developing
and/or testing for multiple video drivers, with only one computer hardware
resource available. What we really want is a one-shot command, as provided
by this series. So, this is the first use case.
The second use case is that sometime the firmware is not reliable.
While there are thousands of ARM64, PowerPC and Mips servers machine,
Most of them don't have a good UEFI firmware support. I haven't test the
drm/amdgpu and drm/radeon at my ARM64 server yet. Because this ARM64
server always use the platform(BMC) integrated display controller as primary.
The UEFI firmware of it does not provide options menu to tune.
So, for the first time, the discrete card because useless, despite more
powerful.
I will take time to carry on the testing, so I will be able to tell more
in the future.
Even on X86, when select the PEG as primary on the UEFI BIOS menu.
There is no way to tell the bios which one of my three
discrete video be the primary. Not to mention some old UEFI
firmware, which doesn't provide a setting at all.
While the benefit of my approach is the flexibility.
Yes the i915, amdgpu and radeon are good quality,
but there may have programmers want to try nouveau.
The third use case is that VGAARB is also not reliable, It will
select a wrong device as primary. Especially on Arm64, Loongarch
and mips arch etc. And the X server will use this wrong device
as primary and completely crash there. Either because of lacking
a driver or the driver has a bug which can not bear the graphic
environment up. VGAARB is firmware dependent.
My patch provide a temporary method to rescue.
The forth is probably the PRIME and reverse PRIME development
and developing driver for new video cards.
[Intel-gfx] [PATCH 8/8] drm/i915/dsc: use REG_BIT, REG_GENMASK, and friends for PPS0 and PPS1
Use the register helper macros for PPS0 and PPS1 register contents.
Cc: Suraj Kandpal
Cc: Ankit Nautiyal
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 15 +--
.../gpu/drm/i915/display/intel_vdsc_regs.h| 27 ++-
2 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 126aff804e33..5c00f7ccad7f 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -423,10 +423,10 @@ static void intel_dsc_pps_configure(const struct
intel_crtc_state *crtc_state)
int vdsc_instances_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state);
/* PPS 0 */
- pps_val = DSC_PPS0_VER_MAJ | vdsc_cfg->dsc_version_minor <<
- DSC_PPS0_VER_MIN_SHIFT |
- vdsc_cfg->bits_per_component << DSC_PPS0_BPC_SHIFT |
- vdsc_cfg->line_buf_depth << DSC_PPS0_LINE_BUF_DEPTH_SHIFT;
+ pps_val = DSC_PPS0_VER_MAJOR(1) |
+ DSC_PPS0_VER_MINOR(vdsc_cfg->dsc_version_minor) |
+ DSC_PPS0_BPC(vdsc_cfg->bits_per_component) |
+ DSC_PPS0_LINE_BUF_DEPTH(vdsc_cfg->line_buf_depth);
if (vdsc_cfg->dsc_version_minor == 2) {
pps_val |= DSC_PPS0_ALT_ICH_SEL;
if (vdsc_cfg->native_420)
@@ -857,9 +857,8 @@ static void intel_dsc_get_pps_config(struct
intel_crtc_state *crtc_state)
/* PPS 0 */
pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 0);
- vdsc_cfg->bits_per_component = (pps_temp & DSC_PPS0_BPC_MASK) >>
DSC_PPS0_BPC_SHIFT;
- vdsc_cfg->line_buf_depth =
- (pps_temp & DSC_PPS0_LINE_BUF_DEPTH_MASK) >>
DSC_PPS0_LINE_BUF_DEPTH_SHIFT;
+ vdsc_cfg->bits_per_component = REG_FIELD_GET(DSC_PPS0_BPC_MASK,
pps_temp);
+ vdsc_cfg->line_buf_depth = REG_FIELD_GET(DSC_PPS0_LINE_BUF_DEPTH_MASK,
pps_temp);
vdsc_cfg->block_pred_enable = pps_temp & DSC_PPS0_BLOCK_PREDICTION;
vdsc_cfg->convert_rgb = pps_temp & DSC_PPS0_COLOR_SPACE_CONVERSION;
vdsc_cfg->simple_422 = pps_temp & DSC_PPS0_422_ENABLE;
@@ -870,7 +869,7 @@ static void intel_dsc_get_pps_config(struct
intel_crtc_state *crtc_state)
/* PPS 1 */
pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 1);
- vdsc_cfg->bits_per_pixel = pps_temp;
+ vdsc_cfg->bits_per_pixel = REG_FIELD_GET(DSC_PPS1_BPP_MASK, pps_temp);
if (vdsc_cfg->native_420)
vdsc_cfg->bits_per_pixel >>= 1;
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc_regs.h
b/drivers/gpu/drm/i915/display/intel_vdsc_regs.h
index 92782de2b309..64f440fdc22b 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_vdsc_regs.h
@@ -73,22 +73,25 @@
#define ICL_DSC1_PPS(pipe, pps) _MMIO(_ICL_DSC1_PPS_0(pipe) +
((pps) * 4))
/* PPS 0 */
-#define DSC_PPS0_NATIVE_422_ENABLE BIT(23)
-#define DSC_PPS0_NATIVE_420_ENABLE BIT(22)
-#define DSC_PPS0_ALT_ICH_SEL (1 << 20)
-#define DSC_PPS0_VBR_ENABLE (1 << 19)
-#define DSC_PPS0_422_ENABLE (1 << 18)
-#define DSC_PPS0_COLOR_SPACE_CONVERSION (1 << 17)
-#define DSC_PPS0_BLOCK_PREDICTION(1 << 16)
-#define DSC_PPS0_LINE_BUF_DEPTH_SHIFT12
+#define DSC_PPS0_NATIVE_422_ENABLE REG_BIT(23)
+#define DSC_PPS0_NATIVE_420_ENABLE REG_BIT(22)
+#define DSC_PPS0_ALT_ICH_SEL REG_BIT(20)
+#define DSC_PPS0_VBR_ENABLE REG_BIT(19)
+#define DSC_PPS0_422_ENABLE REG_BIT(18)
+#define DSC_PPS0_COLOR_SPACE_CONVERSION REG_BIT(17)
+#define DSC_PPS0_BLOCK_PREDICTIONREG_BIT(16)
#define DSC_PPS0_LINE_BUF_DEPTH_MASK REG_GENMASK(15, 12)
-#define DSC_PPS0_BPC_SHIFT 8
+#define DSC_PPS0_LINE_BUF_DEPTH(depth)
REG_FIELD_PREP(DSC_PPS0_LINE_BUF_DEPTH_MASK, depth)
#define DSC_PPS0_BPC_MASKREG_GENMASK(11, 8)
-#define DSC_PPS0_VER_MIN_SHIFT 4
-#define DSC_PPS0_VER_MAJ (0x1 << 0)
+#define DSC_PPS0_BPC(bpc)
REG_FIELD_PREP(DSC_PPS0_BPC_MASK, bpc)
+#define DSC_PPS0_VER_MINOR_MASK REG_GENMASK(7, 4)
+#define DSC_PPS0_VER_MINOR(minor)
REG_FIELD_PREP(DSC_PPS0_VER_MINOR_MASK, minor)
+#define DSC_PPS0_VER_MAJOR_MASK REG_GENMASK(3, 0)
+#define DSC_PPS0_VER_MAJOR(major)
REG_FIELD_PREP(DSC_PPS0_VER_MAJOR_MASK, major)
/* PPS 1 */
-#define DSC_PPS1_BPP(bpp)((bpp) << 0)
+#define DSC_PPS1_BPP_MASKREG_GENMASK(9, 0)
+#define DSC_PPS1_BPP(bpp)
REG_FIELD_PREP(DSC_PPS1_BPP_MASK, bpp)
/* PPS 2 */
#define DSC_PPS2_PIC_WIDTH_MASK REG_GENMASK(31, 16)
--
2.39.2
[Intel-gfx] [PATCH 7/8] drm/i915/dsc: add the PPS number to the register content macros
Improve clarity by specifying the PPS number in the register content
macros. It's easier to notice if macros are being used for the wrong
register.
Cc: Suraj Kandpal
Cc: Ankit Nautiyal
Signed-off-by: Jani Nikula
---
Probably easiest to review by applying and using 'git show --word-diff'
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 146 -
.../gpu/drm/i915/display/intel_vdsc_regs.h| 152 +-
2 files changed, 149 insertions(+), 149 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 4855514d7b09..126aff804e33 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -423,109 +423,109 @@ static void intel_dsc_pps_configure(const struct
intel_crtc_state *crtc_state)
int vdsc_instances_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state);
/* PPS 0 */
- pps_val = DSC_VER_MAJ | vdsc_cfg->dsc_version_minor <<
- DSC_VER_MIN_SHIFT |
- vdsc_cfg->bits_per_component << DSC_BPC_SHIFT |
- vdsc_cfg->line_buf_depth << DSC_LINE_BUF_DEPTH_SHIFT;
+ pps_val = DSC_PPS0_VER_MAJ | vdsc_cfg->dsc_version_minor <<
+ DSC_PPS0_VER_MIN_SHIFT |
+ vdsc_cfg->bits_per_component << DSC_PPS0_BPC_SHIFT |
+ vdsc_cfg->line_buf_depth << DSC_PPS0_LINE_BUF_DEPTH_SHIFT;
if (vdsc_cfg->dsc_version_minor == 2) {
- pps_val |= DSC_ALT_ICH_SEL;
+ pps_val |= DSC_PPS0_ALT_ICH_SEL;
if (vdsc_cfg->native_420)
- pps_val |= DSC_NATIVE_420_ENABLE;
+ pps_val |= DSC_PPS0_NATIVE_420_ENABLE;
if (vdsc_cfg->native_422)
- pps_val |= DSC_NATIVE_422_ENABLE;
+ pps_val |= DSC_PPS0_NATIVE_422_ENABLE;
}
if (vdsc_cfg->block_pred_enable)
- pps_val |= DSC_BLOCK_PREDICTION;
+ pps_val |= DSC_PPS0_BLOCK_PREDICTION;
if (vdsc_cfg->convert_rgb)
- pps_val |= DSC_COLOR_SPACE_CONVERSION;
+ pps_val |= DSC_PPS0_COLOR_SPACE_CONVERSION;
if (vdsc_cfg->simple_422)
- pps_val |= DSC_422_ENABLE;
+ pps_val |= DSC_PPS0_422_ENABLE;
if (vdsc_cfg->vbr_enable)
- pps_val |= DSC_VBR_ENABLE;
+ pps_val |= DSC_PPS0_VBR_ENABLE;
drm_dbg_kms(_priv->drm, "PPS0 = 0x%08x\n", pps_val);
intel_dsc_pps_write(crtc_state, 0, pps_val);
/* PPS 1 */
- pps_val = DSC_BPP(vdsc_cfg->bits_per_pixel);
+ pps_val = DSC_PPS1_BPP(vdsc_cfg->bits_per_pixel);
drm_dbg_kms(_priv->drm, "PPS1 = 0x%08x\n", pps_val);
intel_dsc_pps_write(crtc_state, 1, pps_val);
/* PPS 2 */
- pps_val = DSC_PIC_HEIGHT(vdsc_cfg->pic_height) |
- DSC_PIC_WIDTH(vdsc_cfg->pic_width / num_vdsc_instances);
+ pps_val = DSC_PPS2_PIC_HEIGHT(vdsc_cfg->pic_height) |
+ DSC_PPS2_PIC_WIDTH(vdsc_cfg->pic_width / num_vdsc_instances);
drm_dbg_kms(_priv->drm, "PPS2 = 0x%08x\n", pps_val);
intel_dsc_pps_write(crtc_state, 2, pps_val);
/* PPS 3 */
- pps_val = DSC_SLICE_HEIGHT(vdsc_cfg->slice_height) |
- DSC_SLICE_WIDTH(vdsc_cfg->slice_width);
+ pps_val = DSC_PPS3_SLICE_HEIGHT(vdsc_cfg->slice_height) |
+ DSC_PPS3_SLICE_WIDTH(vdsc_cfg->slice_width);
drm_dbg_kms(_priv->drm, "PPS3 = 0x%08x\n", pps_val);
intel_dsc_pps_write(crtc_state, 3, pps_val);
/* PPS 4 */
- pps_val = DSC_INITIAL_XMIT_DELAY(vdsc_cfg->initial_xmit_delay) |
- DSC_INITIAL_DEC_DELAY(vdsc_cfg->initial_dec_delay);
+ pps_val = DSC_PPS4_INITIAL_XMIT_DELAY(vdsc_cfg->initial_xmit_delay) |
+ DSC_PPS4_INITIAL_DEC_DELAY(vdsc_cfg->initial_dec_delay);
drm_dbg_kms(_priv->drm, "PPS4 = 0x%08x\n", pps_val);
intel_dsc_pps_write(crtc_state, 4, pps_val);
/* PPS 5 */
- pps_val = DSC_SCALE_INC_INT(vdsc_cfg->scale_increment_interval) |
- DSC_SCALE_DEC_INT(vdsc_cfg->scale_decrement_interval);
+ pps_val = DSC_PPS5_SCALE_INC_INT(vdsc_cfg->scale_increment_interval) |
+ DSC_PPS5_SCALE_DEC_INT(vdsc_cfg->scale_decrement_interval);
drm_dbg_kms(_priv->drm, "PPS5 = 0x%08x\n", pps_val);
intel_dsc_pps_write(crtc_state, 5, pps_val);
/* PPS 6 */
- pps_val = DSC_INITIAL_SCALE_VALUE(vdsc_cfg->initial_scale_value) |
- DSC_FIRST_LINE_BPG_OFFSET(vdsc_cfg->first_line_bpg_offset) |
- DSC_FLATNESS_MIN_QP(vdsc_cfg->flatness_min_qp) |
- DSC_FLATNESS_MAX_QP(vdsc_cfg->flatness_max_qp);
+ pps_val = DSC_PPS6_INITIAL_SCALE_VALUE(vdsc_cfg->initial_scale_value) |
+ DSC_PPS6_FIRST_LINE_BPG_OFFSET(vdsc_cfg->first_line_bpg_offset)
|
+ DSC_PPS6_FLATNESS_MIN_QP(vdsc_cfg->flatness_min_qp) |
+
[Intel-gfx] [PATCH 6/8] drm/i915/dsc: clean up pps comments
Unify comments to be the simple "PPS n" instead of all sorts of variants. Cc: Suraj Kandpal Cc: Ankit Nautiyal Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_vdsc.c | 56 +-- .../gpu/drm/i915/display/intel_vdsc_regs.h| 29 +- 2 files changed, 42 insertions(+), 43 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c b/drivers/gpu/drm/i915/display/intel_vdsc.c index 73bfa4d6633d..4855514d7b09 100644 --- a/drivers/gpu/drm/i915/display/intel_vdsc.c +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c @@ -422,7 +422,7 @@ static void intel_dsc_pps_configure(const struct intel_crtc_state *crtc_state) int num_vdsc_instances = intel_dsc_get_num_vdsc_instances(crtc_state); int vdsc_instances_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state); - /* Populate PICTURE_PARAMETER_SET_0 registers */ + /* PPS 0 */ pps_val = DSC_VER_MAJ | vdsc_cfg->dsc_version_minor << DSC_VER_MIN_SHIFT | vdsc_cfg->bits_per_component << DSC_BPC_SHIFT | @@ -445,36 +445,36 @@ static void intel_dsc_pps_configure(const struct intel_crtc_state *crtc_state) drm_dbg_kms(_priv->drm, "PPS0 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 0, pps_val); - /* Populate PICTURE_PARAMETER_SET_1 registers */ + /* PPS 1 */ pps_val = DSC_BPP(vdsc_cfg->bits_per_pixel); drm_dbg_kms(_priv->drm, "PPS1 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 1, pps_val); - /* Populate PICTURE_PARAMETER_SET_2 registers */ + /* PPS 2 */ pps_val = DSC_PIC_HEIGHT(vdsc_cfg->pic_height) | DSC_PIC_WIDTH(vdsc_cfg->pic_width / num_vdsc_instances); drm_dbg_kms(_priv->drm, "PPS2 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 2, pps_val); - /* Populate PICTURE_PARAMETER_SET_3 registers */ + /* PPS 3 */ pps_val = DSC_SLICE_HEIGHT(vdsc_cfg->slice_height) | DSC_SLICE_WIDTH(vdsc_cfg->slice_width); drm_dbg_kms(_priv->drm, "PPS3 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 3, pps_val); - /* Populate PICTURE_PARAMETER_SET_4 registers */ + /* PPS 4 */ pps_val = DSC_INITIAL_XMIT_DELAY(vdsc_cfg->initial_xmit_delay) | DSC_INITIAL_DEC_DELAY(vdsc_cfg->initial_dec_delay); drm_dbg_kms(_priv->drm, "PPS4 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 4, pps_val); - /* Populate PICTURE_PARAMETER_SET_5 registers */ + /* PPS 5 */ pps_val = DSC_SCALE_INC_INT(vdsc_cfg->scale_increment_interval) | DSC_SCALE_DEC_INT(vdsc_cfg->scale_decrement_interval); drm_dbg_kms(_priv->drm, "PPS5 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 5, pps_val); - /* Populate PICTURE_PARAMETER_SET_6 registers */ + /* PPS 6 */ pps_val = DSC_INITIAL_SCALE_VALUE(vdsc_cfg->initial_scale_value) | DSC_FIRST_LINE_BPG_OFFSET(vdsc_cfg->first_line_bpg_offset) | DSC_FLATNESS_MIN_QP(vdsc_cfg->flatness_min_qp) | @@ -482,25 +482,25 @@ static void intel_dsc_pps_configure(const struct intel_crtc_state *crtc_state) drm_dbg_kms(_priv->drm, "PPS6 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 6, pps_val); - /* Populate PICTURE_PARAMETER_SET_7 registers */ + /* PPS 7 */ pps_val = DSC_SLICE_BPG_OFFSET(vdsc_cfg->slice_bpg_offset) | DSC_NFL_BPG_OFFSET(vdsc_cfg->nfl_bpg_offset); drm_dbg_kms(_priv->drm, "PPS7 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 7, pps_val); - /* Populate PICTURE_PARAMETER_SET_8 registers */ + /* PPS 8 */ pps_val = DSC_FINAL_OFFSET(vdsc_cfg->final_offset) | DSC_INITIAL_OFFSET(vdsc_cfg->initial_offset); drm_dbg_kms(_priv->drm, "PPS8 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 8, pps_val); - /* Populate PICTURE_PARAMETER_SET_9 registers */ + /* PPS 9 */ pps_val = DSC_RC_MODEL_SIZE(vdsc_cfg->rc_model_size) | DSC_RC_EDGE_FACTOR(DSC_RC_EDGE_FACTOR_CONST); drm_dbg_kms(_priv->drm, "PPS9 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 9, pps_val); - /* Populate PICTURE_PARAMETER_SET_10 registers */ + /* PPS 10 */ pps_val = DSC_RC_QUANT_INC_LIMIT0(vdsc_cfg->rc_quant_incr_limit0) | DSC_RC_QUANT_INC_LIMIT1(vdsc_cfg->rc_quant_incr_limit1) | DSC_RC_TARGET_OFF_HIGH(DSC_RC_TGT_OFFSET_HI_CONST) | @@ -508,7 +508,7 @@ static void intel_dsc_pps_configure(const struct intel_crtc_state *crtc_state) drm_dbg_kms(_priv->drm, "PPS10 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 10, pps_val); - /* Populate Picture parameter set 16 */ + /* PPS 16 */ pps_val = DSC_SLICE_CHUNK_SIZE(vdsc_cfg->slice_chunk_size) |
[Intel-gfx] [PATCH 4/8] drm/i915/dsc: rename pps write to intel_dsc_pps_write()
Make the function name conform to existing style better.
Cc: Suraj Kandpal
Cc: Ankit Nautiyal
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 32 +++
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index b0be6615a865..4086dbb25ca5 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -389,8 +389,8 @@ static void intel_dsc_get_pps_reg(const struct
intel_crtc_state *crtc_state, int
dsc_reg[0] = pipe_dsc ? ICL_DSC0_PPS(pipe, pps) : DSCA_PPS(pps);
}
-static void intel_dsc_write_pps_reg(const struct intel_crtc_state *crtc_state,
- int pps, u32 pps_val)
+static void intel_dsc_pps_write(const struct intel_crtc_state *crtc_state,
+ int pps, u32 pps_val)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
@@ -443,41 +443,41 @@ static void intel_dsc_pps_configure(const struct
intel_crtc_state *crtc_state)
if (vdsc_cfg->vbr_enable)
pps_val |= DSC_VBR_ENABLE;
drm_dbg_kms(_priv->drm, "PPS0 = 0x%08x\n", pps_val);
- intel_dsc_write_pps_reg(crtc_state, 0, pps_val);
+ intel_dsc_pps_write(crtc_state, 0, pps_val);
/* Populate PICTURE_PARAMETER_SET_1 registers */
pps_val = 0;
pps_val |= DSC_BPP(vdsc_cfg->bits_per_pixel);
drm_dbg_kms(_priv->drm, "PPS1 = 0x%08x\n", pps_val);
- intel_dsc_write_pps_reg(crtc_state, 1, pps_val);
+ intel_dsc_pps_write(crtc_state, 1, pps_val);
/* Populate PICTURE_PARAMETER_SET_2 registers */
pps_val = 0;
pps_val |= DSC_PIC_HEIGHT(vdsc_cfg->pic_height) |
DSC_PIC_WIDTH(vdsc_cfg->pic_width / num_vdsc_instances);
drm_dbg_kms(_priv->drm, "PPS2 = 0x%08x\n", pps_val);
- intel_dsc_write_pps_reg(crtc_state, 2, pps_val);
+ intel_dsc_pps_write(crtc_state, 2, pps_val);
/* Populate PICTURE_PARAMETER_SET_3 registers */
pps_val = 0;
pps_val |= DSC_SLICE_HEIGHT(vdsc_cfg->slice_height) |
DSC_SLICE_WIDTH(vdsc_cfg->slice_width);
drm_dbg_kms(_priv->drm, "PPS3 = 0x%08x\n", pps_val);
- intel_dsc_write_pps_reg(crtc_state, 3, pps_val);
+ intel_dsc_pps_write(crtc_state, 3, pps_val);
/* Populate PICTURE_PARAMETER_SET_4 registers */
pps_val = 0;
pps_val |= DSC_INITIAL_XMIT_DELAY(vdsc_cfg->initial_xmit_delay) |
DSC_INITIAL_DEC_DELAY(vdsc_cfg->initial_dec_delay);
drm_dbg_kms(_priv->drm, "PPS4 = 0x%08x\n", pps_val);
- intel_dsc_write_pps_reg(crtc_state, 4, pps_val);
+ intel_dsc_pps_write(crtc_state, 4, pps_val);
/* Populate PICTURE_PARAMETER_SET_5 registers */
pps_val = 0;
pps_val |= DSC_SCALE_INC_INT(vdsc_cfg->scale_increment_interval) |
DSC_SCALE_DEC_INT(vdsc_cfg->scale_decrement_interval);
drm_dbg_kms(_priv->drm, "PPS5 = 0x%08x\n", pps_val);
- intel_dsc_write_pps_reg(crtc_state, 5, pps_val);
+ intel_dsc_pps_write(crtc_state, 5, pps_val);
/* Populate PICTURE_PARAMETER_SET_6 registers */
pps_val = 0;
@@ -486,28 +486,28 @@ static void intel_dsc_pps_configure(const struct
intel_crtc_state *crtc_state)
DSC_FLATNESS_MIN_QP(vdsc_cfg->flatness_min_qp) |
DSC_FLATNESS_MAX_QP(vdsc_cfg->flatness_max_qp);
drm_dbg_kms(_priv->drm, "PPS6 = 0x%08x\n", pps_val);
- intel_dsc_write_pps_reg(crtc_state, 6, pps_val);
+ intel_dsc_pps_write(crtc_state, 6, pps_val);
/* Populate PICTURE_PARAMETER_SET_7 registers */
pps_val = 0;
pps_val |= DSC_SLICE_BPG_OFFSET(vdsc_cfg->slice_bpg_offset) |
DSC_NFL_BPG_OFFSET(vdsc_cfg->nfl_bpg_offset);
drm_dbg_kms(_priv->drm, "PPS7 = 0x%08x\n", pps_val);
- intel_dsc_write_pps_reg(crtc_state, 7, pps_val);
+ intel_dsc_pps_write(crtc_state, 7, pps_val);
/* Populate PICTURE_PARAMETER_SET_8 registers */
pps_val = 0;
pps_val |= DSC_FINAL_OFFSET(vdsc_cfg->final_offset) |
DSC_INITIAL_OFFSET(vdsc_cfg->initial_offset);
drm_dbg_kms(_priv->drm, "PPS8 = 0x%08x\n", pps_val);
- intel_dsc_write_pps_reg(crtc_state, 8, pps_val);
+ intel_dsc_pps_write(crtc_state, 8, pps_val);
/* Populate PICTURE_PARAMETER_SET_9 registers */
pps_val = 0;
pps_val |= DSC_RC_MODEL_SIZE(vdsc_cfg->rc_model_size) |
DSC_RC_EDGE_FACTOR(DSC_RC_EDGE_FACTOR_CONST);
drm_dbg_kms(_priv->drm, "PPS9 = 0x%08x\n", pps_val);
- intel_dsc_write_pps_reg(crtc_state, 9, pps_val);
+ intel_dsc_pps_write(crtc_state, 9, pps_val);
/* Populate PICTURE_PARAMETER_SET_10 registers */
pps_val = 0;
@@ -516,7 +516,7 @@
[Intel-gfx] [PATCH 3/8] drm/i915/dsc: have intel_dsc_pps_read() return the value
Register read functions usually return the value instead of passing via
pointer parameters. Return the multiple register verification results
via a pointer parameter, which can also be NULL to skip the extra
checks.
Make the name conform to existing style better while at it.
Cc: Suraj Kandpal
Cc: Ankit Nautiyal
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 32 ++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index abb2c4370231..b0be6615a865 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -809,13 +809,14 @@ void intel_dsc_disable(const struct intel_crtc_state
*old_crtc_state)
}
}
-static bool intel_dsc_read_pps_reg(struct intel_crtc_state *crtc_state,
- int pps, u32 *pps_val)
+static u32 intel_dsc_pps_read(struct intel_crtc_state *crtc_state, int pps,
+ bool *check_equal)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
i915_reg_t dsc_reg[2];
int i, vdsc_per_pipe, dsc_reg_num;
+ u32 val = 0;
vdsc_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state);
dsc_reg_num = min_t(int, ARRAY_SIZE(dsc_reg), vdsc_per_pipe);
@@ -824,20 +825,25 @@ static bool intel_dsc_read_pps_reg(struct
intel_crtc_state *crtc_state,
intel_dsc_get_pps_reg(crtc_state, pps, dsc_reg, dsc_reg_num);
- *pps_val = 0;
+ if (check_equal)
+ *check_equal = true;
for (i = 0; i < dsc_reg_num; i++) {
- u32 pps_temp;
+ u32 tmp;
- pps_temp = intel_de_read(i915, dsc_reg[i]);
+ tmp = intel_de_read(i915, dsc_reg[i]);
- if (i == 0)
- *pps_val = pps_temp;
- else if (pps_temp != *pps_val)
- return false;
+ if (i == 0) {
+ val = tmp;
+ } else if (check_equal && tmp != val) {
+ *check_equal = false;
+ break;
+ } else if (!check_equal) {
+ break;
+ }
}
- return true;
+ return val;
}
static u32 intel_dsc_pps_read_and_verify(struct intel_crtc_state *crtc_state,
int pps)
@@ -845,10 +851,10 @@ static u32 intel_dsc_pps_read_and_verify(struct
intel_crtc_state *crtc_state, in
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
u32 val;
- int ret;
+ bool all_equal;
- ret = intel_dsc_read_pps_reg(crtc_state, pps, );
- drm_WARN_ON(>drm, !ret);
+ val = intel_dsc_pps_read(crtc_state, pps, _equal);
+ drm_WARN_ON(>drm, !all_equal);
return val;
}
--
2.39.2
[Intel-gfx] [PATCH 2/8] drm/i915/dsc: have intel_dsc_pps_read_and_verify() return the value
Register read functions usually return the value instead of passing via
pointer parameters. The calling code becomes easier to read.
Make the name conform to existing style better while at it.
Cc: Suraj Kandpal
Cc: Ankit Nautiyal
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 36 ---
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 14317bb6d3df..abb2c4370231 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -840,15 +840,17 @@ static bool intel_dsc_read_pps_reg(struct
intel_crtc_state *crtc_state,
return true;
}
-static void intel_dsc_read_and_verify_pps_reg(struct intel_crtc_state
*crtc_state,
- int pps, u32 *pps_val)
+static u32 intel_dsc_pps_read_and_verify(struct intel_crtc_state *crtc_state,
int pps)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+ u32 val;
int ret;
- ret = intel_dsc_read_pps_reg(crtc_state, pps, pps_val);
+ ret = intel_dsc_read_pps_reg(crtc_state, pps, );
drm_WARN_ON(>drm, !ret);
+
+ return val;
}
static void intel_dsc_get_pps_config(struct intel_crtc_state *crtc_state)
@@ -860,7 +862,7 @@ static void intel_dsc_get_pps_config(struct
intel_crtc_state *crtc_state)
u32 pps_temp;
/* PPS_0 */
- intel_dsc_read_and_verify_pps_reg(crtc_state, 0, _temp);
+ pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 0);
vdsc_cfg->bits_per_component = (pps_temp & DSC_BPC_MASK) >>
DSC_BPC_SHIFT;
vdsc_cfg->line_buf_depth =
@@ -873,7 +875,7 @@ static void intel_dsc_get_pps_config(struct
intel_crtc_state *crtc_state)
vdsc_cfg->vbr_enable = pps_temp & DSC_VBR_ENABLE;
/* PPS_1 */
- intel_dsc_read_and_verify_pps_reg(crtc_state, 1, _temp);
+ pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 1);
vdsc_cfg->bits_per_pixel = pps_temp;
@@ -883,31 +885,31 @@ static void intel_dsc_get_pps_config(struct
intel_crtc_state *crtc_state)
crtc_state->dsc.compressed_bpp = vdsc_cfg->bits_per_pixel >> 4;
/* PPS_2 */
- intel_dsc_read_and_verify_pps_reg(crtc_state, 2, _temp);
+ pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 2);
vdsc_cfg->pic_width = REG_FIELD_GET(DSC_PIC_WIDTH_MASK, pps_temp) /
num_vdsc_instances;
vdsc_cfg->pic_height = REG_FIELD_GET(DSC_PIC_HEIGHT_MASK, pps_temp);
/* PPS_3 */
- intel_dsc_read_and_verify_pps_reg(crtc_state, 3, _temp);
+ pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 3);
vdsc_cfg->slice_width = REG_FIELD_GET(DSC_SLICE_WIDTH_MASK, pps_temp);
vdsc_cfg->slice_height = REG_FIELD_GET(DSC_SLICE_HEIGHT_MASK, pps_temp);
/* PPS_4 */
- intel_dsc_read_and_verify_pps_reg(crtc_state, 4, _temp);
+ pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 4);
vdsc_cfg->initial_dec_delay = REG_FIELD_GET(DSC_INITIAL_DEC_DELAY_MASK,
pps_temp);
vdsc_cfg->initial_xmit_delay =
REG_FIELD_GET(DSC_INITIAL_XMIT_DELAY_MASK, pps_temp);
/* PPS_5 */
- intel_dsc_read_and_verify_pps_reg(crtc_state, 5, _temp);
+ pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 5);
vdsc_cfg->scale_decrement_interval =
REG_FIELD_GET(DSC_SCALE_DEC_INT_MASK, pps_temp);
vdsc_cfg->scale_increment_interval =
REG_FIELD_GET(DSC_SCALE_INC_INT_MASK, pps_temp);
/* PPS_6 */
- intel_dsc_read_and_verify_pps_reg(crtc_state, 6, _temp);
+ pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 6);
vdsc_cfg->initial_scale_value =
REG_FIELD_GET(DSC_INITIAL_SCALE_VALUE_MASK, pps_temp);
vdsc_cfg->first_line_bpg_offset =
REG_FIELD_GET(DSC_FIRST_LINE_BPG_OFFSET_MASK, pps_temp);
@@ -915,41 +917,41 @@ static void intel_dsc_get_pps_config(struct
intel_crtc_state *crtc_state)
vdsc_cfg->flatness_max_qp = REG_FIELD_GET(DSC_FLATNESS_MAX_QP_MASK,
pps_temp);
/* PPS_7 */
- intel_dsc_read_and_verify_pps_reg(crtc_state, 7, _temp);
+ pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 7);
vdsc_cfg->nfl_bpg_offset = REG_FIELD_GET(DSC_NFL_BPG_OFFSET_MASK,
pps_temp);
vdsc_cfg->slice_bpg_offset = REG_FIELD_GET(DSC_SLICE_BPG_OFFSET_MASK,
pps_temp);
/* PPS_8 */
- intel_dsc_read_and_verify_pps_reg(crtc_state, 8, _temp);
+ pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 8);
vdsc_cfg->initial_offset = REG_FIELD_GET(DSC_INITIAL_OFFSET_MASK,
pps_temp);
vdsc_cfg->final_offset = REG_FIELD_GET(DSC_FINAL_OFFSET_MASK, pps_temp);
/* PPS_9 */
- intel_dsc_read_and_verify_pps_reg(crtc_state, 9, _temp);
+ pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 9);
[Intel-gfx] [PATCH 0/8] drm/i915/dsc: cleanups
Jani Nikula (8): drm/i915/dsc: improve clarify of the pps reg read/write helpers drm/i915/dsc: have intel_dsc_pps_read_and_verify() return the value drm/i915/dsc: have intel_dsc_pps_read() return the value drm/i915/dsc: rename pps write to intel_dsc_pps_write() drm/i915/dsc: drop redundant = 0 assignments drm/i915/dsc: clean up pps comments drm/i915/dsc: add the PPS number to the register content macros drm/i915/dsc: use REG_BIT, REG_GENMASK, and friends for PPS0 and PPS1 drivers/gpu/drm/i915/display/intel_vdsc.c | 362 +- .../gpu/drm/i915/display/intel_vdsc_regs.h| 184 - 2 files changed, 272 insertions(+), 274 deletions(-) -- 2.39.2
[Intel-gfx] [PATCH 5/8] drm/i915/dsc: drop redundant = 0 assignments
Directly assign the values instead of first assigning 0 and then |= the values. Cc: Suraj Kandpal Cc: Ankit Nautiyal Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_vdsc.c | 43 --- 1 file changed, 15 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c b/drivers/gpu/drm/i915/display/intel_vdsc.c index 4086dbb25ca5..73bfa4d6633d 100644 --- a/drivers/gpu/drm/i915/display/intel_vdsc.c +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c @@ -415,7 +415,7 @@ static void intel_dsc_pps_configure(const struct intel_crtc_state *crtc_state) const struct drm_dsc_config *vdsc_cfg = _state->dsc.config; enum transcoder cpu_transcoder = crtc_state->cpu_transcoder; enum pipe pipe = crtc->pipe; - u32 pps_val = 0; + u32 pps_val; u32 rc_buf_thresh_dword[4]; u32 rc_range_params_dword[8]; int i = 0; @@ -446,42 +446,36 @@ static void intel_dsc_pps_configure(const struct intel_crtc_state *crtc_state) intel_dsc_pps_write(crtc_state, 0, pps_val); /* Populate PICTURE_PARAMETER_SET_1 registers */ - pps_val = 0; - pps_val |= DSC_BPP(vdsc_cfg->bits_per_pixel); + pps_val = DSC_BPP(vdsc_cfg->bits_per_pixel); drm_dbg_kms(_priv->drm, "PPS1 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 1, pps_val); /* Populate PICTURE_PARAMETER_SET_2 registers */ - pps_val = 0; - pps_val |= DSC_PIC_HEIGHT(vdsc_cfg->pic_height) | + pps_val = DSC_PIC_HEIGHT(vdsc_cfg->pic_height) | DSC_PIC_WIDTH(vdsc_cfg->pic_width / num_vdsc_instances); drm_dbg_kms(_priv->drm, "PPS2 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 2, pps_val); /* Populate PICTURE_PARAMETER_SET_3 registers */ - pps_val = 0; - pps_val |= DSC_SLICE_HEIGHT(vdsc_cfg->slice_height) | + pps_val = DSC_SLICE_HEIGHT(vdsc_cfg->slice_height) | DSC_SLICE_WIDTH(vdsc_cfg->slice_width); drm_dbg_kms(_priv->drm, "PPS3 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 3, pps_val); /* Populate PICTURE_PARAMETER_SET_4 registers */ - pps_val = 0; - pps_val |= DSC_INITIAL_XMIT_DELAY(vdsc_cfg->initial_xmit_delay) | + pps_val = DSC_INITIAL_XMIT_DELAY(vdsc_cfg->initial_xmit_delay) | DSC_INITIAL_DEC_DELAY(vdsc_cfg->initial_dec_delay); drm_dbg_kms(_priv->drm, "PPS4 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 4, pps_val); /* Populate PICTURE_PARAMETER_SET_5 registers */ - pps_val = 0; - pps_val |= DSC_SCALE_INC_INT(vdsc_cfg->scale_increment_interval) | + pps_val = DSC_SCALE_INC_INT(vdsc_cfg->scale_increment_interval) | DSC_SCALE_DEC_INT(vdsc_cfg->scale_decrement_interval); drm_dbg_kms(_priv->drm, "PPS5 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 5, pps_val); /* Populate PICTURE_PARAMETER_SET_6 registers */ - pps_val = 0; - pps_val |= DSC_INITIAL_SCALE_VALUE(vdsc_cfg->initial_scale_value) | + pps_val = DSC_INITIAL_SCALE_VALUE(vdsc_cfg->initial_scale_value) | DSC_FIRST_LINE_BPG_OFFSET(vdsc_cfg->first_line_bpg_offset) | DSC_FLATNESS_MIN_QP(vdsc_cfg->flatness_min_qp) | DSC_FLATNESS_MAX_QP(vdsc_cfg->flatness_max_qp); @@ -489,29 +483,25 @@ static void intel_dsc_pps_configure(const struct intel_crtc_state *crtc_state) intel_dsc_pps_write(crtc_state, 6, pps_val); /* Populate PICTURE_PARAMETER_SET_7 registers */ - pps_val = 0; - pps_val |= DSC_SLICE_BPG_OFFSET(vdsc_cfg->slice_bpg_offset) | + pps_val = DSC_SLICE_BPG_OFFSET(vdsc_cfg->slice_bpg_offset) | DSC_NFL_BPG_OFFSET(vdsc_cfg->nfl_bpg_offset); drm_dbg_kms(_priv->drm, "PPS7 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 7, pps_val); /* Populate PICTURE_PARAMETER_SET_8 registers */ - pps_val = 0; - pps_val |= DSC_FINAL_OFFSET(vdsc_cfg->final_offset) | + pps_val = DSC_FINAL_OFFSET(vdsc_cfg->final_offset) | DSC_INITIAL_OFFSET(vdsc_cfg->initial_offset); drm_dbg_kms(_priv->drm, "PPS8 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 8, pps_val); /* Populate PICTURE_PARAMETER_SET_9 registers */ - pps_val = 0; - pps_val |= DSC_RC_MODEL_SIZE(vdsc_cfg->rc_model_size) | + pps_val = DSC_RC_MODEL_SIZE(vdsc_cfg->rc_model_size) | DSC_RC_EDGE_FACTOR(DSC_RC_EDGE_FACTOR_CONST); drm_dbg_kms(_priv->drm, "PPS9 = 0x%08x\n", pps_val); intel_dsc_pps_write(crtc_state, 9, pps_val); /* Populate PICTURE_PARAMETER_SET_10 registers */ - pps_val = 0; - pps_val |= DSC_RC_QUANT_INC_LIMIT0(vdsc_cfg->rc_quant_incr_limit0) | + pps_val = DSC_RC_QUANT_INC_LIMIT0(vdsc_cfg->rc_quant_incr_limit0) |
[Intel-gfx] [PATCH 1/8] drm/i915/dsc: improve clarify of the pps reg read/write helpers
Make it clear what's the number of vdsc per pipe, and what's the number
of registers to grab. Have intel_dsc_get_pps_reg() return the registers
it knows even if the requested amount is bigger.
Cc: Suraj Kandpal
Cc: Ankit Nautiyal
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 40 ---
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index b24601d0b2c5..14317bb6d3df 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -372,7 +372,7 @@ int intel_dsc_get_num_vdsc_instances(const struct
intel_crtc_state *crtc_state)
}
static void intel_dsc_get_pps_reg(const struct intel_crtc_state *crtc_state,
int pps,
- i915_reg_t *dsc_reg, int vdsc_per_pipe)
+ i915_reg_t *dsc_reg, int dsc_reg_num)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
@@ -381,16 +381,12 @@ static void intel_dsc_get_pps_reg(const struct
intel_crtc_state *crtc_state, int
pipe_dsc = is_pipe_dsc(crtc, cpu_transcoder);
- switch (vdsc_per_pipe) {
- case 2:
+ if (dsc_reg_num >= 3)
+ MISSING_CASE(dsc_reg_num);
+ if (dsc_reg_num >= 2)
dsc_reg[1] = pipe_dsc ? ICL_DSC1_PPS(pipe, pps) : DSCC_PPS(pps);
- fallthrough;
- case 1:
+ if (dsc_reg_num >= 1)
dsc_reg[0] = pipe_dsc ? ICL_DSC0_PPS(pipe, pps) : DSCA_PPS(pps);
- break;
- default:
- MISSING_CASE(vdsc_per_pipe);
- }
}
static void intel_dsc_write_pps_reg(const struct intel_crtc_state *crtc_state,
@@ -399,13 +395,16 @@ static void intel_dsc_write_pps_reg(const struct
intel_crtc_state *crtc_state,
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
i915_reg_t dsc_reg[2];
- int i, vdsc_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state);
+ int i, vdsc_per_pipe, dsc_reg_num;
+
+ vdsc_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state);
+ dsc_reg_num = min_t(int, ARRAY_SIZE(dsc_reg), vdsc_per_pipe);
- drm_WARN_ON_ONCE(>drm, ARRAY_SIZE(dsc_reg) < vdsc_per_pipe);
+ drm_WARN_ON_ONCE(>drm, dsc_reg_num < vdsc_per_pipe);
- intel_dsc_get_pps_reg(crtc_state, pps, dsc_reg, vdsc_per_pipe);
+ intel_dsc_get_pps_reg(crtc_state, pps, dsc_reg, dsc_reg_num);
- for (i = 0; i < min_t(int, ARRAY_SIZE(dsc_reg), vdsc_per_pipe); i++)
+ for (i = 0; i < dsc_reg_num; i++)
intel_de_write(i915, dsc_reg[i], pps_val);
}
@@ -815,16 +814,19 @@ static bool intel_dsc_read_pps_reg(struct
intel_crtc_state *crtc_state,
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
- const int vdsc_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state);
i915_reg_t dsc_reg[2];
- int i;
+ int i, vdsc_per_pipe, dsc_reg_num;
- *pps_val = 0;
- drm_WARN_ON_ONCE(>drm, ARRAY_SIZE(dsc_reg) < vdsc_per_pipe);
+ vdsc_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state);
+ dsc_reg_num = min_t(int, ARRAY_SIZE(dsc_reg), vdsc_per_pipe);
- intel_dsc_get_pps_reg(crtc_state, pps, dsc_reg, vdsc_per_pipe);
+ drm_WARN_ON_ONCE(>drm, dsc_reg_num < vdsc_per_pipe);
+
+ intel_dsc_get_pps_reg(crtc_state, pps, dsc_reg, dsc_reg_num);
+
+ *pps_val = 0;
- for (i = 0; i < min_t(int, ARRAY_SIZE(dsc_reg), vdsc_per_pipe); i++) {
+ for (i = 0; i < dsc_reg_num; i++) {
u32 pps_temp;
pps_temp = intel_de_read(i915, dsc_reg[i]);
--
2.39.2
Re: [Intel-gfx] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
On Wed, 6 Sep 2023 00:21:09 +0800 suijingfeng wrote: > Hi, > > On 2023/9/5 22:52, Alex Williamson wrote: > > On Tue, 5 Sep 2023 03:57:15 +0800 > > Sui Jingfeng wrote: > > > >> From: Sui Jingfeng > >> > >> On a machine with multiple GPUs, a Linux user has no control over which > >> one is primary at boot time. This series tries to solve above mentioned > >> problem by introduced the ->be_primary() function stub. The specific > >> device drivers can provide an implementation to hook up with this stub by > >> calling the vga_client_register() function. > >> > >> Once the driver bound the device successfully, VGAARB will call back to > >> the device driver. To query if the device drivers want to be primary or > >> not. Device drivers can just pass NULL if have no such needs. > >> > >> Please note that: > >> > >> 1) The ARM64, Loongarch, Mips servers have a lot PCIe slot, and I would > >> like to mount at least three video cards. > >> > >> 2) Typically, those non-86 machines don't have a good UEFI firmware > >> support, which doesn't support select primary GPU as firmware stage. > >> Even on x86, there are old UEFI firmwares which already made undesired > >> decision for you. > >> > >> 3) This series is attempt to solve the remain problems at the driver level, > >> while another series[1] of me is target to solve the majority of the > >> problems at device level. > >> > >> Tested (limited) on x86 with four video card mounted, Intel UHD Graphics > >> 630 is the default boot VGA, successfully override by ast2400 with > >> ast.modeset=10 append at the kernel cmd line. > >> > >> $ lspci | grep VGA > >> > >> 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 > >> [UHD Graphics 630] > > In all my previous experiments with VGA routing and IGD I found that > > IGD can't actually release VGA routing and Intel confirmed the hardware > > doesn't have the ability to do so. It will always be primary from a > > VGA routing perspective. Was this actually tested with non-UEFI? > > Yes, I have tested on my aspire e471 notebook (i5 5200U), > because that notebook using legacy firmware (also have UEFI, double firmware). > But this machine have difficult in install ubuntu under UEFI firmware in the > past. > So I keep it using the legacy firmware. > > It have two video card, IGD and nvidia video card(GFORCE 840M). > nvidia call its video card as 3D controller (pci->class = 0x030200) > > I have tested this patch and another patch mention at [1] together. > I can tell you that the firmware framebuffer of this notebook using vesafb, > not efifb. > And the framebuffer size (lfb.size) is very small. This is very strange, > but I don't have enough time to look in details. But still works. > > I'm using and tesing my patch whenever and wherever possible. So you're testing VGA routing using a non-VGA 3D controller through the VESA address space? How does that test anything about VGA routing? > > I suspect it might only work in UEFI mode where we probably don't > > actually have a dependency on VGA routing. This is essentially why > > vfio requires UEFI ROMs when assigning GPUs to VMs, VGA routing is too > > broken to use on Intel systems with IGD. Thanks, > > > What you tell me here is the side effect come with the VGA-compatible, > but I'm focus on the arbitration itself. I think there no need to keep > the VGA routing hardware features nowadays except that hardware vendor > want keep the backward compatibility and/or comply the PCI VGA compatible > spec. "VGA arbitration" is the mediation of VGA routing between devices, so I'm confused how you can be focused on the arbitration without the routing itself. Thanks, Alex
Re: [Intel-gfx] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Hi, On 2023/9/5 22:52, Alex Williamson wrote: On Tue, 5 Sep 2023 03:57:15 +0800 Sui Jingfeng wrote: From: Sui Jingfeng On a machine with multiple GPUs, a Linux user has no control over which one is primary at boot time. This series tries to solve above mentioned problem by introduced the ->be_primary() function stub. The specific device drivers can provide an implementation to hook up with this stub by calling the vga_client_register() function. Once the driver bound the device successfully, VGAARB will call back to the device driver. To query if the device drivers want to be primary or not. Device drivers can just pass NULL if have no such needs. Please note that: 1) The ARM64, Loongarch, Mips servers have a lot PCIe slot, and I would like to mount at least three video cards. 2) Typically, those non-86 machines don't have a good UEFI firmware support, which doesn't support select primary GPU as firmware stage. Even on x86, there are old UEFI firmwares which already made undesired decision for you. 3) This series is attempt to solve the remain problems at the driver level, while another series[1] of me is target to solve the majority of the problems at device level. Tested (limited) on x86 with four video card mounted, Intel UHD Graphics 630 is the default boot VGA, successfully override by ast2400 with ast.modeset=10 append at the kernel cmd line. $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] In all my previous experiments with VGA routing and IGD I found that IGD can't actually release VGA routing and Intel confirmed the hardware doesn't have the ability to do so. It will always be primary from a VGA routing perspective. Was this actually tested with non-UEFI? Yes, I have tested on my aspire e471 notebook (i5 5200U), because that notebook using legacy firmware (also have UEFI, double firmware). But this machine have difficult in install ubuntu under UEFI firmware in the past. So I keep it using the legacy firmware. It have two video card, IGD and nvidia video card(GFORCE 840M). nvidia call its video card as 3D controller (pci->class = 0x030200) I have tested this patch and another patch mention at [1] together. I can tell you that the firmware framebuffer of this notebook using vesafb, not efifb. And the framebuffer size (lfb.size) is very small. This is very strange, but I don't have enough time to look in details. But still works. I'm using and tesing my patch whenever and wherever possible. I suspect it might only work in UEFI mode where we probably don't actually have a dependency on VGA routing. This is essentially why vfio requires UEFI ROMs when assigning GPUs to VMs, VGA routing is too broken to use on Intel systems with IGD. Thanks, What you tell me here is the side effect come with the VGA-compatible, but I'm focus on the arbitration itself. I think there no need to keep the VGA routing hardware features nowadays except that hardware vendor want keep the backward compatibility and/or comply the PCI VGA compatible spec. Alex
Re: [Intel-gfx] [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
On 2023/9/5 18:49, Thomas Zimmermann wrote: Hi Am 04.09.23 um 21:57 schrieb Sui Jingfeng: From: Sui Jingfeng On a machine with multiple GPUs, a Linux user has no control over which one is primary at boot time. This series tries to solve above mentioned problem by introduced the ->be_primary() function stub. The specific device drivers can provide an implementation to hook up with this stub by calling the vga_client_register() function. Once the driver bound the device successfully, VGAARB will call back to the device driver. To query if the device drivers want to be primary or not. Device drivers can just pass NULL if have no such needs. Please note that: 1) The ARM64, Loongarch, Mips servers have a lot PCIe slot, and I would like to mount at least three video cards. 2) Typically, those non-86 machines don't have a good UEFI firmware support, which doesn't support select primary GPU as firmware stage. Even on x86, there are old UEFI firmwares which already made undesired decision for you. 3) This series is attempt to solve the remain problems at the driver level, while another series[1] of me is target to solve the majority of the problems at device level. Tested (limited) on x86 with four video card mounted, Intel UHD Graphics 630 is the default boot VGA, successfully override by ast2400 with ast.modeset=10 append at the kernel cmd line. FYI: per-driver modeset parameters are deprecated and not to be used. Please don't promote them. Well, please wait, I want to explain. drm/nouveau already promote it a little bit. Despite no code of conduct or specification guiding how the modules parameters should be. Noticed that there already have a lot of DRM drivers support the modeset parameters, for the modeset parameter, authors of various device driver try to make the usage not conflict with others. I believe that this is good thing for Linux users. It is probably the responsibility of the drm core maintainers to force various drm drivers to reach a minimal consensus. Probably it pains to do so and doesn't pay off. But reach a minimal consensus do benefit to Linux users. You can use modprobe.blacklist or initcall_blacklist on the kernel command line. There are some cases where the modprobe.blacklist doesn't works, I have come cross several time during the past. Because the device selected by the VGAARB is device-level thing, it is not the driver's problem. Sometimes when VGAARB has a bug, it will select a wrong device as primary. And the X server will use this wrong device as primary and completely crash there, due to lack a driver. Take my old S3 Graphics as an example: $ lspci | grep VGA 00:06.1 VGA compatible controller: Loongson Technology LLC DC (Display Controller) (rev 01) 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos XT [Radeon HD 7470/8470 / R5 235/310 OEM] 07:00.0 VGA compatible controller: S3 Graphics Ltd. Device 9070 (rev 01) 08:00.0 VGA compatible controller: S3 Graphics Ltd. Device 9070 (rev 01) Before apply this patch: [0.361748] pci :00:06.1: vgaarb: setting as boot VGA device [0.361753] pci :00:06.1: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.361765] pci :03:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none [0.361773] pci :07:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none [0.361779] pci :08:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none [0.361781] vgaarb: loaded [0.367838] pci :00:06.1: Overriding boot device as 1002:6778 [0.367841] pci :00:06.1: Overriding boot device as 5333:9070 [0.367843] pci :00:06.1: Overriding boot device as 5333:9070 For known reason, one of my system select the S3 Graphics as primary GPU. But this S3 Graphics not even have a decent drm upstream driver yet. Under such a case, I begin to believe that only the device who has a driver deserve the primary. Under such a condition, I want to reboot and enter the graphic environment with other working video cards. Either platform integrated and discrete GPU. This don't means I should compromise by un-mount the S3 graphics card from the motherboard, this also don't means that I should update my BIOS setting. As sometimes, the BIOS is more worse. With this series applied, all I need to do is to reboot the computer and pass a command line. By force override another video card (who has a decent driver support) as primary, I'm able to do the debugging under graphic environment. I would like to examine what's wrong with the vgaarb on a specific platform under X server graphic environment. Probably try compile a driver for this card and see it works, simply reboot without the need to change anything. It is so efficient. So this is probably the second usage of my patch. It hand the right of control back to the graphic developer.
Re: [Intel-gfx] [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Hi
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
If anything, the primary graphics adapter is the one initialized by
the firmware. I think our boot-up graphics also make this assumption
implicitly.
Yes, but by the time of DRM drivers get loaded successfully,the boot-up
graphics already finished.
Firmware framebuffer device already get killed by the
drm_aperture_remove_conflicting_pci_framebuffers()
function (or its siblings). So, this series is definitely not to
interact with the firmware framebuffer
Yes and no. The helpers you mention will attempt to remove the firmware
framebuffer on the given PCI device. If you have multiple PCI devices,
the other devices would not be affected.
This also means that probing a non-primary card will not affect the
firmware framebuffer on the primary card. You can have all these drivers
co-exist next to each other. If you link a full DRM driver into the
kernel image, it might even be loaded before the firmware-framebuffer's
driver. We had some funny bugs from these interactions.
(or more intelligent framebuffer drivers). It is for user space
program, such as X server and Wayland
compositor. Its for Linux user or drm drivers testers, which allow them
to direct graphic display server
using right hardware of interested as primary video card.
Also, I believe that X server and Wayland compositor are the best test
examples.
If a specific DRM driver can't work with X server as a primary,
then there probably have something wrong.
If you want to run a userspace compositor or X11 on a certain device,
you best configure this in the program's config files. But not on the
kernel command line.
The whole concept of a 'primary' display is bogus IMHO. It only exists
because old VGA and BIOS (and their equivalents on non-PC systems) were
unable to use more than one graphics device. Hence, as you write below,
only the first device got POSTed by the BIOS. If you had an additional
card, the device driver needed to perform the POSTing.
However, on modern Linux systems the primary display does not really
exist. 'Primary' is the device that is available via VGA, VESA or EFI.
Our drivers don't use these interfaces, but the native registers. As you
said yourself, these firmware devices (VGA, VESA, EFI) are removed ASAP
by the native drivers.
But what's the use case for overriding this setting?
On a specific machine with multiple GPUs mounted,
only the primary graphics get POST-ed (initialized) by the firmware.
Therefore, the DRM drivers for the rest video cards, have to choose to
work without the prerequisite setups done by firmware, This is called as
POST.
One of the use cases of this series is to test if a specific DRM driver
could works properly,
even though there is no prerequisite works have been done by firmware at
all.
And it seems that the results is not satisfying in all cases.
drm/ast is the first drm drivers which refused to work if not being
POST-ed by the firmware.
You might have found a bug in the ast driver. Ast has means to detect if
the device has been POSTed and maybe do that. If this doesn't work
correctly, it needs a fix.
As Christian mentioned, if anything, you might add an option to specify
the default card to vgaarb (e.g., as PCI slot). But userspace should
avoid the idea of a primary card IMHO.
Best regards
Thomas
Before apply this series, I was unable make drm/ast as the primary video
card easily. On a
multiple video card configuration, the monitor connected with the
AST2400 not light up.
While confusing, a naive programmer may suspect the PRIME is not working.
After applied this series and passing ast.modeset=10 on the kernel cmd
line,
I found that the monitor connected with my ast2400 video card still black,
It doesn't display and doesn't show image to me.
While in the process of study drm/ast, I know that drm/ast driver has
the POST code shipped.
See the ast_post_gpu() function, then, I was wondering why this function
doesn't works.
After a short-time (hasty) debugging, I found that the the
ast_post_gpu() function
didn't get run. Because it have something to do with the ast->config_mode.
Without thinking too much, I hardcoded the ast->config_mode as
ast_use_p2a to
force the ast_post_gpu() function get run.
```
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -132,6 +132,8 @@ static int ast_device_config_init(struct ast_device
*ast)
}
}
+ ast->config_mode = ast_use_p2a;
+
switch (ast->config_mode) {
case ast_use_defaults:
drm_info(dev, "Using default configuration\n");
```
Then, the monitor light up, it display the Ubuntu
Re: [Intel-gfx] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
On Tue, 5 Sep 2023 03:57:15 +0800 Sui Jingfeng wrote: > From: Sui Jingfeng > > On a machine with multiple GPUs, a Linux user has no control over which > one is primary at boot time. This series tries to solve above mentioned > problem by introduced the ->be_primary() function stub. The specific > device drivers can provide an implementation to hook up with this stub by > calling the vga_client_register() function. > > Once the driver bound the device successfully, VGAARB will call back to > the device driver. To query if the device drivers want to be primary or > not. Device drivers can just pass NULL if have no such needs. > > Please note that: > > 1) The ARM64, Loongarch, Mips servers have a lot PCIe slot, and I would >like to mount at least three video cards. > > 2) Typically, those non-86 machines don't have a good UEFI firmware >support, which doesn't support select primary GPU as firmware stage. >Even on x86, there are old UEFI firmwares which already made undesired >decision for you. > > 3) This series is attempt to solve the remain problems at the driver level, >while another series[1] of me is target to solve the majority of the >problems at device level. > > Tested (limited) on x86 with four video card mounted, Intel UHD Graphics > 630 is the default boot VGA, successfully override by ast2400 with > ast.modeset=10 append at the kernel cmd line. > > $ lspci | grep VGA > > 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD > Graphics 630] In all my previous experiments with VGA routing and IGD I found that IGD can't actually release VGA routing and Intel confirmed the hardware doesn't have the ability to do so. It will always be primary from a VGA routing perspective. Was this actually tested with non-UEFI? I suspect it might only work in UEFI mode where we probably don't actually have a dependency on VGA routing. This is essentially why vfio requires UEFI ROMs when assigning GPUs to VMs, VGA routing is too broken to use on Intel systems with IGD. Thanks, Alex > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Caicos XTX [Radeon HD 8490 / R5 235X OEM] > 04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics > Family (rev 30) > 05:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT > 720] (rev a1) > > $ sudo dmesg | grep vgaarb > > pci :00:02.0: vgaarb: setting as boot VGA device > pci :00:02.0: vgaarb: VGA device added: > decodes=io+mem,owns=io+mem,locks=none > pci :01:00.0: vgaarb: VGA device added: > decodes=io+mem,owns=none,locks=none > pci :04:00.0: vgaarb: VGA device added: > decodes=io+mem,owns=none,locks=none > pci :05:00.0: vgaarb: VGA device added: > decodes=io+mem,owns=none,locks=none > vgaarb: loaded > ast :04:00.0: vgaarb: Override as primary by driver > i915 :00:02.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=none:owns=io+mem > radeon :01:00.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=none:owns=none > ast :04:00.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=none:owns=none > > v2: > * Add a simple implemment for drm/i915 and drm/ast > * Pick up all tags (Mario) > v3: > * Fix a mistake for drm/i915 implement > * Fix patch can not be applied problem because of merge conflect. > v4: > * Focus on solve the real problem. > > v1,v2 at https://patchwork.freedesktop.org/series/120059/ >v3 at https://patchwork.freedesktop.org/series/120562/ > > [1] https://patchwork.freedesktop.org/series/122845/ > > Sui Jingfeng (9): > PCI/VGA: Allowing the user to select the primary video adapter at boot > time > drm/nouveau: Implement .be_primary() callback > drm/radeon: Implement .be_primary() callback > drm/amdgpu: Implement .be_primary() callback > drm/i915: Implement .be_primary() callback > drm/loongson: Implement .be_primary() callback > drm/ast: Register as a VGA client by calling vga_client_register() > drm/hibmc: Register as a VGA client by calling vga_client_register() > drm/gma500: Register as a VGA client by calling vga_client_register() > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 11 +++- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 - > drivers/gpu/drm/ast/ast_drv.c | 31 ++ > drivers/gpu/drm/gma500/psb_drv.c | 57 ++- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 15 + > drivers/gpu/drm/i915/display/intel_vga.c | 15 - > drivers/gpu/drm/loongson/loongson_module.c| 2 +- > drivers/gpu/drm/loongson/loongson_module.h| 1 + > drivers/gpu/drm/loongson/lsdc_drv.c | 10 +++- > drivers/gpu/drm/nouveau/nouveau_vga.c | 11 +++- > drivers/gpu/drm/radeon/radeon_device.c| 10 +++- > drivers/pci/vgaarb.c | 43 -- > drivers/vfio/pci/vfio_pci_core.c
Re: [Intel-gfx] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Hi, On 2023/9/5 21:28, Christian König wrote: 2) Typically, those non-86 machines don't have a good UEFI firmware support, which doesn't support select primary GPU as firmware stage. Even on x86, there are old UEFI firmwares which already made undesired decision for you. 3) This series is attempt to solve the remain problems at the driver level, while another series[1] of me is target to solve the majority of the problems at device level. Tested (limited) on x86 with four video card mounted, Intel UHD Graphics 630 is the default boot VGA, successfully override by ast2400 with ast.modeset=10 append at the kernel cmd line. The value 10 is incredibly arbitrary, and multiplied as a magic number all over the place. +1 This is the exact reason why I made this series as RFC, because this is a open-ended problem. The choices of 3,4,5,6,7,8 and 9 are as arbitrary as the number of '10'. '1' and '2' is definitely not suitable, because the seat has already been taken. Take the drm/nouveau as an example: ``` MODULE_PARM_DESC(modeset, "enable driver (default: auto, " "0 = disabled, 1 = enabled, 2 = headless)"); int nouveau_modeset = -1; module_param_named(modeset, nouveau_modeset, int, 0400); ``` '1' is for enable the drm driver, some driver even override the 'nomodeset' parameter. '2' is not suitable, because nouveau use it as headless GPU (render-only or compute class GPU?) '3' is also not likely the best, the concerns is that what if a specific drm driver want to expand the usage in the future? The reason I pick up the digit '10' is that 1) The modeset parameter is unlikely to get expanded up to 10 usages. Other drm drivers only use the '-1', '0' and 1, choose '2' will conflict with drm/nouveau. By pick the digit '10', it leave some space(room) to various device driver authors. It also helps to keep the usage consistent across various drivers. 2) An int taken up 4 byte, I don't want to waste even a single byte, While in the process of defencing my patch, I have to say draft another kernel command line would cause the wasting of precious RAM storage. An int can have 2^31 usage, why we can't improve the utilization rate? 3) Please consider the fact that the modeset is the most common and attractive parameter No name is better than the 'modeset', as other name is not easy to remember. Again, this is for Linux user, thus it is not arbitrary. Despite simple and trivial, I think about it more than one week.
[Intel-gfx] [PATCH 1/2] Revert "drm/i915: Use uabi engines for the default engine map"
Commit 1ec23ed7126e ("drm/i915: Use uabi engines for the default engine
map") switched from using for_each_engine() to for_each_uabi_engine() to
iterate over the user engines. While this seems to be a sensible change,
it's only safe to do when the engines are actually chained using the
rb-tree structure which is not the case during early driver
initialization where it can be either a lock-less list or regular
double-linked list.
In fact, the modesetting initialization code may end up calling
default_engines() through the fb helper code while the engines list
is still llist_node-based:
i915_driver_probe() ->
intel_modeset_init() ->
intel_fbdev_init() ->
drm_fb_helper_init() ->
drm_client_init() ->
drm_client_open() ->
drm_file_alloc() ->
i915_driver_open() ->
i915_gem_open() ->
i915_gem_context_open() ->
i915_gem_create_context() ->
default_engines()
Using for_each_uabi_engine() in default_engines() is therefore wrong, as
it would try to interpret the llist as rb-tree, making it find no engine
at all, as the rb_left and rb_right members will still be NULL, as they
haven't been iniitalized yet.
Revert back to use for_each_engine() which will look at each individual
engine based on its id, i.e. purely array-index based, avoiding the type
confusion mess.
Reported-by: sanitiy checks in grsecurity
Fixes: 1ec23ed7126e ("drm/i915: Use uabi engines for the default engine map")
Signed-off-by: Mathias Krause
Cc: Jonathan Cavitt
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9a9ff84c90d7..e4f7ebbd2690 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1100,15 +1100,16 @@ static struct i915_gem_engines *alloc_engines(unsigned
int count)
static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx,
struct intel_sseu rcs_sseu)
{
- const unsigned int max = I915_NUM_ENGINES;
+ const struct intel_gt *gt = to_gt(ctx->i915);
struct intel_engine_cs *engine;
struct i915_gem_engines *e, *err;
+ enum intel_engine_id id;
- e = alloc_engines(max);
+ e = alloc_engines(I915_NUM_ENGINES);
if (!e)
return ERR_PTR(-ENOMEM);
- for_each_uabi_engine(engine, ctx->i915) {
+ for_each_engine(engine, gt, id) {
struct intel_context *ce;
struct intel_sseu sseu = {};
int ret;
@@ -1116,7 +1117,7 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx,
if (engine->legacy_idx == INVALID_ENGINE)
continue;
- GEM_BUG_ON(engine->legacy_idx >= max);
+ GEM_BUG_ON(engine->legacy_idx >= I915_NUM_ENGINES);
GEM_BUG_ON(e->engines[engine->legacy_idx]);
ce = intel_context_create(engine);
--
2.39.2
[Intel-gfx] [PATCH 0/2] drm/i915: fix rb-tree/llist/list confusion
Commit 1ec23ed7126e ("drm/i915: Use uabi engines for the default engine
map") introduced a bug regarding engine iteration in default_engines()
as the rb tree isn't set up yet that early during driver initialization.
This triggered a sanity check we have in our grsecurity kernels, fixed
by reverting the offending commit (patch 1) and giving the
type-multiplexed members some more visibility to avoid making a similar
mistake again in the future (patch 2).
Please apply!
Thanks,
Mathias
Mathias Krause (2):
Revert "drm/i915: Use uabi engines for the default engine map"
drm/i915: Clarify type evolution of uabi_node/uabi_engines
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 +-
drivers/gpu/drm/i915/gt/intel_engine_user.c | 17 +++--
drivers/gpu/drm/i915/i915_drv.h | 17 -
4 files changed, 37 insertions(+), 16 deletions(-)
--
2.39.2
[Intel-gfx] [PATCH 2/2] drm/i915: Clarify type evolution of uabi_node/uabi_engines
Chaining user engines happens in multiple passes during driver
initialization, mutating its type along the way. It starts off with a
simple lock-less linked list (struct llist_node/head) populated by
intel_engine_add_user() which later gets sorted and converted to an
intermediate regular list (struct list_head) just to be converted once
more to its final rb-tree structure (struct rb_node/root) in
intel_engines_driver_register().
All of these types overlay the uabi_node/uabi_engines members which is
unfortunate but safe if one takes care about using the rb-tree based
structure only after the conversion has completed. However, mistakes
happen and commit 1ec23ed7126e ("drm/i915: Use uabi engines for the
default engine map") violated that assumption, as the multiple types
evolution was all to easy hidden behind casts papering over it.
Make the type evolution of uabi_node/uabi_engines more visible by
putting all members into an anonymous union and use the correctly typed
member in its various users. This allows us to drop quite some ugly
casts and, hopefully, make the evolution of the members better
recognisable to avoid future mistakes.
Signed-off-by: Mathias Krause
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 +-
drivers/gpu/drm/i915/gt/intel_engine_user.c | 17 +++--
drivers/gpu/drm/i915/i915_drv.h | 17 -
3 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index e99a6fa03d45..f0e91efb2acc 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -401,7 +401,15 @@ struct intel_engine_cs {
unsigned long context_tag;
- struct rb_node uabi_node;
+ /*
+* The type evolves during initialization, see related comment for
+* struct drm_i915_private's uabi_engines member.
+*/
+ union {
+ struct llist_node uabi_llist;
+ struct list_head uabi_list;
+ struct rb_node uabi_node;
+ };
struct intel_sseu sseu;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index dcedff41a825..118164ddbb2e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -38,8 +38,7 @@ intel_engine_lookup_user(struct drm_i915_private *i915, u8
class, u8 instance)
void intel_engine_add_user(struct intel_engine_cs *engine)
{
- llist_add((struct llist_node *)>uabi_node,
- (struct llist_head *)>i915->uabi_engines);
+ llist_add(>uabi_llist, >i915->uabi_engines_llist);
}
static const u8 uabi_classes[] = {
@@ -54,9 +53,9 @@ static int engine_cmp(void *priv, const struct list_head *A,
const struct list_head *B)
{
const struct intel_engine_cs *a =
- container_of((struct rb_node *)A, typeof(*a), uabi_node);
+ container_of(A, typeof(*a), uabi_list);
const struct intel_engine_cs *b =
- container_of((struct rb_node *)B, typeof(*b), uabi_node);
+ container_of(B, typeof(*b), uabi_list);
if (uabi_classes[a->class] < uabi_classes[b->class])
return -1;
@@ -73,7 +72,7 @@ static int engine_cmp(void *priv, const struct list_head *A,
static struct llist_node *get_engines(struct drm_i915_private *i915)
{
- return llist_del_all((struct llist_head *)>uabi_engines);
+ return llist_del_all(>uabi_engines_llist);
}
static void sort_engines(struct drm_i915_private *i915,
@@ -83,9 +82,8 @@ static void sort_engines(struct drm_i915_private *i915,
llist_for_each_safe(pos, next, get_engines(i915)) {
struct intel_engine_cs *engine =
- container_of((struct rb_node *)pos, typeof(*engine),
-uabi_node);
- list_add((struct list_head *)>uabi_node, engines);
+ container_of(pos, typeof(*engine), uabi_llist);
+ list_add(>uabi_list, engines);
}
list_sort(NULL, engines, engine_cmp);
}
@@ -213,8 +211,7 @@ void intel_engines_driver_register(struct drm_i915_private
*i915)
p = >uabi_engines.rb_node;
list_for_each_safe(it, next, ) {
struct intel_engine_cs *engine =
- container_of((struct rb_node *)it, typeof(*engine),
-uabi_node);
+ container_of(it, typeof(*engine), uabi_list);
if (intel_gt_has_unrecoverable_error(engine->gt))
continue; /* ignore incomplete engines */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b4cf6f0f636d..68fd64d6a880 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -223,7 +223,22 @@ struct
[Intel-gfx] [PATCH v2] drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top
There is an assertion in ggtt_reserve_guc_top that the global GTT
is of size at least GUC_GGTT_TOP, which is not the case on a 32-bit
platform; see commit 562d55d991b39ce376c492df2f7890fd6a541ffc
("drm/i915/bdw: Only use 2g GGTT for 32b platforms"). If GEM_BUG_ON
is enabled, this triggers a BUG(); if GEM_BUG_ON is disabled, the
subsequent reservation fails and the driver fails to initialise
the device:
i915 :00:02.0: [drm:i915_init_ggtt [i915]] Failed to reserve top of GGTT
for GuC
i915 :00:02.0: Device initialization failed (-28)
i915 :00:02.0: Please file a bug on drm/i915; see
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for
details.
i915: probe of :00:02.0 failed with error -28
Make the reservation at the top of the available space, whatever
that is, instead of assuming that the top will be GUC_GGTT_TOP.
Fixes: 911800765ef6 ("drm/i915/uc: Reserve upper range of GGTT")
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9080
Signed-off-by: Javier Pello
Reviewed-by: Daniele Ceraolo Spurio
Cc: Fernando Pacheco
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: intel-gfx@lists.freedesktop.org
Cc: sta...@vger.kernel.org # v5.3+
---
v2: style change
drivers/gpu/drm/i915/gt/intel_ggtt.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index dd0ed941..da21f278 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -511,20 +511,31 @@ void intel_ggtt_unbind_vma(struct i915_address_space *vm,
vm->clear_range(vm, vma_res->start, vma_res->vma_size);
}
+/*
+ * Reserve the top of the GuC address space for firmware images. Addresses
+ * beyond GUC_GGTT_TOP in the GuC address space are inaccessible by GuC,
+ * which makes for a suitable range to hold GuC/HuC firmware images if the
+ * size of the GGTT is 4G. However, on a 32-bit platform the size of the GGTT
+ * is limited to 2G, which is less than GUC_GGTT_TOP, but we reserve a chunk
+ * of the same size anyway, which is far more than needed, to keep the logic
+ * in uc_fw_ggtt_offset() simple.
+ */
+#define GUC_TOP_RESERVE_SIZE (SZ_4G - GUC_GGTT_TOP)
+
static int ggtt_reserve_guc_top(struct i915_ggtt *ggtt)
{
- u64 size;
+ u64 offset;
int ret;
if (!intel_uc_uses_guc(>vm.gt->uc))
return 0;
- GEM_BUG_ON(ggtt->vm.total <= GUC_GGTT_TOP);
- size = ggtt->vm.total - GUC_GGTT_TOP;
+ GEM_BUG_ON(ggtt->vm.total <= GUC_TOP_RESERVE_SIZE);
+ offset = ggtt->vm.total - GUC_TOP_RESERVE_SIZE;
- ret = i915_gem_gtt_reserve(>vm, NULL, >uc_fw, size,
- GUC_GGTT_TOP, I915_COLOR_UNEVICTABLE,
- PIN_NOEVICT);
+ ret = i915_gem_gtt_reserve(>vm, NULL, >uc_fw,
+ GUC_TOP_RESERVE_SIZE, offset,
+ I915_COLOR_UNEVICTABLE, PIN_NOEVICT);
if (ret)
drm_dbg(>vm.i915->drm,
"Failed to reserve top of GGTT for GuC\n");
--
2.41.0
Re: [Intel-gfx] [PATCH] drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top
On Thu, 31 Aug 2023 15:49:28 -0700
"Ceraolo Spurio, Daniele" wrote:
> On 8/25/2023 7:33 AM, Javier Pello wrote:
> > There is an assertion in ggtt_reserve_guc_top that the global GTT
> > is of size at least GUC_GGTT_TOP, which is not the case on a 32-bit
> > platform; see commit 562d55d991b39ce376c492df2f7890fd6a541ffc
> > ("drm/i915/bdw: Only use 2g GGTT for 32b platforms"). If GEM_BUG_ON
> > is enabled, this triggers a BUG(); if GEM_BUG_ON is disabled, the
> > subsequent reservation fails and the driver fails to initialise
> > the device:
> >
> > i915 :00:02.0: [drm:i915_init_ggtt [i915]] Failed to reserve top of
> > GGTT for GuC
> > i915 :00:02.0: Device initialization failed (-28)
> > i915 :00:02.0: Please file a bug on drm/i915; see
> > https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for
> > details.
> > i915: probe of :00:02.0 failed with error -28
> >
> > Make the reservation at the top of the available space, whatever
> > that is, instead of assuming that the top will be GUC_GGTT_TOP.
> >
> > Fixes: 911800765ef6 ("drm/i915/uc: Reserve upper range of GGTT")
>
> For tracking, it might be good to also add:
>
> Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9080
Sure.
> > Signed-off-by: Javier Pello
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: sta...@vger.kernel.org # v5.3+
>
> Need the full CC list here, so that when the patch gets back-ported the
> relevant developers get automatically added.
I was unsure if I should add them from the start or wait for a review.
> > ---
> > drivers/gpu/drm/i915/gt/intel_ggtt.c | 21 +++--
> > 1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > index e9328e1a..0157bebb 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > @@ -511,20 +511,29 @@ void intel_ggtt_unbind_vma(struct i915_address_space
> > *vm,
> > vm->clear_range(vm, vma_res->start, vma_res->vma_size);
> > }
> >
> > +/* Reserve the top of the GuC address space for firmware images. Addresses
> > + * beyond GUC_GGTT_TOP in the GuC address space are inaccessible by GuC,
> > + * which makes for a suitable range to hold GuC/HuC firmware images if the
> > + * size of the GGTT is 4G. However, on a 32-bit platform the size of the
> > GGTT
> > + * is limited to 2G, which is less than GUC_GGTT_TOP, but we reserve a
> > chunk
> > + * of the same size anyway, which is far more than needed, to keep the
> > logic
> > + * in uc_fw_ggtt_offset() simple. */
>
> Style: multi-line comment should be formatted as:
>
> /*
> * Text
> * more text
> */
Yes, I realised that after I sent the patch, but I thought I would
wait for replies rather than resending with only a style change.
> > +#define GUC_TOP_RESERVE_SIZE (SZ_4G - GUC_GGTT_TOP)
> > +
> > static int ggtt_reserve_guc_top(struct i915_ggtt *ggtt)
> > {
> > - u64 size;
> > + u64 offset;
> > int ret;
> >
> > if (!intel_uc_uses_guc(>vm.gt->uc))
> > return 0;
> >
> > - GEM_BUG_ON(ggtt->vm.total <= GUC_GGTT_TOP);
> > - size = ggtt->vm.total - GUC_GGTT_TOP;
> > + GEM_BUG_ON(ggtt->vm.total <= GUC_TOP_RESERVE_SIZE);
> > + offset = ggtt->vm.total - GUC_TOP_RESERVE_SIZE;
> >
> > - ret = i915_gem_gtt_reserve(>vm, NULL, >uc_fw, size,
> > - GUC_GGTT_TOP, I915_COLOR_UNEVICTABLE,
> > - PIN_NOEVICT);
> > + ret = i915_gem_gtt_reserve(>vm, NULL, >uc_fw,
> > + GUC_TOP_RESERVE_SIZE, offset,
> > + I915_COLOR_UNEVICTABLE, PIN_NOEVICT);
>
> The code change looks good to me, so with the style fix and the
> additions to the commit message this is:
>
> Reviewed-by: Daniele Ceraolo Spurio
Thank you.
Javier
Re: [Intel-gfx] [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
If anything, the primary graphics adapter is the one initialized by
the firmware. I think our boot-up graphics also make this assumption
implicitly.
Yes, but by the time of DRM drivers get loaded successfully,the boot-up
graphics already finished.
Firmware framebuffer device already get killed by the
drm_aperture_remove_conflicting_pci_framebuffers()
function (or its siblings). So, this series is definitely not to interact with
the firmware framebuffer
(or more intelligent framebuffer drivers). It is for user space program, such
as X server and Wayland
compositor. Its for Linux user or drm drivers testers, which allow them to
direct graphic display server
using right hardware of interested as primary video card.
Also, I believe that X server and Wayland compositor are the best test examples.
If a specific DRM driver can't work with X server as a primary,
then there probably have something wrong.
But what's the use case for overriding this setting?
On a specific machine with multiple GPUs mounted,
only the primary graphics get POST-ed (initialized) by the firmware.
Therefore, the DRM drivers for the rest video cards, have to choose to
work without the prerequisite setups done by firmware, This is called as POST.
One of the use cases of this series is to test if a specific DRM driver could
works properly,
even though there is no prerequisite works have been done by firmware at all.
And it seems that the results is not satisfying in all cases.
drm/ast is the first drm drivers which refused to work if not being POST-ed by
the firmware.
Before apply this series, I was unable make drm/ast as the primary video card
easily. On a
multiple video card configuration, the monitor connected with the AST2400 not
light up.
While confusing, a naive programmer may suspect the PRIME is not working.
After applied this series and passing ast.modeset=10 on the kernel cmd line,
I found that the monitor connected with my ast2400 video card still black,
It doesn't display and doesn't show image to me.
While in the process of study drm/ast, I know that drm/ast driver has the POST
code shipped.
See the ast_post_gpu() function, then, I was wondering why this function
doesn't works.
After a short-time (hasty) debugging, I found that the the ast_post_gpu()
function
didn't get run. Because it have something to do with the ast->config_mode.
Without thinking too much, I hardcoded the ast->config_mode as ast_use_p2a to
force the ast_post_gpu() function get run.
```
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -132,6 +132,8 @@ static int ast_device_config_init(struct ast_device
*ast)
}
}
+ ast->config_mode = ast_use_p2a;
+
switch (ast->config_mode) {
case ast_use_defaults:
drm_info(dev, "Using default configuration\n");
```
Then, the monitor light up, it display the Ubuntu greeter to me.
Therefore, my patch is helpful, at lease for the Linux drm driver tester and
developer.
It allow programmers to test the specific part of the specific drive
without changing a line of the source code and without the need of sudo
authority.
It helps to improve efficiency of the testing and patch verification.
I know the PrimaryGPU option of Xorg conf, but this approach will remember the
setup
have been made, you need modify it with root authority each time you want to
switch
the primary. But on rapid developing and/or testing multiple video drivers, with
only one computer hardware resource available. What we really want probably is a
one-shoot command as this series provide.
So, this is the first use case. This probably also help to test full modeset,
PRIME and reverse PRIME on multiple video card machine.
Best regards
Thomas
Re: [Intel-gfx] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Am 05.09.23 um 12:38 schrieb Jani Nikula: On Tue, 05 Sep 2023, Sui Jingfeng wrote: From: Sui Jingfeng On a machine with multiple GPUs, a Linux user has no control over which one is primary at boot time. This series tries to solve above mentioned problem by introduced the ->be_primary() function stub. The specific device drivers can provide an implementation to hook up with this stub by calling the vga_client_register() function. Once the driver bound the device successfully, VGAARB will call back to the device driver. To query if the device drivers want to be primary or not. Device drivers can just pass NULL if have no such needs. Please note that: 1) The ARM64, Loongarch, Mips servers have a lot PCIe slot, and I would like to mount at least three video cards. Well, you rarely find a board which can actually handle a single one :) 2) Typically, those non-86 machines don't have a good UEFI firmware support, which doesn't support select primary GPU as firmware stage. Even on x86, there are old UEFI firmwares which already made undesired decision for you. 3) This series is attempt to solve the remain problems at the driver level, while another series[1] of me is target to solve the majority of the problems at device level. Tested (limited) on x86 with four video card mounted, Intel UHD Graphics 630 is the default boot VGA, successfully override by ast2400 with ast.modeset=10 append at the kernel cmd line. The value 10 is incredibly arbitrary, and multiplied as a magic number all over the place. +1 $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos XTX [Radeon HD 8490 / R5 235X OEM] 04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 30) 05:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 720] (rev a1) In this example, all of the GPUs are driven by different drivers. What good does a module parameter do if you have multiple GPUs of the same model, all driven by the same driver module? Completely agree. Question is what is the benefit for the end user to actually specify this? If you want the initial console on a different device than implement a kernel options for vgaarb and *not* the drivers. Regards, Christian. BR, Jani. $ sudo dmesg | grep vgaarb pci :00:02.0: vgaarb: setting as boot VGA device pci :00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none pci :04:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none pci :05:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none vgaarb: loaded ast :04:00.0: vgaarb: Override as primary by driver i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem radeon :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none ast :04:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none v2: * Add a simple implemment for drm/i915 and drm/ast * Pick up all tags (Mario) v3: * Fix a mistake for drm/i915 implement * Fix patch can not be applied problem because of merge conflect. v4: * Focus on solve the real problem. v1,v2 at https://patchwork.freedesktop.org/series/120059/ v3 at https://patchwork.freedesktop.org/series/120562/ [1] https://patchwork.freedesktop.org/series/122845/ Sui Jingfeng (9): PCI/VGA: Allowing the user to select the primary video adapter at boot time drm/nouveau: Implement .be_primary() callback drm/radeon: Implement .be_primary() callback drm/amdgpu: Implement .be_primary() callback drm/i915: Implement .be_primary() callback drm/loongson: Implement .be_primary() callback drm/ast: Register as a VGA client by calling vga_client_register() drm/hibmc: Register as a VGA client by calling vga_client_register() drm/gma500: Register as a VGA client by calling vga_client_register() drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 11 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 - drivers/gpu/drm/ast/ast_drv.c | 31 ++ drivers/gpu/drm/gma500/psb_drv.c | 57 ++- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 15 + drivers/gpu/drm/i915/display/intel_vga.c | 15 - drivers/gpu/drm/loongson/loongson_module.c| 2 +- drivers/gpu/drm/loongson/loongson_module.h| 1 + drivers/gpu/drm/loongson/lsdc_drv.c | 10 +++- drivers/gpu/drm/nouveau/nouveau_vga.c | 11 +++- drivers/gpu/drm/radeon/radeon_device.c| 10 +++- drivers/pci/vgaarb.c | 43 -- drivers/vfio/pci/vfio_pci_core.c | 2 +-
Re: [Intel-gfx] [RFC 00/33] Add Support for Plane Color Pipeline
On Tue, Sep 05, 2023 at 02:33:04PM +0200, Sebastian Wick wrote: > On Tue, Sep 05, 2023 at 02:33:26PM +0300, Pekka Paalanen wrote: > > On Mon, 4 Sep 2023 14:29:56 + > > "Shankar, Uma" wrote: > > > > > > -Original Message- > > > > From: Sebastian Wick > > > > Sent: Thursday, August 31, 2023 2:46 AM > > > > To: Shankar, Uma > > > > Cc: Harry Wentland ; intel- > > > > g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; wayland- > > > > de...@lists.freedesktop.org; Ville Syrjala > > > > ; Pekka > > > > Paalanen ; Simon Ser > > > > ; > > > > Melissa Wen ; Jonas Ådahl ; Shashank > > > > Sharma ; Alexander Goins ; > > > > Naseer Ahmed ; Christopher Braga > > > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > > > On Wed, Aug 30, 2023 at 08:47:37AM +, Shankar, Uma wrote: > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: Harry Wentland > > > > > > Sent: Wednesday, August 30, 2023 12:56 AM > > > > > > To: Shankar, Uma ; > > > > > > intel-gfx@lists.freedesktop.org; dri- de...@lists.freedesktop.org > > > > > > Cc: wayland-de...@lists.freedesktop.org; Ville Syrjala > > > > > > ; Pekka Paalanen > > > > > > ; Simon Ser ; > > > > > > Melissa Wen ; Jonas Ådahl ; > > > > > > Sebastian Wick ; Shashank Sharma > > > > > > ; Alexander Goins ; > > > > > > Naseer Ahmed ; Christopher Braga > > > > > > > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > > > > > > > +CC Naseer and Chris, FYI > > > > > > > > > > > > See https://patchwork.freedesktop.org/series/123024/ for whole > > > > > > series. > > > > > > > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > > > > Introduction > > > > > > > > > > > > > > > > > > > > > Modern hardwares have various color processing capabilities both > > > > > > > at pre-blending and post-blending phases in the color pipeline. > > > > > > > The current drm implementation exposes only the post-blending > > > > > > > color hardware blocks. Support for pre-blending hardware is > > > > > > > missing. > > > > > > > There are multiple use cases where pre-blending color hardware > > > > > > > will be > > > > > > > useful: > > > > > > > a) Linearization of input buffers encoded in various transfer > > > > > > > functions. > > > > > > > b) Color Space conversion > > > > > > > c) Tone mapping > > > > > > > d) Frame buffer format conversion > > > > > > > e) Non-linearization of buffer(apply transfer function) > > > > > > > f) 3D Luts > > > > > > > > > > > > > > and other miscellaneous color operations. > > > > > > > > > > > > > > Hence, there is a need to expose the color capabilities of the > > > > > > > hardware to user-space. This will help userspace/middleware to use > > > > > > > display hardware for color processing and blending instead of > > > > > > > doing it through GPU shaders. > > > > > > > > > > > > > > > > > > > Thanks, Uma, for sending this. I've been working on something > > > > > > similar but you beat me to it. :) > > > > > > > > > > Thanks Harry for the useful feedback and overall collaboration on > > > > > this so far. > > > > > > > > > > > > > > > > > > > Work done so far and relevant references > > > > > > > > > > > > > > > > > > > > > Some implementation is done by Intel and AMD/Igalia to address > > > > > > > the same. > > > > > > > Broad consensus is there that we need a generic API at drm core to > > > > > > > suffice the use case of various HW vendors. Below are the links > > > > > > > capturing the discussion so far. > > > > > > > > > > > > > > Intel's Plane Color Implementation: > > > > > > > https://patchwork.freedesktop.org/series/90825/ > > > > > > > AMD's Plane Color Implementation: > > > > > > > https://patchwork.freedesktop.org/series/116862/ > > > > > > > > > > > > > > > > > > > > > Hackfest conclusions > > > > > > > > > > > > > > > > > > > > > HDR/Color Hackfest was organised by Redhat to bring all the > > > > > > > industry stakeholders together and converge on a common uapi > > > > expectations. > > > > > > > Participants from Intel, AMD, Nvidia, Collabora, Redhat, Igalia > > > > > > > and other prominent user-space developers and maintainers. > > > > > > > > > > > > > > Discussions happened on the uapi expectations, opens, nature of > > > > > > > hardware of multiple hardware vendors, challenges in generalizing > > > > > > > the same and the path forward. Consensus was made that drm core > > > > > > > should implement descriptive APIs and not go with prescriptive > > > > > > > APIs. DRM core should just expose the hardware capabilities; > > > > > > > enabling, customizing and programming the same should be done by > > > > > > > the user-space. Driver should just > > > > > > honor the user space request without doing any operations > > > > > > internally. > > > > > > > > > > > > > > Thanks to Simon Ser, for nicely
Re: [Intel-gfx] [RFC 00/33] Add Support for Plane Color Pipeline
On Tue, Sep 05, 2023 at 02:33:26PM +0300, Pekka Paalanen wrote: > On Mon, 4 Sep 2023 14:29:56 + > "Shankar, Uma" wrote: > > > > -Original Message- > > > From: Sebastian Wick > > > Sent: Thursday, August 31, 2023 2:46 AM > > > To: Shankar, Uma > > > Cc: Harry Wentland ; intel- > > > g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; wayland- > > > de...@lists.freedesktop.org; Ville Syrjala > > > ; Pekka > > > Paalanen ; Simon Ser ; > > > Melissa Wen ; Jonas Ådahl ; Shashank > > > Sharma ; Alexander Goins ; > > > Naseer Ahmed ; Christopher Braga > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > On Wed, Aug 30, 2023 at 08:47:37AM +, Shankar, Uma wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: Harry Wentland > > > > > Sent: Wednesday, August 30, 2023 12:56 AM > > > > > To: Shankar, Uma ; > > > > > intel-gfx@lists.freedesktop.org; dri- de...@lists.freedesktop.org > > > > > Cc: wayland-de...@lists.freedesktop.org; Ville Syrjala > > > > > ; Pekka Paalanen > > > > > ; Simon Ser ; > > > > > Melissa Wen ; Jonas Ådahl ; > > > > > Sebastian Wick ; Shashank Sharma > > > > > ; Alexander Goins ; > > > > > Naseer Ahmed ; Christopher Braga > > > > > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > > > > > +CC Naseer and Chris, FYI > > > > > > > > > > See https://patchwork.freedesktop.org/series/123024/ for whole series. > > > > > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > > > Introduction > > > > > > > > > > > > > > > > > > Modern hardwares have various color processing capabilities both > > > > > > at pre-blending and post-blending phases in the color pipeline. > > > > > > The current drm implementation exposes only the post-blending > > > > > > color hardware blocks. Support for pre-blending hardware is missing. > > > > > > There are multiple use cases where pre-blending color hardware > > > > > > will be > > > > > > useful: > > > > > > a) Linearization of input buffers encoded in various transfer > > > > > >functions. > > > > > > b) Color Space conversion > > > > > > c) Tone mapping > > > > > > d) Frame buffer format conversion > > > > > > e) Non-linearization of buffer(apply transfer function) > > > > > > f) 3D Luts > > > > > > > > > > > > and other miscellaneous color operations. > > > > > > > > > > > > Hence, there is a need to expose the color capabilities of the > > > > > > hardware to user-space. This will help userspace/middleware to use > > > > > > display hardware for color processing and blending instead of > > > > > > doing it through GPU shaders. > > > > > > > > > > > > > > > > Thanks, Uma, for sending this. I've been working on something > > > > > similar but you beat me to it. :) > > > > > > > > Thanks Harry for the useful feedback and overall collaboration on this > > > > so far. > > > > > > > > > > > > > > > > Work done so far and relevant references > > > > > > > > > > > > > > > > > > Some implementation is done by Intel and AMD/Igalia to address the > > > > > > same. > > > > > > Broad consensus is there that we need a generic API at drm core to > > > > > > suffice the use case of various HW vendors. Below are the links > > > > > > capturing the discussion so far. > > > > > > > > > > > > Intel's Plane Color Implementation: > > > > > > https://patchwork.freedesktop.org/series/90825/ > > > > > > AMD's Plane Color Implementation: > > > > > > https://patchwork.freedesktop.org/series/116862/ > > > > > > > > > > > > > > > > > > Hackfest conclusions > > > > > > > > > > > > > > > > > > HDR/Color Hackfest was organised by Redhat to bring all the > > > > > > industry stakeholders together and converge on a common uapi > > > expectations. > > > > > > Participants from Intel, AMD, Nvidia, Collabora, Redhat, Igalia > > > > > > and other prominent user-space developers and maintainers. > > > > > > > > > > > > Discussions happened on the uapi expectations, opens, nature of > > > > > > hardware of multiple hardware vendors, challenges in generalizing > > > > > > the same and the path forward. Consensus was made that drm core > > > > > > should implement descriptive APIs and not go with prescriptive > > > > > > APIs. DRM core should just expose the hardware capabilities; > > > > > > enabling, customizing and programming the same should be done by > > > > > > the user-space. Driver should just > > > > > honor the user space request without doing any operations internally. > > > > > > > > > > > > > > > > > Thanks to Simon Ser, for nicely documenting the design consensus > > > > > > and an UAPI RFC which can be referred to here: > > > > > > > > > > > > https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze > > > > > > _hD5 > > > > > > > > > > > > > > nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1 > > > Q > > > >
Re: [Intel-gfx] [PATCH v5 3/6] drm/i915/panelreplay: Initializaton and compute config for panel replay
Hi Animesh,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Animesh-Manna/drm-panelreplay-dpcd-register-definition-for-panelreplay/20230905-154811
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
patch link:
https://lore.kernel.org/r/20230905073551.958368-4-animesh.manna%40intel.com
patch subject: [Intel-gfx] [PATCH v5 3/6] drm/i915/panelreplay: Initializaton
and compute config for panel replay
config: i386-randconfig-003-20230905
(https://download.01.org/0day-ci/archive/20230905/202309051920.fd7yid3k-...@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git
ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20230905/202309051920.fd7yid3k-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202309051920.fd7yid3k-...@intel.com/
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_dp.c:3779:27: error: overlapping
>> comparisons always evaluate to true [-Werror,-Wtautological-overlap-compare]
if (vsc->revision != 0x5 || vsc->revision != 0x7)
~^~~
1 error generated.
vim +3779 drivers/gpu/drm/i915/display/intel_dp.c
3754
3755 static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
3756 struct dp_sdp *sdp, size_t size)
3757 {
3758 size_t length = sizeof(struct dp_sdp);
3759
3760 if (size < length)
3761 return -ENOSPC;
3762
3763 memset(sdp, 0, size);
3764
3765 /*
3766 * Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
3767 * VSC SDP Header Bytes
3768 */
3769 sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
3770 sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet
Type */
3771 sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
3772 sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data
Bytes */
3773
3774 /*
3775 * Other than revision 0x5 which supports Pixel
Encoding/Colorimetry
3776 * Format as per DP 1.4a spec, revision 0x7 also supports Pixel
3777 * Encoding/Colorimetry Format as per DP 2.0 spec.
3778 */
> 3779 if (vsc->revision != 0x5 || vsc->revision != 0x7)
3780 goto out;
3781
3782 /* VSC SDP Payload for DB16 through DB18 */
3783 /* Pixel Encoding and Colorimetry Formats */
3784 sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
3785 sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
3786
3787 switch (vsc->bpc) {
3788 case 6:
3789 /* 6bpc: 0x0 */
3790 break;
3791 case 8:
3792 sdp->db[17] = 0x1; /* DB17[3:0] */
3793 break;
3794 case 10:
3795 sdp->db[17] = 0x2;
3796 break;
3797 case 12:
3798 sdp->db[17] = 0x3;
3799 break;
3800 case 16:
3801 sdp->db[17] = 0x4;
3802 break;
3803 default:
3804 MISSING_CASE(vsc->bpc);
3805 break;
3806 }
3807 /* Dynamic Range and Component Bit Depth */
3808 if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
3809 sdp->db[17] |= 0x80; /* DB17[7] */
3810
3811 /* Content Type */
3812 sdp->db[18] = vsc->content_type & 0x7;
3813
3814 out:
3815 return length;
3816 }
3817
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [Intel-gfx] [RFC 00/33] Add Support for Plane Color Pipeline
On Mon, 4 Sep 2023 14:29:56 + "Shankar, Uma" wrote: > > -Original Message- > > From: Sebastian Wick > > Sent: Thursday, August 31, 2023 2:46 AM > > To: Shankar, Uma > > Cc: Harry Wentland ; intel- > > g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; wayland- > > de...@lists.freedesktop.org; Ville Syrjala ; > > Pekka > > Paalanen ; Simon Ser ; > > Melissa Wen ; Jonas Ådahl ; Shashank > > Sharma ; Alexander Goins ; > > Naseer Ahmed ; Christopher Braga > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > On Wed, Aug 30, 2023 at 08:47:37AM +, Shankar, Uma wrote: > > > > > > > > > > -Original Message- > > > > From: Harry Wentland > > > > Sent: Wednesday, August 30, 2023 12:56 AM > > > > To: Shankar, Uma ; > > > > intel-gfx@lists.freedesktop.org; dri- de...@lists.freedesktop.org > > > > Cc: wayland-de...@lists.freedesktop.org; Ville Syrjala > > > > ; Pekka Paalanen > > > > ; Simon Ser ; > > > > Melissa Wen ; Jonas Ådahl ; > > > > Sebastian Wick ; Shashank Sharma > > > > ; Alexander Goins ; > > > > Naseer Ahmed ; Christopher Braga > > > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > > > +CC Naseer and Chris, FYI > > > > > > > > See https://patchwork.freedesktop.org/series/123024/ for whole series. > > > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > > Introduction > > > > > > > > > > > > > > > Modern hardwares have various color processing capabilities both > > > > > at pre-blending and post-blending phases in the color pipeline. > > > > > The current drm implementation exposes only the post-blending > > > > > color hardware blocks. Support for pre-blending hardware is missing. > > > > > There are multiple use cases where pre-blending color hardware > > > > > will be > > > > > useful: > > > > > a) Linearization of input buffers encoded in various transfer > > > > > functions. > > > > > b) Color Space conversion > > > > > c) Tone mapping > > > > > d) Frame buffer format conversion > > > > > e) Non-linearization of buffer(apply transfer function) > > > > > f) 3D Luts > > > > > > > > > > and other miscellaneous color operations. > > > > > > > > > > Hence, there is a need to expose the color capabilities of the > > > > > hardware to user-space. This will help userspace/middleware to use > > > > > display hardware for color processing and blending instead of > > > > > doing it through GPU shaders. > > > > > > > > > > > > > Thanks, Uma, for sending this. I've been working on something > > > > similar but you beat me to it. :) > > > > > > Thanks Harry for the useful feedback and overall collaboration on this so > > > far. > > > > > > > > > > > > > Work done so far and relevant references > > > > > > > > > > > > > > > Some implementation is done by Intel and AMD/Igalia to address the > > > > > same. > > > > > Broad consensus is there that we need a generic API at drm core to > > > > > suffice the use case of various HW vendors. Below are the links > > > > > capturing the discussion so far. > > > > > > > > > > Intel's Plane Color Implementation: > > > > > https://patchwork.freedesktop.org/series/90825/ > > > > > AMD's Plane Color Implementation: > > > > > https://patchwork.freedesktop.org/series/116862/ > > > > > > > > > > > > > > > Hackfest conclusions > > > > > > > > > > > > > > > HDR/Color Hackfest was organised by Redhat to bring all the > > > > > industry stakeholders together and converge on a common uapi > > expectations. > > > > > Participants from Intel, AMD, Nvidia, Collabora, Redhat, Igalia > > > > > and other prominent user-space developers and maintainers. > > > > > > > > > > Discussions happened on the uapi expectations, opens, nature of > > > > > hardware of multiple hardware vendors, challenges in generalizing > > > > > the same and the path forward. Consensus was made that drm core > > > > > should implement descriptive APIs and not go with prescriptive > > > > > APIs. DRM core should just expose the hardware capabilities; > > > > > enabling, customizing and programming the same should be done by > > > > > the user-space. Driver should just > > > > honor the user space request without doing any operations internally. > > > > > > > > > > Thanks to Simon Ser, for nicely documenting the design consensus > > > > > and an UAPI RFC which can be referred to here: > > > > > > > > > > https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze > > > > > _hD5 > > > > > > > > > > > nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1 > > Q > > > > Wn48 > > > > > 8=@emersion.fr/ > > > > > > > > > > > > > > > Design considerations > > > > > = > > > > > > > > > > Following are the important aspects taken into account while > > > > > designing the current RFC > > > > > proposal: > > > > > > > > > > 1.
Re: [Intel-gfx] [RFC 02/33] drm: Add color operation structure
On Mon, 4 Sep 2023 14:10:05 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: dri-devel On Behalf Of Pekka
> > Paalanen
> > Sent: Wednesday, August 30, 2023 6:30 PM
> > To: Shankar, Uma
> > Cc: intel-gfx@lists.freedesktop.org; Borah, Chaitanya Kumar
> > ; dri-de...@lists.freedesktop.org; wayland-
> > de...@lists.freedesktop.org
> > Subject: Re: [RFC 02/33] drm: Add color operation structure
> >
> > On Tue, 29 Aug 2023 21:33:51 +0530
> > Uma Shankar wrote:
> >
> > > From: Chaitanya Kumar Borah
> > >
> > > Each Color Hardware block will be represented uniquely in the color
> > > pipeline. Define the structure to represent the same.
> > >
> > > These color operations will form the building blocks of a color
> > > pipeline which best represents the underlying Hardware. Color
> > > operations can be re-arranged, substracted or added to create distinct
> > > color pipelines to accurately describe the Hardware blocks present in
> > > the display engine.
> > >
> > > Co-developed-by: Uma Shankar
> > > Signed-off-by: Uma Shankar
> > > Signed-off-by: Chaitanya Kumar Borah
> > > ---
> > > include/uapi/drm/drm_mode.h | 72
> > > +
> > > 1 file changed, 72 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > index ea1b639bcb28..882479f41745 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -943,6 +943,78 @@ struct hdr_output_metadata {
> > > };
> > > };
> > >
> > > +/**
> > > + * enum color_op_block
> > > + *
> > > + * Enums to identify hardware color blocks.
> > > + *
> > > + * @DRM_CB_PRE_CSC: LUT before the CTM unit
> > > + * @DRM_CB_CSC: CTM hardware supporting 3x3 matrix
> > > + * @DRM_CB_POST_CSC: LUT after the CTM unit
> > > + * @DRM_CB_3D_LUT: LUT hardware with coefficients for all
> > > + * color components
> > > + * @DRM_CB_PRIVATE: Vendor specific hardware unit. Vendor
> > > + * can expose a custom hardware by defining a
> > > + * color operation block with this name as
> > > + * identifier
> >
> > This naming scheme does not seem to work. It assumes a far too rigid
> > pipeline,
> > just like the old KMS property design. What if you have two other operations
> > between PRE_CSC and CSC?
> >
> > What sense do PRE_CSC and POST_CSC make if you don't happen to have a CSC
> > operation?
>
> Sure, we can re-look at the naming. However, it will be good to define some
> standard
> operations common to all vendors and keep the rest as vendor private.
My opinion is that these "names" should not even be an enum at all.
You're talking about operations, but operation is 'type', not 'name'.
There needs to be no pre-defined, hardcoded pipeline structure in the
UAPI design. Your naming scheme, and the old KMS color property design,
assume that there is such a rigid pre-defined structure that all
hardware and drivers must adhere to. That does not work.
Drivers need to be able to expose any arbitrary operations in any
arbitrary order in each pipeline, with no pre-determined or hinted
"intended use". We want to define the operations, and not say what they
should be used for. Usage examples are for accompanying documentation,
not API tokens.
This idea is at the core of the new color pipeline design we have been
discussing.
> > What if a driver put POST_CSC before PRE_CSC in its pipeline?
> >
> > What if your CSC is actually a series of three independent operations, and
> > in
> > addition you have PRE_CSC and POST_CSC?
>
> We should try to standardized the operations as much as possible and leave
> rest as
> vendor private. Current proposal allows us to do that.
>
> > 3D_LUT is an operation category, not a name. The same could be said about
> > private.
>
> Sure, will fix this.
>
> > Given that all these are also UAPI, do we also need protect old userspace
> > from
> > seeing values it does not understand?
>
> For the values userspace doesn't understand, it can ignore the blocks. We
> should ensure
> that userspace always gets a clean state wrt color hardware state and no
> baggage from
> another client should be there. With that there is no burden of disabling
> that particular
> block will be there on an older userspace.
>
> > > + */
> > > +enum color_op_block {
> > > + DRM_CB_INVAL = -1,
> > > +
> > > + DRM_CB_PRE_CSC = 0,
> > > + DRM_CB_CSC,
> > > + DRM_CB_POST_CSC,
> > > + DRM_CB_3D_LUT,
> > > +
> > > + /* Any new generic hardware block can be updated here */
> > > +
> > > + /*
> > > + * PRIVATE is kept at 255 to make it future proof and leave
> > > + * scope for any new addition
> > > + */
> > > + DRM_CB_PRIVATE = 255,
> > > + DRM_CB_MAX = DRM_CB_PRIVATE,
> > > +};
> > > +
> > > +/**
> > > + * enum color_op_type
> > > + *
> > > + * These enums are to identify the mathematical operation that
> > > + * a hardware block is capable of.
> > > + * @CURVE_1D:
Re: [Intel-gfx] [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane Color Pipeline
On Mon, 4 Sep 2023 13:44:49 + "Shankar, Uma" wrote: > > -Original Message- > > From: dri-devel On Behalf Of Pekka > > Paalanen > > Sent: Wednesday, August 30, 2023 5:59 PM > > To: Shankar, Uma > > Cc: intel-gfx@lists.freedesktop.org; Borah, Chaitanya Kumar > > ; dri-de...@lists.freedesktop.org; wayland- > > de...@lists.freedesktop.org > > Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane > > Color Pipeline > > > > On Wed, 30 Aug 2023 08:59:36 + > > "Shankar, Uma" wrote: > > > > > > -Original Message- > > > > From: Harry Wentland > > > > Sent: Wednesday, August 30, 2023 1:10 AM > > > > To: Shankar, Uma ; > > > > intel-gfx@lists.freedesktop.org; dri- de...@lists.freedesktop.org > > > > Cc: Borah, Chaitanya Kumar ; > > > > wayland- de...@lists.freedesktop.org > > > > Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed > > > > Plane Color Pipeline > > > > > > > > > > > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > > Add the documentation for the new proposed Plane Color Pipeline. > > > > > > > > > > Co-developed-by: Chaitanya Kumar Borah > > > > > > > > > > Signed-off-by: Chaitanya Kumar Borah > > > > > > > > > > Signed-off-by: Uma Shankar > > > > > --- > > > > > .../gpu/rfc/plane_color_pipeline.rst | 394 > > > > > ++ > > > > > 1 file changed, 394 insertions(+) > > > > > create mode 100644 > > > > > Documentation/gpu/rfc/plane_color_pipeline.rst > > > > > > > > > > diff --git a/Documentation/gpu/rfc/plane_color_pipeline.rst > > > > > b/Documentation/gpu/rfc/plane_color_pipeline.rst > > > > > new file mode 100644 > > > > > index ..60ce515b6ea7 > > > > > --- /dev/null > > > > > +++ b/Documentation/gpu/rfc/plane_color_pipeline.rst > > > > ... > > > > Hi Uma! > > Thanks Pekka for the feedback and useful inputs. Hi Uma, sorry to say, but the overall feeling I get from this proposal is that it is just the current color related KMS properties wrapped in a pipeline blob. That is not the re-design I believe we are looking for, and the feeling is based on several details that are just copied from the current property design. Also the "private" stuff has to go. All the varying LUT entries, varying LUT precision, 1D/3D LUTs, varying LUT tap distribution, and parametrized curves are good development, but right now we are looking at things one step higher level: the overall color pipeline design and how to represent any operation. Most of this series is considering details below the current attention level, hence I'm paying attention only to the first few patches. More below. > > > > > +This color pipeline is then packaged within a blob for the user > > > > > +space to retrieve it. Details can be found in the next section > > > > > + > > > > > > > > Not sure I like blobs that contain other blob ids. > > > > > > It provides flexibility and helps with just one interface to > > > userspace. Its easy to handle and manage once we get the hang of it . > > > > > > We can clearly define the steps of parsing and data structures to be > > > used while interpreting and parsing the blobs. > > > > Don't forget extendability. Possibly every single struct will need some > > kind of > > versioning, and then it's not simple to parse anymore. Add to that new/old > > kernel > > vs. old/new userspace, and it seems a bit nightmarish to design. > > Structure to be used to interpret the blob should be defined as UAPI only and > is not > expected to change once agreed upon. It should be interpreted like a standard > property. > So structure to be used, say for 3dLut or 1dlut or CTM operations should be > standardized > and fixed. No versioning of structure should be done and same > rules/restrictions as of UAPI > property should be applied. That sounds like a UAPI that cannot be extended, either. So in a few years we'd be looking at replacing it. Or maybe you are just re-inventing the KMS object property system as blobs? Replacing a single KMS property is much easier than replacing the foundations of the whole color pipeline design. > ... > > I have a feeling that introspection will be valuable here, to help people > > understand what their hardware could do if they had the code to use it. > > 'name' > > and 'type' being integers require a translation table to strings before > > they are > > readable, and it would be best if the kernel itself provided that > > translation. > > Name and type can be standardized in enum and well documented in the UAPI. > For all the standard hardware blocks common for all vendors and serving most > of the > common usecases, we can define standard names in enum. These can be easily > interpreted by a table as done in many cases already in driver and userspace. Yeah, but it won't help with the type-specific parameter blobs that are totally custom per each operation type. With the KMS property system we could have more generic introspection
Re: [Intel-gfx] [PATCH v5 3/6] drm/i915/panelreplay: Initializaton and compute config for panel replay
Hi Animesh,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Animesh-Manna/drm-panelreplay-dpcd-register-definition-for-panelreplay/20230905-154811
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
patch link:
https://lore.kernel.org/r/20230905073551.958368-4-animesh.manna%40intel.com
patch subject: [Intel-gfx] [PATCH v5 3/6] drm/i915/panelreplay: Initializaton
and compute config for panel replay
config: i386-randconfig-r036-20230905
(https://download.01.org/0day-ci/archive/20230905/202309051831.amujjocb-...@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git
ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20230905/202309051831.amujjocb-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202309051831.amujjocb-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_dp.c:3779:27: warning: overlapping
>> comparisons always evaluate to true [-Wtautological-overlap-compare]
if (vsc->revision != 0x5 || vsc->revision != 0x7)
~^~~
1 warning generated.
vim +3779 drivers/gpu/drm/i915/display/intel_dp.c
3754
3755 static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
3756 struct dp_sdp *sdp, size_t size)
3757 {
3758 size_t length = sizeof(struct dp_sdp);
3759
3760 if (size < length)
3761 return -ENOSPC;
3762
3763 memset(sdp, 0, size);
3764
3765 /*
3766 * Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
3767 * VSC SDP Header Bytes
3768 */
3769 sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
3770 sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet
Type */
3771 sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
3772 sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data
Bytes */
3773
3774 /*
3775 * Other than revision 0x5 which supports Pixel
Encoding/Colorimetry
3776 * Format as per DP 1.4a spec, revision 0x7 also supports Pixel
3777 * Encoding/Colorimetry Format as per DP 2.0 spec.
3778 */
> 3779 if (vsc->revision != 0x5 || vsc->revision != 0x7)
3780 goto out;
3781
3782 /* VSC SDP Payload for DB16 through DB18 */
3783 /* Pixel Encoding and Colorimetry Formats */
3784 sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
3785 sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
3786
3787 switch (vsc->bpc) {
3788 case 6:
3789 /* 6bpc: 0x0 */
3790 break;
3791 case 8:
3792 sdp->db[17] = 0x1; /* DB17[3:0] */
3793 break;
3794 case 10:
3795 sdp->db[17] = 0x2;
3796 break;
3797 case 12:
3798 sdp->db[17] = 0x3;
3799 break;
3800 case 16:
3801 sdp->db[17] = 0x4;
3802 break;
3803 default:
3804 MISSING_CASE(vsc->bpc);
3805 break;
3806 }
3807 /* Dynamic Range and Component Bit Depth */
3808 if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
3809 sdp->db[17] |= 0x80; /* DB17[7] */
3810
3811 /* Content Type */
3812 sdp->db[18] = vsc->content_type & 0x7;
3813
3814 out:
3815 return length;
3816 }
3817
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [Intel-gfx] [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Hi Am 04.09.23 um 21:57 schrieb Sui Jingfeng: From: Sui Jingfeng On a machine with multiple GPUs, a Linux user has no control over which one is primary at boot time. This series tries to solve above mentioned problem by introduced the ->be_primary() function stub. The specific device drivers can provide an implementation to hook up with this stub by calling the vga_client_register() function. Once the driver bound the device successfully, VGAARB will call back to the device driver. To query if the device drivers want to be primary or not. Device drivers can just pass NULL if have no such needs. Please note that: 1) The ARM64, Loongarch, Mips servers have a lot PCIe slot, and I would like to mount at least three video cards. 2) Typically, those non-86 machines don't have a good UEFI firmware support, which doesn't support select primary GPU as firmware stage. Even on x86, there are old UEFI firmwares which already made undesired decision for you. 3) This series is attempt to solve the remain problems at the driver level, while another series[1] of me is target to solve the majority of the problems at device level. Tested (limited) on x86 with four video card mounted, Intel UHD Graphics 630 is the default boot VGA, successfully override by ast2400 with ast.modeset=10 append at the kernel cmd line. FYI: per-driver modeset parameters are deprecated and not to be used. Please don't promote them. You can use modprobe.blacklist or initcall_blacklist on the kernel command line. Best regards Thomas $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos XTX [Radeon HD 8490 / R5 235X OEM] 04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 30) 05:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 720] (rev a1) $ sudo dmesg | grep vgaarb pci :00:02.0: vgaarb: setting as boot VGA device pci :00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none pci :04:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none pci :05:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none vgaarb: loaded ast :04:00.0: vgaarb: Override as primary by driver i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem radeon :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none ast :04:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none v2: * Add a simple implemment for drm/i915 and drm/ast * Pick up all tags (Mario) v3: * Fix a mistake for drm/i915 implement * Fix patch can not be applied problem because of merge conflect. v4: * Focus on solve the real problem. v1,v2 at https://patchwork.freedesktop.org/series/120059/ v3 at https://patchwork.freedesktop.org/series/120562/ [1] https://patchwork.freedesktop.org/series/122845/ Sui Jingfeng (9): PCI/VGA: Allowing the user to select the primary video adapter at boot time drm/nouveau: Implement .be_primary() callback drm/radeon: Implement .be_primary() callback drm/amdgpu: Implement .be_primary() callback drm/i915: Implement .be_primary() callback drm/loongson: Implement .be_primary() callback drm/ast: Register as a VGA client by calling vga_client_register() drm/hibmc: Register as a VGA client by calling vga_client_register() drm/gma500: Register as a VGA client by calling vga_client_register() drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 11 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 - drivers/gpu/drm/ast/ast_drv.c | 31 ++ drivers/gpu/drm/gma500/psb_drv.c | 57 ++- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 15 + drivers/gpu/drm/i915/display/intel_vga.c | 15 - drivers/gpu/drm/loongson/loongson_module.c| 2 +- drivers/gpu/drm/loongson/loongson_module.h| 1 + drivers/gpu/drm/loongson/lsdc_drv.c | 10 +++- drivers/gpu/drm/nouveau/nouveau_vga.c | 11 +++- drivers/gpu/drm/radeon/radeon_device.c| 10 +++- drivers/pci/vgaarb.c | 43 -- drivers/vfio/pci/vfio_pci_core.c | 2 +- include/linux/vgaarb.h| 8 ++- 14 files changed, 210 insertions(+), 19 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature Description: OpenPGP digital signature
Re: [Intel-gfx] [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Hi Am 04.09.23 um 21:57 schrieb Sui Jingfeng: From: Sui Jingfeng On a machine with multiple GPUs, a Linux user has no control over which one is primary at boot time. This series tries to solve above mentioned If anything, the primary graphics adapter is the one initialized by the firmware. I think our boot-up graphics also make this assumption implicitly. But what's the use case for overriding this setting? Best regards Thomas problem by introduced the ->be_primary() function stub. The specific device drivers can provide an implementation to hook up with this stub by calling the vga_client_register() function. Once the driver bound the device successfully, VGAARB will call back to the device driver. To query if the device drivers want to be primary or not. Device drivers can just pass NULL if have no such needs. Please note that: 1) The ARM64, Loongarch, Mips servers have a lot PCIe slot, and I would like to mount at least three video cards. 2) Typically, those non-86 machines don't have a good UEFI firmware support, which doesn't support select primary GPU as firmware stage. Even on x86, there are old UEFI firmwares which already made undesired decision for you. 3) This series is attempt to solve the remain problems at the driver level, while another series[1] of me is target to solve the majority of the problems at device level. Tested (limited) on x86 with four video card mounted, Intel UHD Graphics 630 is the default boot VGA, successfully override by ast2400 with ast.modeset=10 append at the kernel cmd line. $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos XTX [Radeon HD 8490 / R5 235X OEM] 04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 30) 05:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 720] (rev a1) $ sudo dmesg | grep vgaarb pci :00:02.0: vgaarb: setting as boot VGA device pci :00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none pci :04:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none pci :05:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none vgaarb: loaded ast :04:00.0: vgaarb: Override as primary by driver i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem radeon :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none ast :04:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none v2: * Add a simple implemment for drm/i915 and drm/ast * Pick up all tags (Mario) v3: * Fix a mistake for drm/i915 implement * Fix patch can not be applied problem because of merge conflect. v4: * Focus on solve the real problem. v1,v2 at https://patchwork.freedesktop.org/series/120059/ v3 at https://patchwork.freedesktop.org/series/120562/ [1] https://patchwork.freedesktop.org/series/122845/ Sui Jingfeng (9): PCI/VGA: Allowing the user to select the primary video adapter at boot time drm/nouveau: Implement .be_primary() callback drm/radeon: Implement .be_primary() callback drm/amdgpu: Implement .be_primary() callback drm/i915: Implement .be_primary() callback drm/loongson: Implement .be_primary() callback drm/ast: Register as a VGA client by calling vga_client_register() drm/hibmc: Register as a VGA client by calling vga_client_register() drm/gma500: Register as a VGA client by calling vga_client_register() drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 11 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 - drivers/gpu/drm/ast/ast_drv.c | 31 ++ drivers/gpu/drm/gma500/psb_drv.c | 57 ++- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 15 + drivers/gpu/drm/i915/display/intel_vga.c | 15 - drivers/gpu/drm/loongson/loongson_module.c| 2 +- drivers/gpu/drm/loongson/loongson_module.h| 1 + drivers/gpu/drm/loongson/lsdc_drv.c | 10 +++- drivers/gpu/drm/nouveau/nouveau_vga.c | 11 +++- drivers/gpu/drm/radeon/radeon_device.c| 10 +++- drivers/pci/vgaarb.c | 43 -- drivers/vfio/pci/vfio_pci_core.c | 2 +- include/linux/vgaarb.h| 8 ++- 14 files changed, 210 insertions(+), 19 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature Description: OpenPGP digital signature
Re: [Intel-gfx] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
On Tue, 05 Sep 2023, Sui Jingfeng wrote: > From: Sui Jingfeng > > On a machine with multiple GPUs, a Linux user has no control over which > one is primary at boot time. This series tries to solve above mentioned > problem by introduced the ->be_primary() function stub. The specific > device drivers can provide an implementation to hook up with this stub by > calling the vga_client_register() function. > > Once the driver bound the device successfully, VGAARB will call back to > the device driver. To query if the device drivers want to be primary or > not. Device drivers can just pass NULL if have no such needs. > > Please note that: > > 1) The ARM64, Loongarch, Mips servers have a lot PCIe slot, and I would >like to mount at least three video cards. > > 2) Typically, those non-86 machines don't have a good UEFI firmware >support, which doesn't support select primary GPU as firmware stage. >Even on x86, there are old UEFI firmwares which already made undesired >decision for you. > > 3) This series is attempt to solve the remain problems at the driver level, >while another series[1] of me is target to solve the majority of the >problems at device level. > > Tested (limited) on x86 with four video card mounted, Intel UHD Graphics > 630 is the default boot VGA, successfully override by ast2400 with > ast.modeset=10 append at the kernel cmd line. The value 10 is incredibly arbitrary, and multiplied as a magic number all over the place. > $ lspci | grep VGA > > 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD > Graphics 630] > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Caicos XTX [Radeon HD 8490 / R5 235X OEM] > 04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics > Family (rev 30) > 05:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT > 720] (rev a1) In this example, all of the GPUs are driven by different drivers. What good does a module parameter do if you have multiple GPUs of the same model, all driven by the same driver module? BR, Jani. > > $ sudo dmesg | grep vgaarb > > pci :00:02.0: vgaarb: setting as boot VGA device > pci :00:02.0: vgaarb: VGA device added: > decodes=io+mem,owns=io+mem,locks=none > pci :01:00.0: vgaarb: VGA device added: > decodes=io+mem,owns=none,locks=none > pci :04:00.0: vgaarb: VGA device added: > decodes=io+mem,owns=none,locks=none > pci :05:00.0: vgaarb: VGA device added: > decodes=io+mem,owns=none,locks=none > vgaarb: loaded > ast :04:00.0: vgaarb: Override as primary by driver > i915 :00:02.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=none:owns=io+mem > radeon :01:00.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=none:owns=none > ast :04:00.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=none:owns=none > > v2: > * Add a simple implemment for drm/i915 and drm/ast > * Pick up all tags (Mario) > v3: > * Fix a mistake for drm/i915 implement > * Fix patch can not be applied problem because of merge conflect. > v4: > * Focus on solve the real problem. > > v1,v2 at https://patchwork.freedesktop.org/series/120059/ >v3 at https://patchwork.freedesktop.org/series/120562/ > > [1] https://patchwork.freedesktop.org/series/122845/ > > Sui Jingfeng (9): > PCI/VGA: Allowing the user to select the primary video adapter at boot > time > drm/nouveau: Implement .be_primary() callback > drm/radeon: Implement .be_primary() callback > drm/amdgpu: Implement .be_primary() callback > drm/i915: Implement .be_primary() callback > drm/loongson: Implement .be_primary() callback > drm/ast: Register as a VGA client by calling vga_client_register() > drm/hibmc: Register as a VGA client by calling vga_client_register() > drm/gma500: Register as a VGA client by calling vga_client_register() > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 11 +++- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 - > drivers/gpu/drm/ast/ast_drv.c | 31 ++ > drivers/gpu/drm/gma500/psb_drv.c | 57 ++- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 15 + > drivers/gpu/drm/i915/display/intel_vga.c | 15 - > drivers/gpu/drm/loongson/loongson_module.c| 2 +- > drivers/gpu/drm/loongson/loongson_module.h| 1 + > drivers/gpu/drm/loongson/lsdc_drv.c | 10 +++- > drivers/gpu/drm/nouveau/nouveau_vga.c | 11 +++- > drivers/gpu/drm/radeon/radeon_device.c| 10 +++- > drivers/pci/vgaarb.c | 43 -- > drivers/vfio/pci/vfio_pci_core.c | 2 +- > include/linux/vgaarb.h| 8 ++- > 14 files changed, 210 insertions(+), 19 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: Configure and initialize HDMI audio capabilities
> Subject: [Intel-gfx] [PATCH 3/3] drm/i915/display: Configure and initialize
> HDMI
> audio capabilities
>
> Initialize the source audio capabilities in the crtc_state property, setting
> them to
Nit: maybe mention the above as intel_crtc_state rather than crtc_state
property as
property usually refer to as drm_property and it just seems a little weird to
read. I have seen this in some of your previous patches in this series you can
make the
changes there as well.
> their maximum supported values for max_channel and max_rate. This
> initialization enables the calculation of audio source capabilities
> concerning the
> available mode bandwidth. These capabilities encompass parameters such as
> supported rate and channel configurations.
>
> Additionally, introduces a wrapper function for computing Short Audio
> Descriptors (SADs). The wrapper function incorporates logic for determining
Typo * introduce
> supported rates and channels according to the capabilities of the audio
> source.
> It returns a set of SADs that are compatible with the audio source's
> capabilities.
>
> --v1:
> - Refactor max_channel and max_rate to this commit as it is being initialised
> here
> - Remove call for intel_audio_compute_eld to avoid any regression while
> merge. instead call it in different commit when it is defined.
> - Use int instead of unsigned int for max_channel and max_frequecy
> - Update commit message and header
>
> --v2:
> - Use signed instead of unsigned variables.
> - Avoid using magic numbers and give them proper name.
>
> --v3:
> - Move defines to intel_audio.c.
> - use consistent naming convention for rate and channel.
> - declare num_of_channel and aud_rate separately.
> - Declare index value outside of for loop.
> - Move Bandwidth calculation to intel_Audio.c as it is common for both DP and
> HDMI. Also use static.
>
> --v10:
> - Merged patch 2 and 3 to deduplicate function calls.
> - Instead using Calibrate and calculated functions separately, removed code
> duplication and merged functions.[Nikula, Jani]
> - Remove magic value for SAD Channel mask. [Nikula, Jani]
> - Corrected rate values based on HDMI Spec [Nikula, Jani]
> - Update drm function to extract SAD from ELD [Nikula, Jani]
>
> Signed-off-by: Mitul Golani
> ---
> drivers/gpu/drm/i915/display/intel_audio.c| 127 ++
> .../drm/i915/display/intel_display_types.h| 6 +
> 2 files changed, 133 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index e20ffc8e9654..2584096d80a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -64,6 +64,10 @@
> * struct _audio_component_audio_ops @audio_ops is called from i915
> driver.
> */
>
> +#define AUDIO_SAMPLE_CONTAINER_SIZE 32
> +#define MAX_CHANNEL_COUNT8
> +#define ELD_SAD_CHANNELS_MASK0x7
Use REG_GENMASK() to create masks should look cleaner
> +
> struct intel_audio_funcs {
> void (*audio_codec_enable)(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state, @@
> -770,6 +774,127 @@ void intel_audio_sdp_split_update(struct intel_encoder
> *encoder,
>crtc_state->sdp_split_enable ?
> AUD_ENABLE_SDP_SPLIT : 0); }
>
> +static int sad_to_channels(const u8 *sad) {
> + return 1 + (sad[0] & 0x7);
I think you missed using your defined mask here;
> +}
> +
> +static int calc_audio_bw(int channel_count, int rate) {
> + int bandwidth = channel_count * rate *
> AUDIO_SAMPLE_CONTAINER_SIZE;
> + return bandwidth;
Why introduce a variable here why not just
return channel_count * rate * AUDIO_SAMPLE_CONTAINER_SIZE;
> +}
> +
> +static void calc_and_calibrate_audio_config_params(struct intel_crtc_state
> *pipe_config,
> +int channel, bool
> calibration_required) {
I think this should have a int type function that returns 0 if max_rate and
max_channel_count
are non zero else return -EINVAL
> + struct drm_display_mode *adjusted_mode = _config-
> >hw.adjusted_mode;
> + int channel_count;
> + int index, rate[] = { 192000, 176400, 96000, 88200, 48000, 44100,
> 32000 };
Where do we get these rate values from.
What if we kept them at crtc_state so these can be update if required.
> + int audio_req_bandwidth, available_blank_bandwidth, vblank, hblank;
> +
> + hblank = adjusted_mode->htotal - adjusted_mode->hdisplay;
> + vblank = adjusted_mode->vtotal - adjusted_mode->vdisplay;
> + available_blank_bandwidth = hblank * vblank *
> + drm_mode_vrefresh(adjusted_mode) * pipe_config->pipe_bpp;
> +
> + /*
> + * Expected calibration of channels and respective rates,
> + * based on MAX_CHANNEL_COUNT. First calculate channel and
> + * rate based on Maximum that source can compute, letter
> + * with respect to
Re: [Intel-gfx] [PATCH] drm/i915/psr: Add psr sink error status into sink status debugfs
> -Original Message-
> From: Intel-gfx On Behalf Of Jouni
> Högander
> Sent: Monday, August 28, 2023 2:01 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/psr: Add psr sink error status into sink
> status debugfs
>
> Normally PSR errors detected by the panel are triggering HPD interrupt and
> seen as error in dmesg. Some panels are not triggering the interrupt even it
> is
> requested and they are detecting error. Due to this it would be good to have
> possibility to check panel detected errors. Add PSR error status into PSR sink
> status debugfs interface.
>
> Signed-off-by: Jouni Högander
LGTM.
Reviewed-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 34 +---
> 1 file changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 72887c29fb51..a008918b4d71 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -23,6 +23,7 @@
>
> #include
> #include
> +#include
>
> #include "i915_drv.h"
> #include "i915_reg.h"
> @@ -3153,7 +3154,7 @@ static int i915_psr_sink_status_show(struct seq_file
> *m, void *data)
> };
> const char *str;
> int ret;
> - u8 val;
> + u8 status, error_status;
>
> if (!CAN_PSR(intel_dp)) {
> seq_puts(m, "PSR Unsupported\n");
> @@ -3163,19 +3164,34 @@ static int i915_psr_sink_status_show(struct
> seq_file *m, void *data)
> if (connector->base.status != connector_status_connected)
> return -ENODEV;
>
> - ret = drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS, );
> - if (ret != 1)
> - return ret < 0 ? ret : -EIO;
> + ret = psr_get_status_and_error_status(intel_dp, ,
> _status);
> + if (ret)
> + return ret;
>
> - val &= DP_PSR_SINK_STATE_MASK;
> - if (val < ARRAY_SIZE(sink_status))
> - str = sink_status[val];
> + status &= DP_PSR_SINK_STATE_MASK;
> + if (status < ARRAY_SIZE(sink_status))
> + str = sink_status[status];
> else
> str = "unknown";
>
> - seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val, str);
> + seq_printf(m, "Sink PSR status: 0x%x [%s]\n", status, str);
>
> - return 0;
> + seq_printf(m, "Sink PSR error status: 0x%x", error_status);
> +
> + if (error_status & (DP_PSR_RFB_STORAGE_ERROR |
> + DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR |
> + DP_PSR_LINK_CRC_ERROR))
> + seq_puts(m, ":\n");
> + else
> + seq_puts(m, "\n");
> + if (error_status & DP_PSR_RFB_STORAGE_ERROR)
> + seq_puts(m, "\tPSR RFB storage error\n");
> + if (error_status & DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR)
> + seq_puts(m, "\tPSR VSC SDP uncorrectable error\n");
> + if (error_status & DP_PSR_LINK_CRC_ERROR)
> + seq_puts(m, "\tPSR Link CRC error\n");
> +
> + return ret;
> }
> DEFINE_SHOW_ATTRIBUTE(i915_psr_sink_status);
>
> --
> 2.34.1
[Intel-gfx] [PATCH v5 6/6] drm/i915/panelreplay: Debugfs support for panel replay
Add debugfs support which will print source and sink status
per connector basis.
Cc: Jouni Högander
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_psr.c | 70
1 file changed, 48 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 5cbf08a4c94c..f50f110feb09 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -3044,7 +3044,7 @@ psr_source_status(struct intel_dp *intel_dp, struct
seq_file *m)
status = live_status[status_val];
}
- seq_printf(m, "Source PSR status: %s [0x%08x]\n", status, val);
+ seq_printf(m, "Source PSR/PanelReplay status: %s [0x%08x]\n", status,
val);
}
static int intel_psr_status(struct seq_file *m, struct intel_dp *intel_dp)
@@ -3057,18 +3057,23 @@ static int intel_psr_status(struct seq_file *m, struct
intel_dp *intel_dp)
bool enabled;
u32 val;
- seq_printf(m, "Sink support: %s", str_yes_no(psr->sink_support));
- if (psr->sink_support)
+ seq_printf(m, "Sink support: PSR = %s, Panel Replay = %s",
+ str_yes_no(psr->sink_support),
+ str_yes_no(psr->sink_panel_replay_support));
+
+ if (psr->sink_support || psr->sink_panel_replay_support)
seq_printf(m, " [0x%02x]", intel_dp->psr_dpcd[0]);
seq_puts(m, "\n");
- if (!psr->sink_support)
+ if (!(psr->sink_support || psr->sink_panel_replay_support))
return 0;
wakeref = intel_runtime_pm_get(_priv->runtime_pm);
mutex_lock(>lock);
- if (psr->enabled)
+ if (psr->panel_replay_enabled)
+ status = "Panel Replay Enabled";
+ else if (psr->enabled)
status = psr->psr2_enabled ? "PSR2 enabled" : "PSR1 enabled";
else
status = "disabled";
@@ -3081,14 +3086,17 @@ static int intel_psr_status(struct seq_file *m, struct
intel_dp *intel_dp)
goto unlock;
}
- if (psr->psr2_enabled) {
+ if (psr->panel_replay_enabled) {
+ val = intel_de_read(dev_priv, TRANS_DP2_CTL(cpu_transcoder));
+ enabled = val & TRANS_DP2_PANEL_REPLAY_ENABLE;
+ } else if (psr->psr2_enabled) {
val = intel_de_read(dev_priv, EDP_PSR2_CTL(cpu_transcoder));
enabled = val & EDP_PSR2_ENABLE;
} else {
val = intel_de_read(dev_priv, psr_ctl_reg(dev_priv,
cpu_transcoder));
enabled = val & EDP_PSR_ENABLE;
}
- seq_printf(m, "Source PSR ctl: %s [0x%08x]\n",
+ seq_printf(m, "Source PSR/PanelReplay ctl: %s [0x%08x]\n",
str_enabled_disabled(enabled), val);
psr_source_status(intel_dp, m);
seq_printf(m, "Busy frontbuffer bits: 0x%08x\n",
@@ -3230,6 +3238,7 @@ static int i915_psr_sink_status_show(struct seq_file *m,
void *data)
{
struct intel_connector *connector = m->private;
struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct intel_psr *psr = _dp->psr;
static const char * const sink_status[] = {
"inactive",
"transition to active, capture and display",
@@ -3240,27 +3249,47 @@ static int i915_psr_sink_status_show(struct seq_file
*m, void *data)
"reserved",
"sink internal error",
};
+ static const char * const panel_replay_status[] = {
+ "Sink device frame is locked to the Source device",
+ "Sink device is coasting, using the VTotal target",
+ "Sink device is governing the frame rate (frame rate unlock is
granted)",
+ "Sink device in the process of re-locking with the Source
device",
+ };
const char *str;
int ret;
- u8 val;
+ u8 val, temp;
- if (!CAN_PSR(intel_dp)) {
- seq_puts(m, "PSR Unsupported\n");
+ if (!(CAN_PSR(intel_dp) || CAN_PANEL_REPLAY(intel_dp))) {
+ seq_puts(m, "PSR/Panel-Replay Unsupported\n");
return -ENODEV;
}
if (connector->base.status != connector_status_connected)
return -ENODEV;
- ret = drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS, );
- if (ret != 1)
- return ret < 0 ? ret : -EIO;
+ if (psr->panel_replay_enabled) {
+ ret = drm_dp_dpcd_readb(_dp->aux,
+
DP_SINK_DEVICE_PR_AND_FRAME_LOCK_STATUS, );
+ if (ret != 1)
+ return ret < 0 ? ret : -EIO;
- val &= DP_PSR_SINK_STATE_MASK;
- if (val < ARRAY_SIZE(sink_status))
- str = sink_status[val];
- else
- str = "unknown";
+ temp = val & DP_SINK_FRAME_LOCKED_MASK;
+ temp >>= DP_SINK_FRAME_LOCKED_SHIFT;
+
[Intel-gfx] [PATCH v5 5/6] drm/i915/panelreplay: enable/disable panel replay
TRANS_DP2_CTL register is programmed to enable panel replay from source
and sink is enabled through panel replay dpcd configuration address.
Bspec: 1407940617
v1: Initial version.
v2:
- Use pr_* flags instead psr_* flags. [Jouni]
- Remove intel_dp_is_edp check as edp1.5 also has panel replay. [Jouni]
v3: Cover letter updated and selective fetch condition check is added
before updating its bit in PSR2_MAN_TRK_CTL register. [Jouni]
v4: Selective fetch related PSR2_MAN_TRK_CTL programmming dropped. [Jouni]
Note: Initial plan is to enable panel replay in full-screen live active
frame update mode. In a incremental approach panel replay will be enabled
in selctive update mode if there is any gap in curent implementation.
Cc: Jouni Högander
Signed-off-by: Animesh Manna
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_psr.c | 65 ++-
2 files changed, 50 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 4022d6d8281a..b1383988b656 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1696,6 +1696,7 @@ struct intel_psr {
u16 su_y_granularity;
bool source_panel_replay_support;
bool sink_panel_replay_support;
+ bool panel_replay_enabled;
u32 dc3co_exitline;
u32 dc3co_exit_delay;
struct delayed_work dc3co_work;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 4e9c126a47ff..5cbf08a4c94c 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -606,8 +606,14 @@ static void intel_psr_enable_sink(struct intel_dp
*intel_dp)
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
u8 dpcd_val = DP_PSR_ENABLE;
- /* Enable ALPM at sink for psr2 */
+ if (intel_dp->psr.panel_replay_enabled) {
+ drm_dp_dpcd_writeb(_dp->aux, PANEL_REPLAY_CONFIG,
+ DP_PANEL_REPLAY_ENABLE);
+ return;
+ }
+
if (intel_dp->psr.psr2_enabled) {
+ /* Enable ALPM at sink for psr2 */
drm_dp_dpcd_writeb(_dp->aux, DP_RECEIVER_ALPM_CONFIG,
DP_ALPM_ENABLE |
DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE);
@@ -757,6 +763,14 @@ static int psr2_block_count(struct intel_dp *intel_dp)
return psr2_block_count_lines(intel_dp) / 4;
}
+static void dg2_activate_panel_replay(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+ intel_de_rmw(dev_priv, TRANS_DP2_CTL(intel_dp->psr.transcoder), 0,
+TRANS_DP2_PANEL_REPLAY_ENABLE);
+}
+
static void hsw_activate_psr2(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -1320,18 +1334,23 @@ void intel_psr_get_config(struct intel_encoder *encoder,
return;
intel_dp = _port->dp;
- if (!CAN_PSR(intel_dp))
+ if (!(CAN_PSR(intel_dp) || CAN_PANEL_REPLAY(intel_dp)))
return;
mutex_lock(_dp->psr.lock);
if (!intel_dp->psr.enabled)
goto unlock;
- /*
-* Not possible to read EDP_PSR/PSR2_CTL registers as it is
-* enabled/disabled because of frontbuffer tracking and others.
-*/
- pipe_config->has_psr = true;
+ if (intel_dp->psr.panel_replay_enabled) {
+ pipe_config->has_panel_replay = true;
+ } else {
+ /*
+* Not possible to read EDP_PSR/PSR2_CTL registers as it is
+* enabled/disabled because of frontbuffer tracking and others.
+*/
+ pipe_config->has_psr = true;
+ }
+
pipe_config->has_psr2 = intel_dp->psr.psr2_enabled;
pipe_config->infoframes.enable |=
intel_hdmi_infoframe_enable(DP_SDP_VSC);
@@ -1368,8 +1387,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
lockdep_assert_held(_dp->psr.lock);
- /* psr1 and psr2 are mutually exclusive.*/
- if (intel_dp->psr.psr2_enabled)
+ /* psr1, psr2 and panel-replay are mutually exclusive.*/
+ if (intel_dp->psr.panel_replay_enabled)
+ dg2_activate_panel_replay(intel_dp);
+ else if (intel_dp->psr.psr2_enabled)
hsw_activate_psr2(intel_dp);
else
hsw_activate_psr1(intel_dp);
@@ -1547,6 +1568,7 @@ static void intel_psr_enable_locked(struct intel_dp
*intel_dp,
drm_WARN_ON(_priv->drm, intel_dp->psr.enabled);
intel_dp->psr.psr2_enabled = crtc_state->has_psr2;
+ intel_dp->psr.panel_replay_enabled = crtc_state->has_panel_replay;
intel_dp->psr.busy_frontbuffer_bits = 0;
intel_dp->psr.pipe =
[Intel-gfx] [PATCH v5 4/6] drm/i915/panelreplay: Enable panel replay dpcd initialization for DP
Due to similarity panel replay dpcd initialization got added in psr function which is specific for edp panel. This patch enables panel replay initialization for dp connector. Signed-off-by: Animesh Manna --- drivers/gpu/drm/i915/display/intel_psr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index f2209fc94125..4e9c126a47ff 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -2747,6 +2747,9 @@ void intel_psr_init(struct intel_dp *intel_dp) if (!(HAS_PSR(dev_priv) || HAS_DP20(dev_priv))) return; + if (!intel_dp_is_edp(intel_dp)) + intel_psr_init_dpcd(intel_dp); + /* * HSW spec explicitly says PSR is tied to port A. * BDW+ platforms have a instance of PSR registers per transcoder but -- 2.29.0
[Intel-gfx] [PATCH v5 3/6] drm/i915/panelreplay: Initializaton and compute config for panel replay
Modify existing PSR implementation to enable panel replay feature of DP 2.0
which is similar to PSR feature of EDP panel. There is different DPCD
address to check panel capability compare to PSR and vsc sdp header
is different.
v1: Initial version.
v2:
- Set source_panel_replay_support flag under HAS_PANEL_REPLAY()
condition check. [Jouni]
- Code restructured around intel_panel_replay_init
and renamed to intel_panel_replay_init_dpcd. [Jouni]
- Remove the initial code modification around has_psr2 flag. [Jouni]
- Add CAN_PANEL_REPLAY() in intel_encoder_can_psr which is used to
enable in intel_psr_post_plane_update. [Jouni]
v3:
- Initialize both psr and panel-replay. [Jouni]
- Initialize both panel replay and psr if detected. [Jouni]
- Refactoring psr function by introducing _psr_compute_config(). [Jouni]
- Add check for !is_edp while deriving source_panel_replay_support. [Jouni]
- Enable panel replay dpcd initialization in a separate patch. [Jouni]
v4:
- HAS_PANEL_REPLAY() check not needed during sink capability check. [Jouni]
- Set either panel replay source support or psr. [Jouni]
v5:
- HAS_PANEL_REPLAY() removed and use HAS_DP20() instead. [Jouni]
- Move psr related code to intel_psr.c. [Jani]
- Reset sink_panel_replay_support flag during disconnection. [Jani]
Cc: Jouni Högander
Signed-off-by: Animesh Manna
---
.../drm/i915/display/intel_display_types.h| 14 +--
drivers/gpu/drm/i915/display/intel_dp.c | 45 +++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +
drivers/gpu/drm/i915/display/intel_psr.c | 96 +--
drivers/gpu/drm/i915/display/intel_psr.h | 7 ++
5 files changed, 118 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c21064794f32..4022d6d8281a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1202,6 +1202,7 @@ struct intel_crtc_state {
bool has_psr2;
bool enable_psr2_sel_fetch;
bool req_psr2_sdp_prior_scanline;
+ bool has_panel_replay;
bool wm_level_disabled;
u32 dc3co_exitline;
u16 su_y_granularity;
@@ -1693,6 +1694,8 @@ struct intel_psr {
bool irq_aux_error;
u16 su_w_granularity;
u16 su_y_granularity;
+ bool source_panel_replay_support;
+ bool sink_panel_replay_support;
u32 dc3co_exitline;
u32 dc3co_exit_delay;
struct delayed_work dc3co_work;
@@ -1980,17 +1983,6 @@ dp_to_lspcon(struct intel_dp *intel_dp)
#define dp_to_i915(__intel_dp)
to_i915(dp_to_dig_port(__intel_dp)->base.base.dev)
-#define CAN_PSR(intel_dp) ((intel_dp)->psr.sink_support && \
- (intel_dp)->psr.source_support)
-
-static inline bool intel_encoder_can_psr(struct intel_encoder *encoder)
-{
- if (!intel_encoder_is_dp(encoder))
- return false;
-
- return CAN_PSR(enc_to_intel_dp(encoder));
-}
-
static inline struct intel_digital_port *
hdmi_to_dig_port(struct intel_hdmi *intel_hdmi)
{
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3faa68989d85..d8c151196a81 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2338,12 +2338,22 @@ static void intel_dp_compute_vsc_colorimetry(const
struct intel_crtc_state *crtc
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- /*
-* Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
-* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
-* Colorimetry Format indication.
-*/
- vsc->revision = 0x5;
+ if (crtc_state->has_panel_replay) {
+ /*
+* Prepare VSC Header for SU as per DP 2.0 spec, Table 2-223
+* VSC SDP supporting 3D stereo, Panel Replay, and Pixel
+* Encoding/Colorimetry Format indication.
+*/
+ vsc->revision = 0x7;
+ } else {
+ /*
+* Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
+* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
+* Colorimetry Format indication.
+*/
+ vsc->revision = 0x5;
+ }
+
vsc->length = 0x13;
/* DP 1.4a spec, Table 2-120 */
@@ -2452,6 +2462,21 @@ void intel_dp_compute_psr_vsc_sdp(struct intel_dp
*intel_dp,
vsc->revision = 0x4;
vsc->length = 0xe;
}
+ } else if (crtc_state->has_panel_replay) {
+ if (intel_dp->psr.colorimetry_support &&
+ intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
+ /* [Panel Replay with colorimetry info] */
+
[Intel-gfx] [PATCH v5 2/6] drm/i915/psr: Move psr specific dpcd init into own function
From: Jouni Högander
This patch is preparing adding panel replay specific dpcd init.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 39 +---
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index b9e38acc5132..24eed99e8811 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -473,27 +473,22 @@ static void intel_dp_get_su_granularity(struct intel_dp
*intel_dp)
intel_dp->psr.su_y_granularity = y;
}
-void intel_psr_init_dpcd(struct intel_dp *intel_dp)
+static void _psr_init_dpcd(struct intel_dp *intel_dp)
{
- struct drm_i915_private *dev_priv =
+ struct drm_i915_private *i915 =
to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
- drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
-sizeof(intel_dp->psr_dpcd));
-
- if (!intel_dp->psr_dpcd[0])
- return;
- drm_dbg_kms(_priv->drm, "eDP panel supports PSR version %x\n",
+ drm_dbg_kms(>drm, "eDP panel supports PSR version %x\n",
intel_dp->psr_dpcd[0]);
if (drm_dp_has_quirk(_dp->desc, DP_DPCD_QUIRK_NO_PSR)) {
- drm_dbg_kms(_priv->drm,
+ drm_dbg_kms(>drm,
"PSR support not currently available for this
panel\n");
return;
}
if (!(intel_dp->edp_dpcd[1] & DP_EDP_SET_POWER_CAP)) {
- drm_dbg_kms(_priv->drm,
+ drm_dbg_kms(>drm,
"Panel lacks power state control, PSR cannot be
enabled\n");
return;
}
@@ -502,7 +497,7 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
intel_dp->psr.sink_sync_latency =
intel_dp_get_sink_sync_latency(intel_dp);
- if (DISPLAY_VER(dev_priv) >= 9 &&
+ if (DISPLAY_VER(i915) >= 9 &&
(intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
bool y_req = intel_dp->psr_dpcd[1] &
DP_PSR2_SU_Y_COORDINATE_REQUIRED;
@@ -520,14 +515,24 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
* GTC first.
*/
intel_dp->psr.sink_psr2_support = y_req && alpm;
- drm_dbg_kms(_priv->drm, "PSR2 %ssupported\n",
+ drm_dbg_kms(>drm, "PSR2 %ssupported\n",
intel_dp->psr.sink_psr2_support ? "" : "not ");
+ }
+}
- if (intel_dp->psr.sink_psr2_support) {
- intel_dp->psr.colorimetry_support =
- intel_dp_get_colorimetry_status(intel_dp);
- intel_dp_get_su_granularity(intel_dp);
- }
+void intel_psr_init_dpcd(struct intel_dp *intel_dp)
+{
+ drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
+sizeof(intel_dp->psr_dpcd));
+
+ if (intel_dp->psr_dpcd[0])
+ _psr_init_dpcd(intel_dp);
+ /* TODO: Add PR case here */
+
+ if (intel_dp->psr.sink_psr2_support) {
+ intel_dp->psr.colorimetry_support =
+ intel_dp_get_colorimetry_status(intel_dp);
+ intel_dp_get_su_granularity(intel_dp);
}
}
--
2.29.0
[Intel-gfx] [PATCH v5 1/6] drm/panelreplay: dpcd register definition for panelreplay
Add DPCD register definition for discovering, enabling and checking status of panel replay of the sink. Cc: Jouni Högander Signed-off-by: Animesh Manna --- include/drm/display/drm_dp.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h index e69cece404b3..23c2a68c32a4 100644 --- a/include/drm/display/drm_dp.h +++ b/include/drm/display/drm_dp.h @@ -543,6 +543,10 @@ /* DFP Capability Extension */ #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0a3 /* 2.0 */ +#define DP_PANEL_REPLAY_CAP 0x0b0 /* DP 2.0 */ +# define DP_PANEL_REPLAY_SUPPORT(1 << 0) +# define DP_PANEL_REPLAY_SU_SUPPORT (1 << 1) + /* Link Configuration */ #defineDP_LINK_BW_SET 0x100 # define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */ @@ -716,6 +720,13 @@ #define DP_BRANCH_DEVICE_CTRL 0x1a1 # define DP_BRANCH_DEVICE_IRQ_HPD (1 << 0) +#define PANEL_REPLAY_CONFIG 0x1b0 /* DP 2.0 */ +# define DP_PANEL_REPLAY_ENABLE (1 << 0) +# define DP_PANEL_REPLAY_UNRECOVERABLE_ERROR(1 << 3) +# define DP_PANEL_REPLAY_RFB_STORAGE_ERROR (1 << 4) +# define DP_PANEL_REPLAY_ACTIVE_FRAME_CRC_ERROR (1 << 5) +# define DP_PANEL_REPLAY_SU_ENABLE (1 << 6) + #define DP_PAYLOAD_ALLOCATE_SET0x1c0 #define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1 #define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2 @@ -1105,6 +1116,13 @@ #define DP_LANE_ALIGN_STATUS_UPDATED_ESI 0x200e /* status same as 0x204 */ #define DP_SINK_STATUS_ESI 0x200f /* status same as 0x205 */ +#define DP_SINK_DEVICE_PR_AND_FRAME_LOCK_STATUS0x2022 /* DP 2.1 */ +# define DP_SINK_DEVICE_PANEL_REPLAY_STATUS_MASK (7 << 0) +# define DP_SINK_FRAME_LOCKED_SHIFT3 +# define DP_SINK_FRAME_LOCKED_MASK (3 << 3) +# define DP_SINK_FRAME_LOCKED_STATUS_VALID_SHIFT 5 +# define DP_SINK_FRAME_LOCKED_STATUS_VALID_MASK(1 << 5) + /* Extended Receiver Capability: See DP_DPCD_REV for definitions */ #define DP_DP13_DPCD_REV0x2200 -- 2.29.0
[Intel-gfx] [PATCH v5 0/6] Panel replay phase1 implementation
Panel Replay is a power saving feature for DP 2.0 monitor and similar to PSR on EDP. These patches are basic enablement patches added on top of existing psr framework to enable full-screen live active frame update mode of panel replay. Panel replay also can be enabled in selective update mode which will be enabled in a incremental approach. As per current design panel replay priority is higher than psr. intel_dp->psr.panel_replay_enabled flag indicate panel replay is enabled. intel_dp->psr.panel_replay_enabled + intel_dp->psr.psr2_enabled indicates panel replay is enabled in selective update mode. intel_dp->psr.panel_replay_enabled + intel_dp->psr.psr2_enabled + intel_psr.selective_fetch enabled indicates panel replay is enabled in selective update mode with selective fetch. PSR replated flags remain same like before. Note: The patches are under testing by using panel replay emulator and panel is not avalible. Cc: Jouni Högander Signed-off-by: Animesh Manna Animesh Manna (5): drm/panelreplay: dpcd register definition for panelreplay drm/i915/panelreplay: Initializaton and compute config for panel replay drm/i915/panelreplay: Enable panel replay dpcd initialization for DP drm/i915/panelreplay: enable/disable panel replay drm/i915/panelreplay: Debugfs support for panel replay Jouni Högander (1): drm/i915/psr: Move psr specific dpcd init into own function .../drm/i915/display/intel_display_types.h| 15 +- drivers/gpu/drm/i915/display/intel_dp.c | 45 ++- drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 + drivers/gpu/drm/i915/display/intel_psr.c | 269 -- drivers/gpu/drm/i915/display/intel_psr.h | 7 + include/drm/display/drm_dp.h | 18 ++ 6 files changed, 257 insertions(+), 100 deletions(-) -- 2.29.0
Re: [Intel-gfx] [PATCH 2/3] drm: Add Wrapper Functions for ELD SAD Extraction
> Subject: [Intel-gfx] [PATCH 2/3] drm: Add Wrapper Functions for ELD SAD
> Extraction
>
> Add wrapper functions to facilitate extracting Short Audio Descriptor (SAD)
> information from EDID-Like Data (ELD) pointers with different constness
> requirements.
>
> 1. `drm_eld_sad`: This function returns a constant `uint8_t` pointer and wraps
> the main extraction function, allowing access to SAD information while
> maintaining const correctness.
>
> 2. `drm_extract_sad_from_eld`: This function returns a mutable `uint8_t`
> pointer and implements the core logic for extracting SAD from the provided ELD
> pointer. It performs version and maximum channel checks to ensure proper
> extraction.
>
> These wrapper functions provide flexibility to the codebase, allowing users to
> access SAD information while adhering to const correctness when needed and
> modifying the pointer when required.
>
> Signed-off-by: Mitul Golani
This should also be floated in drm-devel mailing list.
> ---
> include/drm/drm_edid.h | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index
> 48e93f909ef6..626bc0d542eb 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -418,11 +418,7 @@ static inline int drm_eld_mnl(const uint8_t *eld)
> return (eld[DRM_ELD_CEA_EDID_VER_MNL] &
> DRM_ELD_MNL_MASK) >> DRM_ELD_MNL_SHIFT; }
>
> -/**
> - * drm_eld_sad - Get ELD SAD structures.
> - * @eld: pointer to an eld memory structure with sad_count set
> - */
> -static inline const uint8_t *drm_eld_sad(const uint8_t *eld)
> +static uint8_t *drm_extract_sad_from_eld(uint8_t *eld)
> {
> unsigned int ver, mnl;
>
> @@ -437,6 +433,15 @@ static inline const uint8_t *drm_eld_sad(const uint8_t
> *eld)
> return eld + DRM_ELD_CEA_SAD(mnl, 0);
> }
>
> +/**
> + * drm_eld_sad - Get ELD SAD structures.
> + * @eld: pointer to an eld memory structure with sad_count set */
> +static inline const uint8_t *drm_eld_sad(const uint8_t *eld) {
> + return drm_extract_sad_from_eld((uint8_t *)eld); }
> +
Not sure about the wrapper here the point of the const variable here was we do
not want the eld to be changed
but adding a wrapper seems to make it irrelevant
Also why do you want to change pointer data that is a const.
Regards,
Suraj Kandpal
> /**
> * drm_eld_sad_count - Get ELD SAD count.
> * @eld: pointer to an eld memory structure with sad_count set
> --
> 2.25.1
