[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dgfx: DGFX uses direct VBT pin mapping (rev2)
== Series Details == Series: drm/i915/dgfx: DGFX uses direct VBT pin mapping (rev2) URL : https://patchwork.freedesktop.org/series/113677/ State : success == Summary == CI Bug Log - changes from CI_DRM_13943 -> Patchwork_113677v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113677v2/index.html Participating hosts (39 -> 36) -- Missing(3): bat-rpls-1 bat-dg2-9 fi-snb-2520m Changes --- No changes found Build changes - * Linux: CI_DRM_13943 -> Patchwork_113677v2 CI-20190529: 20190529 CI_DRM_13943: 0417ec152200d74916f157bfe76677b3b4af8224 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7609: 72a759595100b8d167ca78cd2d62e9acd97e36bf @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_113677v2: 0417ec152200d74916f157bfe76677b3b4af8224 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 32a6e977855e drm/i915/dgfx: DGFX uses direct VBT pin mapping == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113677v2/index.html
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Atomically invalidate userptr on mmu-notifier
== Series Details == Series: drm/i915/gem: Atomically invalidate userptr on mmu-notifier URL : https://patchwork.freedesktop.org/series/126998/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13943 -> Patchwork_126998v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_126998v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_126998v1, please notify your bug team (i915-ci-in...@lists.freedesktop.org) 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_126998v1/index.html Participating hosts (39 -> 35) -- Missing(4): fi-pnv-d510 bat-dg2-9 fi-snb-2520m bat-dg1-5 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_126998v1: ### IGT changes ### Possible regressions * igt@i915_selftest@live@requests: - bat-atsm-1: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13943/bat-atsm-1/igt@i915_selftest@l...@requests.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v1/bat-atsm-1/igt@i915_selftest@l...@requests.html Known issues Here are the changes found in Patchwork_126998v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_suspend@basic-s3-without-i915: - bat-rpls-1: [PASS][3] -> [ABORT][4] ([i915#7978] / [i915#9631]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13943/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v1/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_hdmi_inject@inject-audio: - fi-kbl-guc: [PASS][5] -> [FAIL][6] ([IGT#3]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13943/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v1/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-adlp-9: NOTRUN -> [SKIP][7] ([i915#1845] / [i915#3546]) +2 other tests skip [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v1/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3 [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#9631]: https://gitlab.freedesktop.org/drm/intel/issues/9631 Build changes - * Linux: CI_DRM_13943 -> Patchwork_126998v1 CI-20190529: 20190529 CI_DRM_13943: 0417ec152200d74916f157bfe76677b3b4af8224 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7609: 72a759595100b8d167ca78cd2d62e9acd97e36bf @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_126998v1: 0417ec152200d74916f157bfe76677b3b4af8224 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 51fffa148995 drm/i915/gem: Atomically invalidate userptr on mmu-notifier == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126998v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: Atomically invalidate userptr on mmu-notifier
== Series Details == Series: drm/i915/gem: Atomically invalidate userptr on mmu-notifier URL : https://patchwork.freedesktop.org/series/126998/ 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/gem: Atomically invalidate userptr on mmu-notifier
== Series Details == Series: drm/i915/gem: Atomically invalidate userptr on mmu-notifier URL : https://patchwork.freedesktop.org/series/126998/ State : warning == Summary == Error: dim checkpatch failed f524462a283b drm/i915/gem: Atomically invalidate userptr on mmu-notifier -:117: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #117: deleted file mode 100644 total: 0 errors, 1 warnings, 0 checks, 97 lines checked
Re: [Intel-gfx] [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices
On Tue, 28 Nov 2023 at 23:07, Christian König wrote: > > Am 28.11.23 um 13:50 schrieb Weixi Zhu: > > The problem: > > > > Accelerator driver developers are forced to reinvent external MM subsystems > > case by case, because Linux core MM only considers host memory resources. > > These reinvented MM subsystems have similar orders of magnitude of LoC as > > Linux MM (80K), e.g. Nvidia-UVM has 70K, AMD GPU has 14K and Huawei NPU has > > 30K. Meanwhile, more and more vendors are implementing their own > > accelerators, e.g. Microsoft's Maia 100. At the same time, > > application-level developers suffer from poor programmability -- they must > > consider parallel address spaces and be careful about the limited device > > DRAM capacity. This can be alleviated if a malloc()-ed virtual address can > > be shared by the accelerator, or the abundant host DRAM can further > > transparently backup the device local memory. > > > > These external MM systems share similar mechanisms except for the > > hardware-dependent part, so reinventing them is effectively introducing > > redundant code (14K~70K for each case). Such developing/maintaining is not > > cheap. Furthermore, to share a malloc()-ed virtual address, device drivers > > need to deeply interact with Linux MM via low-level MM APIs, e.g. MMU > > notifiers/HMM. This raises the bar for driver development, since developers > > must understand how Linux MM works. Further, it creates code maintenance > > problems -- any changes to Linux MM potentially require coordinated changes > > to accelerator drivers using low-level MM APIs. > > > > Putting a cache-coherent bus between host and device will not make these > > external MM subsystems disappear. For example, a throughput-oriented > > accelerator will not tolerate executing heavy memory access workload with > > a host MMU/IOMMU via a remote bus. Therefore, devices will still have > > their own MMU and pick a simpler page table format for lower address > > translation overhead, requiring external MM subsystems. > > > > > > > > What GMEM (Generalized Memory Management [1]) does: > > > > GMEM extends Linux MM to share its machine-independent MM code. Only > > high-level interface is provided for device drivers. This prevents > > accelerator drivers from reinventing the wheel, but relies on drivers to > > implement their hardware-dependent functions declared by GMEM. GMEM's key > > interface include gm_dev_create(), gm_as_create(), gm_as_attach() and > > gm_dev_register_physmem(). Here briefly describe how a device driver > > utilizes them: > > 1. At boot time, call gm_dev_create() and registers the implementation of > > hardware-dependent functions as declared in struct gm_mmu. > > - If the device has local DRAM, call gm_dev_register_physmem() to > > register available physical addresses. > > 2. When a device context is initialized (e.g. triggered by ioctl), check if > > the current CPU process has been attached to a gmem address space > > (struct gm_as). If not, call gm_as_create() and point current->mm->gm_as > > to it. > > 3. Call gm_as_attach() to attach the device context to a gmem address space. > > 4. Invoke gm_dev_fault() to resolve a page fault or prepare data before > > device computation happens. > > > > GMEM has changed the following assumptions in Linux MM: > >1. An mm_struct not only handle a single CPU context, but may also handle > > external memory contexts encapsulated as gm_context listed in > > mm->gm_as. An external memory context can include a few or all of the > > following parts: an external MMU (that requires TLB invalidation), an > > external page table (that requires PTE manipulation) and external DRAM > > (that requires physical memory management). > > Well that is pretty much exactly what AMD has already proposed with KFD > and was rejected for rather good reasons. > > > > MMU functions > > The MMU functions peer_map() and peer_unmap() overlap other functions, > > leaving a question if the MMU functions should be decoupled as more basic > > operations. Decoupling them could potentially prevent device drivers > > coalescing these basic steps within a single host-device communication > > operation, while coupling them makes it more difficult for device drivers > > to utilize GMEM interface. > > Well to be honest all of this sounds like history to me. We have already > seen the same basic approach in KFD, HMM and to some extend in TTM as well. > > And all of them more or less failed. Why should this here be different? Any info we have on why this has failed to work in the past would be useful to provide. This is one of those cases where we may not have documented the bad ideas to stop future developers from thinking they are bad. I do think we would want more common code in this area, but I would think we'd have it more on the driver infrastructure side, than in the core mm. Dave.
[Intel-gfx] ✓ Fi.CI.BAT: success for Prepare intel_fb for Xe (rev8)
== Series Details == Series: Prepare intel_fb for Xe (rev8) URL : https://patchwork.freedesktop.org/series/126507/ State : success == Summary == CI Bug Log - changes from CI_DRM_13943 -> Patchwork_126507v8 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126507v8/index.html Participating hosts (39 -> 37) -- Missing(2): bat-mtlp-8 fi-snb-2520m Known issues Here are the changes found in Patchwork_126507v8 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0@smem: - bat-jsl-1: [PASS][1] -> [INCOMPLETE][2] ([i915#9275]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13943/bat-jsl-1/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126507v8/bat-jsl-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_suspend@basic-s3-without-i915: - bat-jsl-1: [PASS][3] -> [FAIL][4] ([fdo#103375]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13943/bat-jsl-1/igt@i915_susp...@basic-s3-without-i915.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126507v8/bat-jsl-1/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_hdmi_inject@inject-audio: - fi-kbl-guc: [PASS][5] -> [FAIL][6] ([IGT#3]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13943/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126507v8/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3 [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [i915#9275]: https://gitlab.freedesktop.org/drm/intel/issues/9275 Build changes - * Linux: CI_DRM_13943 -> Patchwork_126507v8 CI-20190529: 20190529 CI_DRM_13943: 0417ec152200d74916f157bfe76677b3b4af8224 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7609: 72a759595100b8d167ca78cd2d62e9acd97e36bf @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_126507v8: 0417ec152200d74916f157bfe76677b3b4af8224 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 2759e5eb7646 drm/i915/display: Split i915 specific code away from intel_fb.c ca5f820b2251 drm/i915/display: Handle invalid fb_modifier in intel_fb_modifier_to_tiling 8f3475b71cd3 drm/i915/display: Convert intel_fb_modifier_to_tiling as non-static 3738fe277b2f drm/i915/display: use intel_bo_to_drm_bo in intel_fb.c == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126507v8/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Skip state verification with TBT-ALT mode
== Series Details ==
Series: drm/i915/display: Skip state verification with TBT-ALT mode
URL : https://patchwork.freedesktop.org/series/126933/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13928 -> Patchwork_126933v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/index.html
Participating hosts (36 -> 35)
--
Additional (1): bat-kbl-2
Missing(2): fi-snb-2520m fi-pnv-d510
Known issues
Here are the changes found in Patchwork_126933v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@info:
- bat-kbl-2: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1849])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-kbl-2/igt@fb...@info.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2: NOTRUN -> [SKIP][2] ([fdo#109271]) +20 other tests
skip
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence:
- bat-kbl-2: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1845]) +14
other tests skip
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-kbl-2/igt@kms_pipe_crc_ba...@read-crc-frame-sequence.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-c-dp-5:
- bat-adlp-11:[PASS][4] -> [FAIL][5] ([i915#9747]) +2 other tests
fail
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-c-dp-5.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-c-dp-5.html
Possible fixes
* igt@kms_flip@basic-flip-vs-modeset@d-dp5:
- bat-adlp-11:[DMESG-FAIL][6] ([i915#6868]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html
* igt@kms_frontbuffer_tracking@basic:
- bat-adlp-11:[SKIP][8] ([i915#4342] / [i915#5354]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_frontbuffer_track...@basic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@kms_flip@basic-flip-vs-modeset@a-dp6:
- bat-adlp-11:[FAIL][10] ([i915#6121]) -> [DMESG-FAIL][11]
([i915#6868])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@a-dp6.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@a-dp6.html
* igt@kms_hdmi_inject@inject-audio:
- bat-adlp-11:[FAIL][12] ([i915#9746]) -> [SKIP][13] ([i915#4369])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_hdmi_inj...@inject-audio.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_hdmi_inj...@inject-audio.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-a-dp-5:
- bat-adlp-11:[ABORT][14] ([i915#8668]) -> [ABORT][15] ([i915#6868]
/ [i915#8668])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-a-dp-5.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-a-dp-5.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#4342]: https://gitlab.freedesktop.org/drm/intel/issues/4342
[i915#4369]: https://gitlab.freedesktop.org/drm/intel/issues/4369
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#6121]: https://gitlab.freedesktop.org/drm/intel/issues/6121
[i915#6868]: https://gitlab.freedesktop.org/drm/intel/issues/6868
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
[i915#9746]: https://gitlab.freedesktop.org/drm/intel/issues/9746
[i915#9747]: https://gitlab.freedesktop.org/drm/intel/issues/9747
Build changes
-
* Linux: CI_DRM_13928 -> Patchwork_126933v1
CI-20190529: 20190529
CI_DRM_13928: 347e889a869b969afb7118cd8d7068d7a1c66571 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7604: d2af13d9f5be5ce23d996e4afd3
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Prepare intel_fb for Xe (rev8)
== Series Details == Series: Prepare intel_fb for Xe (rev8) URL : https://patchwork.freedesktop.org/series/126507/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit' +./arch/x86/inc
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Prepare intel_fb for Xe (rev8)
== Series Details == Series: Prepare intel_fb for Xe (rev8) URL : https://patchwork.freedesktop.org/series/126507/ State : warning == Summary == Error: dim checkpatch failed 3c9de2e1382f drm/i915/display: use intel_bo_to_drm_bo in intel_fb.c caa9b612d5f7 drm/i915/display: Convert intel_fb_modifier_to_tiling as non-static 345c45f2b813 drm/i915/display: Handle invalid fb_modifier in intel_fb_modifier_to_tiling 28f1fdc98e43 drm/i915/display: Split i915 specific code away from intel_fb.c Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:168: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #168: new file mode 100644 -:173: WARNING:SPDX_LICENSE_TAG: Improper SPDX comment style for 'drivers/gpu/drm/i915/display/intel_fb_bo.c', please use '//' instead #173: FILE: drivers/gpu/drm/i915/display/intel_fb_bo.c:1: +/* SPDX-License-Identifier: MIT */ -:173: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #173: FILE: drivers/gpu/drm/i915/display/intel_fb_bo.c:1: +/* SPDX-License-Identifier: MIT */ total: 0 errors, 3 warnings, 0 checks, 238 lines checked
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Supporting GMEM (generalized memory management) for external memory devices
== Series Details == Series: Supporting GMEM (generalized memory management) for external memory devices URL : https://patchwork.freedesktop.org/series/126986/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CC mm/gmem.o In file included from ./include/linux/kernel.h:23, from ./arch/x86/include/asm/percpu.h:27, from ./arch/x86/include/asm/preempt.h:6, from ./include/linux/preempt.h:79, from ./include/linux/spinlock.h:56, from ./include/linux/mmzone.h:8, from ./include/linux/gfp.h:7, from ./include/linux/mm.h:7, from mm/gmem.c:9: mm/gmem.c: In function ‘is_hnode_allowed’: mm/gmem.c:43:51: error: ‘struct task_struct’ has no member named ‘mems_allowed’ 43 | return is_hnode(node) && node_isset(node, current->mems_allowed); | ^~ ./include/linux/bitops.h:50:37: note: in definition of macro ‘bitop’ 50 |__builtin_constant_p((uintptr_t)(addr) != (uintptr_t)NULL) && \ | ^~~~ ./include/linux/nodemask.h:153:36: note: in expansion of macro ‘test_bit’ 153 | #define node_isset(node, nodemask) test_bit((node), (nodemask).bits) |^~~~ mm/gmem.c:43:27: note: in expansion of macro ‘node_isset’ 43 | return is_hnode(node) && node_isset(node, current->mems_allowed); | ^~ mm/gmem.c:43:51: error: ‘struct task_struct’ has no member named ‘mems_allowed’ 43 | return is_hnode(node) && node_isset(node, current->mems_allowed); | ^~ ./include/linux/bitops.h:51:16: note: in definition of macro ‘bitop’ 51 |(uintptr_t)(addr) != (uintptr_t)NULL && \ |^~~~ ./include/linux/nodemask.h:153:36: note: in expansion of macro ‘test_bit’ 153 | #define node_isset(node, nodemask) test_bit((node), (nodemask).bits) |^~~~ mm/gmem.c:43:27: note: in expansion of macro ‘node_isset’ 43 | return is_hnode(node) && node_isset(node, current->mems_allowed); | ^~ mm/gmem.c:43:51: error: ‘struct task_struct’ has no member named ‘mems_allowed’ 43 | return is_hnode(node) && node_isset(node, current->mems_allowed); | ^~ ./include/linux/bitops.h:52:50: note: in definition of macro ‘bitop’ 52 |__builtin_constant_p(*(const unsigned long *)(addr))) ? \ | ^~~~ ./include/linux/nodemask.h:153:36: note: in expansion of macro ‘test_bit’ 153 | #define node_isset(node, nodemask) test_bit((node), (nodemask).bits) |^~~~ mm/gmem.c:43:27: note: in expansion of macro ‘node_isset’ 43 | return is_hnode(node) && node_isset(node, current->mems_allowed); | ^~ mm/gmem.c:43:51: error: ‘struct task_struct’ has no member named ‘mems_allowed’ 43 | return is_hnode(node) && node_isset(node, current->mems_allowed); | ^~ ./include/linux/bitops.h:53:17: note: in definition of macro ‘bitop’ 53 | const##op(nr, addr) : op(nr, addr)) | ^~~~ ./include/linux/nodemask.h:153:36: note: in expansion of macro ‘test_bit’ 153 | #define node_isset(node, nodemask) test_bit((node), (nodemask).bits) |^~~~ mm/gmem.c:43:27: note: in expansion of macro ‘node_isset’ 43 | return is_hnode(node) && node_isset(node, current->mems_allowed); | ^~ mm/gmem.c:43:51: error: ‘struct task_struct’ has no member named ‘mems_allowed’ 43 | return is_hnode(node) && node_isset(node, current->mems_allowed); | ^~ ./include/linux/bitops.h:53:32: note: in definition of macro ‘bitop’ 53 | const##op(nr, addr) : op(nr, addr)) |^~~~ ./include/linux/nodemask.h:153:36: note: in expansion of macro ‘test_bit’ 153 | #define node_isset(node, nodemask) test_bit((node), (nodemask).bits) |^~~~ mm/gmem.c:43:27: note: in expansion of macro ‘node_isset’ 43 | return is_hnode(node) && node_isset(node, current->mems_allowed); | ^~ mm/gmem.c: At top level: mm/gmem.c:401:6: warning: no previous prototype for ‘gm_dev_unregister_physmem’ [-Wmissing-prototypes] 401 | void gm_dev_unregister_physmem(struct gm_dev *dev, unsigned int nid) | ^ In file included from ./include/linux/mmzone.h:18, from ./include/linux/gfp.h:7,
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Skip state verification with TBT-ALT mode
== Series Details ==
Series: drm/i915/display: Skip state verification with TBT-ALT mode
URL : https://patchwork.freedesktop.org/series/126933/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13928 -> Patchwork_126933v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_126933v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_126933v1, please notify your bug team
(i915-ci-in...@lists.freedesktop.org) 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_126933v1/index.html
Participating hosts (36 -> 35)
--
Additional (1): bat-kbl-2
Missing(2): fi-snb-2520m fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_126933v1:
### IGT changes ###
Possible regressions
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-b-dp-6:
- bat-adlp-11:[PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-b-dp-6.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-b-dp-6.html
Known issues
Here are the changes found in Patchwork_126933v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@info:
- bat-kbl-2: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1849])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-kbl-2/igt@fb...@info.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2: NOTRUN -> [SKIP][4] ([fdo#109271]) +20 other tests
skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence:
- bat-kbl-2: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1845]) +14
other tests skip
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-kbl-2/igt@kms_pipe_crc_ba...@read-crc-frame-sequence.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-c-dp-5:
- bat-adlp-11:[PASS][6] -> [FAIL][7] ([i915#9747]) +1 other test
fail
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-c-dp-5.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-c-dp-5.html
Possible fixes
* igt@kms_flip@basic-flip-vs-modeset@d-dp5:
- bat-adlp-11:[DMESG-FAIL][8] ([i915#6868]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html
* igt@kms_frontbuffer_tracking@basic:
- bat-adlp-11:[SKIP][10] ([i915#4342] / [i915#5354]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_frontbuffer_track...@basic.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@kms_flip@basic-flip-vs-modeset@a-dp6:
- bat-adlp-11:[FAIL][12] ([i915#6121]) -> [DMESG-FAIL][13]
([i915#6868])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@a-dp6.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@a-dp6.html
* igt@kms_hdmi_inject@inject-audio:
- bat-adlp-11:[FAIL][14] ([i915#9746]) -> [SKIP][15] ([i915#4369])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_hdmi_inj...@inject-audio.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_hdmi_inj...@inject-audio.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-a-dp-5:
- bat-adlp-11:[ABORT][16] ([i915#8668]) -> [ABORT][17] ([i915#6868]
/ [i915#8668])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-a-dp-5.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-a-dp-5.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=1
[Intel-gfx] ✓ Fi.CI.BAT: success for PCI: qcom: Fix compile error
== Series Details ==
Series: PCI: qcom: Fix compile error
URL : https://patchwork.freedesktop.org/series/126987/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13941 -> Patchwork_126987v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/index.html
Participating hosts (37 -> 36)
--
Additional (1): bat-mtlp-8
Missing(2): fi-snb-2520m fi-pnv-d510
Known issues
Here are the changes found in Patchwork_126987v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-mtlp-8: NOTRUN -> [SKIP][1] ([i915#9318])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html
* igt@gem_lmem_swapping@verify-random:
- bat-mtlp-8: NOTRUN -> [SKIP][2] ([i915#4613]) +3 other tests skip
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_mmap@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][3] ([i915#4083])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@gem_m...@basic.html
* igt@gem_mmap_gtt@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][4] ([i915#4077]) +2 other tests skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@gem_mmap_...@basic.html
* igt@gem_render_tiled_blits@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][5] ([i915#4079]) +1 other test skip
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html
* igt@i915_pm_rps@basic-api:
- bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#6621])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][7] ([i915#6645])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][8] ([i915#5190])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html
* igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][9] ([i915#4212]) +8 other tests skip
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#4213]) +1 other test skip
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_dsc@dsc-basic:
- bat-mtlp-8: NOTRUN -> [SKIP][11] ([i915#3555] / [i915#3840] /
[i915#4098] / [i915#9159])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@kms_...@dsc-basic.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-mtlp-8: NOTRUN -> [SKIP][12] ([fdo#109285])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_force_connector_basic@prune-stale-modes:
- bat-mtlp-8: NOTRUN -> [SKIP][13] ([i915#5274])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#3555] / [i915#8809])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-fence-mmap:
- bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#3708] / [i915#4077]) +1
other test skip
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@prime_v...@basic-fence-mmap.html
* igt@prime_vgem@basic-fence-read:
- bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#3708]) +2 other tests skip
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-mtlp-8/igt@prime_v...@basic-fence-read.html
Possible fixes
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [ABORT][17] ([i915#8668]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13941/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126987v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
{name}: This element is suppressed. This means it is igno
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for PCI: qcom: Fix compile error
== Series Details == Series: PCI: qcom: Fix compile error URL : https://patchwork.freedesktop.org/series/126987/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: cdclk/voltage_level cleanups and fixes
== Series Details == Series: drm/i915: cdclk/voltage_level cleanups and fixes URL : https://patchwork.freedesktop.org/series/126979/ State : success == Summary == CI Bug Log - changes from CI_DRM_13940 -> Patchwork_126979v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126979v1/index.html Participating hosts (39 -> 35) -- Missing(4): bat-mtlp-8 bat-kbl-2 fi-snb-2520m fi-pnv-d510 Known issues Here are the changes found in Patchwork_126979v1 that come from known issues: ### CI changes ### Issues hit * boot: - bat-adlp-11:[PASS][1] -> [FAIL][2] ([i915#8293]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/bat-adlp-11/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126979v1/bat-adlp-11/boot.html ### IGT changes ### Issues hit * igt@core_hotunplug@unbind-rebind: - fi-glk-j4005: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-glk-j4005/igt@core_hotunp...@unbind-rebind.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126979v1/fi-glk-j4005/igt@core_hotunp...@unbind-rebind.html * igt@i915_selftest@live@hangcheck: - bat-adls-5: [PASS][5] -> [DMESG-WARN][6] ([i915#5591]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/bat-adls-5/igt@i915_selftest@l...@hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126979v1/bat-adls-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_suspend@basic-s3-without-i915: - bat-jsl-3: [PASS][7] -> [INCOMPLETE][8] ([i915#9664]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126979v1/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html - bat-jsl-1: [PASS][9] -> [INCOMPLETE][10] ([i915#9664]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/bat-jsl-1/igt@i915_susp...@basic-s3-without-i915.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126979v1/bat-jsl-1/igt@i915_susp...@basic-s3-without-i915.html Possible fixes * igt@gem_exec_suspend@basic-s0@smem: - bat-dg2-9: [INCOMPLETE][11] ([i915#9275]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126979v1/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html * igt@kms_hdmi_inject@inject-audio: - fi-kbl-guc: [FAIL][13] ([IGT#3]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126979v1/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#5591]: https://gitlab.freedesktop.org/drm/intel/issues/5591 [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293 [i915#9275]: https://gitlab.freedesktop.org/drm/intel/issues/9275 [i915#9664]: https://gitlab.freedesktop.org/drm/intel/issues/9664 Build changes - * Linux: CI_DRM_13940 -> Patchwork_126979v1 CI-20190529: 20190529 CI_DRM_13940: 901cb0fd3326a1c7d40bed6568db1d9e46a1f466 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7609: 72a759595100b8d167ca78cd2d62e9acd97e36bf @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_126979v1: 901cb0fd3326a1c7d40bed6568db1d9e46a1f466 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 7db23071146e drm/i915: Simplify intel_ddi_compute_min_voltage_level() c1c10ef5aa0e drm/i915/mtl: Calculate the correct voltage level from port_clock c6672d1d4e4f drm/i915: Split intel_ddi_compute_min_voltage_level() into platform variants ef3a9106841b drm/i915/mtl: Fix voltage_level for cdclk==480MHz 950c9b113ae2 drm/i915/cdclk: Rewrite cdclk->voltage_level selection to use tables 5ec914296f72 drm/i915/cdclk: Remove the assumption that cd2x div==2 when using squashing 72649f96b8f9 drm/i915/cdclk: Give the squash waveform length a name 682ad79ad219 drm/i915/cdclk: s/-1/~0/ when dealing with unsigned values == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126979v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: cdclk/voltage_level cleanups and fixes
== Series Details == Series: drm/i915: cdclk/voltage_level cleanups and fixes URL : https://patchwork.freedesktop.org/series/126979/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:185:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:191:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:236:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:238:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +drivers/gpu/drm/i915/display/intel_display_types.h:1910:17: warning: unreplaced symbol 'encoder' +drivers/gpu/drm/i915/display/intel_display_types.h:1910:9: warning: unreplaced symbol 'break' +drivers/gpu/drm/i915/display/intel_display_types.h:1910:9: warning: unreplaced symbol 'case' +drivers/gpu/drm/i915/display/intel_display_types.h:1911:9: warning: unreplaced symbol '' +drivers/gpu/drm/i915/display/intel_display_types.h:1911:9: warning: unreplaced symbol '' +drivers/gpu/drm/i915/display/intel_display_types.h:1912:9: warning: too many warnings +drivers/gpu/drm/i915/display/intel_display_types.h:1912:9: warning: unreplaced symbol '' +drivers/gpu/drm/i915/display/intel_display_types.h:1913:9: warning: unreplaced symbol '' +drivers/gpu/drm/i915/display/intel_display_types.h:1914:9: warning: unreplaced symbol '' +drivers/gpu/drm/i915/display/intel_display_types.h:1915:17: warning: unreplaced symbol 'return' +drivers/gpu/drm/i915/display/intel_display_types.h:1916:9: warning: unreplaced symbol '' +drivers/gpu/drm/i915/display/intel_display_types.h:1917:17: warning: unreplaced symbol 'return' +drivers/gpu/drm/i915/display/intel_display_types.h:1936:9: warning: unreplaced symbol 'intel_encoder' +drivers/gpu/drm/i915/display/intel_display_types.h:1983:24: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/display/intel_display_types.h:1983:24: warning: trying to copy expression type 31 +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'v
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: wait for active idle event in i915_active_unlock_wait
== Series Details == Series: drm/i915/selftests: wait for active idle event in i915_active_unlock_wait URL : https://patchwork.freedesktop.org/series/126978/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13940 -> Patchwork_126978v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_126978v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_126978v1, please notify your bug team (i915-ci-in...@lists.freedesktop.org) 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_126978v1/index.html Participating hosts (39 -> 36) -- Missing(3): bat-kbl-2 bat-adlp-6 fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_126978v1: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gt_contexts: - fi-ilk-650: [PASS][1] -> [TIMEOUT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-ilk-650/igt@i915_selftest@live@gt_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/fi-ilk-650/igt@i915_selftest@live@gt_contexts.html - bat-jsl-1: [PASS][3] -> [TIMEOUT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/bat-jsl-1/igt@i915_selftest@live@gt_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/bat-jsl-1/igt@i915_selftest@live@gt_contexts.html - fi-tgl-1115g4: [PASS][5] -> [TIMEOUT][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-tgl-1115g4/igt@i915_selftest@live@gt_contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/fi-tgl-1115g4/igt@i915_selftest@live@gt_contexts.html - fi-blb-e6850: [PASS][7] -> [TIMEOUT][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-blb-e6850/igt@i915_selftest@live@gt_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/fi-blb-e6850/igt@i915_selftest@live@gt_contexts.html - fi-skl-6600u: [PASS][9] -> [TIMEOUT][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-skl-6600u/igt@i915_selftest@live@gt_contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/fi-skl-6600u/igt@i915_selftest@live@gt_contexts.html - fi-apl-guc: [PASS][11] -> [TIMEOUT][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-apl-guc/igt@i915_selftest@live@gt_contexts.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/fi-apl-guc/igt@i915_selftest@live@gt_contexts.html - fi-pnv-d510:[PASS][13] -> [TIMEOUT][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-pnv-d510/igt@i915_selftest@live@gt_contexts.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/fi-pnv-d510/igt@i915_selftest@live@gt_contexts.html - fi-glk-j4005: [PASS][15] -> [TIMEOUT][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-glk-j4005/igt@i915_selftest@live@gt_contexts.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/fi-glk-j4005/igt@i915_selftest@live@gt_contexts.html - fi-skl-guc: [PASS][17] -> [TIMEOUT][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-skl-guc/igt@i915_selftest@live@gt_contexts.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/fi-skl-guc/igt@i915_selftest@live@gt_contexts.html - fi-kbl-7567u: [PASS][19] -> [TIMEOUT][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-kbl-7567u/igt@i915_selftest@live@gt_contexts.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/fi-kbl-7567u/igt@i915_selftest@live@gt_contexts.html - fi-cfl-8700k: [PASS][21] -> [TIMEOUT][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-cfl-8700k/igt@i915_selftest@live@gt_contexts.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/fi-cfl-8700k/igt@i915_selftest@live@gt_contexts.html - fi-bsw-nick:[PASS][23] -> [TIMEOUT][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-bsw-nick/igt@i915_selftest@live@gt_contexts.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/fi-bsw-nick/igt@i915_selftest@live@gt_contexts.html - fi-rkl-11600: [PASS][25] -> [TIMEOUT][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13940/fi-rkl-11600/igt@i915_selftest@live@gt_contexts.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126978v1/fi-rkl-11600/igt@i915_selftest@live@gt_contexts.html - bat-adls-5: [PASS][27] -> [TIMEOUT][28] [27]: https://intel
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix IP version of the WAs
== Series Details == Series: drm/i915/display: Fix IP version of the WAs URL : https://patchwork.freedesktop.org/series/126967/ State : success == Summary == CI Bug Log - changes from CI_DRM_13939 -> Patchwork_126967v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/index.html Participating hosts (37 -> 35) -- Additional (2): bat-mtlp-8 fi-pnv-d510 Missing(4): bat-kbl-2 bat-dg2-9 fi-snb-2520m bat-dg1-5 Known issues Here are the changes found in Patchwork_126967v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-mtlp-8: NOTRUN -> [SKIP][1] ([i915#9318]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html * igt@gem_lmem_swapping@basic: - fi-pnv-d510:NOTRUN -> [SKIP][2] ([fdo#109271]) +25 other tests skip [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/fi-pnv-d510/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - bat-mtlp-8: NOTRUN -> [SKIP][3] ([i915#4613]) +3 other tests skip [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-mtlp-8: NOTRUN -> [SKIP][4] ([i915#4083]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-mtlp-8: NOTRUN -> [SKIP][5] ([i915#4077]) +2 other tests skip [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@gem_mmap_...@basic.html * igt@gem_render_tiled_blits@basic: - bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#4079]) +1 other test skip [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html * igt@i915_pm_rps@basic-api: - bat-mtlp-8: NOTRUN -> [SKIP][7] ([i915#6621]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [PASS][8] -> [DMESG-FAIL][9] ([i915#5334]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13939/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@migrate: - bat-rpls-1: NOTRUN -> [INCOMPLETE][10] ([i915#9667]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-rpls-1/igt@i915_selftest@l...@migrate.html * igt@i915_suspend@basic-s3-without-i915: - bat-mtlp-8: NOTRUN -> [SKIP][11] ([i915#6645]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - bat-mtlp-8: NOTRUN -> [SKIP][12] ([i915#5190]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-mtlp-8: NOTRUN -> [SKIP][13] ([i915#4212]) +8 other tests skip [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#4213]) +1 other test skip [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_dsc@dsc-basic: - bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#3555] / [i915#3840] / [i915#4098] / [i915#9159]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@kms_...@dsc-basic.html * igt@kms_force_connector_basic@force-load-detect: - bat-mtlp-8: NOTRUN -> [SKIP][16] ([fdo#109285]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-mtlp-8: NOTRUN -> [SKIP][17] ([i915#5274]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-mtlp-8/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1: - bat-rplp-1: [PASS][18] -> [ABORT][19] ([i915#8668]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13939/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126967v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-sequ
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915/psr: Include some basic PSR information in the state dump (rev2)
== Series Details == Series: series starting with [1/5] drm/i915/psr: Include some basic PSR information in the state dump (rev2) URL : https://patchwork.freedesktop.org/series/126859/ State : success == Summary == CI Bug Log - changes from CI_DRM_13939 -> Patchwork_126859v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/index.html Participating hosts (37 -> 37) -- Additional (2): bat-mtlp-8 fi-pnv-d510 Missing(2): bat-dg2-9 fi-snb-2520m Known issues Here are the changes found in Patchwork_126859v2 that come from known issues: ### CI changes ### Issues hit * boot: - bat-adlp-11:[PASS][1] -> [FAIL][2] ([i915#8293]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13939/bat-adlp-11/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-adlp-11/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-mtlp-8: NOTRUN -> [SKIP][3] ([i915#9318]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html * igt@gem_lmem_swapping@basic: - fi-pnv-d510:NOTRUN -> [SKIP][4] ([fdo#109271]) +25 other tests skip [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/fi-pnv-d510/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - bat-mtlp-8: NOTRUN -> [SKIP][5] ([i915#4613]) +3 other tests skip [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#4083]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-mtlp-8: NOTRUN -> [SKIP][7] ([i915#4077]) +2 other tests skip [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@gem_mmap_...@basic.html * igt@gem_render_tiled_blits@basic: - bat-mtlp-8: NOTRUN -> [SKIP][8] ([i915#4079]) +1 other test skip [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html * igt@i915_pm_rps@basic-api: - bat-mtlp-8: NOTRUN -> [SKIP][9] ([i915#6621]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@execlists: - bat-mtlp-8: NOTRUN -> [INCOMPLETE][10] ([i915#9527]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: NOTRUN -> [ABORT][11] ([i915#9413]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_suspend@basic-s3-without-i915: - bat-rpls-1: NOTRUN -> [ABORT][12] ([i915#7978] / [i915#9631]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - bat-mtlp-8: NOTRUN -> [SKIP][13] ([i915#5190]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#4212]) +8 other tests skip [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#4213]) +1 other test skip [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_dsc@dsc-basic: - bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#3555] / [i915#3840] / [i915#4098] / [i915#9159]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@kms_...@dsc-basic.html * igt@kms_force_connector_basic@force-load-detect: - bat-mtlp-8: NOTRUN -> [SKIP][17] ([fdo#109285]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-mtlp-8: NOTRUN -> [SKIP][18] ([i915#5274]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126859v2/bat-mtlp-8/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1: - bat-rplp-1: [PASS][19] -> [ABORT][20] ([i915#8668]) [19]: https://intel-gfx-ci.01.org/
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/i915/psr: Include some basic PSR information in the state dump (rev2)
== Series Details == Series: series starting with [1/5] drm/i915/psr: Include some basic PSR information in the state dump (rev2) URL : https://patchwork.freedesktop.org/series/126859/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v7 4/4] drm/i915/display: Split i915 specific code away from intel_fb.c
On Tue, Nov 28, 2023 at 05:39:20PM +0200, Jouni Högander wrote:
> We are preparing for Xe driver. Backing object implementation is differing
> between i915 and Xe. Split i915 specific code into separate source file
> built only for i915.
>
> v7:
> - drop #include
> - s/user_mode_cmd/mode_cmd/
> - Use passed i915 pointer instead of to_i915(obj->base.dev)
> v6: Add missing intel_fb_bo.[ch]
> v5:
> - Keep drm_any_plane_has_format check in intel_fb.c
> - Use mode_cmd instead of user_mode_cmd for intel_fb_bo_lookup_valid_bo
> v4: Move drm_any_plane_has_format check into intel_fb_bo.c
> v3: Fix failure handling in intel_framebuffer_init
> v2: Couple of fixes to error value handling
>
> Signed-off-by: Jouni Högander
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_fb.c| 69 ++--
> drivers/gpu/drm/i915/display/intel_fb_bo.c | 92 ++
> drivers/gpu/drm/i915/display/intel_fb_bo.h | 24 ++
> 4 files changed, 125 insertions(+), 61 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_fb_bo.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_fb_bo.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 65e984242089..5060c7b98a56 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -280,6 +280,7 @@ i915-y += \
> display/intel_dsb.o \
> display/intel_dsb_buffer.o \
> display/intel_fb.o \
> + display/intel_fb_bo.o \
> display/intel_fb_pin.o \
> display/intel_fbc.o \
> display/intel_fdi.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 868e39291e9f..2c37806b379a 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -4,7 +4,6 @@
> */
>
> #include
> -#include
> #include
>
> #include
> @@ -15,6 +14,7 @@
> #include "intel_display_types.h"
> #include "intel_dpt.h"
> #include "intel_fb.h"
> +#include "intel_fb_bo.h"
> #include "intel_frontbuffer.h"
>
> #define check_array_bounds(i915, a, i) drm_WARN_ON(&(i915)->drm, (i) >=
> ARRAY_SIZE(a))
> @@ -1985,7 +1985,6 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
> struct drm_i915_private *dev_priv =
> to_i915(intel_bo_to_drm_bo(obj)->dev);
> struct drm_framebuffer *fb = &intel_fb->base;
> u32 max_stride;
> - unsigned int tiling, stride;
> int ret = -EINVAL;
> int i;
>
> @@ -1993,32 +1992,11 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
> if (!intel_fb->frontbuffer)
> return -ENOMEM;
>
> - i915_gem_object_lock(obj, NULL);
> - tiling = i915_gem_object_get_tiling(obj);
> - stride = i915_gem_object_get_stride(obj);
> - i915_gem_object_unlock(obj);
> -
> - if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) {
> - /*
> - * If there's a fence, enforce that
> - * the fb modifier and tiling mode match.
> - */
> - if (tiling != I915_TILING_NONE &&
> - tiling !=
> intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
> - drm_dbg_kms(&dev_priv->drm,
> - "tiling_mode doesn't match fb modifier\n");
> - goto err;
> - }
> - } else {
> - if (tiling == I915_TILING_X) {
> - mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
> - } else if (tiling == I915_TILING_Y) {
> - drm_dbg_kms(&dev_priv->drm,
> - "No Y tiling for legacy addfb\n");
> - goto err;
> - }
> - }
> + ret = intel_fb_bo_framebuffer_init(intel_fb, obj, mode_cmd);
> + if (ret)
> + goto err;
>
> + ret = -EINVAL;
> if (!drm_any_plane_has_format(&dev_priv->drm,
> mode_cmd->pixel_format,
> mode_cmd->modifier[0])) {
> @@ -2028,17 +2006,6 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
> goto err;
> }
>
> - /*
> - * gen2/3 display engine uses the fence if present,
> - * so the tiling mode must match the fb modifier exactly.
> - */
> - if (DISPLAY_VER(dev_priv) < 4 &&
> - tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
> - drm_dbg_kms(&dev_priv->drm,
> - "tiling_mode must match fb modifier exactly on
> gen2/3\n");
> - goto err;
> - }
> -
> max_stride = intel_fb_max_stride(dev_priv, mode_cmd->pixel_format,
>mode_cmd->modifier[0]);
> if (mode_cmd->pitches[0] > max_stride) {
> @@ -2050,17 +2017,6 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_
[Intel-gfx] [CI] drm/i915/dgfx: DGFX uses direct VBT pin mapping
From: Clint Taylor
DDC pin mapping for DGFX cards uses direct VBT pin mapping
Cc: Lucas De Marchi
Cc: Matt Roper
Signed-off-by: Clint Taylor
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_bios.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 2fd72b2fd109..3e7e96acb24a 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2201,6 +2201,9 @@ static u8 map_ddc_pin(struct drm_i915_private *i915, u8
vbt_pin)
const u8 *ddc_pin_map;
int i, n_entries;
+ if (IS_DGFX(i915))
+ return vbt_pin;
+
if (INTEL_PCH_TYPE(i915) >= PCH_LNL || HAS_PCH_MTP(i915) ||
IS_ALDERLAKE_P(i915)) {
ddc_pin_map = adlp_ddc_pin_map;
@@ -2208,8 +2211,6 @@ static u8 map_ddc_pin(struct drm_i915_private *i915, u8
vbt_pin)
} else if (IS_ALDERLAKE_S(i915)) {
ddc_pin_map = adls_ddc_pin_map;
n_entries = ARRAY_SIZE(adls_ddc_pin_map);
- } else if (INTEL_PCH_TYPE(i915) >= PCH_DG1) {
- return vbt_pin;
} else if (IS_ROCKETLAKE(i915) && INTEL_PCH_TYPE(i915) == PCH_TGP) {
ddc_pin_map = rkl_pch_tgp_ddc_pin_map;
n_entries = ARRAY_SIZE(rkl_pch_tgp_ddc_pin_map);
--
2.40.1
Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/pxp: Add missing tag for Wa_14019159160
On Mon, Nov 27, 2023 at 12:11:50PM -0800, Alan Previn wrote:
> Add missing tag for "Wa_14019159160 - Case 2" (for existing
> PXP code that ensures run alone mode bit is set to allow
> PxP-decryption.
>
> v3: - Check targeted platforms using IP_VAL. (John Harrison)
> v2: - Fix WA id number (John Harrison).
> - Improve comments and code to be specific
>for the targeted platforms (John Harrison)
>
> Signed-off-by: Alan Previn
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 7c367ba8d9dc..1152cf25d578 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -863,10 +863,12 @@ static bool ctx_needs_runalone(const struct
> intel_context *ce)
> bool ctx_is_protected = false;
>
> /*
> - * On MTL and newer platforms, protected contexts require setting
> - * the LRC run-alone bit or else the encryption will not happen.
> + * Wa_14019159160 - Case 2: mtl
> + * On some platforms, protected contexts require setting
> + * the LRC run-alone bit or else the encryption/decryption will not
> happen.
> + * NOTE: Case 2 only applies to PXP use-case of said workaround.
>*/
> - if (GRAPHICS_VER_FULL(ce->engine->i915) >= IP_VER(12, 70) &&
> + if (GRAPHICS_VER_FULL(ce->engine->i915) == IP_VER(12, 70) &&
The workaround database lists this as being needed on both 12.70 and
12.71. Should this be a
IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71))
check instead?
The workaround is also listed in the database as applying to DG2; is
this "case 2" subset of the workaround not relevant to that platform?
Matt
> (ce->engine->class == COMPUTE_CLASS || ce->engine->class ==
> RENDER_CLASS)) {
> rcu_read_lock();
> gem_ctx = rcu_dereference(ce->gem_context);
>
> base-commit: 5429d55de723544dfc0630cf39d96392052b27a1
> --
> 2.39.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915: Skip some timing checks on BXT/GLK DSI transcoders (rev2)
== Series Details ==
Series: series starting with [1/4] drm/i915: Skip some timing checks on BXT/GLK
DSI transcoders (rev2)
URL : https://patchwork.freedesktop.org/series/126923/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13934_full -> Patchwork_126923v2_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_126923v2_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_126923v2_full, please notify your bug team
(i915-ci-in...@lists.freedesktop.org) to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_126923v2_full:
### IGT changes ###
Possible regressions
* igt@kms_flip@flip-vs-expired-vblank@d-hdmi-a4:
- shard-dg1: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13934/shard-dg1-16/igt@kms_flip@flip-vs-expired-vbl...@d-hdmi-a4.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-dg1-16/igt@kms_flip@flip-vs-expired-vbl...@d-hdmi-a4.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-render:
- shard-mtlp: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13934/shard-mtlp-8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-render.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-mtlp-4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-render.html
* igt@perf_pmu@module-unload:
- shard-snb: [PASS][5] -> [ABORT][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13934/shard-snb2/igt@perf_...@module-unload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-snb4/igt@perf_...@module-unload.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_feature_discovery@display-1x}:
- shard-rkl: NOTRUN -> [SKIP][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-rkl-2/igt@kms_feature_discov...@display-1x.html
Known issues
Here are the changes found in Patchwork_126923v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@api_intel_bb@crc32:
- shard-rkl: NOTRUN -> [SKIP][8] ([i915#6230])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-rkl-4/igt@api_intel...@crc32.html
* igt@debugfs_test@basic-hwmon:
- shard-rkl: NOTRUN -> [SKIP][9] ([i915#9318])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-rkl-6/igt@debugfs_t...@basic-hwmon.html
* igt@drm_fdinfo@idle@rcs0:
- shard-rkl: NOTRUN -> [FAIL][10] ([i915#7742])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-rkl-1/igt@drm_fdinfo@i...@rcs0.html
* igt@drm_fdinfo@most-busy-check-all@bcs0:
- shard-dg2: NOTRUN -> [SKIP][11] ([i915#8414]) +29 other tests
skip
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-dg2-5/igt@drm_fdinfo@most-busy-check-...@bcs0.html
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- shard-rkl: [PASS][12] -> [FAIL][13] ([i915#7742])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13934/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@gem_basic@multigpu-create-close:
- shard-rkl: NOTRUN -> [SKIP][14] ([i915#7697]) +2 other tests skip
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-rkl-1/igt@gem_ba...@multigpu-create-close.html
* igt@gem_close_race@multigpu-basic-process:
- shard-tglu: NOTRUN -> [SKIP][15] ([i915#7697])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-tglu-4/igt@gem_close_r...@multigpu-basic-process.html
* igt@gem_create@create-ext-cpu-access-big:
- shard-dg2: NOTRUN -> [INCOMPLETE][16] ([i915#9364])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-dg2-5/igt@gem_cre...@create-ext-cpu-access-big.html
* igt@gem_create@create-ext-cpu-access-sanity-check:
- shard-rkl: NOTRUN -> [SKIP][17] ([i915#6335]) +1 other test skip
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/shard-rkl-6/igt@gem_cre...@create-ext-cpu-access-sanity-check.html
* igt@gem_ctx_persistence@heartbeat-hang:
- shard-dg2: NOTRUN -> [SKIP][18] ([i915#8555])
[Intel-gfx] [PATCH] drm/i915/gem: Atomically invalidate userptr on mmu-notifier
Never block for outstanding work on userptr object upon receipt of a
mmu-notifier. The reason we originally did so was to immediately unbind
the userptr and unpin its pages, but since that has been dropped in
commit b4b9731b02c3c ("drm/i915: Simplify userptr locking"), we never
return the pages to the system i.e. never drop our page->mapcount and so
do not allow the page and CPU PTE to be revoked. Based on this history,
we know we are safe to drop the wait entirely.
Upon return from mmu-notifier, we will still have the userptr pages
pinned preventing the following PTE operation (such as try_to_unmap)
adjusting the vm_area_struct, so it is safe to keep the pages around for
as long as we still have i/o pending.
We do not have any means currently to asynchronously revalidate the
userptr pages, that is always prior to next use.
Signed-off-by: Chris Wilson
Signed-off-by: Jonathan Cavitt
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 8
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 42 ---
drivers/gpu/drm/i915/gem/i915_gem_userptr.h | 14 ---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/i915_gem.c | 5 ---
5 files changed, 77 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/gem/i915_gem_userptr.h
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b1aa62dfb155d..eff601389ef85 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2159,12 +2159,6 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
#ifdef CONFIG_MMU_NOTIFIER
if (!err && (eb->args->flags & __EXEC_USERPTR_USED)) {
- read_lock(&eb->i915->mm.notifier_lock);
-
- /*
-* count is always at least 1, otherwise __EXEC_USERPTR_USED
-* could not have been set
-*/
for (i = 0; i < count; i++) {
struct eb_vma *ev = &eb->vma[i];
struct drm_i915_gem_object *obj = ev->vma->obj;
@@ -2176,8 +2170,6 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
if (err)
break;
}
-
- read_unlock(&eb->i915->mm.notifier_lock);
}
#endif
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 1d3ebdf4069b5..0e21ce9d3e5ac 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -42,7 +42,6 @@
#include "i915_drv.h"
#include "i915_gem_ioctls.h"
#include "i915_gem_object.h"
-#include "i915_gem_userptr.h"
#include "i915_scatterlist.h"
#ifdef CONFIG_MMU_NOTIFIER
@@ -61,36 +60,7 @@ static bool i915_gem_userptr_invalidate(struct
mmu_interval_notifier *mni,
const struct mmu_notifier_range *range,
unsigned long cur_seq)
{
- struct drm_i915_gem_object *obj = container_of(mni, struct
drm_i915_gem_object, userptr.notifier);
- struct drm_i915_private *i915 = to_i915(obj->base.dev);
- long r;
-
- if (!mmu_notifier_range_blockable(range))
- return false;
-
- write_lock(&i915->mm.notifier_lock);
-
mmu_interval_set_seq(mni, cur_seq);
-
- write_unlock(&i915->mm.notifier_lock);
-
- /*
-* We don't wait when the process is exiting. This is valid
-* because the object will be cleaned up anyway.
-*
-* This is also temporarily required as a hack, because we
-* cannot currently force non-consistent batch buffers to preempt
-* and reschedule by waiting on it, hanging processes on exit.
-*/
- if (current->flags & PF_EXITING)
- return true;
-
- /* we will unbind on next submission, still have userptr pins */
- r = dma_resv_wait_timeout(obj->base.resv, DMA_RESV_USAGE_BOOKKEEP,
false,
- MAX_SCHEDULE_TIMEOUT);
- if (r <= 0)
- drm_err(&i915->drm, "(%ld) failed to wait for idle\n", r);
-
return true;
}
@@ -580,15 +550,3 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
#endif
}
-int i915_gem_init_userptr(struct drm_i915_private *dev_priv)
-{
-#ifdef CONFIG_MMU_NOTIFIER
- rwlock_init(&dev_priv->mm.notifier_lock);
-#endif
-
- return 0;
-}
-
-void i915_gem_cleanup_userptr(struct drm_i915_private *dev_priv)
-{
-}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.h
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.h
deleted file mode 100644
index 8dadb2f8436d4..0
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.h
+++ /dev/null
@@ -1,14 +0,0 @@
-/* SPDX-License-Identifier: MIT */
-/*
- * Copyright © 2021 Intel Corporation
- */
-
-#ifndef __I915_GEM_USERPTR_H__
-#define __I915_GEM_USERPTR_H__
-
-struct drm_i915_private;
-
-
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Drop Wa_22014600077
On Tue, Nov 28, 2023 at 05:03:51AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/dg2: Drop Wa_22014600077 > URL : https://patchwork.freedesktop.org/series/126942/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_13929_full -> Patchwork_126942v1_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_126942v1_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_126942v1_full, please notify your bug team > (i915-ci-in...@lists.freedesktop.org) 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_126942v1_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-vga1: > - shard-snb: [PASS][1] -> [ABORT][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-snb4/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-vga1.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126942v1/shard-snb7/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-vga1.html Lock corruption outside the graphics driver. Not related to i915 or this patch. Patch applied to drm-intel-gt-next. Thanks Gustavo for the review. Matt > > > Known issues > > > Here are the changes found in Patchwork_126942v1_full that come from known > issues: > > ### CI changes ### > > Possible fixes > > * boot: > - shard-glk: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], > [PASS][7], [PASS][8], [PASS][9], [PASS][10], [FAIL][11], [PASS][12], > [PASS][13], [PASS][14], [FAIL][15], [PASS][16], [PASS][17], [PASS][18], > [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], > [PASS][25], [PASS][26], [PASS][27]) ([i915#8293]) -> ([PASS][28], [PASS][29], > [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], > [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], > [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], > [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk9/boot.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk9/boot.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk9/boot.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk8/boot.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk8/boot.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk8/boot.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk8/boot.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk7/boot.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk7/boot.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk7/boot.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk6/boot.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk6/boot.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk5/boot.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk4/boot.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk4/boot.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk4/boot.html >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk3/boot.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk3/boot.html >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk3/boot.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk2/boot.html >[23]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk2/boot.html >[24]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk2/boot.html >[25]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk1/boot.html >[26]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk1/boot.html >[27]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13929/shard-glk1/boot.html >[28]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126942v1/shard-glk9/boot.html >[29]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126942v1/shard-glk9/boot.html >[30]: > https://intel-gfx-ci.01.org/tr
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix IP version of the WAs
On Tue, Nov 28, 2023 at 03:54:51PM +0530, Balasubramani Vivekanandan wrote: > WAs 14011508470, 14011503030 were applied on IP versions beyond which > they are applicable. Fixed the IP version checks for these workarounds. > > Signed-off-by: Balasubramani Vivekanandan > Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/display/intel_display_power.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c > b/drivers/gpu/drm/i915/display/intel_display_power.c > index 18ff7f3639ff..5f091502719b 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_power.c > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c > @@ -1697,14 +1697,14 @@ static void icl_display_core_init(struct > drm_i915_private *dev_priv, > if (resume) > intel_dmc_load_program(dev_priv); > > - /* Wa_14011508470:tgl,dg1,rkl,adl-s,adl-p */ > - if (DISPLAY_VER(dev_priv) >= 12) > + /* Wa_14011508470:tgl,dg1,rkl,adl-s,adl-p,dg2 */ > + if (IS_DISPLAY_IP_RANGE(dev_priv, IP_VER(12, 0), IP_VER(13, 0))) > intel_de_rmw(dev_priv, GEN11_CHICKEN_DCPR_2, 0, >DCPR_CLEAR_MEMSTAT_DIS | DCPR_SEND_RESP_IMM | >DCPR_MASK_LPMODE | DCPR_MASK_MAXLATENCY_MEMUP_CLR); > > /* Wa_14011503030:xelpd */ > - if (DISPLAY_VER(dev_priv) >= 13) > + if (DISPLAY_VER(dev_priv) == 13) > intel_de_write(dev_priv, XELPD_DISPLAY_ERR_FATAL_MASK, ~0); > } > > -- > 2.25.1 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [Intel-gfx] [linus:master] [file] 0ede61d858: will-it-scale.per_thread_ops -2.9% regression
On Mon, Nov 27, 2023 at 09:10:54AM -0800, Linus Torvalds wrote: > On Mon, 27 Nov 2023 at 02:27, Christian Brauner wrote: > > > > So I've picked up your patch (vfs.misc). It's clever alright so thanks > > for the comments in there otherwise I would've stared at this for far > > too long. > > Note that I should probably have commented on one other thing: that > whole "just load from fd[0] is always safe, because the fd[] array > always exists". I added a comment to that effect in the code. > > IOW, that whole "load and mask" thing only works when you know the > array exists at all. > > Doing that "just mask the index" wouldn't be valid if "size = 0" is an > option and might mean that we don't have an array at all (ie if "->fd" > itself could be NULL. > > But we never have a completely empty file descriptor array, and > fdp->fd is never NULL. At a minimum 'max_fds' is NR_OPEN_DEFAULT. > > (The whole 'tsk->files' could be NULL, but only for kernel threads or > when exiting, so fget_task() will check for *that*, but it's a > separate thing) Yep. > > So that's why it's safe to *entirely* remove the whole > > if (unlikely(fd >= fdt->max_fds)) > > test, and do it *all* with just "mask the index, and mask the resulting load". Yep.
Re: [Intel-gfx] [PATCH v6 4/4] drm/i915/display: Split i915 specific code away from intel_fb.c
On Tue, 2023-11-28 at 15:29 +0200, Ville Syrjälä wrote:
> On Thu, Nov 23, 2023 at 09:41:20AM +0200, Jouni Högander wrote:
> > We are preparing for Xe driver. Backing object implementation is
> > differing
> > between i915 and Xe. Split i915 specific code into separate source
> > file
> > built only for i915.
> >
> > v6: Add missing intel_fb_bo.[ch]
> > v5:
> > - Keep drm_any_plane_has_format check in intel_fb.c
> > - Use mode_cmd instead of user_mode_cmd for
> > intel_fb_bo_lookup_valid_bo
> > v4: Move drm_any_plane_has_format check into intel_fb_bo.c
> > v3: Fix failure handling in intel_framebuffer_init
> > v2: Couple of fixes to error value handling
> >
> > Signed-off-by: Jouni Högander
> > ---
> > drivers/gpu/drm/i915/Makefile | 1 +
> > drivers/gpu/drm/i915/display/intel_fb.c | 69 ++--
> > drivers/gpu/drm/i915/display/intel_fb_bo.c | 93
> > ++
> > drivers/gpu/drm/i915/display/intel_fb_bo.h | 24 ++
> > 4 files changed, 126 insertions(+), 61 deletions(-)
> > create mode 100644 drivers/gpu/drm/i915/display/intel_fb_bo.c
> > create mode 100644 drivers/gpu/drm/i915/display/intel_fb_bo.h
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile
> > b/drivers/gpu/drm/i915/Makefile
> > index 7e5d6a39d450..c14ba1212b84 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -279,6 +279,7 @@ i915-y += \
> > display/intel_dsb.o \
> > display/intel_dsb_buffer.o \
> > display/intel_fb.o \
> > + display/intel_fb_bo.o \
> > display/intel_fb_pin.o \
> > display/intel_fbc.o \
> > display/intel_fdi.o \
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> > b/drivers/gpu/drm/i915/display/intel_fb.c
> > index f63f56b24b11..d5de213be2c0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > @@ -4,7 +4,6 @@
> > */
> >
> > #include
> > -#include
> > #include
> >
> > #include
> > @@ -15,6 +14,7 @@
> > #include "intel_display_types.h"
> > #include "intel_dpt.h"
> > #include "intel_fb.h"
> > +#include "intel_fb_bo.h"
> > #include "intel_frontbuffer.h"
> >
> > #define check_array_bounds(i915, a, i) drm_WARN_ON(&(i915)->drm,
> > (i) >= ARRAY_SIZE(a))
> > @@ -1985,7 +1985,6 @@ int intel_framebuffer_init(struct
> > intel_framebuffer *intel_fb,
> > struct drm_i915_private *dev_priv =
> > to_i915(intel_bo_to_drm_bo(obj)->dev);
> > struct drm_framebuffer *fb = &intel_fb->base;
> > u32 max_stride;
> > - unsigned int tiling, stride;
> > int ret = -EINVAL;
> > int i;
> >
> > @@ -1993,32 +1992,11 @@ int intel_framebuffer_init(struct
> > intel_framebuffer *intel_fb,
> > if (!intel_fb->frontbuffer)
> > return -ENOMEM;
> >
> > - i915_gem_object_lock(obj, NULL);
> > - tiling = i915_gem_object_get_tiling(obj);
> > - stride = i915_gem_object_get_stride(obj);
> > - i915_gem_object_unlock(obj);
> > -
> > - if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) {
> > - /*
> > - * If there's a fence, enforce that
> > - * the fb modifier and tiling mode match.
> > - */
> > - if (tiling != I915_TILING_NONE &&
> > - tiling != intel_fb_modifier_to_tiling(mode_cmd-
> > >modifier[0])) {
> > - drm_dbg_kms(&dev_priv->drm,
> > - "tiling_mode doesn't match fb
> > modifier\n");
> > - goto err;
> > - }
> > - } else {
> > - if (tiling == I915_TILING_X) {
> > - mode_cmd->modifier[0] =
> > I915_FORMAT_MOD_X_TILED;
> > - } else if (tiling == I915_TILING_Y) {
> > - drm_dbg_kms(&dev_priv->drm,
> > - "No Y tiling for legacy
> > addfb\n");
> > - goto err;
> > - }
> > - }
> > + ret = intel_fb_bo_framebuffer_init(intel_fb, obj,
> > mode_cmd);
> > + if (ret)
> > + goto err;
> >
> > + ret = -EINVAL;
> > if (!drm_any_plane_has_format(&dev_priv->drm,
> > mode_cmd->pixel_format,
> > mode_cmd->modifier[0])) {
> > @@ -2028,17 +2006,6 @@ int intel_framebuffer_init(struct
> > intel_framebuffer *intel_fb,
> > goto err;
> > }
> >
> > - /*
> > - * gen2/3 display engine uses the fence if present,
> > - * so the tiling mode must match the fb modifier exactly.
> > - */
> > - if (DISPLAY_VER(dev_priv) < 4 &&
> > - tiling != intel_fb_modifier_to_tiling(mode_cmd-
> > >modifier[0])) {
> > - drm_dbg_kms(&dev_priv->drm,
> > - "tiling_mode must match fb modifier
> > exactly on gen2/3\n");
> > - goto er
[Intel-gfx] [PATCH v7 3/4] drm/i915/display: Handle invalid fb_modifier in intel_fb_modifier_to_tiling
Lookup_modifier is returning INTEL_PLANE_CAP_TILING_4 on invalid
fb_modifier value. Use lookup_modifier_or_null in
intel_fb_modifier_to_tiling and return I915_TILING_NONE in case
lookup_modifier_or_null returns null.
Signed-off-by: Jouni Högander
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 6c89cb2f2002..868e39291e9f 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -303,7 +303,14 @@ lookup_format_info(const struct drm_format_info formats[],
unsigned int intel_fb_modifier_to_tiling(u64 fb_modifier)
{
- u8 tiling_caps = lookup_modifier(fb_modifier)->plane_caps &
+ const struct intel_modifier_desc *md;
+ u8 tiling_caps;
+
+ md = lookup_modifier_or_null(fb_modifier);
+ if (!md)
+ return I915_TILING_NONE;
+
+ tiling_caps = lookup_modifier_or_null(fb_modifier)->plane_caps &
INTEL_PLANE_CAP_TILING_MASK;
switch (tiling_caps) {
--
2.34.1
[Intel-gfx] [PATCH v7 4/4] drm/i915/display: Split i915 specific code away from intel_fb.c
We are preparing for Xe driver. Backing object implementation is differing
between i915 and Xe. Split i915 specific code into separate source file
built only for i915.
v7:
- drop #include
- s/user_mode_cmd/mode_cmd/
- Use passed i915 pointer instead of to_i915(obj->base.dev)
v6: Add missing intel_fb_bo.[ch]
v5:
- Keep drm_any_plane_has_format check in intel_fb.c
- Use mode_cmd instead of user_mode_cmd for intel_fb_bo_lookup_valid_bo
v4: Move drm_any_plane_has_format check into intel_fb_bo.c
v3: Fix failure handling in intel_framebuffer_init
v2: Couple of fixes to error value handling
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_fb.c| 69 ++--
drivers/gpu/drm/i915/display/intel_fb_bo.c | 92 ++
drivers/gpu/drm/i915/display/intel_fb_bo.h | 24 ++
4 files changed, 125 insertions(+), 61 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_fb_bo.c
create mode 100644 drivers/gpu/drm/i915/display/intel_fb_bo.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 65e984242089..5060c7b98a56 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -280,6 +280,7 @@ i915-y += \
display/intel_dsb.o \
display/intel_dsb_buffer.o \
display/intel_fb.o \
+ display/intel_fb_bo.o \
display/intel_fb_pin.o \
display/intel_fbc.o \
display/intel_fdi.o \
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 868e39291e9f..2c37806b379a 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -4,7 +4,6 @@
*/
#include
-#include
#include
#include
@@ -15,6 +14,7 @@
#include "intel_display_types.h"
#include "intel_dpt.h"
#include "intel_fb.h"
+#include "intel_fb_bo.h"
#include "intel_frontbuffer.h"
#define check_array_bounds(i915, a, i) drm_WARN_ON(&(i915)->drm, (i) >=
ARRAY_SIZE(a))
@@ -1985,7 +1985,6 @@ int intel_framebuffer_init(struct intel_framebuffer
*intel_fb,
struct drm_i915_private *dev_priv =
to_i915(intel_bo_to_drm_bo(obj)->dev);
struct drm_framebuffer *fb = &intel_fb->base;
u32 max_stride;
- unsigned int tiling, stride;
int ret = -EINVAL;
int i;
@@ -1993,32 +1992,11 @@ int intel_framebuffer_init(struct intel_framebuffer
*intel_fb,
if (!intel_fb->frontbuffer)
return -ENOMEM;
- i915_gem_object_lock(obj, NULL);
- tiling = i915_gem_object_get_tiling(obj);
- stride = i915_gem_object_get_stride(obj);
- i915_gem_object_unlock(obj);
-
- if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) {
- /*
-* If there's a fence, enforce that
-* the fb modifier and tiling mode match.
-*/
- if (tiling != I915_TILING_NONE &&
- tiling !=
intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
- drm_dbg_kms(&dev_priv->drm,
- "tiling_mode doesn't match fb modifier\n");
- goto err;
- }
- } else {
- if (tiling == I915_TILING_X) {
- mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
- } else if (tiling == I915_TILING_Y) {
- drm_dbg_kms(&dev_priv->drm,
- "No Y tiling for legacy addfb\n");
- goto err;
- }
- }
+ ret = intel_fb_bo_framebuffer_init(intel_fb, obj, mode_cmd);
+ if (ret)
+ goto err;
+ ret = -EINVAL;
if (!drm_any_plane_has_format(&dev_priv->drm,
mode_cmd->pixel_format,
mode_cmd->modifier[0])) {
@@ -2028,17 +2006,6 @@ int intel_framebuffer_init(struct intel_framebuffer
*intel_fb,
goto err;
}
- /*
-* gen2/3 display engine uses the fence if present,
-* so the tiling mode must match the fb modifier exactly.
-*/
- if (DISPLAY_VER(dev_priv) < 4 &&
- tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
- drm_dbg_kms(&dev_priv->drm,
- "tiling_mode must match fb modifier exactly on
gen2/3\n");
- goto err;
- }
-
max_stride = intel_fb_max_stride(dev_priv, mode_cmd->pixel_format,
mode_cmd->modifier[0]);
if (mode_cmd->pitches[0] > max_stride) {
@@ -2050,17 +2017,6 @@ int intel_framebuffer_init(struct intel_framebuffer
*intel_fb,
goto err;
}
- /*
-* If there's a fence, enforce that
-* the fb pitch and fence stride match.
-*/
- if (tiling != I915_TILING_NONE && mode_cmd->pitches[0] != stride) {
-
[Intel-gfx] [PATCH v7 2/4] drm/i915/display: Convert intel_fb_modifier_to_tiling as non-static
We are about to split i915 specific code from intel_fb.c. Convert
intel_fb_modifier_to_tiling as non-static to allow calling it from split
code.
Signed-off-by: Jouni Högander
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb.c | 40 -
drivers/gpu/drm/i915/display/intel_fb.h | 2 ++
2 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 4af5b7181fdf..6c89cb2f2002 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -301,6 +301,26 @@ lookup_format_info(const struct drm_format_info formats[],
return NULL;
}
+unsigned int intel_fb_modifier_to_tiling(u64 fb_modifier)
+{
+ u8 tiling_caps = lookup_modifier(fb_modifier)->plane_caps &
+INTEL_PLANE_CAP_TILING_MASK;
+
+ switch (tiling_caps) {
+ case INTEL_PLANE_CAP_TILING_Y:
+ return I915_TILING_Y;
+ case INTEL_PLANE_CAP_TILING_X:
+ return I915_TILING_X;
+ case INTEL_PLANE_CAP_TILING_4:
+ case INTEL_PLANE_CAP_TILING_Yf:
+ case INTEL_PLANE_CAP_TILING_NONE:
+ return I915_TILING_NONE;
+ default:
+ MISSING_CASE(tiling_caps);
+ return I915_TILING_NONE;
+ }
+}
+
/**
* intel_fb_get_format_info: Get a modifier specific format information
* @cmd: FB add command structure
@@ -737,26 +757,6 @@ intel_fb_align_height(const struct drm_framebuffer *fb,
return ALIGN(height, tile_height);
}
-static unsigned int intel_fb_modifier_to_tiling(u64 fb_modifier)
-{
- u8 tiling_caps = lookup_modifier(fb_modifier)->plane_caps &
-INTEL_PLANE_CAP_TILING_MASK;
-
- switch (tiling_caps) {
- case INTEL_PLANE_CAP_TILING_Y:
- return I915_TILING_Y;
- case INTEL_PLANE_CAP_TILING_X:
- return I915_TILING_X;
- case INTEL_PLANE_CAP_TILING_4:
- case INTEL_PLANE_CAP_TILING_Yf:
- case INTEL_PLANE_CAP_TILING_NONE:
- return I915_TILING_NONE;
- default:
- MISSING_CASE(tiling_caps);
- return I915_TILING_NONE;
- }
-}
-
bool intel_fb_modifier_uses_dpt(struct drm_i915_private *i915, u64 modifier)
{
return HAS_DPT(i915) && modifier != DRM_FORMAT_MOD_LINEAR;
diff --git a/drivers/gpu/drm/i915/display/intel_fb.h
b/drivers/gpu/drm/i915/display/intel_fb.h
index e85167d6bc34..23db6628f53e 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.h
+++ b/drivers/gpu/drm/i915/display/intel_fb.h
@@ -95,4 +95,6 @@ intel_user_framebuffer_create(struct drm_device *dev,
bool intel_fb_modifier_uses_dpt(struct drm_i915_private *i915, u64 modifier);
bool intel_fb_uses_dpt(const struct drm_framebuffer *fb);
+unsigned int intel_fb_modifier_to_tiling(u64 fb_modifier);
+
#endif /* __INTEL_FB_H__ */
--
2.34.1
[Intel-gfx] [PATCH v7 1/4] drm/i915/display: use intel_bo_to_drm_bo in intel_fb.c
We are preparing for Xe driver. I915 and Xe object implementation are
differing. Do not use i915_gem_object->base directly. Instead use
intel_bo_to_drm_bo.
Also use drm_gem_object_put instead of i915_gem_object_put. This should be
ok as i915_gem_object_put is really just doing __drm_gem_object_put.
Signed-off-by: Jouni Högander
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 6d48aa3af95a..4af5b7181fdf 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -1657,10 +1657,10 @@ int intel_fill_fb_info(struct drm_i915_private *i915,
struct intel_framebuffer *
max_size = max(max_size, offset + size);
}
- if (mul_u32_u32(max_size, tile_size) > obj->base.size) {
+ if (mul_u32_u32(max_size, tile_size) > intel_bo_to_drm_bo(obj)->size) {
drm_dbg_kms(&i915->drm,
"fb too big for bo (need %llu bytes, have %zu
bytes)\n",
- mul_u32_u32(max_size, tile_size), obj->base.size);
+ mul_u32_u32(max_size, tile_size),
intel_bo_to_drm_bo(obj)->size);
return -EINVAL;
}
@@ -1889,7 +1889,7 @@ static int intel_user_framebuffer_create_handle(struct
drm_framebuffer *fb,
unsigned int *handle)
{
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
- struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct drm_i915_private *i915 = to_i915(intel_bo_to_drm_bo(obj)->dev);
if (i915_gem_object_is_userptr(obj)) {
drm_dbg(&i915->drm,
@@ -1897,7 +1897,7 @@ static int intel_user_framebuffer_create_handle(struct
drm_framebuffer *fb,
return -EINVAL;
}
- return drm_gem_handle_create(file, &obj->base, handle);
+ return drm_gem_handle_create(file, intel_bo_to_drm_bo(obj), handle);
}
struct frontbuffer_fence_cb {
@@ -1975,7 +1975,7 @@ int intel_framebuffer_init(struct intel_framebuffer
*intel_fb,
struct drm_i915_gem_object *obj,
struct drm_mode_fb_cmd2 *mode_cmd)
{
- struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
+ struct drm_i915_private *dev_priv =
to_i915(intel_bo_to_drm_bo(obj)->dev);
struct drm_framebuffer *fb = &intel_fb->base;
u32 max_stride;
unsigned int tiling, stride;
@@ -2153,7 +2153,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
}
fb = intel_framebuffer_create(obj, &mode_cmd);
- i915_gem_object_put(obj);
+ drm_gem_object_put(intel_bo_to_drm_bo(obj));
return fb;
}
--
2.34.1
[Intel-gfx] [PATCH v7 0/4] Prepare intel_fb for Xe
Intel fb creation is differing between Xe and i915 due to different implementations of backing object. This patch set is splitting i915 specific code into it's own source file. Similar source files will be introduced for Xe as well. Also use intel_bo_to_drm_bo instead of directly referring i915_gem_object->base. One i915_gem_object_put is changed to drm_gem_object_put. v7: - drop #include - s/user_mode_cmd/mode_cmd/ - Use passed i915 pointer instead of to_i915(obj->base.dev) v6: Add missing intel_fb_bo.[ch] v5: - Keep drm_any_plane_has_format check in intel_fb.c - Use mode_cmd instead of user_mode_cmd for intel_fb_bo_lookup_valid_bo - Use lookup_modifier_or_null in intel_fb_modifier_to_tiling and handle null value v4: Move drm_any_plane_has_format check into intel_fb_bo.c v3: Fix failure handling in intel_framebuffer_init v2: Couple of fixes to error value handling Cc: Rodrigo Vivi Cc: Maarten Lankhorst Cc: Jani Nikula Cc: Uma Shankar Jouni Högander (4): drm/i915/display: use intel_bo_to_drm_bo in intel_fb.c drm/i915/display: Convert intel_fb_modifier_to_tiling as non-static drm/i915/display: Handle invalid fb_modifier in intel_fb_modifier_to_tiling drm/i915/display: Split i915 specific code away from intel_fb.c drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_fb.c| 128 +++-- drivers/gpu/drm/i915/display/intel_fb.h| 2 + drivers/gpu/drm/i915/display/intel_fb_bo.c | 92 +++ drivers/gpu/drm/i915/display/intel_fb_bo.h | 24 5 files changed, 160 insertions(+), 87 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_fb_bo.c create mode 100644 drivers/gpu/drm/i915/display/intel_fb_bo.h -- 2.34.1
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Skip some timing checks on BXT/GLK DSI transcoders (rev2)
== Series Details ==
Series: series starting with [1/4] drm/i915: Skip some timing checks on BXT/GLK
DSI transcoders (rev2)
URL : https://patchwork.freedesktop.org/series/126923/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13934 -> Patchwork_126923v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/index.html
Participating hosts (37 -> 36)
--
Additional (1): fi-pnv-d510
Missing(2): bat-jsl-1 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_126923v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@basic:
- fi-pnv-d510:NOTRUN -> [SKIP][1] ([fdo#109271]) +25 other tests
skip
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/fi-pnv-d510/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][2] -> [ABORT][3] ([i915#7911])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13934/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][4] -> [DMESG-FAIL][5] ([i915#5334])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13934/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-5:
- bat-adlp-11:[PASS][6] -> [DMESG-FAIL][7] ([i915#6868])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13934/bat-adlp-11/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-5.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/bat-adlp-11/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-5.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-5:
- bat-adlp-11:[PASS][8] -> [FAIL][9] ([i915#9666])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13934/bat-adlp-11/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-5.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/bat-adlp-11/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-5.html
* igt@kms_pipe_crc_basic@read-crc@pipe-d-dp-5:
- bat-adlp-11:[PASS][10] -> [ABORT][11] ([i915#8668])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13934/bat-adlp-11/igt@kms_pipe_crc_basic@read-...@pipe-d-dp-5.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/bat-adlp-11/igt@kms_pipe_crc_basic@read-...@pipe-d-dp-5.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6868]: https://gitlab.freedesktop.org/drm/intel/issues/6868
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
[i915#9666]: https://gitlab.freedesktop.org/drm/intel/issues/9666
Build changes
-
* Linux: CI_DRM_13934 -> Patchwork_126923v2
CI-20190529: 20190529
CI_DRM_13934: 33e5d9fa840cd559e6a64564e2e286173275421f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7606: 44572f29eec746c345ff215e2d156e84ee00b520 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_126923v2: 33e5d9fa840cd559e6a64564e2e286173275421f @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
63d6dea74af4 drm/i915: Clean up some DISPLAY_VER checks
a4ad511e8c9e drm/i915/mst: Reject modes that require the bigjoiner
e5eaa8bc55d5 drm/i915/mst: Fix .mode_valid_ctx() return values
13e32f61a329 drm/i915: Skip some timing checks on BXT/GLK DSI transcoders
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126923v2/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915: Skip some timing checks on BXT/GLK DSI transcoders (rev2)
== Series Details == Series: series starting with [1/4] drm/i915: Skip some timing checks on BXT/GLK DSI transcoders (rev2) URL : https://patchwork.freedesktop.org/series/126923/ 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: failure for drm/i915/display: Skip state verification with TBT-ALT mode
== Series Details ==
Series: drm/i915/display: Skip state verification with TBT-ALT mode
URL : https://patchwork.freedesktop.org/series/126933/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13928 -> Patchwork_126933v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_126933v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_126933v1, please notify your bug team
(i915-ci-in...@lists.freedesktop.org) 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_126933v1/index.html
Participating hosts (36 -> 35)
--
Additional (1): bat-kbl-2
Missing(2): fi-snb-2520m fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_126933v1:
### IGT changes ###
Possible regressions
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-dp-5:
- bat-adlp-11:[PASS][1] -> [FAIL][2] +1 other test fail
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-dp-5.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-dp-5.html
Known issues
Here are the changes found in Patchwork_126933v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@info:
- bat-kbl-2: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1849])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-kbl-2/igt@fb...@info.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2: NOTRUN -> [SKIP][4] ([fdo#109271]) +20 other tests
skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence:
- bat-kbl-2: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1845]) +14
other tests skip
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-kbl-2/igt@kms_pipe_crc_ba...@read-crc-frame-sequence.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-c-dp-5:
- bat-adlp-11:[PASS][6] -> [FAIL][7] ([i915#9747])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-c-dp-5.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-c-dp-5.html
Possible fixes
* igt@kms_flip@basic-flip-vs-modeset@d-dp5:
- bat-adlp-11:[DMESG-FAIL][8] ([i915#6868]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html
* igt@kms_frontbuffer_tracking@basic:
- bat-adlp-11:[SKIP][10] ([i915#4342] / [i915#5354]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_frontbuffer_track...@basic.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@kms_flip@basic-flip-vs-modeset@a-dp6:
- bat-adlp-11:[FAIL][12] ([i915#6121]) -> [DMESG-FAIL][13]
([i915#6868])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@a-dp6.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@a-dp6.html
* igt@kms_hdmi_inject@inject-audio:
- bat-adlp-11:[FAIL][14] ([i915#9746]) -> [SKIP][15] ([i915#4369])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_hdmi_inj...@inject-audio.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_hdmi_inj...@inject-audio.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-a-dp-5:
- bat-adlp-11:[ABORT][16] ([i915#8668]) -> [ABORT][17] ([i915#6868]
/ [i915#8668])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13928/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-a-dp-5.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126933v1/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-a-dp-5.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=10
Re: [Intel-gfx] [PATCH] PCI: qcom: Fix compile error
On Tue, Nov 28, 2023 at 09:50:26AM +0530, Vignesh Raman wrote:
> Commit a2458d8f618a ("PCI/ASPM: pci_enable_link_state: Add argument
> to acquire bus lock") has added an argument to acquire bus lock
> in pci_enable_link_state, but qcom_pcie_enable_aspm calls it
> without this argument, resulting in below build error.
>
Where do you see this error? That patch is not even merged. Looks like you are
sending the patch against some downstream tree.
- Mani
> drivers/pci/controller/dwc/pcie-qcom.c:973:9: error: too few arguments to
> function 'pci_enable_link_state'
>
> This commit fixes the compilation error by passing the sem argument
> to pci_enable_link_state in the qcom_pcie_enable_aspm function.
>
> Signed-off-by: Vignesh Raman
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> b/drivers/pci/controller/dwc/pcie-qcom.c
> index 6902e97719d1..e846e3531d8e 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -970,7 +970,7 @@ static int qcom_pcie_enable_aspm(struct pci_dev *pdev,
> void *userdata)
> {
> /* Downstream devices need to be in D0 state before enabling PCI PM
> substates */
> pci_set_power_state(pdev, PCI_D0);
> - pci_enable_link_state(pdev, PCIE_LINK_STATE_ALL);
> + pci_enable_link_state(pdev, PCIE_LINK_STATE_ALL, false);
>
> return 0;
> }
> --
> 2.40.1
>
>
--
மணிவண்ணன் சதாசிவம்
[Intel-gfx] [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices
The problem: Accelerator driver developers are forced to reinvent external MM subsystems case by case, because Linux core MM only considers host memory resources. These reinvented MM subsystems have similar orders of magnitude of LoC as Linux MM (80K), e.g. Nvidia-UVM has 70K, AMD GPU has 14K and Huawei NPU has 30K. Meanwhile, more and more vendors are implementing their own accelerators, e.g. Microsoft's Maia 100. At the same time, application-level developers suffer from poor programmability -- they must consider parallel address spaces and be careful about the limited device DRAM capacity. This can be alleviated if a malloc()-ed virtual address can be shared by the accelerator, or the abundant host DRAM can further transparently backup the device local memory. These external MM systems share similar mechanisms except for the hardware-dependent part, so reinventing them is effectively introducing redundant code (14K~70K for each case). Such developing/maintaining is not cheap. Furthermore, to share a malloc()-ed virtual address, device drivers need to deeply interact with Linux MM via low-level MM APIs, e.g. MMU notifiers/HMM. This raises the bar for driver development, since developers must understand how Linux MM works. Further, it creates code maintenance problems -- any changes to Linux MM potentially require coordinated changes to accelerator drivers using low-level MM APIs. Putting a cache-coherent bus between host and device will not make these external MM subsystems disappear. For example, a throughput-oriented accelerator will not tolerate executing heavy memory access workload with a host MMU/IOMMU via a remote bus. Therefore, devices will still have their own MMU and pick a simpler page table format for lower address translation overhead, requiring external MM subsystems. What GMEM (Generalized Memory Management [1]) does: GMEM extends Linux MM to share its machine-independent MM code. Only high-level interface is provided for device drivers. This prevents accelerator drivers from reinventing the wheel, but relies on drivers to implement their hardware-dependent functions declared by GMEM. GMEM's key interface include gm_dev_create(), gm_as_create(), gm_as_attach() and gm_dev_register_physmem(). Here briefly describe how a device driver utilizes them: 1. At boot time, call gm_dev_create() and registers the implementation of hardware-dependent functions as declared in struct gm_mmu. - If the device has local DRAM, call gm_dev_register_physmem() to register available physical addresses. 2. When a device context is initialized (e.g. triggered by ioctl), check if the current CPU process has been attached to a gmem address space (struct gm_as). If not, call gm_as_create() and point current->mm->gm_as to it. 3. Call gm_as_attach() to attach the device context to a gmem address space. 4. Invoke gm_dev_fault() to resolve a page fault or prepare data before device computation happens. GMEM has changed the following assumptions in Linux MM: 1. An mm_struct not only handle a single CPU context, but may also handle external memory contexts encapsulated as gm_context listed in mm->gm_as. An external memory context can include a few or all of the following parts: an external MMU (that requires TLB invalidation), an external page table (that requires PTE manipulation) and external DRAM (that requires physical memory management). 2. Faulting a MAP_PRIVATE VMA with no CPU PTE found does not necessarily mean that a zero-filled physical page should be mapped. The virtual page may have been mapped to an external memory device. 3. Unmapping a page may include sending device TLB invalidation (even if its MMU shares CPU page table) and manipulating device PTEs. Semantics of new syscalls: 1. mmap(..., MAP_PRIVATE | MAP_PEER_SHARED) Allocate virtual address that is shared between the CPU and all attached devices. Data is guaranteed to be coherent whenever the address is accessed by either CPU or any attached device. If the device does not support page fault, then device driver is responsible for faulting memory before data gets accessed. By default, the CPU DRAM is can be used as a swap backup for the device local memory. 2. hmadvise(NUMA_id, va_start, size, memory_hint) Issuing memory hint for a given VMA. This extends traditional madvise() syscall with an extra argument so that programmers have better control with heterogeneous devices registered as NUMA nodes. One useful memory hint could be MADV_PREFETCH, which guarantees that the physical data of the given VMA [VA, VA+size) is migrated to NUMA node #id. Another useful memory hint is MADV_DONTNEED. This is helpful to increase device memory utilization. It is worth considering extending the existing madvise() syscall with one additional argument. Implementation det
[Intel-gfx] [RFC PATCH 6/6] mm/gmem: extending Linux core MM to support unified virtual address space
This patch extends Linux core MM to support unified virtual address space.
A unified virtual address space provides a coherent view of memory for the
CPU and devices. This is achieved by maintaining coherent page tables for
the CPU and any attached devices for each process, without assuming that
the underlying interconnect between the CPU and peripheral device is
cache-coherent.
Specifically, for each mm_struct that is attached with one or more device
computing contexts, a per-process logical page table is utilized to track
the mapping status of anonymous memory allocated via mmap(MAP_PRIVATE |
MAP_PEER_SHARED). The CPU page fault handling path is modified to examine
whether a faulted virtual page has already been faulted elsewhere, e.g. on
a device, by looking up the logical page table in vm_object. If so, a page
migration operation should be orchestrated by the core MM to prepare the
CPU physical page, instead of zero-filling. This is achieved by invoking
gm_host_fault_locked(). The logical page table must also be updated once
the CPU page table gets modified.
Ideally, the logical page table should always be looked up or modified
first if the CPU page table is changed, but the currently implementation is
reverse. Also, current implementation only considers anonymous memory,
while a device may want to operate on a disk-file directly via mmap(fd). In
the future, logical page table is planned to play a more generic role for
anonymous memory, folios/huge pages and file-backed memory, as well as to
provide a clean abstraction for CPU page table functions (including these
stage-2 functions). More, the page fault handler path will be enhanced to
deal with cache-coherent buses as well, since it might be desirable for
devices to operate sparse data remotely instead of migration data at page
granules.
Signed-off-by: Weixi Zhu
---
kernel/fork.c| 1 +
mm/huge_memory.c | 85 +++-
mm/memory.c | 42 +---
mm/mmap.c| 2 ++
mm/oom_kill.c| 2 ++
mm/vm_object.c | 84 +++
6 files changed, 203 insertions(+), 13 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index eab96cdb25a6..06130c73bf2e 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -543,6 +543,7 @@ static void vm_area_free_rcu_cb(struct rcu_head *head)
void vm_area_free(struct vm_area_struct *vma)
{
+ free_gm_mappings(vma);
#ifdef CONFIG_PER_VMA_LOCK
call_rcu(&vma->vm_rcu, vm_area_free_rcu_cb);
#else
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 4f542444a91f..59f63f04 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
@@ -684,6 +685,10 @@ static vm_fault_t __do_huge_pmd_anonymous_page(struct
vm_fault *vmf,
pgtable_t pgtable;
unsigned long haddr = vmf->address & HPAGE_PMD_MASK;
vm_fault_t ret = 0;
+ struct gm_mapping *gm_mapping = NULL;
+
+ if (vma_is_peer_shared(vma))
+ gm_mapping = vm_object_lookup(vma->vm_mm->vm_obj, haddr);
VM_BUG_ON_FOLIO(!folio_test_large(folio), folio);
@@ -691,7 +696,8 @@ static vm_fault_t __do_huge_pmd_anonymous_page(struct
vm_fault *vmf,
folio_put(folio);
count_vm_event(THP_FAULT_FALLBACK);
count_vm_event(THP_FAULT_FALLBACK_CHARGE);
- return VM_FAULT_FALLBACK;
+ ret = VM_FAULT_FALLBACK;
+ goto gm_mapping_release;
}
folio_throttle_swaprate(folio, gfp);
@@ -701,7 +707,14 @@ static vm_fault_t __do_huge_pmd_anonymous_page(struct
vm_fault *vmf,
goto release;
}
- clear_huge_page(page, vmf->address, HPAGE_PMD_NR);
+ /*
+* Skip zero-filling page if the logical mapping indicates
+* that page contains valid data of the virtual address. This
+* could happen if the page was a victim of device memory
+* oversubscription.
+*/
+ if (!(vma_is_peer_shared(vma) && gm_mapping_cpu(gm_mapping)))
+ clear_huge_page(page, vmf->address, HPAGE_PMD_NR);
/*
* The memory barrier inside __folio_mark_uptodate makes sure that
* clear_huge_page writes become visible before the set_pmd_at()
@@ -726,7 +739,7 @@ static vm_fault_t __do_huge_pmd_anonymous_page(struct
vm_fault *vmf,
pte_free(vma->vm_mm, pgtable);
ret = handle_userfault(vmf, VM_UFFD_MISSING);
VM_BUG_ON(ret & VM_FAULT_FALLBACK);
- return ret;
+ goto gm_mapping_release;
}
entry = mk_huge_pmd(page, vma->vm_page_prot);
@@ -734,6 +747,13 @@ static vm_fault_t __do_huge_pmd_anonymous_page(struct
vm_fault *vmf,
folio_add_new_anon_rmap(folio, vma, haddr);
folio_add_lru_vma(folio, vma);
[Intel-gfx] [RFC PATCH 3/6] mm/gmem: add GMEM (Generalized Memory Management) interface for external accelerators
Accelerator driver developers are forced to reinvent external MM subsystems
case by case, introducing redundant code (14K~70K for each case). This is
because Linux core MM only considers host memory resources. At the same
time, application-level developers suffer from poor programmability -- they
must consider parallel address spaces and be careful about the limited
device DRAM capacity.
This patch adds GMEM interface to help accelerator drivers directly reuse
Linux core MM, preventing them from reinventing the wheel. Drivers which
utilize GMEM interface can directly support unified virtual address spaces
for application users -- memory allocated with malloc()/mmap() can be
directly used by either CPU and accelerators, providing a coherent view of
memory.
The GMEM device interface prefixed with "gm_dev" is used to decouple
accelerator-specific operations. Device drivers should invoke
gm_dev_create() to register a device instance at the device boot time. A
device-specific implementation of "struct gm_mmu" must be provided, so
Linux can invoke hardware-related functions at the right time. If the
driver wants Linux to take charge of the local DRAM of the accelerator,
then it should register a range of physical addresses to be managed by
gm_dev_register_physmem().
The GMEM address space interface prefixed with "gm_as" is used to connect a
device context with a CPU context, i.e. an mm_struct. Struct gm_as is
created as a unified address space that not only includes a CPU context,
but may also include one or more device contexts. Device driver should
utilize gm_as_attach() to include a device context to a created struct
gm_as. Then gm_dev_fault() can then serve as a generic device page fault
handler. It is important that a device driver invokes gm_as_attach() at the
beginning of a CPU program. This invocation can happen inside an ioctl()
call when a device context is initialized.
Signed-off-by: Weixi Zhu
---
include/linux/gmem.h | 196 +++
include/linux/mm_types.h | 1 +
mm/gmem.c| 408 +++
3 files changed, 605 insertions(+)
diff --git a/include/linux/gmem.h b/include/linux/gmem.h
index 529ff6755a99..f424225daa03 100644
--- a/include/linux/gmem.h
+++ b/include/linux/gmem.h
@@ -13,6 +13,35 @@
#ifdef CONFIG_GMEM
+#define GMEM_MMAP_RETRY_TIMES 10 /* gmem retry times before OOM */
+
+DECLARE_STATIC_KEY_FALSE(gmem_status);
+
+static inline bool gmem_is_enabled(void)
+{
+ return static_branch_likely(&gmem_status);
+}
+
+struct gm_dev {
+ int id;
+
+ /*
+* TODO: define more device capabilities and consider different device
+* base page sizes
+*/
+ unsigned long capability;
+ struct gm_mmu *mmu;
+ void *dev_data;
+ /* A device may support time-sliced context switch. */
+ struct gm_context *current_ctx;
+
+ struct list_head gm_ctx_list;
+
+ /* Add tracking of registered device local physical memory. */
+ nodemask_t registered_hnodes;
+ struct device *dma_dev;
+};
+
#define GM_PAGE_CPU0x10 /* Determines whether page is a pointer or a pfn
number. */
#define GM_PAGE_DEVICE 0x20
#define GM_PAGE_NOMAP 0x40
@@ -96,7 +125,161 @@ void unmap_gm_mappings_range(struct vm_area_struct *vma,
unsigned long start,
unsigned long end);
void munmap_in_peer_devices(struct mm_struct *mm, unsigned long start,
unsigned long end);
+
+/* core gmem */
+enum gm_ret {
+ GM_RET_SUCCESS = 0,
+ GM_RET_NOMEM,
+ GM_RET_PAGE_EXIST,
+ GM_RET_MIGRATING,
+ GM_RET_FAILURE_UNKNOWN,
+};
+
+/**
+ * enum gm_mmu_mode - defines the method to share a physical page table.
+ *
+ * @GM_MMU_MODE_SHARE: Share a physical page table with another attached
+ * device's MMU, requiring one of the attached MMUs to be compatible. For
+ * example, the IOMMU is compatible with the CPU MMU on most modern machines.
+ * This mode requires the device physical memory to be cache-coherent.
+ * TODO: add MMU cookie to detect compatible MMUs.
+ *
+ * @GM_MMU_MODE_COHERENT_EXCLUSIVE: Maintain a coherent page table that holds
+ * exclusive mapping entries, so that device memory accesses can trigger
+ * fault-driven migration for automatic data locality optimizations.
+ * This mode does not require a cache-coherent link between the CPU and device.
+ *
+ * @GM_MMU_MODE_REPLICATE: Maintain a coherent page table that replicates
+ * physical mapping entries whenever a physical mapping is installed inside the
+ * address space, so that it may minimize the page faults to be triggered by
+ * this device.
+ * This mode requires the device physical memory to be cache-coherent.
+ */
+enum gm_mmu_mode {
+ GM_MMU_MODE_SHARE,
+ GM_MMU_MODE_COHERENT_EXCLUSIVE,
+ GM_MMU_MODE_REPLICATE,
+};
+
+enum gm_fault_hint {
+ GM_FAULT_HINT_MARK_HOT,
+ /*
+* TODO: introduce other fault hints, e.g. read-on
Re: [Intel-gfx] [PATCH] PCI: qcom: Fix compile error
Hi Mani,
On 28/11/23 10:44, Manivannan Sadhasivam wrote:
On Tue, Nov 28, 2023 at 09:50:26AM +0530, Vignesh Raman wrote:
Commit a2458d8f618a ("PCI/ASPM: pci_enable_link_state: Add argument
to acquire bus lock") has added an argument to acquire bus lock
in pci_enable_link_state, but qcom_pcie_enable_aspm calls it
without this argument, resulting in below build error.
Where do you see this error? That patch is not even merged. Looks like you are
sending the patch against some downstream tree.
I got this error with drm-tip - git://anongit.freedesktop.org/drm-tip
This commit is merged in drm-intel/topic/core-for-CI -
https://cgit.freedesktop.org/drm-intel/log/?h=topic/core-for-CI
Regards,
Vignesh
[Intel-gfx] [RFC PATCH 4/6] mm/gmem: add new syscall hmadvise() to issue memory hints for heterogeneous NUMA nodes
This patch adds a new syscall, hmadvise(), to issue memory hints for
heterogeneous NUMA nodes. The new syscall effectively extends madvise()
with one additional argument that indicates the NUMA id of a heterogeneous
device, which is not necessarily accessible by the CPU.
The implemented memory hint is MADV_PREFETCH, which guarantees that the
physical data of the given VMA [VA, VA+size) is migrated to a designated
NUMA id, so subsequent accesses from the corresponding device can obtain
local memory access speed. This prefetch hint is internally parallized with
multiple workqueue threads, allowing the page table management to be
overlapped. In a test with Huawei's Ascend NPU card, the MADV_PREFETCH is
able to saturate the host-device bandwidth if the given VMA size is larger
than 16MB.
Signed-off-by: Weixi Zhu
---
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
include/linux/gmem.h| 9 +
include/uapi/asm-generic/mman-common.h | 3 +
include/uapi/asm-generic/unistd.h | 5 +-
kernel/sys_ni.c | 2 +
mm/gmem.c | 222
tools/include/uapi/asm-generic/unistd.h | 5 +-
8 files changed, 247 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
index 531effca5f1f..298313d2e0af 100644
--- a/arch/arm64/include/asm/unistd.h
+++ b/arch/arm64/include/asm/unistd.h
@@ -39,7 +39,7 @@
#define __ARM_NR_compat_set_tls(__ARM_NR_COMPAT_BASE + 5)
#define __ARM_NR_COMPAT_END(__ARM_NR_COMPAT_BASE + 0x800)
-#define __NR_compat_syscalls 457
+#define __NR_compat_syscalls 458
#endif
#define __ARCH_WANT_SYS_CLONE
diff --git a/arch/arm64/include/asm/unistd32.h
b/arch/arm64/include/asm/unistd32.h
index 9f7c1bf99526..0d44383b98be 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -919,6 +919,8 @@ __SYSCALL(__NR_futex_wake, sys_futex_wake)
__SYSCALL(__NR_futex_wait, sys_futex_wait)
#define __NR_futex_requeue 456
__SYSCALL(__NR_futex_requeue, sys_futex_requeue)
+#define __NR_hmadvise 457
+__SYSCALL(__NR_hmadvise, sys_hmadvise)
/*
* Please add new compat syscalls above this comment and update
diff --git a/include/linux/gmem.h b/include/linux/gmem.h
index f424225daa03..97186f29638d 100644
--- a/include/linux/gmem.h
+++ b/include/linux/gmem.h
@@ -22,6 +22,11 @@ static inline bool gmem_is_enabled(void)
return static_branch_likely(&gmem_status);
}
+static inline bool vma_is_peer_shared(struct vm_area_struct *vma)
+{
+ return false;
+}
+
struct gm_dev {
int id;
@@ -280,6 +285,10 @@ int gm_as_attach(struct gm_as *as, struct gm_dev *dev,
enum gm_mmu_mode mode,
bool activate, struct gm_context **out_ctx);
#else
static inline bool gmem_is_enabled(void) { return false; }
+static inline bool vma_is_peer_shared(struct vm_area_struct *vma)
+{
+ return false;
+}
static inline void hnuma_init(void) {}
static inline void __init vm_object_init(void)
{
diff --git a/include/uapi/asm-generic/mman-common.h
b/include/uapi/asm-generic/mman-common.h
index 6ce1f1ceb432..49b22a497c5d 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -79,6 +79,9 @@
#define MADV_COLLAPSE 25 /* Synchronous hugepage collapse */
+/* for hmadvise */
+#define MADV_PREFETCH 26 /* prefetch pages for hNUMA node */
+
/* compatibility flags */
#define MAP_FILE 0
diff --git a/include/uapi/asm-generic/unistd.h
b/include/uapi/asm-generic/unistd.h
index 756b013fb832..a0773d4f7fa5 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -829,8 +829,11 @@ __SYSCALL(__NR_futex_wait, sys_futex_wait)
#define __NR_futex_requeue 456
__SYSCALL(__NR_futex_requeue, sys_futex_requeue)
+#define __NR_hmadvise 453
+__SYSCALL(__NR_hmadvise, sys_hmadvise)
+
#undef __NR_syscalls
-#define __NR_syscalls 457
+#define __NR_syscalls 458
/*
* 32 bit systems traditionally used different
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index e1a6e3c675c0..73bc1b35b8c6 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -374,3 +374,5 @@ COND_SYSCALL(setuid16);
/* restartable sequence */
COND_SYSCALL(rseq);
+
+COND_SYSCALL(hmadvise);
diff --git a/mm/gmem.c b/mm/gmem.c
index b95b6b42ed6d..4eb522026a0d 100644
--- a/mm/gmem.c
+++ b/mm/gmem.c
@@ -9,6 +9,8 @@
#include
#include
#include
+#include
+#include
DEFINE_STATIC_KEY_FALSE(gmem_status);
EXPORT_SYMBOL_GPL(gmem_status);
@@ -484,3 +486,223 @@ int gm_as_attach(struct gm_as *as, struct gm_dev *dev,
enum gm_mmu_mode mode,
return GM_RET_SUCCESS;
}
EXPORT_SYMBOL_GPL(gm_as_attach);
+
+struct prefetch_data {
+ struct mm_struct *mm;
+ struct gm_dev *dev;
+ unsigned long addr;
+ size_t size;
+ struct work_struct work;
[Intel-gfx] [PATCH] PCI: qcom: Fix compile error
Commit a2458d8f618a ("PCI/ASPM: pci_enable_link_state: Add argument
to acquire bus lock") has added an argument to acquire bus lock
in pci_enable_link_state, but qcom_pcie_enable_aspm calls it
without this argument, resulting in below build error.
drivers/pci/controller/dwc/pcie-qcom.c:973:9: error: too few arguments to
function 'pci_enable_link_state'
This commit fixes the compilation error by passing the sem argument
to pci_enable_link_state in the qcom_pcie_enable_aspm function.
Signed-off-by: Vignesh Raman
---
drivers/pci/controller/dwc/pcie-qcom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
b/drivers/pci/controller/dwc/pcie-qcom.c
index 6902e97719d1..e846e3531d8e 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -970,7 +970,7 @@ static int qcom_pcie_enable_aspm(struct pci_dev *pdev, void
*userdata)
{
/* Downstream devices need to be in D0 state before enabling PCI PM
substates */
pci_set_power_state(pdev, PCI_D0);
- pci_enable_link_state(pdev, PCIE_LINK_STATE_ALL);
+ pci_enable_link_state(pdev, PCIE_LINK_STATE_ALL, false);
return 0;
}
--
2.40.1
Re: [Intel-gfx] [PATCH] PCI: qcom: Fix compile error
On Tue, Nov 28, 2023 at 11:44:26AM +0530, Vignesh Raman wrote:
> Hi Mani,
>
> On 28/11/23 10:44, Manivannan Sadhasivam wrote:
> > On Tue, Nov 28, 2023 at 09:50:26AM +0530, Vignesh Raman wrote:
> > > Commit a2458d8f618a ("PCI/ASPM: pci_enable_link_state: Add argument
> > > to acquire bus lock") has added an argument to acquire bus lock
> > > in pci_enable_link_state, but qcom_pcie_enable_aspm calls it
> > > without this argument, resulting in below build error.
> > >
> >
> > Where do you see this error? That patch is not even merged. Looks like you
> > are
> > sending the patch against some downstream tree.
>
> I got this error with drm-tip - git://anongit.freedesktop.org/drm-tip
>
> This commit is merged in drm-intel/topic/core-for-CI -
> https://cgit.freedesktop.org/drm-intel/log/?h=topic/core-for-CI
>
Okay. Since this patch is just for CI, please do not CC linux-pci as it causes
confusion.
- Mani
> Regards,
> Vignesh
--
மணிவண்ணன் சதாசிவம்
[Intel-gfx] [RFC PATCH 1/6] mm/gmem: add heterogeneous NUMA node
This patch adds a new NUMA node state, named N_HETEROGENEOUS. It is
utilized to identify heterogeneous NUMA (hNUMA) node. Note that hNUMA node
may not be directly accessible by the CPU.
Each hNUMA node can be identified with a NUMA id. This can be extended to
provide NUMA topology including device local DRAM, where a cache-coherent
bus does not need to exist between the CPU and device local DRAM.
Furthermore, this allows an application user to issue memory hints that
bind with specific hNUMA nodes.
Signed-off-by: Weixi Zhu
---
drivers/base/node.c | 6
include/linux/gmem.h | 19 ++
include/linux/nodemask.h | 10 ++
init/main.c | 2 ++
mm/Kconfig | 14
mm/Makefile | 1 +
mm/gmem.c| 78
mm/page_alloc.c | 3 ++
8 files changed, 133 insertions(+)
create mode 100644 include/linux/gmem.h
create mode 100644 mm/gmem.c
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 493d533f8375..aa4d2ca266aa 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -928,6 +928,9 @@ static struct node_attr node_state_attr[] = {
[N_CPU] = _NODE_ATTR(has_cpu, N_CPU),
[N_GENERIC_INITIATOR] = _NODE_ATTR(has_generic_initiator,
N_GENERIC_INITIATOR),
+#ifdef CONFIG_GMEM
+ [N_HETEROGENEOUS] = _NODE_ATTR(has_hetero_memory, N_HETEROGENEOUS),
+#endif
};
static struct attribute *node_state_attrs[] = {
@@ -940,6 +943,9 @@ static struct attribute *node_state_attrs[] = {
&node_state_attr[N_MEMORY].attr.attr,
&node_state_attr[N_CPU].attr.attr,
&node_state_attr[N_GENERIC_INITIATOR].attr.attr,
+#ifdef CONFIG_GMEM
+ &node_state_attr[N_HETEROGENEOUS].attr.attr,
+#endif
NULL
};
diff --git a/include/linux/gmem.h b/include/linux/gmem.h
new file mode 100644
index ..fff877873557
--- /dev/null
+++ b/include/linux/gmem.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Generalized Memory Management.
+ *
+ * Copyright (C) 2023- Huawei, Inc.
+ * Author: Weixi Zhu
+ *
+ */
+#ifndef _GMEM_H
+#define _GMEM_H
+
+#ifdef CONFIG_GMEM
+/* h-NUMA topology */
+void __init hnuma_init(void);
+#else
+static inline void hnuma_init(void) {}
+#endif
+
+#endif /* _GMEM_H */
diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
index 8d07116caaf1..66e4640a52ba 100644
--- a/include/linux/nodemask.h
+++ b/include/linux/nodemask.h
@@ -407,6 +407,9 @@ enum node_states {
N_MEMORY, /* The node has memory(regular, high, movable)
*/
N_CPU, /* The node has one or more cpus */
N_GENERIC_INITIATOR,/* The node has one or more Generic Initiators
*/
+#ifdef CONFIG_GMEM
+ N_HETEROGENEOUS,/* The node has heterogeneous memory */
+#endif
NR_NODE_STATES
};
@@ -536,6 +539,13 @@ static inline int node_random(const nodemask_t *maskp)
#define for_each_node(node) for_each_node_state(node, N_POSSIBLE)
#define for_each_online_node(node) for_each_node_state(node, N_ONLINE)
+#ifdef CONFIG_GMEM
+/* For h-NUMA topology */
+#define hnode_map node_states[N_HETEROGENEOUS]
+#define num_hnodes() num_node_state(N_HETEROGENEOUS)
+#define for_each_hnode(node) for_each_node_state(node, N_HETEROGENEOUS)
+#endif
+
/*
* For nodemask scratch area.
* NODEMASK_ALLOC(type, name) allocates an object with a specified type and
diff --git a/init/main.c b/init/main.c
index e24b0780fdff..12dfb5b63d51 100644
--- a/init/main.c
+++ b/init/main.c
@@ -100,6 +100,7 @@
#include
#include
#include
+#include
#include
#include
@@ -901,6 +902,7 @@ void start_kernel(void)
setup_per_cpu_areas();
smp_prepare_boot_cpu(); /* arch-specific boot-cpu hooks */
boot_cpu_hotplug_init();
+ hnuma_init();
pr_notice("Kernel command line: %s\n", saved_command_line);
/* parameters may set static keys */
diff --git a/mm/Kconfig b/mm/Kconfig
index 89971a894b60..1a7d8194513c 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -1270,6 +1270,20 @@ config LOCK_MM_AND_FIND_VMA
bool
depends on !STACK_GROWSUP
+config GMEM
+ bool "generalized memory management for external memory devices"
+ depends on (ARM64 || X86_64) && MMU && TRANSPARENT_HUGEPAGE
+ select ARCH_USES_HIGH_VMA_FLAGS
+ default y
+ help
+ Supporting GMEM (generalized memory management) for external memory
+ devices
+
+ GMEM extends Linux MM to share its machine-independent MM code. Only
+ high-level interface is provided for device drivers. This prevents
+ accelerator drivers from reinventing the wheel, but relies on drivers
to
+ implement their hardware-dependent functions declared by GMEM.
+
source "mm/damon/Kconfig"
endmenu
diff --git a/mm/Makefile b/mm/Makefile
index 33873c8aedb3..f48ea2eb4a44 100644
--- a/mm/Makefi
[Intel-gfx] [RFC PATCH 5/6] mm/gmem: resolve VMA conflicts for attached peer devices
This patch resolves potential VMA conflicts when
mmap(MAP_PRIVATE | MAP_PEER_SHARED) is invoked. Note that the semantic of
mmap(MAP_PRIVATE | MAP_PEER_SHARED) is to provide a coherent view of memory
through the allocated virtual addresses between the CPU and all attached
devices. However, an attached device may create its own computing context
that does not necessarily share the same address space layout with the CPU
process. Therefore, the mmap() syscall must return virtual addresses that
are guaranteed to be valid across all attached peer devices.
In current implementation, if a candidate VMA is detected to be
conflicting, it will be temporarily blacklisted. The mmap_region()
function will retry other VMA candidates for a predefined number of
iterations.
Signed-off-by: Weixi Zhu
---
fs/proc/task_mmu.c | 3 ++
include/linux/gmem.h | 26 +++-
include/linux/mm.h | 8 +
include/uapi/asm-generic/mman-common.h | 1 +
kernel/fork.c | 4 +++
mm/gmem.c | 38
mm/mempolicy.c | 4 +++
mm/mmap.c | 38 ++--
mm/vm_object.c | 41 ++
9 files changed, 159 insertions(+), 4 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index ef2eb12906da..5af03d8f0319 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -701,6 +701,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct
vm_area_struct *vma)
#endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
#ifdef CONFIG_X86_USER_SHADOW_STACK
[ilog2(VM_SHADOW_STACK)] = "ss",
+#endif
+#ifdef CONFIG_GMEM
+ [ilog2(VM_PEER_SHARED)] = "ps",
#endif
};
size_t i;
diff --git a/include/linux/gmem.h b/include/linux/gmem.h
index 97186f29638d..82d88df5ce44 100644
--- a/include/linux/gmem.h
+++ b/include/linux/gmem.h
@@ -24,7 +24,10 @@ static inline bool gmem_is_enabled(void)
static inline bool vma_is_peer_shared(struct vm_area_struct *vma)
{
- return false;
+ if (!gmem_is_enabled())
+ return false;
+
+ return !!(vma->vm_flags & VM_PEER_SHARED);
}
struct gm_dev {
@@ -130,6 +133,8 @@ void unmap_gm_mappings_range(struct vm_area_struct *vma,
unsigned long start,
unsigned long end);
void munmap_in_peer_devices(struct mm_struct *mm, unsigned long start,
unsigned long end);
+void gm_reserve_vma(struct vm_area_struct *value, struct list_head *head);
+void gm_release_vma(struct mm_struct *mm, struct list_head *head);
/* core gmem */
enum gm_ret {
@@ -283,6 +288,10 @@ int gm_as_create(unsigned long begin, unsigned long end,
struct gm_as **new_as);
int gm_as_destroy(struct gm_as *as);
int gm_as_attach(struct gm_as *as, struct gm_dev *dev, enum gm_mmu_mode mode,
bool activate, struct gm_context **out_ctx);
+
+int gm_alloc_va_in_peer_devices(struct mm_struct *mm,
+ struct vm_area_struct *vma, unsigned long addr,
+ unsigned long len, vm_flags_t vm_flags);
#else
static inline bool gmem_is_enabled(void) { return false; }
static inline bool vma_is_peer_shared(struct vm_area_struct *vma)
@@ -339,6 +348,21 @@ int gm_as_attach(struct gm_as *as, struct gm_dev *dev,
enum gm_mmu_mode mode,
{
return 0;
}
+static inline void gm_reserve_vma(struct vm_area_struct *value,
+ struct list_head *head)
+{
+}
+static inline void gm_release_vma(struct mm_struct *mm, struct list_head *head)
+{
+}
+static inline int gm_alloc_va_in_peer_devices(struct mm_struct *mm,
+ struct vm_area_struct *vma,
+ unsigned long addr,
+ unsigned long len,
+ vm_flags_t vm_flags)
+{
+ return 0;
+}
#endif
#endif /* _GMEM_H */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 418d26608ece..8837624e4c66 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -320,14 +320,22 @@ extern unsigned int kobjsize(const void *objp);
#define VM_HIGH_ARCH_BIT_3 35 /* bit only usable on 64-bit
architectures */
#define VM_HIGH_ARCH_BIT_4 36 /* bit only usable on 64-bit
architectures */
#define VM_HIGH_ARCH_BIT_5 37 /* bit only usable on 64-bit
architectures */
+#define VM_HIGH_ARCH_BIT_6 38 /* bit only usable on 64-bit
architectures */
#define VM_HIGH_ARCH_0 BIT(VM_HIGH_ARCH_BIT_0)
#define VM_HIGH_ARCH_1 BIT(VM_HIGH_ARCH_BIT_1)
#define VM_HIGH_ARCH_2 BIT(VM_HIGH_ARCH_BIT_2)
#define VM_HIGH_ARCH_3 BIT(VM_HIGH_ARCH_BIT_3)
#define VM_HIGH_ARCH_4 BIT(VM_HIGH_ARCH_BIT_4)
#define VM_HIGH_ARCH_5 BIT(VM_HIGH_ARCH_BIT_5)
+#define VM_HIGH_ARCH_6 BIT(VM_HIGH_A
[Intel-gfx] [RFC PATCH 2/6] mm/gmem: add arch-independent abstraction to track address mapping status
This patch adds an abstraction layer, struct vm_object, that maintains
per-process virtual-to-physical mapping status stored in struct gm_mapping.
For example, a virtual page may be mapped to a CPU physical page or to a
device physical page. Struct vm_object effectively maintains an
arch-independent page table, which is defined as a "logical page table".
While arch-dependent page table used by a real MMU is named a "physical
page table". The logical page table is useful if Linux core MM is extended
to handle a unified virtual address space with external accelerators using
customized MMUs.
In this patch, struct vm_object utilizes a radix
tree (xarray) to track where a virtual page is mapped to. This adds extra
memory consumption from xarray, but provides a nice abstraction to isolate
mapping status from the machine-dependent layer (PTEs). Besides supporting
accelerators with external MMUs, struct vm_object is planned to further
union with i_pages in struct address_mapping for file-backed memory.
The idea of struct vm_object is originated from FreeBSD VM design, which
provides a unified abstraction for anonymous memory, file-backed memory,
page cache and etc[1].
Currently, Linux utilizes a set of hierarchical page walk functions to
abstract page table manipulations of different CPU architecture. The
problem happens when a device wants to reuse Linux MM code to manage its
page table -- the device page table may not be accessible to the CPU.
Existing solution like Linux HMM utilizes the MMU notifier mechanisms to
invoke device-specific MMU functions, but relies on encoding the mapping
status on the CPU page table entries. This entangles machine-independent
code with machine-dependent code, and also brings unnecessary restrictions.
The PTE size and format vary arch by arch, which harms the extensibility.
[1] https://docs.freebsd.org/en/articles/vm-design/
Signed-off-by: Weixi Zhu
---
include/linux/gmem.h | 120 +
include/linux/mm_types.h | 4 +
mm/Makefile | 2 +-
mm/vm_object.c | 184 +++
4 files changed, 309 insertions(+), 1 deletion(-)
create mode 100644 mm/vm_object.c
diff --git a/include/linux/gmem.h b/include/linux/gmem.h
index fff877873557..529ff6755a99 100644
--- a/include/linux/gmem.h
+++ b/include/linux/gmem.h
@@ -9,11 +9,131 @@
#ifndef _GMEM_H
#define _GMEM_H
+#include
+
#ifdef CONFIG_GMEM
+
+#define GM_PAGE_CPU0x10 /* Determines whether page is a pointer or a pfn
number. */
+#define GM_PAGE_DEVICE 0x20
+#define GM_PAGE_NOMAP 0x40
+#define GM_PAGE_WILLNEED 0x80
+
+#define GM_PAGE_TYPE_MASK (GM_PAGE_CPU | GM_PAGE_DEVICE | GM_PAGE_NOMAP)
+
+struct gm_mapping {
+ unsigned int flag;
+
+ union {
+ struct page *page; /* CPU node */
+ struct gm_dev *dev; /* hetero-node. TODO: support multiple
devices */
+ unsigned long pfn;
+ };
+
+ struct mutex lock;
+};
+
+static inline void gm_mapping_flags_set(struct gm_mapping *gm_mapping, int
flags)
+{
+ if (flags & GM_PAGE_TYPE_MASK)
+ gm_mapping->flag &= ~GM_PAGE_TYPE_MASK;
+
+ gm_mapping->flag |= flags;
+}
+
+static inline void gm_mapping_flags_clear(struct gm_mapping *gm_mapping, int
flags)
+{
+ gm_mapping->flag &= ~flags;
+}
+
+static inline bool gm_mapping_cpu(struct gm_mapping *gm_mapping)
+{
+ return !!(gm_mapping->flag & GM_PAGE_CPU);
+}
+
+static inline bool gm_mapping_device(struct gm_mapping *gm_mapping)
+{
+ return !!(gm_mapping->flag & GM_PAGE_DEVICE);
+}
+
+static inline bool gm_mapping_nomap(struct gm_mapping *gm_mapping)
+{
+ return !!(gm_mapping->flag & GM_PAGE_NOMAP);
+}
+
+static inline bool gm_mapping_willneed(struct gm_mapping *gm_mapping)
+{
+ return !!(gm_mapping->flag & GM_PAGE_WILLNEED);
+}
+
/* h-NUMA topology */
void __init hnuma_init(void);
+
+/* vm object */
+/*
+ * Each per-process vm_object tracks the mapping status of virtual pages from
+ * all VMAs mmap()-ed with MAP_PRIVATE | MAP_PEER_SHARED.
+ */
+struct vm_object {
+ spinlock_t lock;
+
+ /*
+* The logical_page_table is a container that holds the mapping
+* information between a VA and a struct page.
+*/
+ struct xarray *logical_page_table;
+ atomic_t nr_pages;
+};
+
+int __init vm_object_init(void);
+struct vm_object *vm_object_create(struct mm_struct *mm);
+void vm_object_drop_locked(struct mm_struct *mm);
+
+struct gm_mapping *alloc_gm_mapping(void);
+void free_gm_mappings(struct vm_area_struct *vma);
+struct gm_mapping *vm_object_lookup(struct vm_object *obj, unsigned long va);
+void vm_object_mapping_create(struct vm_object *obj, unsigned long start);
+void unmap_gm_mappings_range(struct vm_area_struct *vma, unsigned long start,
+unsigned long end);
+void munmap_in_peer_devices(struct mm_struct *mm, unsigned long start,
+ u
Re: [Intel-gfx] [PATCH 2/2] drm/amdgpu: use GTT only as fallback for VRAM|GTT
[AMD Official Use Only - General] -Original Message- From: amd-gfx On Behalf Of Hamza Mahfooz Sent: Monday, November 27, 2023 10:53 AM To: Christian König ; jani.nik...@linux.intel.com; kher...@redhat.com; d...@redhat.com; za...@vmware.com; Olsak, Marek ; linux-graphics-maintai...@vmware.com; amd-...@lists.freedesktop.org; nouv...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; virtualizat...@lists.linux.dev; spice-de...@lists.freedesktop.org; dri-de...@lists.freedesktop.org Subject: Re: [PATCH 2/2] drm/amdgpu: use GTT only as fallback for VRAM|GTT On 11/27/23 09:54, Christian König wrote: > Try to fill up VRAM as well by setting the busy flag on GTT allocations. > > This fixes the issue that when VRAM was evacuated for suspend it's > never filled up again unless the application is restarted. I found the subject description a bit misleading. Maybe use a Fixes tag describing it is a fix for suspend resume regression other than that, looks good to me. Acked-by: Rajneesh Bhardwaj > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2893 > Signed-off-by: Christian König > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > index aa0dd6dad068..ddc8fb4db678 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > @@ -173,6 +173,12 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo > *abo, u32 domain) > abo->flags & AMDGPU_GEM_CREATE_PREEMPTIBLE ? > AMDGPU_PL_PREEMPT : TTM_PL_TT; > places[c].flags = 0; > + /* > + * When GTT is just an alternative to VRAM make sure that we > + * only use it as fallback and still try to fill up VRAM first. > + */ > + if (domain & AMDGPU_GEM_DOMAIN_VRAM) > + places[c].flags |= TTM_PL_FLAG_BUSY; > c++; > } > -- Hamza
Re: [Intel-gfx] [PATCH] PCI: qcom: Fix compile error
On 28/11/23 12:21, Manivannan Sadhasivam wrote:
On Tue, Nov 28, 2023 at 11:44:26AM +0530, Vignesh Raman wrote:
Hi Mani,
On 28/11/23 10:44, Manivannan Sadhasivam wrote:
On Tue, Nov 28, 2023 at 09:50:26AM +0530, Vignesh Raman wrote:
Commit a2458d8f618a ("PCI/ASPM: pci_enable_link_state: Add argument
to acquire bus lock") has added an argument to acquire bus lock
in pci_enable_link_state, but qcom_pcie_enable_aspm calls it
without this argument, resulting in below build error.
Where do you see this error? That patch is not even merged. Looks like you are
sending the patch against some downstream tree.
I got this error with drm-tip - git://anongit.freedesktop.org/drm-tip
This commit is merged in drm-intel/topic/core-for-CI -
https://cgit.freedesktop.org/drm-intel/log/?h=topic/core-for-CI
Okay. Since this patch is just for CI, please do not CC linux-pci as it causes
confusion.
Sure, thank you.
Jani, is this fix required for topic/core-for-CI ?
Regards,
Vignesh
Re: [Intel-gfx] [PATCH] PCI: qcom: Fix compile error
On Tue, Nov 28, 2023 at 12:39:02PM +0200, Jani Nikula wrote:
> On Tue, 28 Nov 2023, Manivannan Sadhasivam
> wrote:
> > On Tue, Nov 28, 2023 at 11:44:26AM +0530, Vignesh Raman wrote:
> >> Hi Mani,
> >>
> >> On 28/11/23 10:44, Manivannan Sadhasivam wrote:
> >> > On Tue, Nov 28, 2023 at 09:50:26AM +0530, Vignesh Raman wrote:
> >> > > Commit a2458d8f618a ("PCI/ASPM: pci_enable_link_state: Add argument
> >> > > to acquire bus lock") has added an argument to acquire bus lock
> >> > > in pci_enable_link_state, but qcom_pcie_enable_aspm calls it
> >> > > without this argument, resulting in below build error.
> >> > >
> >> >
> >> > Where do you see this error? That patch is not even merged. Looks like
> >> > you are
> >> > sending the patch against some downstream tree.
> >>
> >> I got this error with drm-tip - git://anongit.freedesktop.org/drm-tip
> >>
> >> This commit is merged in drm-intel/topic/core-for-CI -
> >> https://cgit.freedesktop.org/drm-intel/log/?h=topic/core-for-CI
> >>
> >
> > Okay. Since this patch is just for CI, please do not CC linux-pci as it
> > causes
> > confusion.
>
> Agreed. More on-topic for linux-pci is what happened with [1].
>
> We've been running CI with that for months now to avoid lockdep splats,
> and it's obviously in everyone's best interest to get a fix upstream.
>
Yes, ofc. Right now we have 2 series/patches to fix the locking issue:
https://lore.kernel.org/all/20230321233849.3408339-1-david.e@linux.intel.com/
https://lore.kernel.org/linux-pci/20231128081512.19387-1-johan+lin...@kernel.org/
Bjorn has to choose one among them.
- Mani
> David, Bjorn?
>
>
> BR,
> Jani.
>
>
> [1]
> https://lore.kernel.org/all/20230321233849.3408339-1-david.e@linux.intel.com/
>
>
>
>
> >
> > - Mani
> >
> >> Regards,
> >> Vignesh
>
> --
> Jani Nikula, Intel
--
மணிவண்ணன் சதாசிவம்
Re: [Intel-gfx] [PATCH v6 3/4] drm/i915/display: Handle invalid fb_modifier in intel_fb_modifier_to_tiling
On Thu, Nov 23, 2023 at 09:41:19AM +0200, Jouni Högander wrote:
> Lookup_modifier is returning INTEL_PLANE_CAP_TILING_4 on invalid
> fb_modifier value. Use lookup_modifier_or_null in
> intel_fb_modifier_to_tiling and return I915_TILING_NONE in case
> lookup_modifier_or_null returns null.
>
> Signed-off-by: Jouni Högander
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fb.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index a235ec0f192d..f63f56b24b11 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -303,7 +303,14 @@ lookup_format_info(const struct drm_format_info
> formats[],
>
> unsigned int intel_fb_modifier_to_tiling(u64 fb_modifier)
> {
> - u8 tiling_caps = lookup_modifier(fb_modifier)->plane_caps &
> + const struct intel_modifier_desc *md;
> + u8 tiling_caps;
> +
> + md = lookup_modifier_or_null(fb_modifier);
> + if (!md)
> + return I915_TILING_NONE;
> +
> + tiling_caps = lookup_modifier_or_null(fb_modifier)->plane_caps &
>INTEL_PLANE_CAP_TILING_MASK;
>
> switch (tiling_caps) {
> --
> 2.34.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v6 1/4] drm/i915/display: use intel_bo_to_drm_bo in intel_fb.c
On Thu, Nov 23, 2023 at 09:41:17AM +0200, Jouni Högander wrote:
> We are preparing for Xe driver. I915 and Xe object implementation are
> differing. Do not use i915_gem_object->base directly. Instead use
> intel_bo_to_drm_bo.
>
> Also use drm_gem_object_put instead of i915_gem_object_put. This should be
> ok as i915_gem_object_put is really just doing__drm_gem_object_put.
>
> Signed-off-by: Jouni Högander
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fb.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index c1777ea35761..7c2df6c1f377 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -1657,10 +1657,10 @@ int intel_fill_fb_info(struct drm_i915_private *i915,
> struct intel_framebuffer *
> max_size = max(max_size, offset + size);
> }
>
> - if (mul_u32_u32(max_size, tile_size) > obj->base.size) {
> + if (mul_u32_u32(max_size, tile_size) > intel_bo_to_drm_bo(obj)->size) {
> drm_dbg_kms(&i915->drm,
> "fb too big for bo (need %llu bytes, have %zu
> bytes)\n",
> - mul_u32_u32(max_size, tile_size), obj->base.size);
> + mul_u32_u32(max_size, tile_size),
> intel_bo_to_drm_bo(obj)->size);
> return -EINVAL;
> }
>
> @@ -1889,7 +1889,7 @@ static int intel_user_framebuffer_create_handle(struct
> drm_framebuffer *fb,
> unsigned int *handle)
> {
> struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> - struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + struct drm_i915_private *i915 = to_i915(intel_bo_to_drm_bo(obj)->dev);
>
> if (i915_gem_object_is_userptr(obj)) {
> drm_dbg(&i915->drm,
> @@ -1897,7 +1897,7 @@ static int intel_user_framebuffer_create_handle(struct
> drm_framebuffer *fb,
> return -EINVAL;
> }
>
> - return drm_gem_handle_create(file, &obj->base, handle);
> + return drm_gem_handle_create(file, intel_bo_to_drm_bo(obj), handle);
> }
>
> struct frontbuffer_fence_cb {
> @@ -1975,7 +1975,7 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
> struct drm_i915_gem_object *obj,
> struct drm_mode_fb_cmd2 *mode_cmd)
> {
> - struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> + struct drm_i915_private *dev_priv =
> to_i915(intel_bo_to_drm_bo(obj)->dev);
> struct drm_framebuffer *fb = &intel_fb->base;
> u32 max_stride;
> unsigned int tiling, stride;
> @@ -2153,7 +2153,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
> }
>
> fb = intel_framebuffer_create(obj, &mode_cmd);
> - i915_gem_object_put(obj);
> + drm_gem_object_put(intel_bo_to_drm_bo(obj));
>
> return fb;
> }
> --
> 2.34.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v6 4/4] drm/i915/display: Split i915 specific code away from intel_fb.c
On Thu, Nov 23, 2023 at 09:41:20AM +0200, Jouni Högander wrote:
> We are preparing for Xe driver. Backing object implementation is differing
> between i915 and Xe. Split i915 specific code into separate source file
> built only for i915.
>
> v6: Add missing intel_fb_bo.[ch]
> v5:
> - Keep drm_any_plane_has_format check in intel_fb.c
> - Use mode_cmd instead of user_mode_cmd for intel_fb_bo_lookup_valid_bo
> v4: Move drm_any_plane_has_format check into intel_fb_bo.c
> v3: Fix failure handling in intel_framebuffer_init
> v2: Couple of fixes to error value handling
>
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_fb.c| 69 ++--
> drivers/gpu/drm/i915/display/intel_fb_bo.c | 93 ++
> drivers/gpu/drm/i915/display/intel_fb_bo.h | 24 ++
> 4 files changed, 126 insertions(+), 61 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_fb_bo.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_fb_bo.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 7e5d6a39d450..c14ba1212b84 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -279,6 +279,7 @@ i915-y += \
> display/intel_dsb.o \
> display/intel_dsb_buffer.o \
> display/intel_fb.o \
> + display/intel_fb_bo.o \
> display/intel_fb_pin.o \
> display/intel_fbc.o \
> display/intel_fdi.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index f63f56b24b11..d5de213be2c0 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -4,7 +4,6 @@
> */
>
> #include
> -#include
> #include
>
> #include
> @@ -15,6 +14,7 @@
> #include "intel_display_types.h"
> #include "intel_dpt.h"
> #include "intel_fb.h"
> +#include "intel_fb_bo.h"
> #include "intel_frontbuffer.h"
>
> #define check_array_bounds(i915, a, i) drm_WARN_ON(&(i915)->drm, (i) >=
> ARRAY_SIZE(a))
> @@ -1985,7 +1985,6 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
> struct drm_i915_private *dev_priv =
> to_i915(intel_bo_to_drm_bo(obj)->dev);
> struct drm_framebuffer *fb = &intel_fb->base;
> u32 max_stride;
> - unsigned int tiling, stride;
> int ret = -EINVAL;
> int i;
>
> @@ -1993,32 +1992,11 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
> if (!intel_fb->frontbuffer)
> return -ENOMEM;
>
> - i915_gem_object_lock(obj, NULL);
> - tiling = i915_gem_object_get_tiling(obj);
> - stride = i915_gem_object_get_stride(obj);
> - i915_gem_object_unlock(obj);
> -
> - if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) {
> - /*
> - * If there's a fence, enforce that
> - * the fb modifier and tiling mode match.
> - */
> - if (tiling != I915_TILING_NONE &&
> - tiling !=
> intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
> - drm_dbg_kms(&dev_priv->drm,
> - "tiling_mode doesn't match fb modifier\n");
> - goto err;
> - }
> - } else {
> - if (tiling == I915_TILING_X) {
> - mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
> - } else if (tiling == I915_TILING_Y) {
> - drm_dbg_kms(&dev_priv->drm,
> - "No Y tiling for legacy addfb\n");
> - goto err;
> - }
> - }
> + ret = intel_fb_bo_framebuffer_init(intel_fb, obj, mode_cmd);
> + if (ret)
> + goto err;
>
> + ret = -EINVAL;
> if (!drm_any_plane_has_format(&dev_priv->drm,
> mode_cmd->pixel_format,
> mode_cmd->modifier[0])) {
> @@ -2028,17 +2006,6 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
> goto err;
> }
>
> - /*
> - * gen2/3 display engine uses the fence if present,
> - * so the tiling mode must match the fb modifier exactly.
> - */
> - if (DISPLAY_VER(dev_priv) < 4 &&
> - tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
> - drm_dbg_kms(&dev_priv->drm,
> - "tiling_mode must match fb modifier exactly on
> gen2/3\n");
> - goto err;
> - }
> -
> max_stride = intel_fb_max_stride(dev_priv, mode_cmd->pixel_format,
>mode_cmd->modifier[0]);
> if (mode_cmd->pitches[0] > max_stride) {
> @@ -2050,17 +2017,6 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
> goto err;
> }
>
> - /*
> - * If there's a fence, enforce that
> - * the fb pitch and fence stride match.
> -
Re: [Intel-gfx] [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices
Adding a few missing important people to the explicit to list. Am 28.11.23 um 13:50 schrieb Weixi Zhu: The problem: Accelerator driver developers are forced to reinvent external MM subsystems case by case, because Linux core MM only considers host memory resources. These reinvented MM subsystems have similar orders of magnitude of LoC as Linux MM (80K), e.g. Nvidia-UVM has 70K, AMD GPU has 14K and Huawei NPU has 30K. Meanwhile, more and more vendors are implementing their own accelerators, e.g. Microsoft's Maia 100. At the same time, application-level developers suffer from poor programmability -- they must consider parallel address spaces and be careful about the limited device DRAM capacity. This can be alleviated if a malloc()-ed virtual address can be shared by the accelerator, or the abundant host DRAM can further transparently backup the device local memory. These external MM systems share similar mechanisms except for the hardware-dependent part, so reinventing them is effectively introducing redundant code (14K~70K for each case). Such developing/maintaining is not cheap. Furthermore, to share a malloc()-ed virtual address, device drivers need to deeply interact with Linux MM via low-level MM APIs, e.g. MMU notifiers/HMM. This raises the bar for driver development, since developers must understand how Linux MM works. Further, it creates code maintenance problems -- any changes to Linux MM potentially require coordinated changes to accelerator drivers using low-level MM APIs. Putting a cache-coherent bus between host and device will not make these external MM subsystems disappear. For example, a throughput-oriented accelerator will not tolerate executing heavy memory access workload with a host MMU/IOMMU via a remote bus. Therefore, devices will still have their own MMU and pick a simpler page table format for lower address translation overhead, requiring external MM subsystems. What GMEM (Generalized Memory Management [1]) does: GMEM extends Linux MM to share its machine-independent MM code. Only high-level interface is provided for device drivers. This prevents accelerator drivers from reinventing the wheel, but relies on drivers to implement their hardware-dependent functions declared by GMEM. GMEM's key interface include gm_dev_create(), gm_as_create(), gm_as_attach() and gm_dev_register_physmem(). Here briefly describe how a device driver utilizes them: 1. At boot time, call gm_dev_create() and registers the implementation of hardware-dependent functions as declared in struct gm_mmu. - If the device has local DRAM, call gm_dev_register_physmem() to register available physical addresses. 2. When a device context is initialized (e.g. triggered by ioctl), check if the current CPU process has been attached to a gmem address space (struct gm_as). If not, call gm_as_create() and point current->mm->gm_as to it. 3. Call gm_as_attach() to attach the device context to a gmem address space. 4. Invoke gm_dev_fault() to resolve a page fault or prepare data before device computation happens. GMEM has changed the following assumptions in Linux MM: 1. An mm_struct not only handle a single CPU context, but may also handle external memory contexts encapsulated as gm_context listed in mm->gm_as. An external memory context can include a few or all of the following parts: an external MMU (that requires TLB invalidation), an external page table (that requires PTE manipulation) and external DRAM (that requires physical memory management). 2. Faulting a MAP_PRIVATE VMA with no CPU PTE found does not necessarily mean that a zero-filled physical page should be mapped. The virtual page may have been mapped to an external memory device. 3. Unmapping a page may include sending device TLB invalidation (even if its MMU shares CPU page table) and manipulating device PTEs. Semantics of new syscalls: 1. mmap(..., MAP_PRIVATE | MAP_PEER_SHARED) Allocate virtual address that is shared between the CPU and all attached devices. Data is guaranteed to be coherent whenever the address is accessed by either CPU or any attached device. If the device does not support page fault, then device driver is responsible for faulting memory before data gets accessed. By default, the CPU DRAM is can be used as a swap backup for the device local memory. 2. hmadvise(NUMA_id, va_start, size, memory_hint) Issuing memory hint for a given VMA. This extends traditional madvise() syscall with an extra argument so that programmers have better control with heterogeneous devices registered as NUMA nodes. One useful memory hint could be MADV_PREFETCH, which guarantees that the physical data of the given VMA [VA, VA+size) is migrated to NUMA node #id. Another useful memory hint is MADV_DONTNEED. This is helpful to increase device memory utilization. It
Re: [Intel-gfx] [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices
Am 28.11.23 um 13:50 schrieb Weixi Zhu: The problem: Accelerator driver developers are forced to reinvent external MM subsystems case by case, because Linux core MM only considers host memory resources. These reinvented MM subsystems have similar orders of magnitude of LoC as Linux MM (80K), e.g. Nvidia-UVM has 70K, AMD GPU has 14K and Huawei NPU has 30K. Meanwhile, more and more vendors are implementing their own accelerators, e.g. Microsoft's Maia 100. At the same time, application-level developers suffer from poor programmability -- they must consider parallel address spaces and be careful about the limited device DRAM capacity. This can be alleviated if a malloc()-ed virtual address can be shared by the accelerator, or the abundant host DRAM can further transparently backup the device local memory. These external MM systems share similar mechanisms except for the hardware-dependent part, so reinventing them is effectively introducing redundant code (14K~70K for each case). Such developing/maintaining is not cheap. Furthermore, to share a malloc()-ed virtual address, device drivers need to deeply interact with Linux MM via low-level MM APIs, e.g. MMU notifiers/HMM. This raises the bar for driver development, since developers must understand how Linux MM works. Further, it creates code maintenance problems -- any changes to Linux MM potentially require coordinated changes to accelerator drivers using low-level MM APIs. Putting a cache-coherent bus between host and device will not make these external MM subsystems disappear. For example, a throughput-oriented accelerator will not tolerate executing heavy memory access workload with a host MMU/IOMMU via a remote bus. Therefore, devices will still have their own MMU and pick a simpler page table format for lower address translation overhead, requiring external MM subsystems. What GMEM (Generalized Memory Management [1]) does: GMEM extends Linux MM to share its machine-independent MM code. Only high-level interface is provided for device drivers. This prevents accelerator drivers from reinventing the wheel, but relies on drivers to implement their hardware-dependent functions declared by GMEM. GMEM's key interface include gm_dev_create(), gm_as_create(), gm_as_attach() and gm_dev_register_physmem(). Here briefly describe how a device driver utilizes them: 1. At boot time, call gm_dev_create() and registers the implementation of hardware-dependent functions as declared in struct gm_mmu. - If the device has local DRAM, call gm_dev_register_physmem() to register available physical addresses. 2. When a device context is initialized (e.g. triggered by ioctl), check if the current CPU process has been attached to a gmem address space (struct gm_as). If not, call gm_as_create() and point current->mm->gm_as to it. 3. Call gm_as_attach() to attach the device context to a gmem address space. 4. Invoke gm_dev_fault() to resolve a page fault or prepare data before device computation happens. GMEM has changed the following assumptions in Linux MM: 1. An mm_struct not only handle a single CPU context, but may also handle external memory contexts encapsulated as gm_context listed in mm->gm_as. An external memory context can include a few or all of the following parts: an external MMU (that requires TLB invalidation), an external page table (that requires PTE manipulation) and external DRAM (that requires physical memory management). Well that is pretty much exactly what AMD has already proposed with KFD and was rejected for rather good reasons. 2. Faulting a MAP_PRIVATE VMA with no CPU PTE found does not necessarily mean that a zero-filled physical page should be mapped. The virtual page may have been mapped to an external memory device. 3. Unmapping a page may include sending device TLB invalidation (even if its MMU shares CPU page table) and manipulating device PTEs. Semantics of new syscalls: 1. mmap(..., MAP_PRIVATE | MAP_PEER_SHARED) Allocate virtual address that is shared between the CPU and all attached devices. Data is guaranteed to be coherent whenever the address is accessed by either CPU or any attached device. If the device does not support page fault, then device driver is responsible for faulting memory before data gets accessed. By default, the CPU DRAM is can be used as a swap backup for the device local memory. 2. hmadvise(NUMA_id, va_start, size, memory_hint) Issuing memory hint for a given VMA. This extends traditional madvise() syscall with an extra argument so that programmers have better control with heterogeneous devices registered as NUMA nodes. One useful memory hint could be MADV_PREFETCH, which guarantees that the physical data of the given VMA [VA, VA+size) is migrated to NUMA node #id. Another useful memory hint is MADV_DONTNEED. This is
Re: [Intel-gfx] [PATCH] PCI: qcom: Fix compile error
On Tue, 28 Nov 2023, Vignesh Raman wrote:
> On 28/11/23 12:21, Manivannan Sadhasivam wrote:
>> On Tue, Nov 28, 2023 at 11:44:26AM +0530, Vignesh Raman wrote:
>>> Hi Mani,
>>>
>>> On 28/11/23 10:44, Manivannan Sadhasivam wrote:
On Tue, Nov 28, 2023 at 09:50:26AM +0530, Vignesh Raman wrote:
> Commit a2458d8f618a ("PCI/ASPM: pci_enable_link_state: Add argument
> to acquire bus lock") has added an argument to acquire bus lock
> in pci_enable_link_state, but qcom_pcie_enable_aspm calls it
> without this argument, resulting in below build error.
>
Where do you see this error? That patch is not even merged. Looks like you
are
sending the patch against some downstream tree.
>>>
>>> I got this error with drm-tip - git://anongit.freedesktop.org/drm-tip
>>>
>>> This commit is merged in drm-intel/topic/core-for-CI -
>>> https://cgit.freedesktop.org/drm-intel/log/?h=topic/core-for-CI
>>>
>>
>> Okay. Since this patch is just for CI, please do not CC linux-pci as it
>> causes
>> confusion.
>
> Sure, thank you.
>
> Jani, is this fix required for topic/core-for-CI ?
Done. Please double check drm-tip works for you now.
BR,
Jani.
>
> Regards,
> Vignesh
--
Jani Nikula, Intel
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Skip some timing checks on BXT/GLK DSI transcoders
On Tue, Nov 28, 2023 at 02:47:35PM +0200, Jani Nikula wrote:
> On Tue, 28 Nov 2023, Ville Syrjälä wrote:
> > On Tue, Nov 28, 2023 at 02:22:23PM +0200, Jani Nikula wrote:
> >> On Mon, 27 Nov 2023, Ville Syrjala wrote:
> >> > From: Ville Syrjälä
> >> >
> >> > Apparently some BXT/GLK systems have DSI panels whose timings
> >> > don't agree with the normal cpu transcoder hblank>=32 limitation.
> >> > This is perhaps fine as there are no specific hblank/etc. limits
> >> > listed for the BXT/GLK DSI transcoders.
> >> >
> >> > Move those checks out from the global intel_mode_valid() into
> >> > into connector specific .mode_valid() hooks, skipping BXT/GLK
> >> > DSI connectors. We'll leave the basic [hv]display/[hv]total
> >> > checks in intel_mode_valid() as those seem like sensible upper
> >> > limits regardless of the transcoder used.
> >> >
> >> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9720
> >> > Fixes: 8f4b1068e7fc ("drm/i915: Check some transcoder timing minimum
> >> > limits")
> >> > Signed-off-by: Ville Syrjälä
> >> > ---
> >> > drivers/gpu/drm/i915/display/icl_dsi.c | 7 +++
> >> > drivers/gpu/drm/i915/display/intel_crt.c | 5 +
> >> > drivers/gpu/drm/i915/display/intel_display.c | 10 ++
> >> > drivers/gpu/drm/i915/display/intel_display.h | 3 +++
> >> > drivers/gpu/drm/i915/display/intel_dp.c | 4
> >> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4
> >> > drivers/gpu/drm/i915/display/intel_dvo.c | 6 ++
> >> > drivers/gpu/drm/i915/display/intel_hdmi.c| 4
> >> > drivers/gpu/drm/i915/display/intel_lvds.c| 5 +
> >> > drivers/gpu/drm/i915/display/intel_sdvo.c| 8 +++-
> >> > drivers/gpu/drm/i915/display/intel_tv.c | 8 +++-
> >> > drivers/gpu/drm/i915/display/vlv_dsi.c | 18 +-
> >> > 12 files changed, 79 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> >> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> >> > index 481fcb650850..ac456a2275db 100644
> >> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> >> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> >> > @@ -1440,6 +1440,13 @@ static void gen11_dsi_post_disable(struct
> >> > intel_atomic_state *state,
> >> > static enum drm_mode_status gen11_dsi_mode_valid(struct drm_connector
> >> > *connector,
> >> > struct
> >> > drm_display_mode *mode)
> >> > {
> >> > +struct drm_i915_private *i915 = to_i915(connector->dev);
> >> > +enum drm_mode_status status;
> >> > +
> >> > +status = intel_cpu_transcoder_mode_valid(i915, mode);
> >> > +if (status != MODE_OK)
> >> > +return status;
> >> > +
> >> > /* FIXME: DSC? */
> >> > return intel_dsi_mode_valid(connector, mode);
> >> > }
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
> >> > b/drivers/gpu/drm/i915/display/intel_crt.c
> >> > index 0e33a0523a75..abaacea5c2cc 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_crt.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> >> > @@ -348,8 +348,13 @@ intel_crt_mode_valid(struct drm_connector
> >> > *connector,
> >> > struct drm_device *dev = connector->dev;
> >> > struct drm_i915_private *dev_priv = to_i915(dev);
> >> > int max_dotclk = dev_priv->max_dotclk_freq;
> >> > +enum drm_mode_status status;
> >> > int max_clock;
> >> >
> >> > +status = intel_cpu_transcoder_mode_valid(dev_priv, mode);
> >> > +if (status != MODE_OK)
> >> > +return status;
> >> > +
> >> > if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> >> > return MODE_NO_DBLESCAN;
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >> > b/drivers/gpu/drm/i915/display/intel_display.c
> >> > index 5cf162628b95..23b077f43614 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> > @@ -7734,6 +7734,16 @@ enum drm_mode_status intel_mode_valid(struct
> >> > drm_device *dev,
> >> > mode->vtotal > vtotal_max)
> >> > return MODE_V_ILLEGAL;
> >> >
> >> > +return MODE_OK;
> >> > +}
> >> > +
> >> > +enum drm_mode_status intel_cpu_transcoder_mode_valid(struct
> >> > drm_i915_private *dev_priv,
> >> > + const struct
> >> > drm_display_mode *mode)
> >> > +{
> >>
> >> Overall the patch looks fine, even if it's a bit meh we have to
> >> duplicate the calls so much. No way around that I guess.
> >>
> >> Reviewed-by: Jani Nikula
> >>
> >> But please explain the intel_cpu_transcoder_mode_valid() naming. I'm not
> >> sure I follow.
> >
> > These limits (suposedly) only apply to the normal
> > transcoders but not to the BXT/GLK DSI transcoders.
>
> It's just that... some transcoder limits remain in intel_mode_va
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add meaningful traces for QGV point info error handling
Quoting Stanislav Lisovskiy (2023-11-28 05:37:52-03:00)
>For debug purposes we need those - error path won't flood the log,
>however there has been already numerous cases, when due to lack
>of debugs, we couldn't immediately tell what was the problem on
>customer machine, which slowed down the investigation, requiring
>to get access to target device and adding those traces manually.
>
>Signed-off-by: Stanislav Lisovskiy
>---
> drivers/gpu/drm/i915/display/intel_bw.c | 4 +++-
> drivers/gpu/drm/i915/soc/intel_dram.c | 2 ++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
>b/drivers/gpu/drm/i915/display/intel_bw.c
>index bef96db62c80..583cd2ebdf89 100644
>--- a/drivers/gpu/drm/i915/display/intel_bw.c
>+++ b/drivers/gpu/drm/i915/display/intel_bw.c
>@@ -289,8 +289,10 @@ static int icl_get_qgv_points(struct drm_i915_private
>*dev_priv,
> struct intel_qgv_point *sp = &qi->points[i];
>
> ret = intel_read_qgv_point_info(dev_priv, sp, i);
>-if (ret)
>+if (ret) {
>+drm_dbg_kms(&dev_priv->drm, "Could not read QGV %d
>info\n", i);
> return ret;
>+}
>
> drm_dbg_kms(&dev_priv->drm,
> "QGV %d: DCLK=%d tRP=%d tRDPRE=%d tRAS=%d tRCD=%d
> tRC=%d\n",
>diff --git a/drivers/gpu/drm/i915/soc/intel_dram.c
>b/drivers/gpu/drm/i915/soc/intel_dram.c
>index 15492b69f698..37d61dff50a8 100644
>--- a/drivers/gpu/drm/i915/soc/intel_dram.c
>+++ b/drivers/gpu/drm/i915/soc/intel_dram.c
>@@ -647,6 +647,8 @@ static int xelpdp_get_dram_info(struct drm_i915_private
>*i915)
>
> dram_info->num_channels = REG_FIELD_GET(MTL_N_OF_POPULATED_CH_MASK,
> val);
> dram_info->num_qgv_points =
> REG_FIELD_GET(MTL_N_OF_ENABLED_QGV_POINTS_MASK, val);
>+drm_dbg_kms(&i915->drm, "Num qgv points from
>MTL_N_OF_ENABLED_QGV_POINTS_MASK reg: %d\n",
>+dram_info->num_qgv_points);
Maybe use a more general message (not specific to MTL) and do this in
intel_dram_detect() instead?
--
Gustavo Sousa
> /* PSF GV points not supported in D14+ */
>
> return 0;
>--
>2.37.3
>
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Skip some timing checks on BXT/GLK DSI transcoders
On Tue, 28 Nov 2023, Ville Syrjälä wrote:
> On Tue, Nov 28, 2023 at 02:22:23PM +0200, Jani Nikula wrote:
>> On Mon, 27 Nov 2023, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > Apparently some BXT/GLK systems have DSI panels whose timings
>> > don't agree with the normal cpu transcoder hblank>=32 limitation.
>> > This is perhaps fine as there are no specific hblank/etc. limits
>> > listed for the BXT/GLK DSI transcoders.
>> >
>> > Move those checks out from the global intel_mode_valid() into
>> > into connector specific .mode_valid() hooks, skipping BXT/GLK
>> > DSI connectors. We'll leave the basic [hv]display/[hv]total
>> > checks in intel_mode_valid() as those seem like sensible upper
>> > limits regardless of the transcoder used.
>> >
>> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9720
>> > Fixes: 8f4b1068e7fc ("drm/i915: Check some transcoder timing minimum
>> > limits")
>> > Signed-off-by: Ville Syrjälä
>> > ---
>> > drivers/gpu/drm/i915/display/icl_dsi.c | 7 +++
>> > drivers/gpu/drm/i915/display/intel_crt.c | 5 +
>> > drivers/gpu/drm/i915/display/intel_display.c | 10 ++
>> > drivers/gpu/drm/i915/display/intel_display.h | 3 +++
>> > drivers/gpu/drm/i915/display/intel_dp.c | 4
>> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4
>> > drivers/gpu/drm/i915/display/intel_dvo.c | 6 ++
>> > drivers/gpu/drm/i915/display/intel_hdmi.c| 4
>> > drivers/gpu/drm/i915/display/intel_lvds.c| 5 +
>> > drivers/gpu/drm/i915/display/intel_sdvo.c| 8 +++-
>> > drivers/gpu/drm/i915/display/intel_tv.c | 8 +++-
>> > drivers/gpu/drm/i915/display/vlv_dsi.c | 18 +-
>> > 12 files changed, 79 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
>> > b/drivers/gpu/drm/i915/display/icl_dsi.c
>> > index 481fcb650850..ac456a2275db 100644
>> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
>> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
>> > @@ -1440,6 +1440,13 @@ static void gen11_dsi_post_disable(struct
>> > intel_atomic_state *state,
>> > static enum drm_mode_status gen11_dsi_mode_valid(struct drm_connector
>> > *connector,
>> > struct drm_display_mode *mode)
>> > {
>> > + struct drm_i915_private *i915 = to_i915(connector->dev);
>> > + enum drm_mode_status status;
>> > +
>> > + status = intel_cpu_transcoder_mode_valid(i915, mode);
>> > + if (status != MODE_OK)
>> > + return status;
>> > +
>> >/* FIXME: DSC? */
>> >return intel_dsi_mode_valid(connector, mode);
>> > }
>> > diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
>> > b/drivers/gpu/drm/i915/display/intel_crt.c
>> > index 0e33a0523a75..abaacea5c2cc 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_crt.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_crt.c
>> > @@ -348,8 +348,13 @@ intel_crt_mode_valid(struct drm_connector *connector,
>> >struct drm_device *dev = connector->dev;
>> >struct drm_i915_private *dev_priv = to_i915(dev);
>> >int max_dotclk = dev_priv->max_dotclk_freq;
>> > + enum drm_mode_status status;
>> >int max_clock;
>> >
>> > + status = intel_cpu_transcoder_mode_valid(dev_priv, mode);
>> > + if (status != MODE_OK)
>> > + return status;
>> > +
>> >if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
>> >return MODE_NO_DBLESCAN;
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> > b/drivers/gpu/drm/i915/display/intel_display.c
>> > index 5cf162628b95..23b077f43614 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> > @@ -7734,6 +7734,16 @@ enum drm_mode_status intel_mode_valid(struct
>> > drm_device *dev,
>> >mode->vtotal > vtotal_max)
>> >return MODE_V_ILLEGAL;
>> >
>> > + return MODE_OK;
>> > +}
>> > +
>> > +enum drm_mode_status intel_cpu_transcoder_mode_valid(struct
>> > drm_i915_private *dev_priv,
>> > + const struct
>> > drm_display_mode *mode)
>> > +{
>>
>> Overall the patch looks fine, even if it's a bit meh we have to
>> duplicate the calls so much. No way around that I guess.
>>
>> Reviewed-by: Jani Nikula
>>
>> But please explain the intel_cpu_transcoder_mode_valid() naming. I'm not
>> sure I follow.
>
> These limits (suposedly) only apply to the normal
> transcoders but not to the BXT/GLK DSI transcoders.
It's just that... some transcoder limits remain in intel_mode_valid().
>
>>
>>
>>
>> --
>> Jani Nikula, Intel
--
Jani Nikula, Intel
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Skip some timing checks on BXT/GLK DSI transcoders
On Tue, Nov 28, 2023 at 02:22:23PM +0200, Jani Nikula wrote:
> On Mon, 27 Nov 2023, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Apparently some BXT/GLK systems have DSI panels whose timings
> > don't agree with the normal cpu transcoder hblank>=32 limitation.
> > This is perhaps fine as there are no specific hblank/etc. limits
> > listed for the BXT/GLK DSI transcoders.
> >
> > Move those checks out from the global intel_mode_valid() into
> > into connector specific .mode_valid() hooks, skipping BXT/GLK
> > DSI connectors. We'll leave the basic [hv]display/[hv]total
> > checks in intel_mode_valid() as those seem like sensible upper
> > limits regardless of the transcoder used.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9720
> > Fixes: 8f4b1068e7fc ("drm/i915: Check some transcoder timing minimum
> > limits")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/icl_dsi.c | 7 +++
> > drivers/gpu/drm/i915/display/intel_crt.c | 5 +
> > drivers/gpu/drm/i915/display/intel_display.c | 10 ++
> > drivers/gpu/drm/i915/display/intel_display.h | 3 +++
> > drivers/gpu/drm/i915/display/intel_dp.c | 4
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4
> > drivers/gpu/drm/i915/display/intel_dvo.c | 6 ++
> > drivers/gpu/drm/i915/display/intel_hdmi.c| 4
> > drivers/gpu/drm/i915/display/intel_lvds.c| 5 +
> > drivers/gpu/drm/i915/display/intel_sdvo.c| 8 +++-
> > drivers/gpu/drm/i915/display/intel_tv.c | 8 +++-
> > drivers/gpu/drm/i915/display/vlv_dsi.c | 18 +-
> > 12 files changed, 79 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index 481fcb650850..ac456a2275db 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -1440,6 +1440,13 @@ static void gen11_dsi_post_disable(struct
> > intel_atomic_state *state,
> > static enum drm_mode_status gen11_dsi_mode_valid(struct drm_connector
> > *connector,
> > struct drm_display_mode *mode)
> > {
> > + struct drm_i915_private *i915 = to_i915(connector->dev);
> > + enum drm_mode_status status;
> > +
> > + status = intel_cpu_transcoder_mode_valid(i915, mode);
> > + if (status != MODE_OK)
> > + return status;
> > +
> > /* FIXME: DSC? */
> > return intel_dsi_mode_valid(connector, mode);
> > }
> > diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
> > b/drivers/gpu/drm/i915/display/intel_crt.c
> > index 0e33a0523a75..abaacea5c2cc 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crt.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> > @@ -348,8 +348,13 @@ intel_crt_mode_valid(struct drm_connector *connector,
> > struct drm_device *dev = connector->dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > int max_dotclk = dev_priv->max_dotclk_freq;
> > + enum drm_mode_status status;
> > int max_clock;
> >
> > + status = intel_cpu_transcoder_mode_valid(dev_priv, mode);
> > + if (status != MODE_OK)
> > + return status;
> > +
> > if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > return MODE_NO_DBLESCAN;
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 5cf162628b95..23b077f43614 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -7734,6 +7734,16 @@ enum drm_mode_status intel_mode_valid(struct
> > drm_device *dev,
> > mode->vtotal > vtotal_max)
> > return MODE_V_ILLEGAL;
> >
> > + return MODE_OK;
> > +}
> > +
> > +enum drm_mode_status intel_cpu_transcoder_mode_valid(struct
> > drm_i915_private *dev_priv,
> > +const struct
> > drm_display_mode *mode)
> > +{
>
> Overall the patch looks fine, even if it's a bit meh we have to
> duplicate the calls so much. No way around that I guess.
>
> Reviewed-by: Jani Nikula
>
> But please explain the intel_cpu_transcoder_mode_valid() naming. I'm not
> sure I follow.
These limits (suposedly) only apply to the normal
transcoders but not to the BXT/GLK DSI transcoders.
>
>
>
> --
> Jani Nikula, Intel
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v2] drm/i915/irq: Improve error logging for unexpected DE Misc interrupts
On Sun, 26 Nov 2023, Rahul Rameshbabu wrote: > Dump the iir value in hex when the interrupt is unexpected. > > Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9652#note_2178501 > Cc: Jani Nikula > Signed-off-by: Rahul Rameshbabu > Reviewed-by: Chaitanya Kumar Borah Pushed to drm-intel-next. Thanks for the patch and review. BR, Jani. > --- > > Notes: > Changes: > > v1->v2: > - Change format specifier to pad minimum width > - > https://lore.kernel.org/intel-gfx/20231123175638.27650-1-sergeantsag...@protonmail.com/ > > drivers/gpu/drm/i915/display/intel_display_irq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c > b/drivers/gpu/drm/i915/display/intel_display_irq.c > index bff4a76310c0..7c6f20cd951e 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_irq.c > +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c > @@ -896,7 +896,7 @@ gen8_de_misc_irq_handler(struct drm_i915_private > *dev_priv, u32 iir) > } > > if (!found) > - drm_err(&dev_priv->drm, "Unexpected DE Misc interrupt\n"); > + drm_err(&dev_priv->drm, "Unexpected DE Misc interrupt: > 0x%08x\n", iir); > } > > static void gen11_dsi_te_interrupt_handler(struct drm_i915_private *dev_priv, -- Jani Nikula, Intel
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Clean up some DISPLAY_VER checks
On Mon, 27 Nov 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the >= and < operators for the DISPLAY_VER checks everywhere.
> This is what most of the code does, but especially recently random
> pieces of code have started doing this differently for no good reason.
I suppose all the < 14 and >= 14 could be written as < 20 and >= 20, but
functionally should make no difference.
Reviewed-by: Jani Nikula
>
> Conversion done with the following cocci:
> @find@
> expression i915;
> constant ver;
> @@
> (
> DISPLAY_VER(i915) <= ver
> |
> DISPLAY_VER(i915) > ver
> )
>
> @script:python inc@
> old_ver << find.ver;
> new_ver;
> @@
> coccinelle.new_ver = str(int(old_ver) + 1)
>
> @@
> expression find.i915;
> constant find.ver;
> identifier inc.new_ver;
> @@
> (
> - DISPLAY_VER(i915) <= ver
> + DISPLAY_VER(i915) < new_ver
> |
> - DISPLAY_VER(i915) > ver
> + DISPLAY_VER(i915) >= new_ver
> )
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/i9xx_wm.c | 8
> drivers/gpu/drm/i915/display/intel_bw.c | 7 ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display.c| 8
> drivers/gpu/drm/i915/display/intel_display_device.h | 2 +-
> drivers/gpu/drm/i915/display/intel_display_irq.c| 2 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> drivers/gpu/drm/i915/display/intel_lvds.c | 2 +-
> drivers/gpu/drm/i915/display/intel_psr.c| 8
> 10 files changed, 22 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
> b/drivers/gpu/drm/i915/display/i9xx_wm.c
> index b37c0d02d500..03e8fb6caa83 100644
> --- a/drivers/gpu/drm/i915/display/i9xx_wm.c
> +++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
> @@ -2477,7 +2477,7 @@ static unsigned int ilk_plane_wm_max(const struct
> drm_i915_private *dev_priv,
>* FIFO size is only half of the self
>* refresh FIFO size on ILK/SNB.
>*/
> - if (DISPLAY_VER(dev_priv) <= 6)
> + if (DISPLAY_VER(dev_priv) < 7)
> fifo_size /= 2;
> }
>
> @@ -2818,7 +2818,7 @@ static int ilk_compute_pipe_wm(struct
> intel_atomic_state *state,
> usable_level = dev_priv->display.wm.num_levels - 1;
>
> /* ILK/SNB: LP2+ watermarks only w/o sprites */
> - if (DISPLAY_VER(dev_priv) <= 6 && pipe_wm->sprites_enabled)
> + if (DISPLAY_VER(dev_priv) < 7 && pipe_wm->sprites_enabled)
> usable_level = 1;
>
> /* ILK/SNB/IVB: LP1+ watermarks only w/o scaling */
> @@ -2961,7 +2961,7 @@ static void ilk_wm_merge(struct drm_i915_private
> *dev_priv,
> int last_enabled_level = num_levels - 1;
>
> /* ILK/SNB/IVB: LP1+ watermarks only w/ single pipe */
> - if ((DISPLAY_VER(dev_priv) <= 6 || IS_IVYBRIDGE(dev_priv)) &&
> + if ((DISPLAY_VER(dev_priv) < 7 || IS_IVYBRIDGE(dev_priv)) &&
> config->num_pipes_active > 1)
> last_enabled_level = 0;
>
> @@ -3060,7 +3060,7 @@ static void ilk_compute_wm_results(struct
> drm_i915_private *dev_priv,
>* Always set WM_LP_SPRITE_EN when spr_val != 0, even if the
>* level is disabled. Doing otherwise could cause underruns.
>*/
> - if (DISPLAY_VER(dev_priv) <= 6 && r->spr_val) {
> + if (DISPLAY_VER(dev_priv) < 7 && r->spr_val) {
> drm_WARN_ON(&dev_priv->drm, wm_lp != 1);
> results->wm_lp_spr[wm_lp - 1] |= WM_LP_SPRITE_ENABLE;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index bef96db62c80..7f2a50b4f494 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -87,7 +87,8 @@ static int icl_pcode_read_qgv_point_info(struct
> drm_i915_private *dev_priv,
> return ret;
>
> dclk = val & 0x;
> - sp->dclk = DIV_ROUND_UP((16667 * dclk) + (DISPLAY_VER(dev_priv) > 11 ?
> 500 : 0), 1000);
> + sp->dclk = DIV_ROUND_UP((16667 * dclk) + (DISPLAY_VER(dev_priv) >= 12 ?
> 500 : 0),
> + 1000);
> sp->t_rp = (val & 0xff) >> 16;
> sp->t_rcd = (val & 0xff00) >> 24;
>
> @@ -480,7 +481,7 @@ static int tgl_get_bw_info(struct drm_i915_private
> *dev_priv, const struct intel
> if (num_channels < qi.max_numchannels && DISPLAY_VER(dev_priv) >= 12)
> qi.deinterleave = max(DIV_ROUND_UP(qi.deinterleave, 2), 1);
>
> - if (DISPLAY_VER(dev_priv) > 11 && num_channels > qi.max_numchannels)
> + if (DISPLAY_VER(dev_priv) >= 12 && num_channels > qi.max_numchannels)
> drm_warn(&dev_priv->drm, "Number of channels exceeds max number
> of channels.");
> if (qi.max_numchannels != 0)
> num_channels = mi
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix IP version of the WAs
Quoting Balasubramani Vivekanandan (2023-11-28 07:24:51-03:00) >WAs 14011508470, 14011503030 were applied on IP versions beyond which >they are applicable. Fixed the IP version checks for these workarounds. > >Signed-off-by: Balasubramani Vivekanandan > >--- > drivers/gpu/drm/i915/display/intel_display_power.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > >diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c >b/drivers/gpu/drm/i915/display/intel_display_power.c >index 18ff7f3639ff..5f091502719b 100644 >--- a/drivers/gpu/drm/i915/display/intel_display_power.c >+++ b/drivers/gpu/drm/i915/display/intel_display_power.c >@@ -1697,14 +1697,14 @@ static void icl_display_core_init(struct >drm_i915_private *dev_priv, > if (resume) > intel_dmc_load_program(dev_priv); > >-/* Wa_14011508470:tgl,dg1,rkl,adl-s,adl-p */ >-if (DISPLAY_VER(dev_priv) >= 12) >+/* Wa_14011508470:tgl,dg1,rkl,adl-s,adl-p,dg2 */ Nit: I with those who think the platform tags attached to the lineage number are unnecessary. Either way, Reviewed-by: Gustavo Sousa >+if (IS_DISPLAY_IP_RANGE(dev_priv, IP_VER(12, 0), IP_VER(13, 0))) > intel_de_rmw(dev_priv, GEN11_CHICKEN_DCPR_2, 0, > DCPR_CLEAR_MEMSTAT_DIS | DCPR_SEND_RESP_IMM | > DCPR_MASK_LPMODE | > DCPR_MASK_MAXLATENCY_MEMUP_CLR); > > /* Wa_14011503030:xelpd */ >-if (DISPLAY_VER(dev_priv) >= 13) >+if (DISPLAY_VER(dev_priv) == 13) > intel_de_write(dev_priv, XELPD_DISPLAY_ERR_FATAL_MASK, ~0); > } > >-- >2.25.1 >
Re: [Intel-gfx] [PATCH 3/4] drm/i915/mst: Reject modes that require the bigjoiner
On Mon, 27 Nov 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We have no bigjoiner support in the MST code, so .mode_valid()
> pretending otherwise is just going to result black screens for
> users. Reject any mode that needs the joiner.
>
> Cc: Stanislav Lisovskiy
> Fixes: d51f25eb479a ("drm/i915: Add DSC support to MST path")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 0680a42f7d2a..b665fe6ef871 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1332,6 +1332,10 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
> *connector,
> if (intel_dp_need_bigjoiner(intel_dp, mode->hdisplay, target_clock)) {
> bigjoiner = true;
> max_dotclk *= 2;
> +
> + /* TODO: add support for bigjoiner */
> + *status = MODE_CLOCK_HIGH;
> + return 0;
> }
>
> if (DISPLAY_VER(dev_priv) >= 10 &&
--
Jani Nikula, Intel
Re: [Intel-gfx] [PATCH 2/4] drm/i915/mst: Fix .mode_valid_ctx() return values
On Mon, 27 Nov 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> .mode_valid_ctx() returns an errno, not the mode status. Fix
> the code to do the right thing.
>
> Cc: Stanislav Lisovskiy
> Fixes: d51f25eb479a ("drm/i915: Add DSC support to MST path")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 0514f825baf5..0680a42f7d2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1366,11 +1366,15 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
> *connector,
>* Big joiner configuration needs DSC for TGL which is not true for
>* XE_LPD where uncompressed joiner is supported.
>*/
> - if (DISPLAY_VER(dev_priv) < 13 && bigjoiner && !dsc)
> - return MODE_CLOCK_HIGH;
> + if (DISPLAY_VER(dev_priv) < 13 && bigjoiner && !dsc) {
> + *status = MODE_CLOCK_HIGH;
> + return 0;
> + }
>
> - if (mode_rate > max_rate && !dsc)
> - return MODE_CLOCK_HIGH;
> + if (mode_rate > max_rate && !dsc) {
> + *status = MODE_CLOCK_HIGH;
> + return 0;
> + }
>
> *status = intel_mode_valid_max_plane_size(dev_priv, mode, false);
> return 0;
--
Jani Nikula, Intel
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Skip some timing checks on BXT/GLK DSI transcoders
On Mon, 27 Nov 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Apparently some BXT/GLK systems have DSI panels whose timings
> don't agree with the normal cpu transcoder hblank>=32 limitation.
> This is perhaps fine as there are no specific hblank/etc. limits
> listed for the BXT/GLK DSI transcoders.
>
> Move those checks out from the global intel_mode_valid() into
> into connector specific .mode_valid() hooks, skipping BXT/GLK
> DSI connectors. We'll leave the basic [hv]display/[hv]total
> checks in intel_mode_valid() as those seem like sensible upper
> limits regardless of the transcoder used.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9720
> Fixes: 8f4b1068e7fc ("drm/i915: Check some transcoder timing minimum limits")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c | 7 +++
> drivers/gpu/drm/i915/display/intel_crt.c | 5 +
> drivers/gpu/drm/i915/display/intel_display.c | 10 ++
> drivers/gpu/drm/i915/display/intel_display.h | 3 +++
> drivers/gpu/drm/i915/display/intel_dp.c | 4
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 4
> drivers/gpu/drm/i915/display/intel_dvo.c | 6 ++
> drivers/gpu/drm/i915/display/intel_hdmi.c| 4
> drivers/gpu/drm/i915/display/intel_lvds.c| 5 +
> drivers/gpu/drm/i915/display/intel_sdvo.c| 8 +++-
> drivers/gpu/drm/i915/display/intel_tv.c | 8 +++-
> drivers/gpu/drm/i915/display/vlv_dsi.c | 18 +-
> 12 files changed, 79 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 481fcb650850..ac456a2275db 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1440,6 +1440,13 @@ static void gen11_dsi_post_disable(struct
> intel_atomic_state *state,
> static enum drm_mode_status gen11_dsi_mode_valid(struct drm_connector
> *connector,
>struct drm_display_mode *mode)
> {
> + struct drm_i915_private *i915 = to_i915(connector->dev);
> + enum drm_mode_status status;
> +
> + status = intel_cpu_transcoder_mode_valid(i915, mode);
> + if (status != MODE_OK)
> + return status;
> +
> /* FIXME: DSC? */
> return intel_dsi_mode_valid(connector, mode);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
> b/drivers/gpu/drm/i915/display/intel_crt.c
> index 0e33a0523a75..abaacea5c2cc 100644
> --- a/drivers/gpu/drm/i915/display/intel_crt.c
> +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> @@ -348,8 +348,13 @@ intel_crt_mode_valid(struct drm_connector *connector,
> struct drm_device *dev = connector->dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> int max_dotclk = dev_priv->max_dotclk_freq;
> + enum drm_mode_status status;
> int max_clock;
>
> + status = intel_cpu_transcoder_mode_valid(dev_priv, mode);
> + if (status != MODE_OK)
> + return status;
> +
> if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> return MODE_NO_DBLESCAN;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5cf162628b95..23b077f43614 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7734,6 +7734,16 @@ enum drm_mode_status intel_mode_valid(struct
> drm_device *dev,
> mode->vtotal > vtotal_max)
> return MODE_V_ILLEGAL;
>
> + return MODE_OK;
> +}
> +
> +enum drm_mode_status intel_cpu_transcoder_mode_valid(struct drm_i915_private
> *dev_priv,
> + const struct
> drm_display_mode *mode)
> +{
Overall the patch looks fine, even if it's a bit meh we have to
duplicate the calls so much. No way around that I guess.
Reviewed-by: Jani Nikula
But please explain the intel_cpu_transcoder_mode_valid() naming. I'm not
sure I follow.
--
Jani Nikula, Intel
Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Remove divider field from tables
On Tue, Nov 28, 2023 at 11:51:43AM +0200, Ville Syrjälä wrote:
> On Tue, Nov 28, 2023 at 10:43:36AM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 27, 2023 at 08:21:46AM -0800, Matt Roper wrote:
> > > On Fri, Nov 24, 2023 at 05:55:23PM -0300, Gustavo Sousa wrote:
> > > > The cdclk tables were introduced with commit 736da8112fee ("drm/i915:
> > > > Use literal representation of cdclk tables"). It has been almost 4 years
> > > > and the divider field was not really used yet. Let's remove it.
> > >
> > > I think we need to go the other way and actually start using it instead
> > > of (incorrectly) trying to re-derive it from cdclk->vco. The logic the
> > > driver is using today doesn't account for the potential use of
> > > squashing, which means we program the wrong divider value into CDCLK_CTL
> > > in some cases. I pointed that out during the LNL code reviews a couple
> > > months ago, and I believe Stan is working on fixing that.
> >
> > The code should be correct as is, but it does assume that the cd2x
> > divider is 2 when squashing is used. If that no longer holds then we
> > have to change something.
>
> Something like this should be sufficient to eliminate that
> assumption.
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 8bb6bab7c8cd..58567d42e725 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1897,10 +1897,7 @@ static void _bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
>
> waveform = cdclk_squash_waveform(dev_priv, cdclk);
>
> - if (waveform)
> - clock = vco / 2;
> - else
> - clock = cdclk;
> + clock = DIV_ROUND_CLOSEST(cdclk * 16, cdclk_squash_divider(waveform));
>
> if (HAS_CDCLK_SQUASH(dev_priv))
> dg2_cdclk_squash_program(dev_priv, waveform);
Sent that, and a bunch of other cdclk stuff as a proper series to the
list.
>
> >
> > >
> > > I wonder if the misprogramming we're doing today is what requires the
> > > "HACK" at the bottom of intel_crtc_compute_min_cdclk for DG2?
> > >
> > >
> > > Matt
> > >
> > > >
> > > > Cc: Matt Roper
> > > > Cc: Ville Syrjälä
> > > > Signed-off-by: Gustavo Sousa
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 269 ++---
> > > > 1 file changed, 134 insertions(+), 135 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > index b93d1ad7936d..7f85a216ff5c 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > @@ -1227,183 +1227,182 @@ struct intel_cdclk_vals {
> > > > u32 cdclk;
> > > > u16 refclk;
> > > > u16 waveform;
> > > > - u8 divider; /* CD2X divider * 2 */
> > > > u8 ratio;
> > > > };
> > > >
> > > > static const struct intel_cdclk_vals bxt_cdclk_table[] = {
> > > > - { .refclk = 19200, .cdclk = 144000, .divider = 8, .ratio = 60 },
> > > > - { .refclk = 19200, .cdclk = 288000, .divider = 4, .ratio = 60 },
> > > > - { .refclk = 19200, .cdclk = 384000, .divider = 3, .ratio = 60 },
> > > > - { .refclk = 19200, .cdclk = 576000, .divider = 2, .ratio = 60 },
> > > > - { .refclk = 19200, .cdclk = 624000, .divider = 2, .ratio = 65 },
> > > > + { .refclk = 19200, .cdclk = 144000, .ratio = 60 },
> > > > + { .refclk = 19200, .cdclk = 288000, .ratio = 60 },
> > > > + { .refclk = 19200, .cdclk = 384000, .ratio = 60 },
> > > > + { .refclk = 19200, .cdclk = 576000, .ratio = 60 },
> > > > + { .refclk = 19200, .cdclk = 624000, .ratio = 65 },
> > > > {}
> > > > };
> > > >
> > > > static const struct intel_cdclk_vals glk_cdclk_table[] = {
> > > > - { .refclk = 19200, .cdclk = 79200, .divider = 8, .ratio = 33 },
> > > > - { .refclk = 19200, .cdclk = 158400, .divider = 4, .ratio = 33 },
> > > > - { .refclk = 19200, .cdclk = 316800, .divider = 2, .ratio = 33 },
> > > > + { .refclk = 19200, .cdclk = 79200, .ratio = 33 },
> > > > + { .refclk = 19200, .cdclk = 158400, .ratio = 33 },
> > > > + { .refclk = 19200, .cdclk = 316800, .ratio = 33 },
> > > > {}
> > > > };
> > > >
> > > > static const struct intel_cdclk_vals icl_cdclk_table[] = {
> > > > - { .refclk = 19200, .cdclk = 172800, .divider = 2, .ratio = 18 },
> > > > - { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20 },
> > > > - { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32 },
> > > > - { .refclk = 19200, .cdclk = 326400, .divider = 4, .ratio = 68 },
> > > > - { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58 },
> > > > - { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68 },
> > > > -
> > > > - { .refclk = 24000, .cdclk = 18, .divider = 2, .ratio = 15 }
[Intel-gfx] [PATCH 8/8] drm/i915: Simplify intel_ddi_compute_min_voltage_level()
From: Ville Syrjälä
Drop the redundant dev_priv parameters from
intel_ddi_compute_min_voltage_level() to make life easier.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c| 9 +
drivers/gpu/drm/i915/display/intel_ddi.h| 3 +--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index dd04bd7b348c..12a29363e5df 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3696,9 +3696,10 @@ static int icl_ddi_min_voltage_level(const struct
intel_crtc_state *crtc_state)
return 0;
}
-void intel_ddi_compute_min_voltage_level(struct drm_i915_private *dev_priv,
-struct intel_crtc_state *crtc_state)
+void intel_ddi_compute_min_voltage_level(struct intel_crtc_state *crtc_state)
{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
+
if (DISPLAY_VER(dev_priv) >= 14)
crtc_state->min_voltage_level =
icl_ddi_min_voltage_level(crtc_state);
else if (DISPLAY_VER(dev_priv) >= 12)
@@ -3920,7 +3921,7 @@ static void intel_ddi_get_config(struct intel_encoder
*encoder,
pipe_config->lane_lat_optim_mask =
bxt_ddi_phy_get_lane_lat_optim_mask(encoder);
- intel_ddi_compute_min_voltage_level(dev_priv, pipe_config);
+ intel_ddi_compute_min_voltage_level(pipe_config);
intel_hdmi_read_gcp_infoframe(encoder, pipe_config);
@@ -4200,7 +4201,7 @@ static int intel_ddi_compute_config(struct intel_encoder
*encoder,
pipe_config->lane_lat_optim_mask =
bxt_ddi_phy_calc_lane_lat_optim_mask(pipe_config->lane_count);
- intel_ddi_compute_min_voltage_level(dev_priv, pipe_config);
+ intel_ddi_compute_min_voltage_level(pipe_config);
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index 63853a1f6582..434de7196875 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -70,8 +70,7 @@ void intel_ddi_set_dp_msa(const struct intel_crtc_state
*crtc_state,
bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
void intel_ddi_set_vc_payload_alloc(const struct intel_crtc_state *crtc_state,
bool state);
-void intel_ddi_compute_min_voltage_level(struct drm_i915_private *dev_priv,
-struct intel_crtc_state *crtc_state);
+void intel_ddi_compute_min_voltage_level(struct intel_crtc_state *crtc_state);
int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
enum transcoder cpu_transcoder,
bool enable, u32 hdcp_mask);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 63364c9602ef..060728a4b851 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -614,7 +614,7 @@ static int intel_dp_mst_compute_config(struct intel_encoder
*encoder,
intel_dp_audio_compute_config(encoder, pipe_config, conn_state);
- intel_ddi_compute_min_voltage_level(dev_priv, pipe_config);
+ intel_ddi_compute_min_voltage_level(pipe_config);
intel_psr_compute_config(intel_dp, pipe_config, conn_state);
--
2.41.0
[Intel-gfx] [PATCH 7/8] drm/i915/mtl: Calculate the correct voltage level from port_clock
From: Ville Syrjälä
On MTL we need to bump the voltage level to only 1 (not 2)
when port clock exceeds 594MHz. Make it so.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index bcfcd7e789f0..dd04bd7b348c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3699,7 +3699,9 @@ static int icl_ddi_min_voltage_level(const struct
intel_crtc_state *crtc_state)
void intel_ddi_compute_min_voltage_level(struct drm_i915_private *dev_priv,
struct intel_crtc_state *crtc_state)
{
- if (DISPLAY_VER(dev_priv) >= 12)
+ if (DISPLAY_VER(dev_priv) >= 14)
+ crtc_state->min_voltage_level =
icl_ddi_min_voltage_level(crtc_state);
+ else if (DISPLAY_VER(dev_priv) >= 12)
crtc_state->min_voltage_level =
tgl_ddi_min_voltage_level(crtc_state);
else if (IS_JASPERLAKE(dev_priv) || IS_ELKHARTLAKE(dev_priv))
crtc_state->min_voltage_level =
jsl_ddi_min_voltage_level(crtc_state);
--
2.41.0
[Intel-gfx] [PATCH 6/8] drm/i915: Split intel_ddi_compute_min_voltage_level() into platform variants
From: Ville Syrjälä
The mess inside intel_ddi_compute_min_voltage_level() is illegible.
Clean it up a bit by splitting the internals into per-platform
functions.
TODO: make it a vfunc?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 37 +++-
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 38f28c480b38..bcfcd7e789f0 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3672,16 +3672,39 @@ static bool intel_ddi_is_audio_enabled(struct
drm_i915_private *dev_priv,
AUDIO_OUTPUT_ENABLE(cpu_transcoder);
}
+static int tgl_ddi_min_voltage_level(const struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->port_clock > 594000)
+ return 2;
+ else
+ return 0;
+}
+
+static int jsl_ddi_min_voltage_level(const struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->port_clock > 594000)
+ return 3;
+ else
+ return 0;
+}
+
+static int icl_ddi_min_voltage_level(const struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->port_clock > 594000)
+ return 1;
+ else
+ return 0;
+}
+
void intel_ddi_compute_min_voltage_level(struct drm_i915_private *dev_priv,
struct intel_crtc_state *crtc_state)
{
- if (DISPLAY_VER(dev_priv) >= 12 && crtc_state->port_clock > 594000)
- crtc_state->min_voltage_level = 2;
- else if ((IS_JASPERLAKE(dev_priv) || IS_ELKHARTLAKE(dev_priv)) &&
-crtc_state->port_clock > 594000)
- crtc_state->min_voltage_level = 3;
- else if (DISPLAY_VER(dev_priv) >= 11 && crtc_state->port_clock > 594000)
- crtc_state->min_voltage_level = 1;
+ if (DISPLAY_VER(dev_priv) >= 12)
+ crtc_state->min_voltage_level =
tgl_ddi_min_voltage_level(crtc_state);
+ else if (IS_JASPERLAKE(dev_priv) || IS_ELKHARTLAKE(dev_priv))
+ crtc_state->min_voltage_level =
jsl_ddi_min_voltage_level(crtc_state);
+ else if (DISPLAY_VER(dev_priv) >= 11)
+ crtc_state->min_voltage_level =
icl_ddi_min_voltage_level(crtc_state);
}
static enum transcoder bdw_transcoder_master_readout(struct drm_i915_private
*dev_priv,
--
2.41.0
[Intel-gfx] [PATCH 5/8] drm/i915/mtl: Fix voltage_level for cdclk==480MHz
From: Ville Syrjälä
Allow MTL to use voltage level 1 for 480MHz cdclk,
instead of the voltage level 2 that it's currently using.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 6f0a050ad663..f6446102490d 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -3512,7 +3512,7 @@ static const struct intel_cdclk_funcs mtl_cdclk_funcs = {
.get_cdclk = bxt_get_cdclk,
.set_cdclk = bxt_set_cdclk,
.modeset_calc_cdclk = bxt_modeset_calc_cdclk,
- .calc_voltage_level = tgl_calc_voltage_level,
+ .calc_voltage_level = rplu_calc_voltage_level,
};
static const struct intel_cdclk_funcs rplu_cdclk_funcs = {
--
2.41.0
[Intel-gfx] [PATCH 4/8] drm/i915/cdclk: Rewrite cdclk->voltage_level selection to use tables
From: Ville Syrjälä
The cdclk->voltage_level if ladders are hard to read, especially as
they're written the other way around compared to how bspec lists
the limits. Let's rewrite them to use simple arrays that gives us
the max cdclk for each voltage level.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 83 ++
1 file changed, 53 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index d45071675629..6f0a050ad663 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1446,50 +1446,73 @@ static u8 bxt_calc_voltage_level(int cdclk)
return DIV_ROUND_UP(cdclk, 25000);
}
+static u8 calc_voltage_level(int cdclk, int num_voltage_levels,
+const int voltage_level_max_cdclk[])
+{
+ int voltage_level;
+
+ for (voltage_level = 0; voltage_level < num_voltage_levels;
voltage_level++) {
+ if (cdclk <= voltage_level_max_cdclk[voltage_level])
+ return voltage_level;
+ }
+
+ MISSING_CASE(cdclk);
+ return num_voltage_levels - 1;
+}
+
static u8 icl_calc_voltage_level(int cdclk)
{
- if (cdclk > 556800)
- return 2;
- else if (cdclk > 312000)
- return 1;
- else
- return 0;
+ static const int icl_voltage_level_max_cdclk[] = {
+ [0] = 312000,
+ [1] = 556800,
+ [2] = 652800,
+ };
+
+ return calc_voltage_level(cdclk,
+ ARRAY_SIZE(icl_voltage_level_max_cdclk),
+ icl_voltage_level_max_cdclk);
}
static u8 ehl_calc_voltage_level(int cdclk)
{
- if (cdclk > 326400)
- return 3;
- else if (cdclk > 312000)
- return 2;
- else if (cdclk > 18)
- return 1;
- else
- return 0;
+ static const int ehl_voltage_level_max_cdclk[] = {
+ [0] = 18,
+ [1] = 312000,
+ [2] = 326400,
+ [3] = 556800,
+ };
+
+ return calc_voltage_level(cdclk,
+ ARRAY_SIZE(ehl_voltage_level_max_cdclk),
+ ehl_voltage_level_max_cdclk);
}
static u8 tgl_calc_voltage_level(int cdclk)
{
- if (cdclk > 556800)
- return 3;
- else if (cdclk > 326400)
- return 2;
- else if (cdclk > 312000)
- return 1;
- else
- return 0;
+ static const int tgl_voltage_level_max_cdclk[] = {
+ [0] = 312000,
+ [1] = 326400,
+ [2] = 556800,
+ [3] = 652800,
+ };
+
+ return calc_voltage_level(cdclk,
+ ARRAY_SIZE(tgl_voltage_level_max_cdclk),
+ tgl_voltage_level_max_cdclk);
}
static u8 rplu_calc_voltage_level(int cdclk)
{
- if (cdclk > 556800)
- return 3;
- else if (cdclk > 48)
- return 2;
- else if (cdclk > 312000)
- return 1;
- else
- return 0;
+ static const int rplu_voltage_level_max_cdclk[] = {
+ [0] = 312000,
+ [1] = 48,
+ [2] = 556800,
+ [3] = 652800,
+ };
+
+ return calc_voltage_level(cdclk,
+ ARRAY_SIZE(rplu_voltage_level_max_cdclk),
+ rplu_voltage_level_max_cdclk);
}
static void icl_readout_refclk(struct drm_i915_private *dev_priv,
--
2.41.0
[Intel-gfx] [PATCH 3/8] drm/i915/cdclk: Remove the assumption that cd2x div==2 when using squashing
From: Ville Syrjälä Currently we have a hardcoded assumption that the cd2x divider is always 2 when squahsing is used. While that is true for all current platforms it might not hold in the future. So eliminate the assumption and calculate the correct divider from the other parameters. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_cdclk.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c index 87d5e5b67c4e..d45071675629 100644 --- a/drivers/gpu/drm/i915/display/intel_cdclk.c +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c @@ -1899,10 +1899,8 @@ static void _bxt_set_cdclk(struct drm_i915_private *dev_priv, waveform = cdclk_squash_waveform(dev_priv, cdclk); - if (waveform) - clock = vco / 2; - else - clock = cdclk; + clock = DIV_ROUND_CLOSEST(cdclk * cdclk_squash_len, + cdclk_squash_divider(waveform)); if (HAS_CDCLK_SQUASH(dev_priv)) dg2_cdclk_squash_program(dev_priv, waveform); -- 2.41.0
[Intel-gfx] [PATCH 2/8] drm/i915/cdclk: Give the squash waveform length a name
From: Ville Syrjälä
Replace the slightly magic 'size = 16' with a bit more descriptive
name. We'll have another user for this value later on.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 0dca29ec799b..87d5e5b67c4e 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1800,6 +1800,8 @@ static bool cdclk_pll_is_unknown(unsigned int vco)
return vco == ~0;
}
+static const int cdclk_squash_len = 16;
+
static int cdclk_squash_divider(u16 waveform)
{
return hweight16(waveform ?: 0x);
@@ -1811,7 +1813,6 @@ static bool
cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private *i91
struct intel_cdclk_config
*mid_cdclk_config)
{
u16 old_waveform, new_waveform, mid_waveform;
- int size = 16;
int div = 2;
/* Return if PLL is in an unknown state, force a complete disable and
re-enable. */
@@ -1850,7 +1851,8 @@ static bool
cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private *i91
}
mid_cdclk_config->cdclk =
DIV_ROUND_CLOSEST(cdclk_squash_divider(mid_waveform) *
- mid_cdclk_config->vco, size
* div);
+ mid_cdclk_config->vco,
+ cdclk_squash_len * div);
/* make sure the mid clock came out sane */
--
2.41.0
[Intel-gfx] [PATCH 1/8] drm/i915/cdclk: s/-1/~0/ when dealing with unsigned values
From: Ville Syrjälä cdclk_pll_is_unknown() used ~0 when checking for the "VCO is unknown" value, but the assignment uses -1. They are the same in the end, but let's use the same ~0 form on both sides for consistency. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c index b93d1ad7936d..0dca29ec799b 100644 --- a/drivers/gpu/drm/i915/display/intel_cdclk.c +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c @@ -1180,7 +1180,7 @@ static void skl_sanitize_cdclk(struct drm_i915_private *dev_priv) /* force cdclk programming */ dev_priv->display.cdclk.hw.cdclk = 0; /* force full PLL disable + enable */ - dev_priv->display.cdclk.hw.vco = -1; + dev_priv->display.cdclk.hw.vco = ~0; } static void skl_cdclk_init_hw(struct drm_i915_private *dev_priv) @@ -2075,7 +2075,7 @@ static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv) dev_priv->display.cdclk.hw.cdclk = 0; /* force full PLL disable + enable */ - dev_priv->display.cdclk.hw.vco = -1; + dev_priv->display.cdclk.hw.vco = ~0; } static void bxt_cdclk_init_hw(struct drm_i915_private *dev_priv) -- 2.41.0
[Intel-gfx] [PATCH 0/8] drm/i915: cdclk/voltage_level cleanups and fixes
From: Ville Syrjälä A bit of refactoring around the cdclk/voltage_level stuff. I also spotted that we were miscalculating the voltage level on MTL in two different places, so included fixes (or rather power optimizations) for those. Ville Syrjälä (8): drm/i915/cdclk: s/-1/~0/ when dealing with unsigned values drm/i915/cdclk: Give the squash waveform length a name drm/i915/cdclk: Remove the assumption that cd2x div==2 when using squashing drm/i915/cdclk: Rewrite cdclk->voltage_level selection to use tables drm/i915/mtl: Fix voltage_level for cdclk==480MHz drm/i915: Split intel_ddi_compute_min_voltage_level() into platform variants drm/i915/mtl: Calculate the correct voltage level from port_clock drm/i915: Simplify intel_ddi_compute_min_voltage_level() drivers/gpu/drm/i915/display/intel_cdclk.c | 101 drivers/gpu/drm/i915/display/intel_ddi.c| 50 +++--- drivers/gpu/drm/i915/display/intel_ddi.h| 3 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- 4 files changed, 102 insertions(+), 54 deletions(-) -- 2.41.0
[Intel-gfx] [PATCH] drm/i915/selftests: wait for active idle event in i915_active_unlock_wait
After i915_active_unlock_wait i915_active can be still non-idle due to barrier async handling in signal_irq_work. As a result one can observe following errors: bcs0: heartbeat pulse did not flush idle tasks *ERROR* pulse active pulse_active [i915]:pulse_retire [i915] *ERROR* pulsecount: 0 *ERROR* pulsepreallocated barriers? no To prevent it let's wait explicitly for idleness. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/i915/selftests/i915_active.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c b/drivers/gpu/drm/i915/selftests/i915_active.c index b61fe850e92493..c7dd12624f3485 100644 --- a/drivers/gpu/drm/i915/selftests/i915_active.c +++ b/drivers/gpu/drm/i915/selftests/i915_active.c @@ -342,6 +342,9 @@ void i915_active_unlock_wait(struct i915_active *ref) rcu_read_unlock(); i915_active_release(ref); + + ___wait_var_event(ref, i915_active_is_idle(ref), + TASK_INTERRUPTIBLE, 0, 0, schedule()); } /* And wait for the retire callback */ --- base-commit: f5e7a8caf6f5520ceb37c0e2e0d359a110c7cf98 change-id: 20231128-selftest_wait_for_active_idle_event-6bc728cd16a0 Best regards, -- Andrzej Hajda
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix phys_base to be relative not absolute
On Tue, Nov 28, 2023 at 12:12:08PM +0100, Andrzej Hajda wrote:
> On 28.11.2023 04:47, Paz Zcharya wrote:
> >
> > On Mon, Nov 27, 2023 at 8:20 PM Paz Zcharya wrote:
> >
> > Hey Andrzej,
> >
> > On a second thought, what do you think about something like
> >
> > + gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm;
> > + gen8_pte_t pte;
> > + gte += base / I915_GTT_PAGE_SIZE;
> > + pte = ioread64(gte);
> > + pte = pte & I915_GTT_PAGE_MASK;
> > + phys_base = pte - i915->mm.stolen_region->region.start;
> >
> > The only difference is the last line.
>
> Bingo :) It seems to be generic algorithm to get phys_base for all
> platforms:
> - on older platforms stolen_region points to system memory which starts at
> 0,
> - on DG2 it uses lmem region which starts at 0 as well,
> - on MTL stolen_region points to stolen-local which starts at 0x80.
>
> So this whole "if (IS_DGFX(i915)) {...} else {...}" could be replaced
> with sth generic.
> 1. Find pte.
> 2. if(IS_DGFX(i915) && pte & GEN12_GGTT_PTE_LM) mem =
> i915->mm.regions[INTEL_REGION_LMEM_0] else mem = i915->mm.stolen_region
> 3. phys_base = (pte & I915_GTT_PAGE_MASK) - mem->region.start;
>
> Regards
> Andrzej
>
>
Good stuff!! I'll work on this revision and resubmit.
Thank you so much Andrzej!
Re: [Intel-gfx] [PATCH] drm/i915/display: Skip state verification with TBT-ALT mode
> -Original Message- > From: Sousa, Gustavo > Sent: Monday, November 27, 2023 8:33 PM > To: Jani Nikula ; Kahola, Mika > ; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Skip state verification > with TBT-ALT mode > > Quoting Jani Nikula (2023-11-27 13:47:22-03:00) > >On Mon, 27 Nov 2023, Mika Kahola wrote: > >> With TBT-ALT mode we are not programming C20 chip PLL's and hence we > >> don't need to check state verification. We don't need to program DP > >> link signal levels i.e.pre-emphasis and voltage swing either. > >> > >> This patch fixes dmesg errors like this one > >> > >> "[drm] ERROR PHY F Write 0c06 failed after 3 retries." > >> > >> Signed-off-by: Mika Kahola > >> --- > >> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 7 +++ > >> 1 file changed, 7 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c > >> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c > >> index a8fa76580802..3a30cffd450c 100644 > >> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c > >> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c > >> @@ -418,6 +418,10 @@ void intel_cx0_phy_set_signal_levels(struct > >> intel_encoder *encoder, > >> u8 owned_lane_mask = intel_cx0_get_owned_lane_mask(i915, encoder); > >> intel_wakeref_t wakeref; > >> int n_entries, ln; > >> +struct intel_digital_port *dig_port = > >> + enc_to_dig_port(encoder); > >> + > >> +if (intel_tc_port_in_tbt_alt_mode(dig_port)) > >> +return; > >> > >> wakeref = intel_cx0_phy_transaction_begin(encoder); > >> > >> @@ -3136,6 +3140,9 @@ void intel_cx0pll_state_verify(struct > >> intel_atomic_state *state, > >> encoder = intel_get_crtc_new_encoder(state, new_crtc_state); > >> phy = intel_port_to_phy(i915, encoder->port); > >> > >> +if (intel_tc_port_in_tbt_alt_mode(enc_to_dig_port(encoder))) > >> +return; > >> + > > > >Shouldn't we read and ensure it's disabled? > > In TBT-alt mode, the PHY is owned by the Thunderbold controller, and it could > be in use. > > I guess what we could do is verify that PORT_CLOCK_CTL has the expected bits > depending on the mode. That could done here or in > a followup series. From PORT_CLOCK_CTL we could check if DDI or any transcoder directed to DDI is enabled. I could do some testing with this. Probably this is a subject for a follow up patch. -Mika- > > -- > Gustavo Sousa > > > > >> intel_cx0pll_readout_hw_state(encoder, &mpll_hw_state); > >> > >> if (intel_is_c10phy(i915, phy)) > > > >-- > >Jani Nikula, Intel
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix phys_base to be relative not absolute
On 28.11.2023 04:47, Paz Zcharya wrote:
On Mon, Nov 27, 2023 at 8:20 PM Paz Zcharya wrote:
On 21.11.2023 13:06, Andrzej Hajda wrote:
On 18.11.2023 00:01, Paz Zcharya wrote:
On Tue, Nov 14, 2023 at 10:13:59PM -0500, Rodrigo Vivi wrote:
On Sun, Nov 05, 2023 at 05:27:03PM +, Paz Zcharya wrote:
Hi Rodrigo, thanks for the great comments.
Apologies for using a wrong/confusing terminology. I think 'phys_base'
is supposed to be the offset in the GEM BO, where base (or
"Surface Base Address") is supposed to be the GTT offset.
Since base is taken from PLANE_SURF register it should be resolvable via
GGTT to physical address pointing to actual framebuffer.
I couldn't find anything in the specs.
It was quite cryptic. I meant I have not found anything about assumption
from commit history that for iGPU there should be 1:1 mapping, this is why
there was an assignment "phys_base = base". Possibly the assumption is not
valid anymore for MTL(?).
Without the assumption we need to check GGTT to determine phys address.
The simplest approach would be then do the same as in case of DGFX:
gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm;
gen8_pte_t pte;
gte += base / I915_GTT_PAGE_SIZE;
pte = ioread64(gte);
phys_base = pte & I915_GTT_PAGE_MASK;
Regards
Andrzej
Hey Andrzej,
On a second thought, what do you think about something like
+ gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm;
+ gen8_pte_t pte;
+ gte += base / I915_GTT_PAGE_SIZE;
+ pte = ioread64(gte);
+ pte = pte & I915_GTT_PAGE_MASK;
+ phys_base = pte - i915->mm.stolen_region->region.start;
The only difference is the last line.
Bingo :) It seems to be generic algorithm to get phys_base for all
platforms:
- on older platforms stolen_region points to system memory which starts
at 0,
- on DG2 it uses lmem region which starts at 0 as well,
- on MTL stolen_region points to stolen-local which starts at 0x80.
So this whole "if (IS_DGFX(i915)) {...} else {...}" could be replaced
with sth generic.
1. Find pte.
2. if(IS_DGFX(i915) && pte & GEN12_GGTT_PTE_LM) mem =
i915->mm.regions[INTEL_REGION_LMEM_0] else mem = i915->mm.stolen_region
3. phys_base = (pte & I915_GTT_PAGE_MASK) - mem->region.start;
Regards
Andrzej
Based on what I wrote before, I think `phys_base` is named incorrectly and
that it does not reflect the physical address, but the start offset of
i915->mm.stolen_region. So if we offset the start value of the stolen
region, this code looks correct to me (and it also works on my
MeteorLake device).
What do you think?
Many thanks,
Paz
Re: [Intel-gfx] [PATCH] drm/i915/display: Skip state verification with TBT-ALT mode
> -Original Message- > From: Sousa, Gustavo > Sent: Monday, November 27, 2023 8:18 PM > To: Kahola, Mika ; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Skip state verification > with TBT-ALT mode > > Quoting Mika Kahola (2023-11-27 12:47:02-03:00) > >With TBT-ALT mode we are not programming C20 chip PLL's and hence we > >don't need to check state verification. We don't need to program DP > >link signal levels i.e.pre-emphasis and voltage swing either. > > > >This patch fixes dmesg errors like this one > > > >"[drm] ERROR PHY F Write 0c06 failed after 3 retries." > > > >Signed-off-by: Mika Kahola > >--- > > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > >diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c > >b/drivers/gpu/drm/i915/display/intel_cx0_phy.c > >index a8fa76580802..3a30cffd450c 100644 > >--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c > >+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c > >@@ -418,6 +418,10 @@ void intel_cx0_phy_set_signal_levels(struct > >intel_encoder *encoder, > > u8 owned_lane_mask = intel_cx0_get_owned_lane_mask(i915, encoder); > > intel_wakeref_t wakeref; > > int n_entries, ln; > >+struct intel_digital_port *dig_port = > >+ enc_to_dig_port(encoder); > >+ > >+if (intel_tc_port_in_tbt_alt_mode(dig_port)) > >+return; > > I think we could make the call to intel_cx0_get_owned_lane_mask() here, to > make sure we do not waste time doing useless > MMIO. That's true, thanks!. I will move this intel_cx0_get_owned_lane_mask() call here. This way it is not called if we need to bail out early from this function. -Mika- > > With that in place, > > Reviewed-by: Gustavo Sousa > > -- > Gustavo Sousa > > > > > wakeref = intel_cx0_phy_transaction_begin(encoder); > > > >@@ -3136,6 +3140,9 @@ void intel_cx0pll_state_verify(struct > >intel_atomic_state *state, > > encoder = intel_get_crtc_new_encoder(state, new_crtc_state); > > phy = intel_port_to_phy(i915, encoder->port); > > > >+if (intel_tc_port_in_tbt_alt_mode(enc_to_dig_port(encoder))) > >+return; > >+ > > intel_cx0pll_readout_hw_state(encoder, &mpll_hw_state); > > > > if (intel_is_c10phy(i915, phy)) > >-- > >2.34.1 > >
Re: [Intel-gfx] [PATCH] PCI: qcom: Fix compile error
On Tue, 28 Nov 2023, Manivannan Sadhasivam
wrote:
> On Tue, Nov 28, 2023 at 11:44:26AM +0530, Vignesh Raman wrote:
>> Hi Mani,
>>
>> On 28/11/23 10:44, Manivannan Sadhasivam wrote:
>> > On Tue, Nov 28, 2023 at 09:50:26AM +0530, Vignesh Raman wrote:
>> > > Commit a2458d8f618a ("PCI/ASPM: pci_enable_link_state: Add argument
>> > > to acquire bus lock") has added an argument to acquire bus lock
>> > > in pci_enable_link_state, but qcom_pcie_enable_aspm calls it
>> > > without this argument, resulting in below build error.
>> > >
>> >
>> > Where do you see this error? That patch is not even merged. Looks like you
>> > are
>> > sending the patch against some downstream tree.
>>
>> I got this error with drm-tip - git://anongit.freedesktop.org/drm-tip
>>
>> This commit is merged in drm-intel/topic/core-for-CI -
>> https://cgit.freedesktop.org/drm-intel/log/?h=topic/core-for-CI
>>
>
> Okay. Since this patch is just for CI, please do not CC linux-pci as it causes
> confusion.
Agreed. More on-topic for linux-pci is what happened with [1].
We've been running CI with that for months now to avoid lockdep splats,
and it's obviously in everyone's best interest to get a fix upstream.
David, Bjorn?
BR,
Jani.
[1]
https://lore.kernel.org/all/20230321233849.3408339-1-david.e@linux.intel.com/
>
> - Mani
>
>> Regards,
>> Vignesh
--
Jani Nikula, Intel
[Intel-gfx] [PATCH] drm/i915/display: Fix IP version of the WAs
WAs 14011508470, 14011503030 were applied on IP versions beyond which they are applicable. Fixed the IP version checks for these workarounds. Signed-off-by: Balasubramani Vivekanandan --- drivers/gpu/drm/i915/display/intel_display_power.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index 18ff7f3639ff..5f091502719b 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -1697,14 +1697,14 @@ static void icl_display_core_init(struct drm_i915_private *dev_priv, if (resume) intel_dmc_load_program(dev_priv); - /* Wa_14011508470:tgl,dg1,rkl,adl-s,adl-p */ - if (DISPLAY_VER(dev_priv) >= 12) + /* Wa_14011508470:tgl,dg1,rkl,adl-s,adl-p,dg2 */ + if (IS_DISPLAY_IP_RANGE(dev_priv, IP_VER(12, 0), IP_VER(13, 0))) intel_de_rmw(dev_priv, GEN11_CHICKEN_DCPR_2, 0, DCPR_CLEAR_MEMSTAT_DIS | DCPR_SEND_RESP_IMM | DCPR_MASK_LPMODE | DCPR_MASK_MAXLATENCY_MEMUP_CLR); /* Wa_14011503030:xelpd */ - if (DISPLAY_VER(dev_priv) >= 13) + if (DISPLAY_VER(dev_priv) == 13) intel_de_write(dev_priv, XELPD_DISPLAY_ERR_FATAL_MASK, ~0); } -- 2.25.1
Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi Stephen,
On Wed, Nov 22, 2023 at 1:29 AM Stephen Rothwell wrote:
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/accel/ivpu/ivpu_hw_37xx.c
>
> between commit:
>
> 3f7c0634926d ("accel/ivpu/37xx: Fix hangs related to MMIO reset")
>
> from the drm-misc-fixes tree and commits:
>
> 3de6d9597892 ("accel/ivpu: Pass D0i3 residency time to the VPU firmware")
> cc19fedab8bd ("accel/ivpu/37xx: Print warning when VPUIP is not idle during
> power down")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks for your resolution!
> --- a/drivers/accel/ivpu/ivpu_hw_37xx.c
> +++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
> @@@ -720,14 -731,19 +733,14 @@@ static int ivpu_hw_37xx_power_down(stru
> {
> int ret = 0;
>
> - if (!ivpu_hw_37xx_is_idle(vdev))
> - ivpu_warn(vdev, "VPU not idle during power down\n");
> + ivpu_hw_37xx_save_d0i3_entry_timestamp(vdev);
>
> - if (ivpu_hw_37xx_reset(vdev)) {
> - ivpu_err(vdev, "Failed to reset VPU\n");
> - ret = -EIO;
> + if (!ivpu_hw_37xx_is_idle(vdev)) {
> + ivpu_warn(vdev, "VPU not idle during power down\n");
> + if (ivpu_hw_37xx_reset(vdev))
> + ivpu_warn(vdev, "Failed to reset the VPU\n");
> }
>
> - if (ivpu_pll_disable(vdev)) {
> - ivpu_err(vdev, "Failed to disable PLL\n");
> - ret = -EIO;
> - }
> -
> if (ivpu_hw_37xx_d0i3_enable(vdev)) {
> ivpu_err(vdev, "Failed to enter D0I3\n");
> ret = -EIO;
I've just run into the same conflict, and I think you lost the split
into two if-statements in the last hunk of commit 3f7c0634926d
("accel/ivpu/37xx: Fix hangs related to MMIO reset")?
My resolution is:
--- a/drivers/accel/ivpu/ivpu_hw_37xx.c
+++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
@@@ -720,11 -731,16 +733,13 @@@ static int ivpu_hw_37xx_power_down(stru
{
int ret = 0;
+ ivpu_hw_37xx_save_d0i3_entry_timestamp(vdev);
+
- if (!ivpu_hw_37xx_is_idle(vdev)) {
+ if (!ivpu_hw_37xx_is_idle(vdev))
ivpu_warn(vdev, "VPU not idle during power down\n");
- if (ivpu_hw_37xx_reset(vdev))
- ivpu_warn(vdev, "Failed to reset the VPU\n");
- }
- if (ivpu_pll_disable(vdev)) {
- ivpu_err(vdev, "Failed to disable PLL\n");
+ if (ivpu_hw_37xx_reset(vdev)) {
+ ivpu_err(vdev, "Failed to reset VPU\n");
ret = -EIO;
}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Remove divider field from tables
On Tue, Nov 28, 2023 at 10:43:36AM +0200, Ville Syrjälä wrote:
> On Mon, Nov 27, 2023 at 08:21:46AM -0800, Matt Roper wrote:
> > On Fri, Nov 24, 2023 at 05:55:23PM -0300, Gustavo Sousa wrote:
> > > The cdclk tables were introduced with commit 736da8112fee ("drm/i915:
> > > Use literal representation of cdclk tables"). It has been almost 4 years
> > > and the divider field was not really used yet. Let's remove it.
> >
> > I think we need to go the other way and actually start using it instead
> > of (incorrectly) trying to re-derive it from cdclk->vco. The logic the
> > driver is using today doesn't account for the potential use of
> > squashing, which means we program the wrong divider value into CDCLK_CTL
> > in some cases. I pointed that out during the LNL code reviews a couple
> > months ago, and I believe Stan is working on fixing that.
>
> The code should be correct as is, but it does assume that the cd2x
> divider is 2 when squashing is used. If that no longer holds then we
> have to change something.
Something like this should be sufficient to eliminate that
assumption.
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 8bb6bab7c8cd..58567d42e725 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1897,10 +1897,7 @@ static void _bxt_set_cdclk(struct drm_i915_private
*dev_priv,
waveform = cdclk_squash_waveform(dev_priv, cdclk);
- if (waveform)
- clock = vco / 2;
- else
- clock = cdclk;
+ clock = DIV_ROUND_CLOSEST(cdclk * 16, cdclk_squash_divider(waveform));
if (HAS_CDCLK_SQUASH(dev_priv))
dg2_cdclk_squash_program(dev_priv, waveform);
>
> >
> > I wonder if the misprogramming we're doing today is what requires the
> > "HACK" at the bottom of intel_crtc_compute_min_cdclk for DG2?
> >
> >
> > Matt
> >
> > >
> > > Cc: Matt Roper
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Gustavo Sousa
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 269 ++---
> > > 1 file changed, 134 insertions(+), 135 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index b93d1ad7936d..7f85a216ff5c 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -1227,183 +1227,182 @@ struct intel_cdclk_vals {
> > > u32 cdclk;
> > > u16 refclk;
> > > u16 waveform;
> > > - u8 divider; /* CD2X divider * 2 */
> > > u8 ratio;
> > > };
> > >
> > > static const struct intel_cdclk_vals bxt_cdclk_table[] = {
> > > - { .refclk = 19200, .cdclk = 144000, .divider = 8, .ratio = 60 },
> > > - { .refclk = 19200, .cdclk = 288000, .divider = 4, .ratio = 60 },
> > > - { .refclk = 19200, .cdclk = 384000, .divider = 3, .ratio = 60 },
> > > - { .refclk = 19200, .cdclk = 576000, .divider = 2, .ratio = 60 },
> > > - { .refclk = 19200, .cdclk = 624000, .divider = 2, .ratio = 65 },
> > > + { .refclk = 19200, .cdclk = 144000, .ratio = 60 },
> > > + { .refclk = 19200, .cdclk = 288000, .ratio = 60 },
> > > + { .refclk = 19200, .cdclk = 384000, .ratio = 60 },
> > > + { .refclk = 19200, .cdclk = 576000, .ratio = 60 },
> > > + { .refclk = 19200, .cdclk = 624000, .ratio = 65 },
> > > {}
> > > };
> > >
> > > static const struct intel_cdclk_vals glk_cdclk_table[] = {
> > > - { .refclk = 19200, .cdclk = 79200, .divider = 8, .ratio = 33 },
> > > - { .refclk = 19200, .cdclk = 158400, .divider = 4, .ratio = 33 },
> > > - { .refclk = 19200, .cdclk = 316800, .divider = 2, .ratio = 33 },
> > > + { .refclk = 19200, .cdclk = 79200, .ratio = 33 },
> > > + { .refclk = 19200, .cdclk = 158400, .ratio = 33 },
> > > + { .refclk = 19200, .cdclk = 316800, .ratio = 33 },
> > > {}
> > > };
> > >
> > > static const struct intel_cdclk_vals icl_cdclk_table[] = {
> > > - { .refclk = 19200, .cdclk = 172800, .divider = 2, .ratio = 18 },
> > > - { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20 },
> > > - { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32 },
> > > - { .refclk = 19200, .cdclk = 326400, .divider = 4, .ratio = 68 },
> > > - { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58 },
> > > - { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68 },
> > > -
> > > - { .refclk = 24000, .cdclk = 18, .divider = 2, .ratio = 15 },
> > > - { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16 },
> > > - { .refclk = 24000, .cdclk = 312000, .divider = 2, .ratio = 26 },
> > > - { .refclk = 24000, .cdclk = 324000, .divider = 4, .ratio = 54 },
> > > - { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46 },
> > > - { .refclk = 24000, .cdclk = 648000, .divider = 2, .ratio = 54 },
> > > -
> > > - { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 9 },
> > > - { .refclk = 38400, .cdclk = 192000, .divider = 2, .ra
[Intel-gfx] ✗ Fi.CI.BAT: failure for QGV/SAGV related fixes
== Series Details == Series: QGV/SAGV related fixes URL : https://patchwork.freedesktop.org/series/126962/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13931 -> Patchwork_126962v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_126962v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_126962v1, please notify your bug team (i915-ci-in...@lists.freedesktop.org) 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_126962v1/index.html Participating hosts (36 -> 33) -- Additional (1): bat-rpls-1 Missing(4): bat-dg2-14 bat-adlm-1 fi-snb-2520m bat-mtlp-6 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_126962v1: ### IGT changes ### Possible regressions * igt@core_hotunplug@unbind-rebind: - fi-elk-e7500: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13931/fi-elk-e7500/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126962v1/fi-elk-e7500/igt@core_hotunp...@unbind-rebind.html * igt@i915_module_load@load: - bat-adlp-6: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13931/bat-adlp-6/igt@i915_module_l...@load.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126962v1/bat-adlp-6/igt@i915_module_l...@load.html - fi-elk-e7500: [PASS][5] -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13931/fi-elk-e7500/igt@i915_module_l...@load.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126962v1/fi-elk-e7500/igt@i915_module_l...@load.html - bat-adlp-11:[PASS][7] -> [DMESG-WARN][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13931/bat-adlp-11/igt@i915_module_l...@load.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126962v1/bat-adlp-11/igt@i915_module_l...@load.html * igt@i915_module_load@reload: - fi-pnv-d510:[PASS][9] -> [ABORT][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13931/fi-pnv-d510/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126962v1/fi-pnv-d510/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - bat-kbl-2: [PASS][11] -> [DMESG-WARN][12] +42 other tests dmesg-warn [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13931/bat-kbl-2/igt@i915_pm_...@module-reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126962v1/bat-kbl-2/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@client: - fi-kbl-guc: [PASS][13] -> [DMESG-WARN][14] +42 other tests dmesg-warn [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13931/fi-kbl-guc/igt@i915_selftest@l...@client.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126962v1/fi-kbl-guc/igt@i915_selftest@l...@client.html * igt@i915_selftest@live@coherency: - bat-dg2-9: [PASS][15] -> [DMESG-WARN][16] +39 other tests dmesg-warn [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13931/bat-dg2-9/igt@i915_selftest@l...@coherency.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126962v1/bat-dg2-9/igt@i915_selftest@l...@coherency.html * igt@i915_selftest@live@gem: - fi-rkl-11600: [PASS][17] -> [DMESG-WARN][18] +42 other tests dmesg-warn [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13931/fi-rkl-11600/igt@i915_selftest@l...@gem.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126962v1/fi-rkl-11600/igt@i915_selftest@l...@gem.html * igt@i915_selftest@live@gem_contexts: - fi-cfl-guc: [PASS][19] -> [DMESG-WARN][20] +42 other tests dmesg-warn [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13931/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126962v1/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html - fi-skl-6600u: [PASS][21] -> [DMESG-WARN][22] +38 other tests dmesg-warn [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13931/fi-skl-6600u/igt@i915_selftest@live@gem_contexts.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126962v1/fi-skl-6600u/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@live@gt_contexts: - fi-ilk-650: [PASS][23] -> [DMESG-WARN][24] +41 other tests dmesg-warn [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13931/fi-ilk-650/igt@i915_selftest@live@gt_contexts.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126962v1/fi-ilk-650/igt@i915_selftest@live@gt_co
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for QGV/SAGV related fixes
== Series Details == Series: QGV/SAGV related fixes URL : https://patchwork.freedesktop.org/series/126962/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:185:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:191:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:236:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:238:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./drivers/gpu/drm/i915/intel_uncore.h:346:1: warning: trying to copy expression type 31 +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplac
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for QGV/SAGV related fixes
== Series Details == Series: QGV/SAGV related fixes URL : https://patchwork.freedesktop.org/series/126962/ State : warning == Summary == Error: dim checkpatch failed e47332e38255 drm/i915: Add meaningful traces for QGV point info error handling 0ae02a74f8db drm/i915: Extract code required to calculate max qgv/psf gv point c7ba67f6833b drm/i915: Disable SAGV on bw init, to force QGV point recalculation -:9: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible unwrapped commit description?) #9: (i.e all points allowed), however in reality we might get them all restricted, total: 0 errors, 1 warnings, 0 checks, 44 lines checked
Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Remove divider field from tables
On Tue, Nov 28, 2023 at 10:43:36AM +0200, Ville Syrjälä wrote:
> On Mon, Nov 27, 2023 at 08:21:46AM -0800, Matt Roper wrote:
> > On Fri, Nov 24, 2023 at 05:55:23PM -0300, Gustavo Sousa wrote:
> > > The cdclk tables were introduced with commit 736da8112fee ("drm/i915:
> > > Use literal representation of cdclk tables"). It has been almost 4 years
> > > and the divider field was not really used yet. Let's remove it.
> >
> > I think we need to go the other way and actually start using it instead
> > of (incorrectly) trying to re-derive it from cdclk->vco. The logic the
> > driver is using today doesn't account for the potential use of
> > squashing, which means we program the wrong divider value into CDCLK_CTL
> > in some cases. I pointed that out during the LNL code reviews a couple
> > months ago, and I believe Stan is working on fixing that.
>
> The code should be correct as is, but it does assume that the cd2x
> divider is 2 when squashing is used. If that no longer holds then we
> have to change something.
BTW long ago I wrote some patches to cross check all the values in the
table (since there is redundancy in what we store there), but I was
too annoyed at having to do that cross check at runtime that I didn't
send the patches out. I was slightly hopeful that C23 constexpr could
save us, but apparently constexpr for functions didn't end up in in
the spec, so likely not really useful :(
>
> >
> > I wonder if the misprogramming we're doing today is what requires the
> > "HACK" at the bottom of intel_crtc_compute_min_cdclk for DG2?
> >
> >
> > Matt
> >
> > >
> > > Cc: Matt Roper
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Gustavo Sousa
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 269 ++---
> > > 1 file changed, 134 insertions(+), 135 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index b93d1ad7936d..7f85a216ff5c 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -1227,183 +1227,182 @@ struct intel_cdclk_vals {
> > > u32 cdclk;
> > > u16 refclk;
> > > u16 waveform;
> > > - u8 divider; /* CD2X divider * 2 */
> > > u8 ratio;
> > > };
> > >
> > > static const struct intel_cdclk_vals bxt_cdclk_table[] = {
> > > - { .refclk = 19200, .cdclk = 144000, .divider = 8, .ratio = 60 },
> > > - { .refclk = 19200, .cdclk = 288000, .divider = 4, .ratio = 60 },
> > > - { .refclk = 19200, .cdclk = 384000, .divider = 3, .ratio = 60 },
> > > - { .refclk = 19200, .cdclk = 576000, .divider = 2, .ratio = 60 },
> > > - { .refclk = 19200, .cdclk = 624000, .divider = 2, .ratio = 65 },
> > > + { .refclk = 19200, .cdclk = 144000, .ratio = 60 },
> > > + { .refclk = 19200, .cdclk = 288000, .ratio = 60 },
> > > + { .refclk = 19200, .cdclk = 384000, .ratio = 60 },
> > > + { .refclk = 19200, .cdclk = 576000, .ratio = 60 },
> > > + { .refclk = 19200, .cdclk = 624000, .ratio = 65 },
> > > {}
> > > };
> > >
> > > static const struct intel_cdclk_vals glk_cdclk_table[] = {
> > > - { .refclk = 19200, .cdclk = 79200, .divider = 8, .ratio = 33 },
> > > - { .refclk = 19200, .cdclk = 158400, .divider = 4, .ratio = 33 },
> > > - { .refclk = 19200, .cdclk = 316800, .divider = 2, .ratio = 33 },
> > > + { .refclk = 19200, .cdclk = 79200, .ratio = 33 },
> > > + { .refclk = 19200, .cdclk = 158400, .ratio = 33 },
> > > + { .refclk = 19200, .cdclk = 316800, .ratio = 33 },
> > > {}
> > > };
> > >
> > > static const struct intel_cdclk_vals icl_cdclk_table[] = {
> > > - { .refclk = 19200, .cdclk = 172800, .divider = 2, .ratio = 18 },
> > > - { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20 },
> > > - { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32 },
> > > - { .refclk = 19200, .cdclk = 326400, .divider = 4, .ratio = 68 },
> > > - { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58 },
> > > - { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68 },
> > > -
> > > - { .refclk = 24000, .cdclk = 18, .divider = 2, .ratio = 15 },
> > > - { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16 },
> > > - { .refclk = 24000, .cdclk = 312000, .divider = 2, .ratio = 26 },
> > > - { .refclk = 24000, .cdclk = 324000, .divider = 4, .ratio = 54 },
> > > - { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46 },
> > > - { .refclk = 24000, .cdclk = 648000, .divider = 2, .ratio = 54 },
> > > -
> > > - { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 9 },
> > > - { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 10 },
> > > - { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16 },
> > > - { .refclk = 38400, .cdclk = 326400, .divider = 4, .ratio = 34 },
> > > - { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29 },
> > > - { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34 },
> > > + { .refclk = 19200, .cdclk = 172800, .ratio =
Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Remove divider field from tables
On Tue, Nov 28, 2023 at 10:43:36AM +0200, Ville Syrjälä wrote:
> On Mon, Nov 27, 2023 at 08:21:46AM -0800, Matt Roper wrote:
> > On Fri, Nov 24, 2023 at 05:55:23PM -0300, Gustavo Sousa wrote:
> > > The cdclk tables were introduced with commit 736da8112fee ("drm/i915:
> > > Use literal representation of cdclk tables"). It has been almost 4 years
> > > and the divider field was not really used yet. Let's remove it.
> >
> > I think we need to go the other way and actually start using it instead
> > of (incorrectly) trying to re-derive it from cdclk->vco. The logic the
> > driver is using today doesn't account for the potential use of
> > squashing, which means we program the wrong divider value into CDCLK_CTL
> > in some cases. I pointed that out during the LNL code reviews a couple
> > months ago, and I believe Stan is working on fixing that.
>
> The code should be correct as is, but it does assume that the cd2x
> divider is 2 when squashing is used. If that no longer holds then we
> have to change something.
So we need to have some kind of a consensus/agreement here, whether are we
modify the
calculation function and remove divider from the table, or do we just
use the value from the table.
So which approach is better?
Stan
>
> >
> > I wonder if the misprogramming we're doing today is what requires the
> > "HACK" at the bottom of intel_crtc_compute_min_cdclk for DG2?
> >
> >
> > Matt
> >
> > >
> > > Cc: Matt Roper
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Gustavo Sousa
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 269 ++---
> > > 1 file changed, 134 insertions(+), 135 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index b93d1ad7936d..7f85a216ff5c 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -1227,183 +1227,182 @@ struct intel_cdclk_vals {
> > > u32 cdclk;
> > > u16 refclk;
> > > u16 waveform;
> > > - u8 divider; /* CD2X divider * 2 */
> > > u8 ratio;
> > > };
> > >
> > > static const struct intel_cdclk_vals bxt_cdclk_table[] = {
> > > - { .refclk = 19200, .cdclk = 144000, .divider = 8, .ratio = 60 },
> > > - { .refclk = 19200, .cdclk = 288000, .divider = 4, .ratio = 60 },
> > > - { .refclk = 19200, .cdclk = 384000, .divider = 3, .ratio = 60 },
> > > - { .refclk = 19200, .cdclk = 576000, .divider = 2, .ratio = 60 },
> > > - { .refclk = 19200, .cdclk = 624000, .divider = 2, .ratio = 65 },
> > > + { .refclk = 19200, .cdclk = 144000, .ratio = 60 },
> > > + { .refclk = 19200, .cdclk = 288000, .ratio = 60 },
> > > + { .refclk = 19200, .cdclk = 384000, .ratio = 60 },
> > > + { .refclk = 19200, .cdclk = 576000, .ratio = 60 },
> > > + { .refclk = 19200, .cdclk = 624000, .ratio = 65 },
> > > {}
> > > };
> > >
> > > static const struct intel_cdclk_vals glk_cdclk_table[] = {
> > > - { .refclk = 19200, .cdclk = 79200, .divider = 8, .ratio = 33 },
> > > - { .refclk = 19200, .cdclk = 158400, .divider = 4, .ratio = 33 },
> > > - { .refclk = 19200, .cdclk = 316800, .divider = 2, .ratio = 33 },
> > > + { .refclk = 19200, .cdclk = 79200, .ratio = 33 },
> > > + { .refclk = 19200, .cdclk = 158400, .ratio = 33 },
> > > + { .refclk = 19200, .cdclk = 316800, .ratio = 33 },
> > > {}
> > > };
> > >
> > > static const struct intel_cdclk_vals icl_cdclk_table[] = {
> > > - { .refclk = 19200, .cdclk = 172800, .divider = 2, .ratio = 18 },
> > > - { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20 },
> > > - { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32 },
> > > - { .refclk = 19200, .cdclk = 326400, .divider = 4, .ratio = 68 },
> > > - { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58 },
> > > - { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68 },
> > > -
> > > - { .refclk = 24000, .cdclk = 18, .divider = 2, .ratio = 15 },
> > > - { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16 },
> > > - { .refclk = 24000, .cdclk = 312000, .divider = 2, .ratio = 26 },
> > > - { .refclk = 24000, .cdclk = 324000, .divider = 4, .ratio = 54 },
> > > - { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46 },
> > > - { .refclk = 24000, .cdclk = 648000, .divider = 2, .ratio = 54 },
> > > -
> > > - { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 9 },
> > > - { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 10 },
> > > - { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16 },
> > > - { .refclk = 38400, .cdclk = 326400, .divider = 4, .ratio = 34 },
> > > - { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29 },
> > > - { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34 },
> > > + { .refclk = 19200, .cdclk = 172800, .ratio = 18 },
> > > + { .refclk = 19200, .cdclk = 192000, .ratio = 20 },
> > > + { .refclk = 19200, .cdclk = 307200, .ratio = 32 },
> > > + { .refclk = 19200, .cdclk = 3264
Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Remove divider field from tables
On Mon, Nov 27, 2023 at 08:21:46AM -0800, Matt Roper wrote:
> On Fri, Nov 24, 2023 at 05:55:23PM -0300, Gustavo Sousa wrote:
> > The cdclk tables were introduced with commit 736da8112fee ("drm/i915:
> > Use literal representation of cdclk tables"). It has been almost 4 years
> > and the divider field was not really used yet. Let's remove it.
>
> I think we need to go the other way and actually start using it instead
> of (incorrectly) trying to re-derive it from cdclk->vco. The logic the
> driver is using today doesn't account for the potential use of
> squashing, which means we program the wrong divider value into CDCLK_CTL
> in some cases. I pointed that out during the LNL code reviews a couple
> months ago, and I believe Stan is working on fixing that.
The code should be correct as is, but it does assume that the cd2x
divider is 2 when squashing is used. If that no longer holds then we
have to change something.
>
> I wonder if the misprogramming we're doing today is what requires the
> "HACK" at the bottom of intel_crtc_compute_min_cdclk for DG2?
>
>
> Matt
>
> >
> > Cc: Matt Roper
> > Cc: Ville Syrjälä
> > Signed-off-by: Gustavo Sousa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 269 ++---
> > 1 file changed, 134 insertions(+), 135 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index b93d1ad7936d..7f85a216ff5c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1227,183 +1227,182 @@ struct intel_cdclk_vals {
> > u32 cdclk;
> > u16 refclk;
> > u16 waveform;
> > - u8 divider; /* CD2X divider * 2 */
> > u8 ratio;
> > };
> >
> > static const struct intel_cdclk_vals bxt_cdclk_table[] = {
> > - { .refclk = 19200, .cdclk = 144000, .divider = 8, .ratio = 60 },
> > - { .refclk = 19200, .cdclk = 288000, .divider = 4, .ratio = 60 },
> > - { .refclk = 19200, .cdclk = 384000, .divider = 3, .ratio = 60 },
> > - { .refclk = 19200, .cdclk = 576000, .divider = 2, .ratio = 60 },
> > - { .refclk = 19200, .cdclk = 624000, .divider = 2, .ratio = 65 },
> > + { .refclk = 19200, .cdclk = 144000, .ratio = 60 },
> > + { .refclk = 19200, .cdclk = 288000, .ratio = 60 },
> > + { .refclk = 19200, .cdclk = 384000, .ratio = 60 },
> > + { .refclk = 19200, .cdclk = 576000, .ratio = 60 },
> > + { .refclk = 19200, .cdclk = 624000, .ratio = 65 },
> > {}
> > };
> >
> > static const struct intel_cdclk_vals glk_cdclk_table[] = {
> > - { .refclk = 19200, .cdclk = 79200, .divider = 8, .ratio = 33 },
> > - { .refclk = 19200, .cdclk = 158400, .divider = 4, .ratio = 33 },
> > - { .refclk = 19200, .cdclk = 316800, .divider = 2, .ratio = 33 },
> > + { .refclk = 19200, .cdclk = 79200, .ratio = 33 },
> > + { .refclk = 19200, .cdclk = 158400, .ratio = 33 },
> > + { .refclk = 19200, .cdclk = 316800, .ratio = 33 },
> > {}
> > };
> >
> > static const struct intel_cdclk_vals icl_cdclk_table[] = {
> > - { .refclk = 19200, .cdclk = 172800, .divider = 2, .ratio = 18 },
> > - { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20 },
> > - { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32 },
> > - { .refclk = 19200, .cdclk = 326400, .divider = 4, .ratio = 68 },
> > - { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58 },
> > - { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68 },
> > -
> > - { .refclk = 24000, .cdclk = 18, .divider = 2, .ratio = 15 },
> > - { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16 },
> > - { .refclk = 24000, .cdclk = 312000, .divider = 2, .ratio = 26 },
> > - { .refclk = 24000, .cdclk = 324000, .divider = 4, .ratio = 54 },
> > - { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46 },
> > - { .refclk = 24000, .cdclk = 648000, .divider = 2, .ratio = 54 },
> > -
> > - { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 9 },
> > - { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 10 },
> > - { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16 },
> > - { .refclk = 38400, .cdclk = 326400, .divider = 4, .ratio = 34 },
> > - { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29 },
> > - { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34 },
> > + { .refclk = 19200, .cdclk = 172800, .ratio = 18 },
> > + { .refclk = 19200, .cdclk = 192000, .ratio = 20 },
> > + { .refclk = 19200, .cdclk = 307200, .ratio = 32 },
> > + { .refclk = 19200, .cdclk = 326400, .ratio = 68 },
> > + { .refclk = 19200, .cdclk = 556800, .ratio = 58 },
> > + { .refclk = 19200, .cdclk = 652800, .ratio = 68 },
> > +
> > + { .refclk = 24000, .cdclk = 18, .ratio = 15 },
> > + { .refclk = 24000, .cdclk = 192000, .ratio = 16 },
> > + { .refclk = 24000, .cdclk = 312000, .ratio = 26 },
> > + { .refclk = 24000, .cdclk = 324000, .ratio = 54 },
> > +
[Intel-gfx] [PATCH 3/3] drm/i915: Disable SAGV on bw init, to force QGV point recalculation
Problem is that on some platforms, we do get QGV point mask in wrong
state on boot. However driver assumes it is set to 0
(i.e all points allowed), however in reality we might get them all restricted,
causing issues.
Lets disable SAGV initially to force proper QGV point state.
If more QGV points are available, driver will recalculate and update
those then after next commit.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_bw.c | 20 +++-
drivers/gpu/drm/i915/display/intel_bw.h | 1 +
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index efd408e96e8a..f23f9f952de3 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -679,6 +679,9 @@ void intel_bw_init_hw(struct drm_i915_private *dev_priv)
tgl_get_bw_info(dev_priv, &tgl_sa_info);
else if (DISPLAY_VER(dev_priv) == 11)
icl_get_bw_info(dev_priv, &icl_sa_info);
+
+ if (DISPLAY_VER(dev_priv) < 14)
+ icl_force_disable_sagv(dev_priv);
}
static unsigned int intel_bw_crtc_num_active_planes(const struct
intel_crtc_state *crtc_state)
@@ -844,7 +847,7 @@ static unsigned int icl_max_bw_qgv_point(struct
drm_i915_private *i915,
return max_bw_point;
}
-unsigned int icl_max_bw_psf_gv_point(struct drm_i915_private *i915)
+static unsigned int icl_max_bw_psf_gv_point(struct drm_i915_private *i915)
{
unsigned int num_psf_gv_points =
i915->display.bw.max[0].num_psf_gv_points;
unsigned int max_bw = 0;
@@ -863,6 +866,21 @@ unsigned int icl_max_bw_psf_gv_point(struct
drm_i915_private *i915)
return max_bw_point;
}
+int icl_force_disable_sagv(struct drm_i915_private *i915)
+{
+ unsigned int max_bw_qgv_point = icl_max_bw_qgv_point(i915, 0);
+ unsigned int max_bw_psf_gv_point = icl_max_bw_psf_gv_point(i915);
+ unsigned int qgv_points;
+ unsigned int psf_points;
+
+ qgv_points = BIT(max_bw_qgv_point);
+ psf_points = BIT(max_bw_psf_gv_point);
+
+ return icl_pcode_restrict_qgv_points(i915,
~(ICL_PCODE_REQ_QGV_PT(qgv_points) |
+ADLS_PCODE_REQ_PSF_PT(psf_points))
&
+icl_qgv_points_mask(i915));
+}
+
static int mtl_find_qgv_points(struct drm_i915_private *i915,
unsigned int data_rate,
unsigned int num_active_planes,
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
b/drivers/gpu/drm/i915/display/intel_bw.h
index 59cb4fc5db76..74acce1ef107 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -74,5 +74,6 @@ int intel_bw_calc_min_cdclk(struct intel_atomic_state *state,
bool *need_cdclk_calc);
int intel_bw_min_cdclk(struct drm_i915_private *i915,
const struct intel_bw_state *bw_state);
+int icl_force_disable_sagv(struct drm_i915_private *dev_priv);
#endif /* __INTEL_BW_H__ */
--
2.37.3
[Intel-gfx] [PATCH 1/3] drm/i915: Add meaningful traces for QGV point info error handling
For debug purposes we need those - error path won't flood the log,
however there has been already numerous cases, when due to lack
of debugs, we couldn't immediately tell what was the problem on
customer machine, which slowed down the investigation, requiring
to get access to target device and adding those traces manually.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_bw.c | 4 +++-
drivers/gpu/drm/i915/soc/intel_dram.c | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index bef96db62c80..583cd2ebdf89 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -289,8 +289,10 @@ static int icl_get_qgv_points(struct drm_i915_private
*dev_priv,
struct intel_qgv_point *sp = &qi->points[i];
ret = intel_read_qgv_point_info(dev_priv, sp, i);
- if (ret)
+ if (ret) {
+ drm_dbg_kms(&dev_priv->drm, "Could not read QGV %d
info\n", i);
return ret;
+ }
drm_dbg_kms(&dev_priv->drm,
"QGV %d: DCLK=%d tRP=%d tRDPRE=%d tRAS=%d tRCD=%d
tRC=%d\n",
diff --git a/drivers/gpu/drm/i915/soc/intel_dram.c
b/drivers/gpu/drm/i915/soc/intel_dram.c
index 15492b69f698..37d61dff50a8 100644
--- a/drivers/gpu/drm/i915/soc/intel_dram.c
+++ b/drivers/gpu/drm/i915/soc/intel_dram.c
@@ -647,6 +647,8 @@ static int xelpdp_get_dram_info(struct drm_i915_private
*i915)
dram_info->num_channels = REG_FIELD_GET(MTL_N_OF_POPULATED_CH_MASK,
val);
dram_info->num_qgv_points =
REG_FIELD_GET(MTL_N_OF_ENABLED_QGV_POINTS_MASK, val);
+ drm_dbg_kms(&i915->drm, "Num qgv points from
MTL_N_OF_ENABLED_QGV_POINTS_MASK reg: %d\n",
+ dram_info->num_qgv_points);
/* PSF GV points not supported in D14+ */
return 0;
--
2.37.3
[Intel-gfx] [PATCH 2/3] drm/i915: Extract code required to calculate max qgv/psf gv point
We need that in order to force disable SAGV in next patch.
Also it is beneficial to separate that code, as in majority cases,
when SAGV is enabled, we don't even need those calculations.
Also we probably need to determine max PSF GV point as well, however
currently we don't do that when we disable SAGV, which might be
actually causing some issues in that case.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_bw.c | 82 -
1 file changed, 65 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 583cd2ebdf89..efd408e96e8a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -805,6 +805,64 @@ intel_atomic_get_bw_state(struct intel_atomic_state *state)
return to_intel_bw_state(bw_state);
}
+static unsigned int icl_max_bw_qgv_point(struct drm_i915_private *i915,
+int num_active_planes)
+{
+ unsigned int max_bw_point = 0;
+ unsigned int max_bw = 0;
+ unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
+ int i;
+
+ for (i = 0; i < num_qgv_points; i++) {
+ unsigned int idx;
+ unsigned int max_data_rate;
+
+ if (DISPLAY_VER(i915) > 11)
+ idx = tgl_max_bw_index(i915, num_active_planes, i);
+ else
+ idx = icl_max_bw_index(i915, num_active_planes, i);
+
+ if (idx >= ARRAY_SIZE(i915->display.bw.max))
+ continue;
+
+ max_data_rate = i915->display.bw.max[idx].deratedbw[i];
+
+ /*
+* We need to know which qgv point gives us
+* maximum bandwidth in order to disable SAGV
+* if we find that we exceed SAGV block time
+* with watermarks. By that moment we already
+* have those, as it is calculated earlier in
+* intel_atomic_check,
+*/
+ if (max_data_rate > max_bw) {
+ max_bw_point = i;
+ max_bw = max_data_rate;
+ }
+ }
+
+ return max_bw_point;
+}
+
+unsigned int icl_max_bw_psf_gv_point(struct drm_i915_private *i915)
+{
+ unsigned int num_psf_gv_points =
i915->display.bw.max[0].num_psf_gv_points;
+ unsigned int max_bw = 0;
+ unsigned int max_bw_point = 0;
+ int i;
+
+ for (i = 0; i < num_psf_gv_points; i++) {
+ unsigned int max_data_rate = adl_psf_bw(i915, i);
+
+ if (max_data_rate > max_bw) {
+ max_bw_point = i;
+ max_bw = max_data_rate;
+ }
+ }
+
+ return max_bw_point;
+}
+
static int mtl_find_qgv_points(struct drm_i915_private *i915,
unsigned int data_rate,
unsigned int num_active_planes,
@@ -882,8 +940,6 @@ static int icl_find_qgv_points(struct drm_i915_private
*i915,
const struct intel_bw_state *old_bw_state,
struct intel_bw_state *new_bw_state)
{
- unsigned int max_bw_point = 0;
- unsigned int max_bw = 0;
unsigned int num_psf_gv_points =
i915->display.bw.max[0].num_psf_gv_points;
unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
u16 psf_points = 0;
@@ -909,18 +965,6 @@ static int icl_find_qgv_points(struct drm_i915_private
*i915,
max_data_rate = i915->display.bw.max[idx].deratedbw[i];
- /*
-* We need to know which qgv point gives us
-* maximum bandwidth in order to disable SAGV
-* if we find that we exceed SAGV block time
-* with watermarks. By that moment we already
-* have those, as it is calculated earlier in
-* intel_atomic_check,
-*/
- if (max_data_rate > max_bw) {
- max_bw_point = i;
- max_bw = max_data_rate;
- }
if (max_data_rate >= data_rate)
qgv_points |= BIT(i);
@@ -964,9 +1008,13 @@ static int icl_find_qgv_points(struct drm_i915_private
*i915,
* cause.
*/
if (!intel_can_enable_sagv(i915, new_bw_state)) {
- qgv_points = BIT(max_bw_point);
- drm_dbg_kms(&i915->drm, "No SAGV, using single QGV point %d\n",
- max_bw_point);
+ unsigned int max_bw_qgv_point = icl_max_bw_qgv_point(i915,
num_active_planes);
+ unsigned int max_bw_psf_gv_point =
icl_max_bw_psf_gv_point(i915);
+
+ qgv_points = BIT(max_bw_qgv_point);
+ psf_points = BIT(max_bw_psf_gv_point);
+ drm_dbg_kms(&i915->drm, "
[Intel-gfx] [PATCH 0/3] QGV/SAGV related fixes
We have couple of customer issues, related to SAGV/QGV point calculation. Those patches contain fixes plus some additional debugs for those issues. Stanislav Lisovskiy (3): drm/i915: Add meaningful traces for QGV point info error handling drm/i915: Extract code required to calculate max qgv/psf gv point drm/i915: Disable SAGV on bw init, to force QGV point recalculation drivers/gpu/drm/i915/display/intel_bw.c | 104 drivers/gpu/drm/i915/display/intel_bw.h | 1 + drivers/gpu/drm/i915/soc/intel_dram.c | 2 + 3 files changed, 89 insertions(+), 18 deletions(-) -- 2.37.3
