✗ Fi.CI.SPARSE: warning for drm/xe/display: Disable aux ccs framebuffers (rev2)
== Series Details == Series: drm/xe/display: Disable aux ccs framebuffers (rev2) URL : https://patchwork.freedesktop.org/series/128122/ 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' +./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: unreplaced symbol 'mask'
✗ Fi.CI.CHECKPATCH: warning for drm/xe/display: Disable aux ccs framebuffers (rev2)
== Series Details == Series: drm/xe/display: Disable aux ccs framebuffers (rev2) URL : https://patchwork.freedesktop.org/series/128122/ State : warning == Summary == Error: dim checkpatch failed d0298b6981a0 drm/xe/display: Disable aux ccs framebuffers Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:27: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #27: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 194 lines checked
✗ Fi.CI.BAT: failure for drm/i915/display: Skip C10 state verification in case of fastset (rev3)
== Series Details ==
Series: drm/i915/display: Skip C10 state verification in case of fastset (rev3)
URL : https://patchwork.freedesktop.org/series/127966/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14076 -> Patchwork_127966v3
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_127966v3 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_127966v3, 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_127966v3/index.html
Participating hosts (38 -> 36)
--
Missing(2): bat-rpls-2 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_127966v3:
### IGT changes ###
Possible regressions
* igt@gem_exec_fence@basic-await@bcs0:
- bat-adln-1: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/bat-adln-1/igt@gem_exec_fence@basic-aw...@bcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127966v3/bat-adln-1/igt@gem_exec_fence@basic-aw...@bcs0.html
* igt@i915_module_load@reload:
- fi-kbl-7567u: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/fi-kbl-7567u/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127966v3/fi-kbl-7567u/igt@i915_module_l...@reload.html
* igt@kms_pipe_crc_basic@hang-read-crc@pipe-c-dp-1:
- fi-kbl-7567u: [PASS][5] -> [DMESG-FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/fi-kbl-7567u/igt@kms_pipe_crc_basic@hang-read-...@pipe-c-dp-1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127966v3/fi-kbl-7567u/igt@kms_pipe_crc_basic@hang-read-...@pipe-c-dp-1.html
Known issues
Here are the changes found in Patchwork_127966v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-7567u: [PASS][7] -> [DMESG-WARN][8] ([i915#9730]) +31 other
tests dmesg-warn
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127966v3/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-kbl-7567u: [PASS][9] -> [DMESG-WARN][10] ([i915#180])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/fi-kbl-7567u/igt@i915_susp...@basic-s2idle-without-i915.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127966v3/fi-kbl-7567u/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_pm_rpm@basic-pci-d3-state:
- fi-kbl-7567u: [PASS][11] -> [DMESG-WARN][12] ([i915#8585]) +12
other tests dmesg-warn
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/fi-kbl-7567u/igt@kms_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127966v3/fi-kbl-7567u/igt@kms_pm_...@basic-pci-d3-state.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#8585]: https://gitlab.freedesktop.org/drm/intel/issues/8585
[i915#9730]: https://gitlab.freedesktop.org/drm/intel/issues/9730
[i915#9920]: https://gitlab.freedesktop.org/drm/intel/issues/9920
Build changes
-
* Linux: CI_DRM_14076 -> Patchwork_127966v3
CI-20190529: 20190529
CI_DRM_14076: 6fb23c8c47c3c76c9ea4e62d3e4244eb42a6d081 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7655: ddf7cf40a00caa7d02f3729e1e50f78f102463d9 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_127966v3: 6fb23c8c47c3c76c9ea4e62d3e4244eb42a6d081 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
83a1d5fbb5f6 drm/i915/display: Skip C10 state verification in case of fastset
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127966v3/index.html
✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Skip C10 state verification in case of fastset (rev3)
== Series Details == Series: drm/i915/display: Skip C10 state verification in case of fastset (rev3) URL : https://patchwork.freedesktop.org/series/127966/ State : warning == Summary == Error: dim checkpatch failed 13b2c73352d0 drm/i915/display: Skip C10 state verification in case of fastset -:8: WARNING:TYPO_SPELLING: 'verfication' may be misspelled - perhaps 'verification'? #8: verfication compares bios programmed PLL values against ^^^ total: 0 errors, 1 warnings, 0 checks, 9 lines checked
Re: [PATCH v2] drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors
On Wed, 2024-01-03 at 17:26 +0200, Imre Deak wrote:
> MST connectors don't have a static attached encoder, as their encoder
> can change depending on the pipe they use; so the encoder for an MST
> connector can't be retrieved using intel_dp_attached_encoder() (which
> may return NULL for MST). Most of the PSR debugfs entries depend on a
> static connector -> encoder mapping which is only true for eDP and
> SST
> DP connectors and not for MST. These debugfs entries were enabled for
> MST connectors as well recently to provide PR information for them,
> but
> handling MST connectors needs more changes.
>
> Fix this by not adding for now the PSR entries on MST connectors. To
> make things more uniform add the entries for SST connectors on all
> platforms, not just on platforms supporting DP2.0.
>
> v2:
> - Keep adding the entries for SST connectors. (Jouni)
> - Add a TODO: comment for MST support.
Reviewed-by: Jouni Högander
>
> Fixes: ef75c25e8fed ("drm/i915/panelreplay: Debugfs support for panel
> replay")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9850
> Cc: Animesh Manna
> Cc: Jouni Högander
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 494d08817d71e..54120b45958b0 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -3310,11 +3310,11 @@ void intel_psr_connector_debugfs_add(struct
> intel_connector *connector)
> struct drm_i915_private *i915 = to_i915(connector->base.dev);
> struct dentry *root = connector->base.debugfs_entry;
>
> - if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
> {
> - if (!(HAS_DP20(i915) &&
> - connector->base.connector_type ==
> DRM_MODE_CONNECTOR_DisplayPort))
> - return;
> - }
> + /* TODO: Add support for MST connectors as well. */
> + if ((connector->base.connector_type != DRM_MODE_CONNECTOR_eDP
> &&
> + connector->base.connector_type !=
> DRM_MODE_CONNECTOR_DisplayPort) ||
> + connector->mst_port)
> + return;
>
> debugfs_create_file("i915_psr_sink_status", 0444, root,
> connector, _psr_sink_status_fops);
✗ Fi.CI.BAT: failure for drm/i915/display/dp: 128/132b DP-capable with SST (rev2)
== Series Details ==
Series: drm/i915/display/dp: 128/132b DP-capable with SST (rev2)
URL : https://patchwork.freedesktop.org/series/128147/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14076 -> Patchwork_128147v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_128147v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_128147v2, 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_128147v2/index.html
Participating hosts (38 -> 37)
--
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_128147v2:
### IGT changes ###
Possible regressions
* igt@kms_addfb_basic@invalid-set-prop:
- fi-kbl-7567u: [PASS][1] -> [DMESG-WARN][2] +37 other tests
dmesg-warn
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/fi-kbl-7567u/igt@kms_addfb_ba...@invalid-set-prop.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128147v2/fi-kbl-7567u/igt@kms_addfb_ba...@invalid-set-prop.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_contexts:
- {bat-adls-6}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/bat-adls-6/igt@i915_selftest@live@gt_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128147v2/bat-adls-6/igt@i915_selftest@live@gt_contexts.html
Known issues
Here are the changes found in Patchwork_128147v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@info:
- bat-kbl-2: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1849])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128147v2/bat-kbl-2/igt@fb...@info.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2: NOTRUN -> [SKIP][6] ([fdo#109271]) +36 other tests
skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128147v2/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_module_load@load:
- bat-adlp-6: [PASS][7] -> [INCOMPLETE][8] ([i915#8449])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/bat-adlp-6/igt@i915_module_l...@load.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128147v2/bat-adlp-6/igt@i915_module_l...@load.html
* igt@i915_selftest@live@sanitycheck:
- fi-kbl-7567u: [PASS][9] -> [DMESG-WARN][10] ([i915#9730]) +36 other
tests dmesg-warn
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/fi-kbl-7567u/igt@i915_selftest@l...@sanitycheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128147v2/fi-kbl-7567u/igt@i915_selftest@l...@sanitycheck.html
* igt@kms_busy@basic@flip:
- fi-kbl-7567u: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +29 other
tests dmesg-warn
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/fi-kbl-7567u/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128147v2/fi-kbl-7567u/igt@kms_busy@ba...@flip.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][13] -> [ABORT][14] ([i915#8668])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128147v2/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
* igt@kms_pm_rpm@basic-pci-d3-state:
- fi-kbl-7567u: [PASS][15] -> [DMESG-WARN][16] ([i915#180] /
[i915#8585]) +16 other tests dmesg-warn
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/fi-kbl-7567u/igt@kms_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128147v2/fi-kbl-7567u/igt@kms_pm_...@basic-pci-d3-state.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-7567u: [PASS][17] -> [DMESG-WARN][18] ([i915#8585]) +3 other
tests dmesg-warn
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/fi-kbl-7567u/igt@prime_v...@basic-fence-flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128147v2/fi-kbl-7567u/igt@prime_v...@basic-fence-flip.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
✗ Fi.CI.CHECKPATCH: warning for drm/i915/display/dp: 128/132b DP-capable with SST (rev2)
== Series Details == Series: drm/i915/display/dp: 128/132b DP-capable with SST (rev2) URL : https://patchwork.freedesktop.org/series/128147/ State : warning == Summary == Error: dim checkpatch failed 3745b837c1be drm/i915/display/dp: 128/132b DP-capable with SST -:29: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line #29: FILE: drivers/gpu/drm/i915/display/intel_dp.c:4047: + drm_dp_is_uhbr_rate(intel_dp_max_common_rate(intel_dp))) + && i915->display.params.enable_dp_mst; total: 0 errors, 0 warnings, 1 checks, 15 lines checked
Re: [PATCH] nightly.conf: Add the xe repo to drm-tip
On Wed, Jan 03, 2024 at 02:50:57PM +0100, Thomas Hellström wrote: On Tue, 2023-12-26 at 13:30 -0500, Rodrigo Vivi wrote: On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote: > Add the xe repo to drm-tip and the dim tools. > For now use the sha1 of the first drm-xe-next pull request for drm- > tip, > since that branch tip is currently adapted for our CI testing. > > Cc: Rodrigo Vivi > Cc: Lucas De Marchi > Cc: Oded Gabbay > Cc: daniel.vet...@ffwll.ch > Cc: Maarten Lankhorst > Cc: dim-to...@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Signed-off-by: Thomas Hellström > --- > nightly.conf | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/nightly.conf b/nightly.conf > index 24126b61b797..accd3ff2cc39 100644 > --- a/nightly.conf > +++ b/nightly.conf > @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip > https://anongit.freedesktop.org/git/drm/drm-tip > https://anongit.freedesktop.org/git/drm/drm-tip.git > " > +drm_tip_repos[drm-xe]=" > +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git > +https://gitlab.freedesktop.org/drm/xe/kernel.git > +" > drm_tip_repos[drm-intel]=" > ssh://git.freedesktop.org/git/drm/drm-intel > ssh://git.freedesktop.org/git/drm-intel > @@ -65,14 +69,17 @@ drm_tip_config=( > "drm drm-fixes" > "drm-misc drm-misc-fixes" > "drm-intel drm-intel-fixes" > + "drm-xedrm-xe-fixes" > > "drm drm-next" > "drm-misc drm-misc-next-fixes" > "drm-intel drm-intel-next-fixes" > + "drm-xedrm-xe-next-fixes" > > "drm-misc drm-misc-next" > "drm-intel drm-intel-next" > "drm-intel drm-intel-gt-next" > + "drm-xedrm-xe-next b6e1b7081768" yeap, up to this commit nothing else should change, but then we will need an extra rebase of the rest on top of drm/drm-next. But then we need to decide where these following patches will live: 880277f31cc69 drm/xe/guc: define LNL FW 2cfc5ae1b8267 drm/xe/guc: define PVC FW 52383b58eb8cf mei/hdcp: Also enable for XE bea27d7369855 mei: gsc: add support for auxiliary device created by Xe driver fcb3410197f05 fault-inject: Include linux/types.h by default. 8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs Will it be the topic/core-for-CI? or topic/xe-extras? or what? This sounds to me like topic/core-for-CI? Or is there any drawback with that? I think some of them are not really a "for CI". It's more like the workflow we are adopting e.g. with guc/huc, not sending it to linux-firmware until we are confident on what version we will start officially supporting. This one can't go to topic/core-for-CI neither: fcb3410197f05 fault-inject: Include linux/types.h by default. what it would do would be that we would not see the build error anymore, but everyone else would (and it's not a CI-only configuration). Unless it's merged to another branch, we shouldn't merge it. "52383b58eb8cf mei/hdcp: Also enable for XE" could be material for topic/core-for-CI and "8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs" could either be on that branch or another xe-specific one. Anyway, for the inclusion like this, after our CI is ready: Could we merge this patch already at this point, considering it will, at least for now, only update drm-tip with our fixes? ack Lucas De Marchi Thanks, /Thomas Acked-by: Rodrigo Vivi > > "drm-intel topic/core-for-CI" > "drm-misc topic/i915-ttm" > -- > 2.42.0 >
✗ Fi.CI.BAT: failure for Update bxt_sanitize_cdclk() for Xe2_LPD
== Series Details ==
Series: Update bxt_sanitize_cdclk() for Xe2_LPD
URL : https://patchwork.freedesktop.org/series/128175/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14076 -> Patchwork_128175v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_128175v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_128175v1, 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_128175v1/index.html
Participating hosts (38 -> 17)
--
ERROR: It appears as if the changes made in Patchwork_128175v1 prevented too
many machines from booting.
Additional (1): bat-kbl-2
Missing(22): fi-rkl-11600 fi-snb-2520m bat-rpls-3 bat-adls-6 fi-pnv-d510
fi-blb-e6850 fi-skl-6600u fi-bsw-n3050 fi-ilk-650 fi-ivb-3770 fi-elk-e7500
bat-rplp-1 bat-jsl-3 fi-kbl-7567u bat-dg1-7 fi-skl-guc bat-jsl-1 bat-mtlp-6
fi-tgl-1115g4 fi-cfl-guc fi-cfl-8109u bat-dg2-14
Known issues
Here are the changes found in Patchwork_128175v1 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_128175v1/bat-kbl-2/igt@fb...@info.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2: NOTRUN -> [SKIP][2] ([fdo#109271]) +36 other tests
skip
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128175v1/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_selftest@live@workarounds:
- bat-dg2-11: [PASS][3] -> [DMESG-FAIL][4] ([i915#9500])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/bat-dg2-11/igt@i915_selftest@l...@workarounds.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128175v1/bat-dg2-11/igt@i915_selftest@l...@workarounds.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#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#9500]: https://gitlab.freedesktop.org/drm/intel/issues/9500
Build changes
-
* Linux: CI_DRM_14076 -> Patchwork_128175v1
CI-20190529: 20190529
CI_DRM_14076: 6fb23c8c47c3c76c9ea4e62d3e4244eb42a6d081 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7655: ddf7cf40a00caa7d02f3729e1e50f78f102463d9 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_128175v1: 6fb23c8c47c3c76c9ea4e62d3e4244eb42a6d081 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
828d7c8a65d8 drm/i915/cdclk: Re-use bxt_cdclk_ctl() when sanitizing
bc69f75f43c2 drm/i915/cdclk: Reorder bxt_sanitize_cdclk()
ad0655315b55 drm/i915/cdclk: Extract bxt_cdclk_ctl()
cb932418fd32 drm/i915/xe2lpd: Update bxt_sanitize_cdclk()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128175v1/index.html
[PATCH 1/4] drm/i915/xe2lpd: Update bxt_sanitize_cdclk()
With Xe2_LPD, there were changes to the way CDCLK_CTL must be
programmed. Those were reflected on _bxt_set_cdclk() with commit
3d3696c0fed1 ("drm/i915/lnl: Start using CDCLK through PLL"), but
bxt_sanitize_cdclk() was left out.
This was causing some issues when loading the driver with a pre-existing
active display configuration: the driver would mistakenly take the
current value of CDCLK_CTL as wrong and the sanitization would be
triggered.
In a scenario where the display was already configured with a high
CDCLKC and had plane(s) enabled, FIFO underrun errors were reported,
because the current sanitization code selects the minimum possible
CDCLK.
Fix that by updating bxt_sanitize_cdclk() to match the changes made in
_bxt_set_cdclk(). Ideally, we would have a common function to derive the
value for CDCLK_CTL, but that can be done in a future change.
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index c5fecde7afa8..0012e3171f3f 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2071,7 +2071,10 @@ static void bxt_sanitize_cdclk(struct drm_i915_private
*dev_priv)
if (vco != dev_priv->display.cdclk.hw.vco)
goto sanitize;
- expected = skl_cdclk_decimal(cdclk);
+ if (DISPLAY_VER(dev_priv) >= 20)
+ expected = MDCLK_SOURCE_SEL_CDCLK_PLL;
+ else
+ expected = skl_cdclk_decimal(cdclk);
/* Figure out what CD2X divider we should be using for this cdclk */
if (HAS_CDCLK_SQUASH(dev_priv))
--
2.43.0
[PATCH 3/4] drm/i915/cdclk: Reorder bxt_sanitize_cdclk()
Make the sequence of steps more logical by grouping things related to the check on the value of CDCLK_CTL into a single "block". Also, this will make an upcoming change replacing that block with a single function call easier to follow. Signed-off-by: Gustavo Sousa --- drivers/gpu/drm/i915/display/intel_cdclk.c | 24 +++--- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c index b9354ad46fee..fbe9aba41c35 100644 --- a/drivers/gpu/drm/i915/display/intel_cdclk.c +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c @@ -2060,13 +2060,23 @@ static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv) dev_priv->display.cdclk.hw.cdclk == dev_priv->display.cdclk.hw.bypass) goto sanitize; - /* DPLL okay; verify the cdclock -* + /* Make sure this is a legal cdclk value for the platform */ + cdclk = bxt_calc_cdclk(dev_priv, dev_priv->display.cdclk.hw.cdclk); + if (cdclk != dev_priv->display.cdclk.hw.cdclk) + goto sanitize; + + /* Make sure the VCO is correct for the cdclk */ + vco = bxt_calc_cdclk_pll_vco(dev_priv, cdclk); + if (vco != dev_priv->display.cdclk.hw.vco) + goto sanitize; + + /* * Some BIOS versions leave an incorrect decimal frequency value and * set reserved MBZ bits in CDCLK_CTL at least during exiting from S4, * so sanitize this register. */ cdctl = intel_de_read(dev_priv, CDCLK_CTL); + /* * Let's ignore the pipe field, since BIOS could have configured the * dividers both synching to an active pipe, or asynchronously @@ -2074,16 +2084,6 @@ static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv) */ cdctl &= ~bxt_cdclk_cd2x_pipe(dev_priv, INVALID_PIPE); - /* Make sure this is a legal cdclk value for the platform */ - cdclk = bxt_calc_cdclk(dev_priv, dev_priv->display.cdclk.hw.cdclk); - if (cdclk != dev_priv->display.cdclk.hw.cdclk) - goto sanitize; - - /* Make sure the VCO is correct for the cdclk */ - vco = bxt_calc_cdclk_pll_vco(dev_priv, cdclk); - if (vco != dev_priv->display.cdclk.hw.vco) - goto sanitize; - if (DISPLAY_VER(dev_priv) >= 20) expected = MDCLK_SOURCE_SEL_CDCLK_PLL; else -- 2.43.0
[PATCH 0/4] Update bxt_sanitize_cdclk() for Xe2_LPD
This series fixes an issue observed during module load due to missing bits in bxt_sanitize_cdclk() specific to Xe2_LPD. The first patch contains the fix itself. The subsequent patches refactor the code so that bxt_sanitize_cdclk() and _bxt_set_cdclk() use the same function for deriving the value for CDCLK_CTL, hopefully making it harder for the same kind of problem to happen again. Gustavo Sousa (4): drm/i915/xe2lpd: Update bxt_sanitize_cdclk() drm/i915/cdclk: Extract bxt_cdclk_ctl() drm/i915/cdclk: Reorder bxt_sanitize_cdclk() drm/i915/cdclk: Re-use bxt_cdclk_ctl() when sanitizing drivers/gpu/drm/i915/display/intel_cdclk.c | 100 ++--- 1 file changed, 48 insertions(+), 52 deletions(-) -- 2.43.0
[PATCH 4/4] drm/i915/cdclk: Re-use bxt_cdclk_ctl() when sanitizing
That's the function responsible for deriving that register's value; use
it.
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index fbe9aba41c35..26200ee3e23f 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2051,7 +2051,7 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv)
{
u32 cdctl, expected;
- int cdclk, clock, vco;
+ int cdclk, vco;
intel_update_cdclk(dev_priv);
intel_cdclk_dump_config(dev_priv, _priv->display.cdclk.hw, "Current
CDCLK");
@@ -2076,6 +2076,7 @@ static void bxt_sanitize_cdclk(struct drm_i915_private
*dev_priv)
* so sanitize this register.
*/
cdctl = intel_de_read(dev_priv, CDCLK_CTL);
+ expected = bxt_cdclk_ctl(dev_priv, _priv->display.cdclk.hw,
INVALID_PIPE);
/*
* Let's ignore the pipe field, since BIOS could have configured the
@@ -2083,28 +2084,7 @@ static void bxt_sanitize_cdclk(struct drm_i915_private
*dev_priv)
* (PIPE_NONE).
*/
cdctl &= ~bxt_cdclk_cd2x_pipe(dev_priv, INVALID_PIPE);
-
- if (DISPLAY_VER(dev_priv) >= 20)
- expected = MDCLK_SOURCE_SEL_CDCLK_PLL;
- else
- expected = skl_cdclk_decimal(cdclk);
-
- /* Figure out what CD2X divider we should be using for this cdclk */
- if (HAS_CDCLK_SQUASH(dev_priv))
- clock = dev_priv->display.cdclk.hw.vco / 2;
- else
- clock = dev_priv->display.cdclk.hw.cdclk;
-
- expected |= bxt_cdclk_cd2x_div_sel(dev_priv, clock,
- dev_priv->display.cdclk.hw.vco);
-
- /*
-* Disable SSA Precharge when CD clock frequency < 500 MHz,
-* enable otherwise.
-*/
- if ((IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) &&
- dev_priv->display.cdclk.hw.cdclk >= 50)
- expected |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
+ expected &= ~bxt_cdclk_cd2x_pipe(dev_priv, INVALID_PIPE);
if (cdctl == expected)
/* All well; nothing to sanitize */
--
2.43.0
[PATCH 2/4] drm/i915/cdclk: Extract bxt_cdclk_ctl()
This makes the code better readable and will be used later in
bxt_sanitize_cdclk().
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 57 +-
1 file changed, 35 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 0012e3171f3f..b9354ad46fee 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1900,15 +1900,47 @@ static bool pll_enable_wa_needed(struct
drm_i915_private *dev_priv)
dev_priv->display.cdclk.hw.vco > 0;
}
+static u32 bxt_cdclk_ctl(struct drm_i915_private *i915,
+const struct intel_cdclk_config *cdclk_config,
+enum pipe pipe)
+{
+ int cdclk = cdclk_config->cdclk;
+ int vco = cdclk_config->vco;
+ int unsquashed_cdclk;
+ u16 waveform;
+ u32 val;
+
+ waveform = cdclk_squash_waveform(i915, cdclk);
+
+ unsquashed_cdclk = DIV_ROUND_CLOSEST(cdclk * cdclk_squash_len,
+cdclk_squash_divider(waveform));
+
+ val = bxt_cdclk_cd2x_div_sel(i915, unsquashed_cdclk, vco) |
+ bxt_cdclk_cd2x_pipe(i915, pipe);
+
+ /*
+* Disable SSA Precharge when CD clock frequency < 500 MHz,
+* enable otherwise.
+*/
+ if ((IS_GEMINILAKE(i915) || IS_BROXTON(i915)) &&
+ cdclk >= 50)
+ val |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
+
+ if (DISPLAY_VER(i915) >= 20)
+ val |= MDCLK_SOURCE_SEL_CDCLK_PLL;
+ else
+ val |= skl_cdclk_decimal(cdclk);
+
+ return val;
+}
+
static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
const struct intel_cdclk_config *cdclk_config,
enum pipe pipe)
{
int cdclk = cdclk_config->cdclk;
int vco = cdclk_config->vco;
- int unsquashed_cdclk;
u16 waveform;
- u32 val;
if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 &&
vco > 0 &&
!cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco)) {
@@ -1925,29 +1957,10 @@ static void _bxt_set_cdclk(struct drm_i915_private
*dev_priv,
waveform = cdclk_squash_waveform(dev_priv, cdclk);
- unsquashed_cdclk = DIV_ROUND_CLOSEST(cdclk * cdclk_squash_len,
-cdclk_squash_divider(waveform));
-
if (HAS_CDCLK_SQUASH(dev_priv))
dg2_cdclk_squash_program(dev_priv, waveform);
- val = bxt_cdclk_cd2x_div_sel(dev_priv, unsquashed_cdclk, vco) |
- bxt_cdclk_cd2x_pipe(dev_priv, pipe);
-
- /*
-* Disable SSA Precharge when CD clock frequency < 500 MHz,
-* enable otherwise.
-*/
- if ((IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) &&
- cdclk >= 50)
- val |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
-
- if (DISPLAY_VER(dev_priv) >= 20)
- val |= MDCLK_SOURCE_SEL_CDCLK_PLL;
- else
- val |= skl_cdclk_decimal(cdclk);
-
- intel_de_write(dev_priv, CDCLK_CTL, val);
+ intel_de_write(dev_priv, CDCLK_CTL, bxt_cdclk_ctl(dev_priv,
cdclk_config, pipe));
if (pipe != INVALID_PIPE)
intel_crtc_wait_for_next_vblank(intel_crtc_for_pipe(dev_priv,
pipe));
--
2.43.0
RE: [PATCH v2 0/4] TC phy check cleanup
Hi Jani, Thank you for that insight. I will use it for future reference. And as in this case the 1%wart looks better. Need to evaluate if having a tc_phy_mask(as pointed by Imre) in platform info will make things pretty in this case. Regards, Radhakrishna(RK) Sripada > -Original Message- > From: Jani Nikula > Sent: Friday, December 22, 2023 2:04 AM > To: Sripada, Radhakrishna ; intel- > g...@lists.freedesktop.org > Subject: RE: [PATCH v2 0/4] TC phy check cleanup > > On Fri, 22 Dec 2023, "Sripada, Radhakrishna" > wrote: > > Hi Jani, > > > >> -Original Message- > >> From: Jani Nikula > >> Sent: Thursday, December 21, 2023 2:04 AM > >> To: Sripada, Radhakrishna ; intel- > >> g...@lists.freedesktop.org > >> Subject: Re: [PATCH v2 0/4] TC phy check cleanup > >> > >> On Wed, 20 Dec 2023, Radhakrishna Sripada > > >> wrote: > >> > We are relying on end-less if-else ladders for a type-c phy > >> > capabilities check. Though it made sense when platforms supported > >> > legacy type-c support, modern platforms rely on the information > >> > passed by vbt. This cleanup restricts the if-else ladder to the > >> > platforms supporting legacy type-c phys and relies on vbt info > >> > for modern client and discrete platforms. > >> > >> This series is moving the vbt handling in the wrong direction. > >> > >> We want to *avoid* new lookups. The idea is that you do the lookup > >> *once* when initializing the encoder, and after that you use > >> encoder->devdata. > >> > >> If you look at the intel_phy_is_tc() call sites, you'll observe that > >> almost all of the places have the encoder (or devdata) already > >> available. They get the port from encoder->port, and the phy from > >> intel_port_to_phy(). > >> > >> So this throws away the information that's already available, and then > >> goes to look it up again in the worst possible way. > >> > >> You should convert intel_phy_is_tc() to something like > >> intel_encoder_is_tc(), and pass encoder to it instead of phy. Similarly, > >> intel_port_to_tc() should be converted to intel_encoder_to_tc(). > >> > >> There are a couple of special cases that only have devdata or phy. But > >> we can handle the special cases after making the common case > >> straightforward. > > Common case making a tc check out of encoder sure makes lot of sense > > And agreed to you point. The question that arises in the special cases. > > For ex. during vbt_defaults init in intel_bios.c, I can only handle for > > legacy tc > ports. > > > > In other cases where only phy info is available, I may have to iterate over > > all the > > drm_encoders to obtain port info and compare it with phy info adding lot of > lookup > > overhead. Or we may have to use encoder based lookups in all associated > lookups like > > icl_port_to_ddc_pin etc. > > > > Thoughts? > > Frankly, the way I often handle stuff like this is just start making the > changes for the things that obviously make sense. Such as looking the tc > info up via the encoder. You can add the new function(s) and gradually > switch over. It's mostly mechanical changes and pretty quick to do. I > think it'll even clean up a bunch of local enum port and enum phy > usages. > > And often the answer to the rest just presents itself. > > Sometimes the answer is, well, to leave an ugly wart in 1% of the cases > while making 99% of the cases pretty. And that's still better than > having 100% poor design. > > Sometimes you find out you have to redo some of the stuff you did at > first, but it's because you figure things out along the way. For me at > least, this is how the bright ideas come to mind more often than via up > front design attempts. > > HTH, > Jani. > > > > > > Radhakrishna(RK) Sripada > >> > >> > >> BR, > >> Jani. > >> > >> > >> > > >> > v2: Move cleanup vbt later to handle safe encoder removal > >> > > >> > Radhakrishna Sripada (4): > >> > drm/i915: Move intel_bios_driver_remove later > >> > drm/i915: Rename intel_bios_encoder_data_lookup as a port variant > >> > drm/i915: Introduce intel_encoder_phy_data_lookup > >> > drm/i915: Separate tc check for legacy and non legacy tc phys > >> > > >> > drivers/gpu/drm/i915/display/g4x_dp.c | 2 +- > >> > drivers/gpu/drm/i915/display/g4x_hdmi.c | 2 +- > >> > drivers/gpu/drm/i915/display/intel_bios.c | 15 +- > >> > drivers/gpu/drm/i915/display/intel_bios.h | 5 +++- > >> > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- > >> > drivers/gpu/drm/i915/display/intel_display.c | 29 --- > >> > .../drm/i915/display/intel_display_device.h | 1 + > >> > .../drm/i915/display/intel_display_driver.c | 4 +-- > >> > drivers/gpu/drm/i915/display/intel_dp.c | 2 +- > >> > 9 files changed, 44 insertions(+), 18 deletions(-) > >> > >> -- > >> Jani Nikula, Intel > > -- > Jani Nikula, Intel
RE: [PATCH v2 4/4] drm/i915: Separate tc check for legacy and non legacy tc phys
Hi Imre,
Thank you for the pointer. Let me evaluate and see if it is worth taking that
trouble.
Thanks,
Radhakrishna(RK) Sripada
> -Original Message-
> From: Deak, Imre
> Sent: Wednesday, January 3, 2024 8:51 AM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2 4/4] drm/i915: Separate tc check for legacy and non
> legacy tc phys
>
> On Fri, Dec 22, 2023 at 09:47:49PM +0200, Sripada, Radhakrishna wrote:
> > Hi Imre,
> >
> > I have question related to tc legacy handling. I am looking in the context
> > of
> discrete cards.
> >
> > > -Original Message-
> > > From: Deak, Imre
> > > Sent: Friday, December 22, 2023 3:44 AM
> > > To: Sripada, Radhakrishna
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Subject: Re: [PATCH v2 4/4] drm/i915: Separate tc check for legacy and non
> > > legacy tc phys
> > >
> > > On Wed, Dec 20, 2023 at 02:13:41PM -0800, Radhakrishna Sripada wrote:
> > > > Starting MTL and DG2 if a phy is not marked as USB-typeC or TBT capable
> > > > by vbt we should not consider it as a Legacy type-c phy.
> > > >
> > > > The concept of Legacy-tc existed in platforms from Icelake to Alder lake
> > > > where an external FIA can be routed to one of the phy's thus making the
> > > > phy
> > > > tc capable without being marked in the vbt.
> > > >
> > > > Discrete cards have native ports and client products post MTL have a 1:1
> > > > mapping with type-C subsystem which is advertised by the bios. So rely
> > > > on
> > > > the vbt info regarding type-c capability.
> > > >
> > > > Signed-off-by: Radhakrishna Sripada
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> > > > drivers/gpu/drm/i915/display/intel_display.c | 29 ---
> > > > .../drm/i915/display/intel_display_device.h | 1 +
> > > > 3 files changed, 21 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > index 12a29363e5df..7d5b95f97d5f 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > @@ -5100,7 +5100,7 @@ void intel_ddi_init(struct drm_i915_private
> > > *dev_priv,
> > > > }
> > > >
> > > > if (intel_phy_is_tc(dev_priv, phy)) {
> > > > - bool is_legacy =
> > > > + bool is_legacy = HAS_LEGACY_TC(dev_priv) &&
> > >
> > > This doesn't make sense to me. PHYs are either TC or non-TC (aka combo
> > > PHY) and TC PHYs can be configured to work either in legacy (a TC PHY
> > > wired to a native DP connector) or non-legacy mode (a TC PHY wired to a
> > > TC connector). So this would break the functionality on MTL native DP
> > > connectors and all future platforms I looked at which also support this.
> >
> >
> > I understand. I want to figure out a way to determine if a phy is
> > connected to FIA. Like in DG2, the phy's are not connected to FIA. I
> > am assuming that will be the case for all future discrete cards as
> > well. So instead of looking/building an if-else ladder for the phy
> > check, is there something that we can rely on viz. vbt, register etc.
> > to determine if FIA is connected to a phy?
>
> I suppose this question is if a PHY is TypeC or not, TypeC requiring
> some kind of mux (which can be FIA or something else). One other way
> instead of the if-ladder in intel_phy_is_tc() would be adding a
> tc_phy_mask to intel_display_runtime_info, similarly to the port_mask
> there. Not sure how much that would improve things over the current way.
>
> > > > !intel_bios_encoder_supports_typec_usb(devdata) &&
> > > > !intel_bios_encoder_supports_tbt(devdata);
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index b10aad15a63d..03006c9af824 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -1854,17 +1854,9 @@ bool intel_phy_is_combo(struct
> drm_i915_private
> > > *dev_priv, enum phy phy)
> > > > return false;
> > > > }
> > > >
> > > > -bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
> > > > +static bool intel_phy_is_legacy_tc(struct drm_i915_private *dev_priv,
> enum
> > > phy phy)
> > > > {
> > > > - /*
> > > > -* DG2's "TC1", although TC-capable output, doesn't share the same
> > > > flow
> > > > -* as other platforms on the display engine side and rather rely on
> > > > the
> > > > -* SNPS PHY, that is programmed separately
> > > > -*/
> > > > - if (IS_DG2(dev_priv))
> > > > - return false;
> > > > -
> > > > - if (DISPLAY_VER(dev_priv) >= 13)
> > > > + if (DISPLAY_VER(dev_priv) == 13)
> > > > return phy >= PHY_F && phy <= PHY_I;
> > > > else if (IS_TIGERLAKE(dev_priv))
> > > > return phy >= PHY_D && phy <= PHY_I;
>
RE: [PATCH] drm/i915/display: Skip C10 state verification in case of fastset
> -Original Message-
> From: Intel-gfx On Behalf Of Mika
> Kahola
> Sent: Tuesday, December 19, 2023 4:33 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/i915/display: Skip C10 state verification in case of
> fastset
>
> PLL's are not programmed in case of fastset so the state
> verfication compares bios programmed PLL values against
> sw PLL values. To overcome this limitation, we can skip
> the state verification for C10 in fastset case as the
> driver is not writing PLL values.
>
LGTM,
Reviewed-by: Radhakrishna Sripada
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 884a1da36089..3ef54eaca9e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -3016,6 +3016,9 @@ static void intel_c10pll_state_verify(const struct
> intel_crtc_state *state,
> const struct intel_c10pll_state *mpllb_sw_state =
> >cx0pll_state.c10;
> int i;
>
> + if (intel_crtc_needs_fastset(state))
> + return;
> +
> for (i = 0; i < ARRAY_SIZE(mpllb_sw_state->pll); i++) {
> u8 expected = mpllb_sw_state->pll[i];
>
> --
> 2.34.1
Re: [V2] drm/i915: Add workaround 14019877138
On Wed, Jan 03, 2024 at 11:01:11AM +0530, Tejas Upadhyay wrote: > WA 14019877138 needed for Graphics 12.70/71 both Also needed for 12.74 (which is on the mailing list but hasn't landed yet). But this change will automatically cover that too once it lands. You might want to make the prefix "drm/i915/xelpg:" since that's the specific IP that we're adding this for (we already have this workaround for DG2). But otherwise, Reviewed-by: Matt Roper > > V2(Jani): > - Use drm/i915 > > Signed-off-by: Tejas Upadhyay > --- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 3eacbc50caf8..270b56fc85e2 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -820,6 +820,9 @@ static void xelpg_ctx_workarounds_init(struct > intel_engine_cs *engine, > > /* Wa_18019271663 */ > wa_masked_en(wal, CACHE_MODE_1, MSAA_OPTIMIZATION_REDUC_DISABLE); > + > + /* Wa_14019877138 */ > + wa_mcr_masked_en(wal, XEHP_PSS_CHICKEN, FD_END_COLLECT); > } > > static void fakewa_disable_nestedbb_mode(struct intel_engine_cs *engine, > -- > 2.25.1 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
✗ Fi.CI.BAT: failure for drm/i915: Disable DSB in Xe KMD (rev2)
== Series Details ==
Series: drm/i915: Disable DSB in Xe KMD (rev2)
URL : https://patchwork.freedesktop.org/series/128163/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14073 -> Patchwork_128163v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_128163v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_128163v2, 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_128163v2/index.html
Participating hosts (39 -> 26)
--
Missing(13): bat-mtlp-8 bat-dg2-8 fi-cfl-guc fi-apl-guc fi-snb-2520m
fi-ilk-650 fi-kbl-guc fi-elk-e7500 bat-rpls-3 fi-pnv-d510 fi-cfl-8109u
bat-jsl-3 fi-skl-6600u
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_128163v2:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_timelines:
- fi-kbl-7567u: [PASS][1] -> [TIMEOUT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14073/fi-kbl-7567u/igt@i915_selftest@live@gt_timelines.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v2/fi-kbl-7567u/igt@i915_selftest@live@gt_timelines.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-kbl-7567u: [PASS][3] -> [WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14073/fi-kbl-7567u/igt@i915_susp...@basic-s2idle-without-i915.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v2/fi-kbl-7567u/igt@i915_susp...@basic-s2idle-without-i915.html
Known issues
Here are the changes found in Patchwork_128163v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][5] -> [ABORT][6] ([i915#8668])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14073/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v2/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
Possible fixes
* igt@kms_pm_rpm@basic-rte:
- bat-rpls-2: [ABORT][7] ([i915#8668] / [i915#9368] / [i915#9897])
-> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14073/bat-rpls-2/igt@kms_pm_...@basic-rte.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v2/bat-rpls-2/igt@kms_pm_...@basic-rte.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
[i915#9368]: https://gitlab.freedesktop.org/drm/intel/issues/9368
[i915#9897]: https://gitlab.freedesktop.org/drm/intel/issues/9897
Build changes
-
* Linux: CI_DRM_14073 -> Patchwork_128163v2
CI-20190529: 20190529
CI_DRM_14073: 4ff460bc8efdc2ed2d0a388ecaf1555c9de28b04 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7655: ddf7cf40a00caa7d02f3729e1e50f78f102463d9 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_128163v2: 4ff460bc8efdc2ed2d0a388ecaf1555c9de28b04 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
0646d7c34743 drm/i915: Disable DSB in Xe KMD
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v2/index.html
✗ Fi.CI.SPARSE: warning for drm/i915: Disable DSB in Xe KMD (rev2)
== Series Details == Series: drm/i915: Disable DSB in Xe KMD (rev2) URL : https://patchwork.freedesktop.org/series/128163/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[PATCH v2] drm/i915: Disable DSB in Xe KMD
Often getting DBS overflows when starting Xorg or Wayland compositors when running Xe KMD. Issue was reported but nothing was done, so disabling DSB as whole until properly fixed in Xe KMD. v2: - move check to HAS_DSB(Jani) Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/989 Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1031 Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1072 Cc: Animesh Manna Cc: Rodrigo Vivi Cc: Jani Nikula Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_display_device.h | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h b/drivers/gpu/drm/i915/display/intel_display_device.h index fe42688137863..faa49aced46a5 100644 --- a/drivers/gpu/drm/i915/display/intel_display_device.h +++ b/drivers/gpu/drm/i915/display/intel_display_device.h @@ -45,7 +45,12 @@ struct drm_printer; #define HAS_DP_MST(i915) (DISPLAY_INFO(i915)->has_dp_mst) #define HAS_DP20(i915) (IS_DG2(i915) || DISPLAY_VER(i915) >= 14) #define HAS_DPT(i915) (DISPLAY_VER(i915) >= 13) +#ifdef I915 #define HAS_DSB(i915) (DISPLAY_INFO(i915)->has_dsb) +#else +/* TODO: DSB is broken in Xe KMD, so disabling it until fixed */ +#define HAS_DSB(i915) (false) +#endif #define HAS_DSC(__i915) (DISPLAY_RUNTIME_INFO(__i915)->has_dsc) #define HAS_FBC(i915) (DISPLAY_RUNTIME_INFO(i915)->fbc_mask != 0) #define HAS_FPGA_DBG_UNCLAIMED(i915) (DISPLAY_INFO(i915)->has_fpga_dbg) -- 2.43.0
Re: ✓ Fi.CI.BAT: success for drm/i915/mtl: Add fake PCH for Meteor Lake (rev2)
On Tue, Dec 19, 2023 at 07:46:41PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/mtl: Add fake PCH for Meteor Lake (rev2)
> URL : https://patchwork.freedesktop.org/series/127963/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_14045 -> Patchwork_127963v2
>
>
> Summary
> ---
>
> **SUCCESS**
Shards results never showed up on the mailing list, but they've
visible in patchwork; neither of the failures reported there (one
on SNB, one on DG2) are related to this MTL PCH change (the SNB failure
is a lock issue outside the DRM subsystem, and the DG2 failure is a
random timeout on a GT-specific test).
Applied to drm-intel-next. Thanks for the patch.
Matt
>
> No regressions found.
>
> External URL:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127963v2/index.html
>
> Participating hosts (38 -> 37)
> --
>
> Additional (1): fi-pnv-d510
> Missing(2): bat-rpls-2 fi-snb-2520m
>
> Known issues
>
>
> Here are the changes found in Patchwork_127963v2 that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_lmem_swapping@basic:
> - fi-pnv-d510:NOTRUN -> [SKIP][1] ([fdo#109271]) +28 other tests
> skip
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127963v2/fi-pnv-d510/igt@gem_lmem_swapp...@basic.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
>
>
> Build changes
> -
>
> * Linux: CI_DRM_14045 -> Patchwork_127963v2
>
> CI-20190529: 20190529
> CI_DRM_14045: e786d8c6347b8b304e82c6bcebc0d38401792b16 @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_7648: 5c7b44f13c9c5bc15af0cb2b6a5ea10a8a468ac0 @
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
> Patchwork_127963v2: e786d8c6347b8b304e82c6bcebc0d38401792b16 @
> git://anongit.freedesktop.org/gfx-ci/linux
>
>
> ### Linux commits
>
> 22a222ed2423 drm/i915/mtl: Add fake PCH for Meteor Lake
>
> == Logs ==
>
> For more details see:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127963v2/index.html
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v9 09/25] drm/modes: Move named modes parsing to a separate function
On Wed, 3 Jan 2024 at 14:02, Dave Stevenson
wrote:
>
> Hi Maxime
>
> On Wed, 3 Jan 2024 at 13:33, Maxime Ripard wrote:
> >
> > Hi Dave,
> >
> > Happy new year :)
>
> And to you.
>
> > On Tue, Jan 02, 2024 at 03:12:26PM +, Dave Stevenson wrote:
> > > Hi Maxime
> > >
> > > On Mon, 14 Nov 2022 at 13:00, Maxime Ripard wrote:
> > > >
> > > > The current construction of the named mode parsing doesn't allow to
> > > > extend
> > > > it easily. Let's move it to a separate function so we can add more
> > > > parameters and modes.
> > > >
> > > > In order for the tests to still pass, some extra checks are needed, so
> > > > it's not a 1:1 move.
> > > >
> > > > Reviewed-by: Noralf Trønnes
> > > > Tested-by: Mateusz Kwiatkowski
> > > > Signed-off-by: Maxime Ripard
> > > >
> > > > ---
> > > > Changes in v7:
> > > > - Add Noralf Reviewed-by
> > > >
> > > > Changes in v6:
> > > > - Simplify the test for connection status extras
> > > > - Simplify the code path to call drm_mode_parse_cmdline_named_mode
> > > >
> > > > Changes in v4:
> > > > - Fold down all the named mode patches that were split into a single
> > > > patch again to maintain bisectability
> > > > ---
> > > > drivers/gpu/drm/drm_modes.c | 70
> > > > +
> > > > 1 file changed, 58 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > > > index 71c050c3ee6b..37542612912b 100644
> > > > --- a/drivers/gpu/drm/drm_modes.c
> > > > +++ b/drivers/gpu/drm/drm_modes.c
> > > > @@ -2229,6 +2229,51 @@ static const char * const
> > > > drm_named_modes_whitelist[] = {
> > > > "PAL",
> > > > };
> > > >
> > > > +static int drm_mode_parse_cmdline_named_mode(const char *name,
> > > > +unsigned int name_end,
> > > > +struct drm_cmdline_mode
> > > > *cmdline_mode)
> > > > +{
> > > > + unsigned int i;
> > > > +
> > > > + if (!name_end)
> > > > + return 0;
> > > > +
> > > > + /* If the name starts with a digit, it's not a named mode */
> > > > + if (isdigit(name[0]))
> > > > + return 0;
> > > > +
> > > > + /*
> > > > +* If there's an equal sign in the name, the command-line
> > > > +* contains only an option and no mode.
> > > > +*/
> > > > + if (strnchr(name, name_end, '='))
> > > > + return 0;
> > > > +
> > > > + /* The connection status extras can be set without a mode. */
> > > > + if (name_end == 1 &&
> > > > + (name[0] == 'd' || name[0] == 'D' || name[0] == 'e'))
> > > > + return 0;
> > > > +
> > > > + /*
> > > > +* We're sure we're a named mode at this point, iterate over the
> > > > +* list of modes we're aware of.
> > > > +*/
> > > > + for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> > > > + int ret;
> > > > +
> > > > + ret = str_has_prefix(name,
> > > > drm_named_modes_whitelist[i]);
> > > > + if (ret != name_end)
> > > > + continue;
> > > > +
> > > > + strcpy(cmdline_mode->name,
> > > > drm_named_modes_whitelist[i]);
> > > > + cmdline_mode->specified = true;
> > > > +
> > > > + return 1;
> > > > + }
> > > > +
> > > > + return -EINVAL;
> > > > +}
> > > > +
> > > > /**
> > > > * drm_mode_parse_command_line_for_connector - parse command line
> > > > modeline for connector
> > > > * @mode_option: optional per connector mode option
> > > > @@ -2265,7 +2310,7 @@ bool
> > > > drm_mode_parse_command_line_for_connector(const char *mode_option,
> > > > const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr =
> > > > NULL;
> > > > const char *options_ptr = NULL;
> > > > char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
> > > > - int i, len, ret;
> > > > + int len, ret;
> > > >
> > > > memset(mode, 0, sizeof(*mode));
> > > > mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > > > @@ -2306,18 +2351,19 @@ bool
> > > > drm_mode_parse_command_line_for_connector(const char *mode_option,
> > > > parse_extras = true;
> > > > }
> > > >
> > > > - /* First check for a named mode */
> > > > - for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> > > > - ret = str_has_prefix(name,
> > > > drm_named_modes_whitelist[i]);
> > > > - if (ret == mode_end) {
> > > > - if (refresh_ptr)
> > > > - return false; /* named + refresh is
> > > > invalid */
> > > > + if (!mode_end)
> > > > + return false;
> > >
> > > I'm chasing down a change in behaviour between 6.1 and 6.6, and this
> > > patch seems to be at least part of the cause.
> > >
> > > Since [1]
Re: [PATCH v2 4/4] drm/i915: Separate tc check for legacy and non legacy tc phys
On Fri, Dec 22, 2023 at 09:47:49PM +0200, Sripada, Radhakrishna wrote:
> Hi Imre,
>
> I have question related to tc legacy handling. I am looking in the context of
> discrete cards.
>
> > -Original Message-
> > From: Deak, Imre
> > Sent: Friday, December 22, 2023 3:44 AM
> > To: Sripada, Radhakrishna
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [PATCH v2 4/4] drm/i915: Separate tc check for legacy and non
> > legacy tc phys
> >
> > On Wed, Dec 20, 2023 at 02:13:41PM -0800, Radhakrishna Sripada wrote:
> > > Starting MTL and DG2 if a phy is not marked as USB-typeC or TBT capable
> > > by vbt we should not consider it as a Legacy type-c phy.
> > >
> > > The concept of Legacy-tc existed in platforms from Icelake to Alder lake
> > > where an external FIA can be routed to one of the phy's thus making the
> > > phy
> > > tc capable without being marked in the vbt.
> > >
> > > Discrete cards have native ports and client products post MTL have a 1:1
> > > mapping with type-C subsystem which is advertised by the bios. So rely on
> > > the vbt info regarding type-c capability.
> > >
> > > Signed-off-by: Radhakrishna Sripada
> > > ---
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> > > drivers/gpu/drm/i915/display/intel_display.c | 29 ---
> > > .../drm/i915/display/intel_display_device.h | 1 +
> > > 3 files changed, 21 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index 12a29363e5df..7d5b95f97d5f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -5100,7 +5100,7 @@ void intel_ddi_init(struct drm_i915_private
> > *dev_priv,
> > > }
> > >
> > > if (intel_phy_is_tc(dev_priv, phy)) {
> > > - bool is_legacy =
> > > + bool is_legacy = HAS_LEGACY_TC(dev_priv) &&
> >
> > This doesn't make sense to me. PHYs are either TC or non-TC (aka combo
> > PHY) and TC PHYs can be configured to work either in legacy (a TC PHY
> > wired to a native DP connector) or non-legacy mode (a TC PHY wired to a
> > TC connector). So this would break the functionality on MTL native DP
> > connectors and all future platforms I looked at which also support this.
>
>
> I understand. I want to figure out a way to determine if a phy is
> connected to FIA. Like in DG2, the phy's are not connected to FIA. I
> am assuming that will be the case for all future discrete cards as
> well. So instead of looking/building an if-else ladder for the phy
> check, is there something that we can rely on viz. vbt, register etc.
> to determine if FIA is connected to a phy?
I suppose this question is if a PHY is TypeC or not, TypeC requiring
some kind of mux (which can be FIA or something else). One other way
instead of the if-ladder in intel_phy_is_tc() would be adding a
tc_phy_mask to intel_display_runtime_info, similarly to the port_mask
there. Not sure how much that would improve things over the current way.
> > > !intel_bios_encoder_supports_typec_usb(devdata) &&
> > > !intel_bios_encoder_supports_tbt(devdata);
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index b10aad15a63d..03006c9af824 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -1854,17 +1854,9 @@ bool intel_phy_is_combo(struct drm_i915_private
> > *dev_priv, enum phy phy)
> > > return false;
> > > }
> > >
> > > -bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
> > > +static bool intel_phy_is_legacy_tc(struct drm_i915_private *dev_priv,
> > > enum
> > phy phy)
> > > {
> > > - /*
> > > -* DG2's "TC1", although TC-capable output, doesn't share the same
> > > flow
> > > -* as other platforms on the display engine side and rather rely on
> > > the
> > > -* SNPS PHY, that is programmed separately
> > > -*/
> > > - if (IS_DG2(dev_priv))
> > > - return false;
> > > -
> > > - if (DISPLAY_VER(dev_priv) >= 13)
> > > + if (DISPLAY_VER(dev_priv) == 13)
> > > return phy >= PHY_F && phy <= PHY_I;
> > > else if (IS_TIGERLAKE(dev_priv))
> > > return phy >= PHY_D && phy <= PHY_I;
> > > @@ -1874,6 +1866,23 @@ bool intel_phy_is_tc(struct drm_i915_private
> > *dev_priv, enum phy phy)
> > > return false;
> > > }
> > >
> > > +static bool intel_phy_is_vbt_tc(struct drm_i915_private *dev_priv, enum
> > > phy
> > phy)
> > > +{
> > > + const struct intel_bios_encoder_data *data =
> > > + intel_bios_encoder_phy_data_lookup(dev_priv, phy);
> > > +
> > > + return intel_bios_encoder_supports_typec_usb(data) &&
> > > + intel_bios_encoder_supports_tbt(data);
> >
> > Based on the above, this doesn't look correct: a TC PHY can be
> > configured by the
✗ Fi.CI.BAT: failure for drm/i915: Disable DSB in Xe KMD
== Series Details ==
Series: drm/i915: Disable DSB in Xe KMD
URL : https://patchwork.freedesktop.org/series/128163/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14072 -> Patchwork_128163v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_128163v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_128163v1, 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_128163v1/index.html
Participating hosts (31 -> 37)
--
Additional (7): bat-dg1-7 fi-bsw-n3050 fi-skl-guc bat-adlm-1 bat-atsm-1
bat-rpls-2 bat-jsl-1
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_128163v1:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@hugepages:
- bat-atsm-1: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-atsm-1/igt@i915_selftest@l...@hugepages.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_engines:
- {bat-adls-6}: [PASS][2] -> [TIMEOUT][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14072/bat-adls-6/igt@i915_selftest@live@gt_engines.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-adls-6/igt@i915_selftest@live@gt_engines.html
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-adls-6}: [PASS][4] -> [WARN][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14072/bat-adls-6/igt@i915_susp...@basic-s2idle-without-i915.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-adls-6/igt@i915_susp...@basic-s2idle-without-i915.html
Known issues
Here are the changes found in Patchwork_128163v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-rpls-2: NOTRUN -> [SKIP][6] ([i915#9318])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html
- bat-adlm-1: NOTRUN -> [SKIP][7] ([i915#3826])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html
- bat-jsl-1: NOTRUN -> [SKIP][8] ([i915#9318])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html
* igt@fbdev@eof:
- bat-adlm-1: NOTRUN -> [SKIP][9] ([i915#2582]) +3 other tests skip
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-adlm-1/igt@fb...@eof.html
* igt@fbdev@info:
- bat-adlm-1: NOTRUN -> [SKIP][10] ([i915#1849] / [i915#2582])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-adlm-1/igt@fb...@info.html
* igt@gem_huc_copy@huc-copy:
- bat-jsl-1: NOTRUN -> [SKIP][11] ([i915#2190])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-skl-guc: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3
other tests skip
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/fi-skl-guc/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlm-1: NOTRUN -> [SKIP][13] ([i915#4613]) +3 other tests skip
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_lmem_swapping@random-engines:
- fi-bsw-n3050: NOTRUN -> [SKIP][14] ([fdo#109271]) +15 other tests
skip
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html
* igt@gem_lmem_swapping@verify-random:
- bat-jsl-1: NOTRUN -> [SKIP][15] ([i915#4613]) +3 other tests skip
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_mmap@basic:
- bat-atsm-1: NOTRUN -> [SKIP][16] ([i915#4083])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-atsm-1/igt@gem_m...@basic.html
- bat-dg1-7: NOTRUN -> [SKIP][17] ([i915#4083])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128163v1/bat-dg1-7/igt@gem_m...@basic.html
* igt@gem_tiled_fence_blits@basic:
- bat-atsm-1: NOTRUN -> [SKIP][18] ([i915#4077]) +2 other tests skip
[18]:
Re: [PATCH] drm/i915: Disable DSB in Xe KMD
On Wed, 2024-01-03 at 17:37 +0200, Jani Nikula wrote:
> On Wed, 03 Jan 2024, José Roberto de Souza wrote:
> > Often getting DBS overflows when starting Xorg or Wayland compositor
> > when running Xe KMD.
> > Issue was reported but nothing was done, so disabling DSB as whole
> > until properly fixed.
>
> Please just incorporate this into the HAS_DSB() check, and don't litter
> the source with ifdefs.
Like this is enough?
+/* TODO: DSB is broken in Xe KMD, so disabling it until fixed */
+#ifdef I915
#define HAS_DSB(i915) (DISPLAY_INFO(i915)->has_dsb)
+#else
+#define HAS_DSB(i915) (false)
+#endif
>
> Thanks,
> Jani.
>
> >
> > Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/989
> > Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1031
> > Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1072
> > Cc: Animesh Manna
> > Cc: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_dsb.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> > b/drivers/gpu/drm/i915/display/intel_dsb.c
> > index 482c28b5c2de5..bc11c447afe03 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> > @@ -321,6 +321,7 @@ void intel_dsb_finish(struct intel_dsb *dsb)
> > intel_dsb_buffer_flush_map(>dsb_buf);
> > }
> >
> > +#ifdef I915
> > static int intel_dsb_dewake_scanline(const struct intel_crtc_state
> > *crtc_state)
> > {
> > struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> > @@ -339,6 +340,7 @@ static int intel_dsb_dewake_scanline(const struct
> > intel_crtc_state *crtc_state)
> >
> > return max(0, vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> > latency));
> > }
> > +#endif
> >
> > static void _intel_dsb_commit(struct intel_dsb *dsb, u32 ctrl,
> > int dewake_scanline)
> > @@ -444,6 +446,8 @@ void intel_dsb_wait(struct intel_dsb *dsb)
> > struct intel_dsb *intel_dsb_prepare(const struct intel_crtc_state
> > *crtc_state,
> > unsigned int max_cmds)
> > {
> > + /* TODO: DSB is broken in Xe KMD, so disabling it until fixed */
> > +#ifdef I915
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > intel_wakeref_t wakeref;
> > @@ -484,6 +488,7 @@ struct intel_dsb *intel_dsb_prepare(const struct
> > intel_crtc_state *crtc_state,
> > "[CRTC:%d:%s] DSB %d queue setup failed, will fallback to
> > MMIO for display HW programming\n",
> > crtc->base.base.id, crtc->base.name, DSB1);
> >
> > +#endif
> > return NULL;
> > }
>
Re: [PATCH v2 3/3] drm/i915/display: Cleanup mplla/mpllb selection
On Tue, Jan 02, 2024 at 01:57:41PM +0200, Mika Kahola wrote:
> The function intel_c20_use_mplla() is not really
> widely used and can be replaced with the more suitable
>
> pll->tx[0] & C20_PHY_USE_MPLLB
>
> expression. Let's remove the intel_c20_use_mplla()
> alltogether and replace mplla/mpllb selection by
> checking mpllb bit.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 39
> 1 file changed, 15 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index fc7211675b2f..d0b6b4e439e1 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -2096,15 +2096,6 @@ int intel_cx0pll_calc_state(struct intel_crtc_state
> *crtc_state,
> return intel_c20pll_calc_state(crtc_state, encoder);
> }
>
> -static bool intel_c20_use_mplla(u32 clock)
> -{
> - /* 10G and 20G rates use MPLLA */
> - if (clock == 100 || clock == 200)
> - return true;
> -
> - return false;
> -}
> -
> static int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
> const struct intel_c20pll_state
> *pll_state)
> {
> @@ -2221,12 +2212,12 @@ void intel_c20pll_dump_hw_state(struct
> drm_i915_private *i915,
> drm_dbg_kms(>drm, "cmn[0] = 0x%.4x, cmn[1] = 0x%.4x, cmn[2] =
> 0x%.4x, cmn[3] = 0x%.4x\n",
> hw_state->cmn[0], hw_state->cmn[1], hw_state->cmn[2],
> hw_state->cmn[3]);
>
> - if (intel_c20_use_mplla(hw_state->clock)) {
> - for (i = 0; i < ARRAY_SIZE(hw_state->mplla); i++)
> - drm_dbg_kms(>drm, "mplla[%d] = 0x%.4x\n", i,
> hw_state->mplla[i]);
> - } else {
> + if (hw_state->tx[0] & C20_PHY_USE_MPLLB) {
The above could be in a helper.
> for (i = 0; i < ARRAY_SIZE(hw_state->mpllb); i++)
> drm_dbg_kms(>drm, "mpllb[%d] = 0x%.4x\n", i,
> hw_state->mpllb[i]);
> + } else {
> + for (i = 0; i < ARRAY_SIZE(hw_state->mplla); i++)
> + drm_dbg_kms(>drm, "mplla[%d] = 0x%.4x\n", i,
> hw_state->mplla[i]);
> }
> }
>
> @@ -2373,27 +2364,27 @@ static void intel_c20_pll_program(struct
> drm_i915_private *i915,
> }
>
> /* 3.3 mpllb or mplla configuration */
> - if (intel_c20_use_mplla(clock)) {
> - for (i = 0; i < ARRAY_SIZE(pll_state->mplla); i++) {
> + if (pll_state->tx[0] & C20_PHY_USE_MPLLB) {
> + for (i = 0; i < ARRAY_SIZE(pll_state->mpllb); i++) {
> if (cntx)
> intel_c20_sram_write(i915, encoder->port,
> INTEL_CX0_LANE0,
> -
> PHY_C20_A_MPLLA_CNTX_CFG(i),
> - pll_state->mplla[i]);
> +
> PHY_C20_A_MPLLB_CNTX_CFG(i),
> + pll_state->mpllb[i]);
Imo, at one point intel_c20pll_state should be converted to use only one
mpll array instead of mplla/b and define a PHY_C20_MPLL_CNTX_CFG(cntx, pll, idx)
macro instead of the above ones.
The patchset looks ok:
Reviewed-by: Imre Deak
> else
> intel_c20_sram_write(i915, encoder->port,
> INTEL_CX0_LANE0,
> -
> PHY_C20_B_MPLLA_CNTX_CFG(i),
> - pll_state->mplla[i]);
> +
> PHY_C20_B_MPLLB_CNTX_CFG(i),
> + pll_state->mpllb[i]);
> }
> } else {
> - for (i = 0; i < ARRAY_SIZE(pll_state->mpllb); i++) {
> + for (i = 0; i < ARRAY_SIZE(pll_state->mplla); i++) {
> if (cntx)
> intel_c20_sram_write(i915, encoder->port,
> INTEL_CX0_LANE0,
> -
> PHY_C20_A_MPLLB_CNTX_CFG(i),
> - pll_state->mpllb[i]);
> +
> PHY_C20_A_MPLLA_CNTX_CFG(i),
> + pll_state->mplla[i]);
> else
> intel_c20_sram_write(i915, encoder->port,
> INTEL_CX0_LANE0,
> -
> PHY_C20_B_MPLLB_CNTX_CFG(i),
> - pll_state->mpllb[i]);
> +
> PHY_C20_B_MPLLA_CNTX_CFG(i),
> + pll_state->mplla[i]);
> }
> }
>
> --
> 2.34.1
>
✓ Fi.CI.BAT: success for drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors (rev2)
== Series Details == Series: drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors (rev2) URL : https://patchwork.freedesktop.org/series/128152/ State : success == Summary == CI Bug Log - changes from CI_DRM_14072 -> Patchwork_128152v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/index.html Participating hosts (31 -> 28) -- Additional (5): bat-dg1-7 fi-bsw-n3050 bat-adlm-1 bat-atsm-1 bat-mtlp-8 Missing(8): bat-adls-6 fi-tgl-1115g4 fi-snb-2520m fi-kbl-guc fi-glk-j4005 fi-pnv-d510 fi-bsw-nick fi-skl-6600u Known issues Here are the changes found in Patchwork_128152v2 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_128152v2/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html - bat-adlm-1: NOTRUN -> [SKIP][2] ([i915#3826]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html * igt@fbdev@eof: - bat-adlm-1: NOTRUN -> [SKIP][3] ([i915#2582]) +3 other tests skip [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-adlm-1/igt@fb...@eof.html * igt@fbdev@info: - bat-adlm-1: NOTRUN -> [SKIP][4] ([i915#1849] / [i915#2582]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-adlm-1/igt@fb...@info.html * igt@gem_lmem_swapping@parallel-random-engines: - bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#4613]) +3 other tests skip [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@random-engines: - fi-bsw-n3050: NOTRUN -> [SKIP][6] ([fdo#109271]) +15 other tests skip [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html * igt@gem_lmem_swapping@verify-random: - bat-mtlp-8: NOTRUN -> [SKIP][7] ([i915#4613]) +3 other tests skip [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][8] ([i915#4083]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-atsm-1/igt@gem_m...@basic.html - bat-dg1-7: NOTRUN -> [SKIP][9] ([i915#4083]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-dg1-7/igt@gem_m...@basic.html - bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#4083]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-mtlp-8/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-mtlp-8: NOTRUN -> [SKIP][11] ([i915#4077]) +2 other tests skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-mtlp-8/igt@gem_mmap_...@basic.html * igt@gem_render_tiled_blits@basic: - bat-mtlp-8: NOTRUN -> [SKIP][12] ([i915#4079]) +1 other test skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-atsm-1: NOTRUN -> [SKIP][13] ([i915#4077]) +2 other tests skip [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html - bat-dg1-7: NOTRUN -> [SKIP][14] ([i915#4077]) +2 other tests skip [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-dg1-7/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][15] ([i915#4079]) +1 other test skip [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-atsm-1/igt@gem_tiled_pread_basic.html - bat-dg1-7: NOTRUN -> [SKIP][16] ([i915#4079]) +1 other test skip [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-dg1-7/igt@gem_tiled_pread_basic.html - bat-adlm-1: NOTRUN -> [SKIP][17] ([i915#3282]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-adlm-1/igt@gem_tiled_pread_basic.html * igt@i915_pm_rps@basic-api: - bat-dg1-7: NOTRUN -> [SKIP][18] ([i915#6621]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-dg1-7/igt@i915_pm_...@basic-api.html - bat-atsm-1: NOTRUN -> [SKIP][19] ([i915#6621]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-atsm-1/igt@i915_pm_...@basic-api.html - bat-mtlp-8: NOTRUN -> [SKIP][20] ([i915#6621]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128152v2/bat-mtlp-8/igt@i915_pm_...@basic-api.html - bat-adlm-1: NOTRUN -> [SKIP][21] ([i915#6621])
Re: [PATCH] drm/i915: Disable DSB in Xe KMD
On Wed, 03 Jan 2024, José Roberto de Souza wrote:
> Often getting DBS overflows when starting Xorg or Wayland compositor
> when running Xe KMD.
> Issue was reported but nothing was done, so disabling DSB as whole
> until properly fixed.
Please just incorporate this into the HAS_DSB() check, and don't litter
the source with ifdefs.
Thanks,
Jani.
>
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/989
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1031
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1072
> Cc: Animesh Manna
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_dsb.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 482c28b5c2de5..bc11c447afe03 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -321,6 +321,7 @@ void intel_dsb_finish(struct intel_dsb *dsb)
> intel_dsb_buffer_flush_map(>dsb_buf);
> }
>
> +#ifdef I915
> static int intel_dsb_dewake_scanline(const struct intel_crtc_state
> *crtc_state)
> {
> struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> @@ -339,6 +340,7 @@ static int intel_dsb_dewake_scanline(const struct
> intel_crtc_state *crtc_state)
>
> return max(0, vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> latency));
> }
> +#endif
>
> static void _intel_dsb_commit(struct intel_dsb *dsb, u32 ctrl,
> int dewake_scanline)
> @@ -444,6 +446,8 @@ void intel_dsb_wait(struct intel_dsb *dsb)
> struct intel_dsb *intel_dsb_prepare(const struct intel_crtc_state
> *crtc_state,
> unsigned int max_cmds)
> {
> + /* TODO: DSB is broken in Xe KMD, so disabling it until fixed */
> +#ifdef I915
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> intel_wakeref_t wakeref;
> @@ -484,6 +488,7 @@ struct intel_dsb *intel_dsb_prepare(const struct
> intel_crtc_state *crtc_state,
> "[CRTC:%d:%s] DSB %d queue setup failed, will fallback to
> MMIO for display HW programming\n",
> crtc->base.base.id, crtc->base.name, DSB1);
>
> +#endif
> return NULL;
> }
--
Jani Nikula, Intel
[PATCH] drm/i915: Disable DSB in Xe KMD
Often getting DBS overflows when starting Xorg or Wayland compositor
when running Xe KMD.
Issue was reported but nothing was done, so disabling DSB as whole
until properly fixed.
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/989
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1031
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1072
Cc: Animesh Manna
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_dsb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 482c28b5c2de5..bc11c447afe03 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -321,6 +321,7 @@ void intel_dsb_finish(struct intel_dsb *dsb)
intel_dsb_buffer_flush_map(>dsb_buf);
}
+#ifdef I915
static int intel_dsb_dewake_scanline(const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
@@ -339,6 +340,7 @@ static int intel_dsb_dewake_scanline(const struct
intel_crtc_state *crtc_state)
return max(0, vblank_start - intel_usecs_to_scanlines(adjusted_mode,
latency));
}
+#endif
static void _intel_dsb_commit(struct intel_dsb *dsb, u32 ctrl,
int dewake_scanline)
@@ -444,6 +446,8 @@ void intel_dsb_wait(struct intel_dsb *dsb)
struct intel_dsb *intel_dsb_prepare(const struct intel_crtc_state *crtc_state,
unsigned int max_cmds)
{
+ /* TODO: DSB is broken in Xe KMD, so disabling it until fixed */
+#ifdef I915
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
intel_wakeref_t wakeref;
@@ -484,6 +488,7 @@ struct intel_dsb *intel_dsb_prepare(const struct
intel_crtc_state *crtc_state,
"[CRTC:%d:%s] DSB %d queue setup failed, will fallback to
MMIO for display HW programming\n",
crtc->base.base.id, crtc->base.name, DSB1);
+#endif
return NULL;
}
--
2.43.0
[PATCH v2] drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors
MST connectors don't have a static attached encoder, as their encoder
can change depending on the pipe they use; so the encoder for an MST
connector can't be retrieved using intel_dp_attached_encoder() (which
may return NULL for MST). Most of the PSR debugfs entries depend on a
static connector -> encoder mapping which is only true for eDP and SST
DP connectors and not for MST. These debugfs entries were enabled for
MST connectors as well recently to provide PR information for them, but
handling MST connectors needs more changes.
Fix this by not adding for now the PSR entries on MST connectors. To
make things more uniform add the entries for SST connectors on all
platforms, not just on platforms supporting DP2.0.
v2:
- Keep adding the entries for SST connectors. (Jouni)
- Add a TODO: comment for MST support.
Fixes: ef75c25e8fed ("drm/i915/panelreplay: Debugfs support for panel replay")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9850
Cc: Animesh Manna
Cc: Jouni Högander
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_psr.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 494d08817d71e..54120b45958b0 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -3310,11 +3310,11 @@ void intel_psr_connector_debugfs_add(struct
intel_connector *connector)
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct dentry *root = connector->base.debugfs_entry;
- if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP) {
- if (!(HAS_DP20(i915) &&
- connector->base.connector_type ==
DRM_MODE_CONNECTOR_DisplayPort))
- return;
- }
+ /* TODO: Add support for MST connectors as well. */
+ if ((connector->base.connector_type != DRM_MODE_CONNECTOR_eDP &&
+connector->base.connector_type != DRM_MODE_CONNECTOR_DisplayPort)
||
+ connector->mst_port)
+ return;
debugfs_create_file("i915_psr_sink_status", 0444, root,
connector, _psr_sink_status_fops);
--
2.39.2
Re: [PATCH] drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors
On Wed, 2024-01-03 at 16:00 +0200, Imre Deak wrote:
> On Wed, Jan 03, 2024 at 01:37:08PM +0200, Hogander, Jouni wrote:
> > > > > [...]
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > index 494d08817d71e..b5b9340e505e3 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > @@ -3310,11 +3310,8 @@ void
> > > > > intel_psr_connector_debugfs_add(struct
> > > > > intel_connector *connector)
> > > > > struct drm_i915_private *i915 = to_i915(connector-
> > > > > >base.dev);
> > > > > struct dentry *root = connector->base.debugfs_entry;
> > > > >
> > > > > - if (connector->base.connector_type !=
> > > > > DRM_MODE_CONNECTOR_eDP)
> > > > > {
> > > > > - if (!(HAS_DP20(i915) &&
> > > > > - connector->base.connector_type ==
> > > > > DRM_MODE_CONNECTOR_DisplayPort))
> > > > > - return;
> > > > > - }
> > > > > + if (connector->base.connector_type !=
> > > > > DRM_MODE_CONNECTOR_eDP)
> > > > > + return;
> > > >
> > > > Would it be possible to disable it only for MST connector? I
> > > > think
> > > > this is disabling it also for DP SST, no?
> > >
> > > Yes, it keeps it enabled only for eDP. It could be enabled for
> > > SST as
> > > well yes, but I thought as a fix the above is better, adding
> > > support
> > > for other connector types as a follow up.
> >
> > if (connector->mst_port || !(HAS_DP20(i915) &&
> > connectorbase.connector_type == DRM_MODE_CONNECTOR_DisplayPort))
> > return;
> >
> > Is it possible to use this instead?
>
> Looking through it I don't see a problem on SST connectors either, so
> I'd rather leave the entries enabled for them on all platforms, that
> is
>
> if ((connector_type != DRM_MODE_CONNECTOR_eDP &&
> connector_type != DRM_MODE_CONNECTOR_DisplayPort) ||
> connector->mst_port)
> return;
Sounds good. That is anyways same what is done for PSR as well.
BR,
Jouni Högander
>
> > BR,
> >
> > Jouni Högander
> >
> > >
> > > > BR,
> > > >
> > > > Jouni Högander
> > > > >
> > > > > debugfs_create_file("i915_psr_sink_status", 0444,
> > > > > root,
> > > > > connector,
> > > > > _psr_sink_status_fops);
> > > >
> >
Re: [PATCH v9 09/25] drm/modes: Move named modes parsing to a separate function
Hi Maxime
On Wed, 3 Jan 2024 at 13:33, Maxime Ripard wrote:
>
> Hi Dave,
>
> Happy new year :)
And to you.
> On Tue, Jan 02, 2024 at 03:12:26PM +, Dave Stevenson wrote:
> > Hi Maxime
> >
> > On Mon, 14 Nov 2022 at 13:00, Maxime Ripard wrote:
> > >
> > > The current construction of the named mode parsing doesn't allow to extend
> > > it easily. Let's move it to a separate function so we can add more
> > > parameters and modes.
> > >
> > > In order for the tests to still pass, some extra checks are needed, so
> > > it's not a 1:1 move.
> > >
> > > Reviewed-by: Noralf Trønnes
> > > Tested-by: Mateusz Kwiatkowski
> > > Signed-off-by: Maxime Ripard
> > >
> > > ---
> > > Changes in v7:
> > > - Add Noralf Reviewed-by
> > >
> > > Changes in v6:
> > > - Simplify the test for connection status extras
> > > - Simplify the code path to call drm_mode_parse_cmdline_named_mode
> > >
> > > Changes in v4:
> > > - Fold down all the named mode patches that were split into a single
> > > patch again to maintain bisectability
> > > ---
> > > drivers/gpu/drm/drm_modes.c | 70
> > > +
> > > 1 file changed, 58 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > > index 71c050c3ee6b..37542612912b 100644
> > > --- a/drivers/gpu/drm/drm_modes.c
> > > +++ b/drivers/gpu/drm/drm_modes.c
> > > @@ -2229,6 +2229,51 @@ static const char * const
> > > drm_named_modes_whitelist[] = {
> > > "PAL",
> > > };
> > >
> > > +static int drm_mode_parse_cmdline_named_mode(const char *name,
> > > +unsigned int name_end,
> > > +struct drm_cmdline_mode
> > > *cmdline_mode)
> > > +{
> > > + unsigned int i;
> > > +
> > > + if (!name_end)
> > > + return 0;
> > > +
> > > + /* If the name starts with a digit, it's not a named mode */
> > > + if (isdigit(name[0]))
> > > + return 0;
> > > +
> > > + /*
> > > +* If there's an equal sign in the name, the command-line
> > > +* contains only an option and no mode.
> > > +*/
> > > + if (strnchr(name, name_end, '='))
> > > + return 0;
> > > +
> > > + /* The connection status extras can be set without a mode. */
> > > + if (name_end == 1 &&
> > > + (name[0] == 'd' || name[0] == 'D' || name[0] == 'e'))
> > > + return 0;
> > > +
> > > + /*
> > > +* We're sure we're a named mode at this point, iterate over the
> > > +* list of modes we're aware of.
> > > +*/
> > > + for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> > > + int ret;
> > > +
> > > + ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
> > > + if (ret != name_end)
> > > + continue;
> > > +
> > > + strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
> > > + cmdline_mode->specified = true;
> > > +
> > > + return 1;
> > > + }
> > > +
> > > + return -EINVAL;
> > > +}
> > > +
> > > /**
> > > * drm_mode_parse_command_line_for_connector - parse command line
> > > modeline for connector
> > > * @mode_option: optional per connector mode option
> > > @@ -2265,7 +2310,7 @@ bool
> > > drm_mode_parse_command_line_for_connector(const char *mode_option,
> > > const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr =
> > > NULL;
> > > const char *options_ptr = NULL;
> > > char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
> > > - int i, len, ret;
> > > + int len, ret;
> > >
> > > memset(mode, 0, sizeof(*mode));
> > > mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > > @@ -2306,18 +2351,19 @@ bool
> > > drm_mode_parse_command_line_for_connector(const char *mode_option,
> > > parse_extras = true;
> > > }
> > >
> > > - /* First check for a named mode */
> > > - for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> > > - ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
> > > - if (ret == mode_end) {
> > > - if (refresh_ptr)
> > > - return false; /* named + refresh is
> > > invalid */
> > > + if (!mode_end)
> > > + return false;
> >
> > I'm chasing down a change in behaviour between 6.1 and 6.6, and this
> > patch seems to be at least part of the cause.
> >
> > Since [1] we've had the emulated framebuffer on Pi being 16bpp to save
> > memory. All good.
> >
> > It used to be possible to use "video=HDMI-A-1:-32" on the kernel
> > command line to set it back to 32bpp.
> >
> > After this patch that is no longer possible. "mode_end = bpp_off", and
> > "bpp_off = bpp_ptr - name", so with bpp_ptr = name we get mode_end
> >
Re: [PATCH] drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors
On Wed, Jan 03, 2024 at 01:37:08PM +0200, Hogander, Jouni wrote:
> > > > [...]
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > index 494d08817d71e..b5b9340e505e3 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > @@ -3310,11 +3310,8 @@ void
> > > > intel_psr_connector_debugfs_add(struct
> > > > intel_connector *connector)
> > > > struct drm_i915_private *i915 = to_i915(connector->base.dev);
> > > > struct dentry *root = connector->base.debugfs_entry;
> > > >
> > > > - if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
> > > > {
> > > > - if (!(HAS_DP20(i915) &&
> > > > - connector->base.connector_type ==
> > > > DRM_MODE_CONNECTOR_DisplayPort))
> > > > - return;
> > > > - }
> > > > + if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
> > > > + return;
> > >
> > > Would it be possible to disable it only for MST connector? I think
> > > this is disabling it also for DP SST, no?
> >
> > Yes, it keeps it enabled only for eDP. It could be enabled for SST as
> > well yes, but I thought as a fix the above is better, adding support
> > for other connector types as a follow up.
>
> if (connector->mst_port || !(HAS_DP20(i915) &&
> connectorbase.connector_type == DRM_MODE_CONNECTOR_DisplayPort))
> return;
>
> Is it possible to use this instead?
Looking through it I don't see a problem on SST connectors either, so
I'd rather leave the entries enabled for them on all platforms, that is
if ((connector_type != DRM_MODE_CONNECTOR_eDP &&
connector_type != DRM_MODE_CONNECTOR_DisplayPort) ||
connector->mst_port)
return;
> BR,
>
> Jouni Högander
>
> >
> > > BR,
> > >
> > > Jouni Högander
> > > >
> > > > debugfs_create_file("i915_psr_sink_status", 0444, root,
> > > > connector,
> > > > _psr_sink_status_fops);
> > >
>
Re: [PATCH] nightly.conf: Add the xe repo to drm-tip
On Tue, 2023-12-26 at 13:30 -0500, Rodrigo Vivi wrote: > On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote: > > Add the xe repo to drm-tip and the dim tools. > > For now use the sha1 of the first drm-xe-next pull request for drm- > > tip, > > since that branch tip is currently adapted for our CI testing. > > > > Cc: Rodrigo Vivi > > Cc: Lucas De Marchi > > Cc: Oded Gabbay > > Cc: daniel.vet...@ffwll.ch > > Cc: Maarten Lankhorst > > Cc: dim-to...@lists.freedesktop.org > > Cc: dri-de...@lists.freedesktop.org > > Cc: intel-gfx@lists.freedesktop.org > > Signed-off-by: Thomas Hellström > > --- > > nightly.conf | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/nightly.conf b/nightly.conf > > index 24126b61b797..accd3ff2cc39 100644 > > --- a/nightly.conf > > +++ b/nightly.conf > > @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip > > https://anongit.freedesktop.org/git/drm/drm-tip > > https://anongit.freedesktop.org/git/drm/drm-tip.git > > " > > +drm_tip_repos[drm-xe]=" > > +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git > > +https://gitlab.freedesktop.org/drm/xe/kernel.git > > +" > > drm_tip_repos[drm-intel]=" > > ssh://git.freedesktop.org/git/drm/drm-intel > > ssh://git.freedesktop.org/git/drm-intel > > @@ -65,14 +69,17 @@ drm_tip_config=( > > "drmdrm-fixes" > > "drm-misc drm-misc-fixes" > > "drm-intel drm-intel-fixes" > > + "drm-xe drm-xe-fixes" > > > > "drmdrm-next" > > "drm-misc drm-misc-next-fixes" > > "drm-intel drm-intel-next-fixes" > > + "drm-xe drm-xe-next-fixes" > > > > "drm-misc drm-misc-next" > > "drm-intel drm-intel-next" > > "drm-intel drm-intel-gt-next" > > + "drm-xe drm-xe-next b6e1b7081768" > > yeap, up to this commit nothing else should change, but > then we will need an extra rebase of the rest on top of drm/drm-next. > > But then we need to decide where these following patches will live: > 880277f31cc69 drm/xe/guc: define LNL FW > 2cfc5ae1b8267 drm/xe/guc: define PVC FW > 52383b58eb8cf mei/hdcp: Also enable for XE > bea27d7369855 mei: gsc: add support for auxiliary device created by > Xe driver > fcb3410197f05 fault-inject: Include linux/types.h by default. > 8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs > > > Will it be the topic/core-for-CI? > or topic/xe-extras? > or what? This sounds to me like topic/core-for-CI? Or is there any drawback with that? > > Anyway, for the inclusion like this, after our CI is ready: Could we merge this patch already at this point, considering it will, at least for now, only update drm-tip with our fixes? Thanks, /Thomas > > Acked-by: Rodrigo Vivi > > > > > "drm-intel topic/core-for-CI" > > "drm-misc topic/i915-ttm" > > -- > > 2.42.0 > >
Re: [PATCH v9 09/25] drm/modes: Move named modes parsing to a separate function
Hi Dave,
Happy new year :)
On Tue, Jan 02, 2024 at 03:12:26PM +, Dave Stevenson wrote:
> Hi Maxime
>
> On Mon, 14 Nov 2022 at 13:00, Maxime Ripard wrote:
> >
> > The current construction of the named mode parsing doesn't allow to extend
> > it easily. Let's move it to a separate function so we can add more
> > parameters and modes.
> >
> > In order for the tests to still pass, some extra checks are needed, so
> > it's not a 1:1 move.
> >
> > Reviewed-by: Noralf Trønnes
> > Tested-by: Mateusz Kwiatkowski
> > Signed-off-by: Maxime Ripard
> >
> > ---
> > Changes in v7:
> > - Add Noralf Reviewed-by
> >
> > Changes in v6:
> > - Simplify the test for connection status extras
> > - Simplify the code path to call drm_mode_parse_cmdline_named_mode
> >
> > Changes in v4:
> > - Fold down all the named mode patches that were split into a single
> > patch again to maintain bisectability
> > ---
> > drivers/gpu/drm/drm_modes.c | 70
> > +
> > 1 file changed, 58 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index 71c050c3ee6b..37542612912b 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -2229,6 +2229,51 @@ static const char * const
> > drm_named_modes_whitelist[] = {
> > "PAL",
> > };
> >
> > +static int drm_mode_parse_cmdline_named_mode(const char *name,
> > +unsigned int name_end,
> > +struct drm_cmdline_mode
> > *cmdline_mode)
> > +{
> > + unsigned int i;
> > +
> > + if (!name_end)
> > + return 0;
> > +
> > + /* If the name starts with a digit, it's not a named mode */
> > + if (isdigit(name[0]))
> > + return 0;
> > +
> > + /*
> > +* If there's an equal sign in the name, the command-line
> > +* contains only an option and no mode.
> > +*/
> > + if (strnchr(name, name_end, '='))
> > + return 0;
> > +
> > + /* The connection status extras can be set without a mode. */
> > + if (name_end == 1 &&
> > + (name[0] == 'd' || name[0] == 'D' || name[0] == 'e'))
> > + return 0;
> > +
> > + /*
> > +* We're sure we're a named mode at this point, iterate over the
> > +* list of modes we're aware of.
> > +*/
> > + for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> > + int ret;
> > +
> > + ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
> > + if (ret != name_end)
> > + continue;
> > +
> > + strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
> > + cmdline_mode->specified = true;
> > +
> > + return 1;
> > + }
> > +
> > + return -EINVAL;
> > +}
> > +
> > /**
> > * drm_mode_parse_command_line_for_connector - parse command line modeline
> > for connector
> > * @mode_option: optional per connector mode option
> > @@ -2265,7 +2310,7 @@ bool drm_mode_parse_command_line_for_connector(const
> > char *mode_option,
> > const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
> > const char *options_ptr = NULL;
> > char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
> > - int i, len, ret;
> > + int len, ret;
> >
> > memset(mode, 0, sizeof(*mode));
> > mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > @@ -2306,18 +2351,19 @@ bool
> > drm_mode_parse_command_line_for_connector(const char *mode_option,
> > parse_extras = true;
> > }
> >
> > - /* First check for a named mode */
> > - for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> > - ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
> > - if (ret == mode_end) {
> > - if (refresh_ptr)
> > - return false; /* named + refresh is invalid
> > */
> > + if (!mode_end)
> > + return false;
>
> I'm chasing down a change in behaviour between 6.1 and 6.6, and this
> patch seems to be at least part of the cause.
>
> Since [1] we've had the emulated framebuffer on Pi being 16bpp to save
> memory. All good.
>
> It used to be possible to use "video=HDMI-A-1:-32" on the kernel
> command line to set it back to 32bpp.
>
> After this patch that is no longer possible. "mode_end = bpp_off", and
> "bpp_off = bpp_ptr - name", so with bpp_ptr = name we get mode_end
> being 0. That fails this conditional.
> drm_mode_parse_cmdline_named_mode already aborts early but with no
> error if name_end / mode_end is 0, so this "if" clause seems
> redundant, and is a change in behaviour.
>
> We do then get a second parsing failure due to the check if (bpp_ptr
> || refresh_ptr) at [2].
> Prior to this patch my
✓ Fi.CI.BAT: success for drm/i915: Add workaround 14019877138
== Series Details == Series: drm/i915: Add workaround 14019877138 URL : https://patchwork.freedesktop.org/series/128143/ State : success == Summary == CI Bug Log - changes from CI_DRM_14072 -> Patchwork_128143v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/index.html Participating hosts (31 -> 30) -- Missing(1): fi-snb-2520m Changes --- No changes found Build changes - * Linux: CI_DRM_14072 -> Patchwork_128143v1 CI-20190529: 20190529 CI_DRM_14072: d4b6bc6676100931dfd8d6cf7ef1a74cd71c22a7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7655: ddf7cf40a00caa7d02f3729e1e50f78f102463d9 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_128143v1: d4b6bc6676100931dfd8d6cf7ef1a74cd71c22a7 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 3ffe2690fad2 drm/i915: Add workaround 14019877138 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/index.html
Re: [PATCH] drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors
On Wed, 2024-01-03 at 13:20 +0200, Imre Deak wrote:
> On Wed, Jan 03, 2024 at 01:08:05PM +0200, Hogander, Jouni wrote:
> > On Wed, 2024-01-03 at 13:00 +0200, Imre Deak wrote:
> > > MST connectors don't have a static attached encoder, as their
> > > encoder
> > > can change depending on the pipe they use; so the encoder for an
> > > MST
> > > connector can't be retrieved using intel_dp_attached_encoder()
> > > (which
> > > may return NULL for MST). Most of the PSR debugfs entries depend
> > > on a
> > > static connector -> encoder mapping which is only true for eDP
> > > and
> > > SST
> > > DP connectors and not for MST. These debugfs entries were enabled
> > > for
> > > MST connectors as well recently to provide PR information for
> > > them,
> > > but
> > > handling MST connectors needs more changes. Fix this by re-
> > > disabling
> > > for
> > > now the PSR entries on MST connectors.
> > >
> > > Fixes: ef75c25e8fed ("drm/i915/panelreplay: Debugfs support for
> > > panel
> > > replay")
> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9850
> > > Cc: Animesh Manna
> > > Cc: Jouni Högander
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/display/intel_psr.c | 7 ++-
> > > 1 file changed, 2 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 494d08817d71e..b5b9340e505e3 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -3310,11 +3310,8 @@ void
> > > intel_psr_connector_debugfs_add(struct
> > > intel_connector *connector)
> > > struct drm_i915_private *i915 = to_i915(connector-
> > > >base.dev);
> > > struct dentry *root = connector->base.debugfs_entry;
> > >
> > > - if (connector->base.connector_type !=
> > > DRM_MODE_CONNECTOR_eDP)
> > > {
> > > - if (!(HAS_DP20(i915) &&
> > > - connector->base.connector_type ==
> > > DRM_MODE_CONNECTOR_DisplayPort))
> > > - return;
> > > - }
> > > + if (connector->base.connector_type !=
> > > DRM_MODE_CONNECTOR_eDP)
> > > + return;
> >
> > Would it be possible to disable it only for MST connector? I think
> > this
> > is disabling it also for DP SST, no?
>
> Yes, it keeps it enabled only for eDP. It could be enabled for SST as
> well yes, but I thought as a fix the above is better, adding support
> for
> other connector types as a follow up.
if (connector->mst_port || !(HAS_DP20(i915) &&
connectorbase.connector_type == DRM_MODE_CONNECTOR_DisplayPort))
return;
Is it possible to use this instead?
BR,
Jouni Högander
>
> > BR,
> >
> > Jouni Högander
> > >
> > > debugfs_create_file("i915_psr_sink_status", 0444, root,
> > > connector,
> > > _psr_sink_status_fops);
> >
Re: [PATCH] drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors
On Wed, Jan 03, 2024 at 01:08:05PM +0200, Hogander, Jouni wrote:
> On Wed, 2024-01-03 at 13:00 +0200, Imre Deak wrote:
> > MST connectors don't have a static attached encoder, as their encoder
> > can change depending on the pipe they use; so the encoder for an MST
> > connector can't be retrieved using intel_dp_attached_encoder() (which
> > may return NULL for MST). Most of the PSR debugfs entries depend on a
> > static connector -> encoder mapping which is only true for eDP and
> > SST
> > DP connectors and not for MST. These debugfs entries were enabled for
> > MST connectors as well recently to provide PR information for them,
> > but
> > handling MST connectors needs more changes. Fix this by re-disabling
> > for
> > now the PSR entries on MST connectors.
> >
> > Fixes: ef75c25e8fed ("drm/i915/panelreplay: Debugfs support for panel
> > replay")
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9850
> > Cc: Animesh Manna
> > Cc: Jouni Högander
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 7 ++-
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 494d08817d71e..b5b9340e505e3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -3310,11 +3310,8 @@ void intel_psr_connector_debugfs_add(struct
> > intel_connector *connector)
> > struct drm_i915_private *i915 = to_i915(connector->base.dev);
> > struct dentry *root = connector->base.debugfs_entry;
> >
> > - if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
> > {
> > - if (!(HAS_DP20(i915) &&
> > - connector->base.connector_type ==
> > DRM_MODE_CONNECTOR_DisplayPort))
> > - return;
> > - }
> > + if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
> > + return;
>
> Would it be possible to disable it only for MST connector? I think this
> is disabling it also for DP SST, no?
Yes, it keeps it enabled only for eDP. It could be enabled for SST as
well yes, but I thought as a fix the above is better, adding support for
other connector types as a follow up.
> BR,
>
> Jouni Högander
> >
> > debugfs_create_file("i915_psr_sink_status", 0444, root,
> > connector, _psr_sink_status_fops);
>
Re: [PATCH] drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors
On Wed, 2024-01-03 at 13:00 +0200, Imre Deak wrote:
> MST connectors don't have a static attached encoder, as their encoder
> can change depending on the pipe they use; so the encoder for an MST
> connector can't be retrieved using intel_dp_attached_encoder() (which
> may return NULL for MST). Most of the PSR debugfs entries depend on a
> static connector -> encoder mapping which is only true for eDP and
> SST
> DP connectors and not for MST. These debugfs entries were enabled for
> MST connectors as well recently to provide PR information for them,
> but
> handling MST connectors needs more changes. Fix this by re-disabling
> for
> now the PSR entries on MST connectors.
>
> Fixes: ef75c25e8fed ("drm/i915/panelreplay: Debugfs support for panel
> replay")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9850
> Cc: Animesh Manna
> Cc: Jouni Högander
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 494d08817d71e..b5b9340e505e3 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -3310,11 +3310,8 @@ void intel_psr_connector_debugfs_add(struct
> intel_connector *connector)
> struct drm_i915_private *i915 = to_i915(connector->base.dev);
> struct dentry *root = connector->base.debugfs_entry;
>
> - if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
> {
> - if (!(HAS_DP20(i915) &&
> - connector->base.connector_type ==
> DRM_MODE_CONNECTOR_DisplayPort))
> - return;
> - }
> + if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
> + return;
Would it be possible to disable it only for MST connector? I think this
is disabling it also for DP SST, no?
BR,
Jouni Högander
>
> debugfs_create_file("i915_psr_sink_status", 0444, root,
> connector, _psr_sink_status_fops);
[PATCH] drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors
MST connectors don't have a static attached encoder, as their encoder
can change depending on the pipe they use; so the encoder for an MST
connector can't be retrieved using intel_dp_attached_encoder() (which
may return NULL for MST). Most of the PSR debugfs entries depend on a
static connector -> encoder mapping which is only true for eDP and SST
DP connectors and not for MST. These debugfs entries were enabled for
MST connectors as well recently to provide PR information for them, but
handling MST connectors needs more changes. Fix this by re-disabling for
now the PSR entries on MST connectors.
Fixes: ef75c25e8fed ("drm/i915/panelreplay: Debugfs support for panel replay")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9850
Cc: Animesh Manna
Cc: Jouni Högander
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_psr.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 494d08817d71e..b5b9340e505e3 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -3310,11 +3310,8 @@ void intel_psr_connector_debugfs_add(struct
intel_connector *connector)
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct dentry *root = connector->base.debugfs_entry;
- if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP) {
- if (!(HAS_DP20(i915) &&
- connector->base.connector_type ==
DRM_MODE_CONNECTOR_DisplayPort))
- return;
- }
+ if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
+ return;
debugfs_create_file("i915_psr_sink_status", 0444, root,
connector, _psr_sink_status_fops);
--
2.39.2
[PULL] drm-misc-fixes
Hi Dave, Daniel, Happy new year! ~Maarten drm-misc-fixes-2024-01-03: drm-misc-fixes for v6.7 final: - 2 small qaic fixes. - Fixes for overflow in aux xfer. - Fix uninitialised gamma lut in gmag200. - Small compiler warning fix for backports of a ps8640 fix. The following changes since commit 6c9dbee84cd005bed5f9d07b3a2797ae6414b435: drm/panel: ltk050h3146w: Set burst mode for ltk050h3148w (2023-12-13 18:33:43 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2024-01-03 for you to fetch changes up to 11f9eb899ecc8c02b769cf8d2532ba12786a7af7: drm/mgag200: Fix gamma lut not initialized for G200ER, G200EV, G200SE (2023-12-20 13:26:57 +0100) drm-misc-fixes for v6.7 final: - 2 small qaic fixes. - Fixes for overflow in aux xfer. - Fix uninitialised gamma lut in gmag200. - Small compiler warning fix for backports of a ps8640 fix. Douglas Anderson (3): drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer drm/bridge: ps8640: Fix size mismatch warning w/ len Jeffrey Hugo (1): accel/qaic: Implement quirk for SOC_HW_VERSION Jocelyn Falempe (1): drm/mgag200: Fix gamma lut not initialized for G200ER, G200EV, G200SE Pranjal Ramajor Asha Kanojiya (1): accel/qaic: Fix GEM import path code drivers/accel/qaic/mhi_controller.c | 15 ++- drivers/accel/qaic/qaic_data.c | 6 ++ drivers/gpu/drm/bridge/parade-ps8640.c | 7 --- drivers/gpu/drm/bridge/ti-sn65dsi86.c| 4 +++- drivers/gpu/drm/mgag200/mgag200_drv.h| 5 + drivers/gpu/drm/mgag200/mgag200_g200er.c | 5 + drivers/gpu/drm/mgag200/mgag200_g200ev.c | 5 + drivers/gpu/drm/mgag200/mgag200_g200se.c | 5 + drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +- 9 files changed, 48 insertions(+), 14 deletions(-)
RE: [PATCH 1/7] drm: Add eDP 1.5 early transport definition
> -Original Message- > From: Intel-gfx On Behalf Of Jouni > Högander > Sent: Monday, December 18, 2023 7:50 PM > To: intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Subject: [PATCH 1/7] drm: Add eDP 1.5 early transport definition > > Add DP_PSR_ENABLE_SU_REGION_ET to enable panel early transport. > > Cc: dri-de...@lists.freedesktop.org > Reviewed-by: Mika Kahola > Signed-off-by: Jouni Högander > --- > include/drm/display/drm_dp.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h > index 3731828825bd..281afff6ee4e 100644 > --- a/include/drm/display/drm_dp.h > +++ b/include/drm/display/drm_dp.h > @@ -718,6 +718,7 @@ > # define DP_PSR_SU_REGION_SCANLINE_CAPTURE BIT(4) /* eDP 1.4a */ > # define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS BIT(5) /* eDP 1.4a */ > # define DP_PSR_ENABLE_PSR2 BIT(6) /* eDP 1.4a */ > +# define DP_PSR_ENABLE_SU_REGION_ET BIT(7) /* eDP 1.5 */ > > #define DP_ADAPTER_CTRL 0x1a0 > # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) > -- > 2.34.1
[PATCH] drm/i915/display/dp: 128/132b DP-capable with SST
With a value of '0' read from MSTM_CAP register MST to be enabled. DP2.1 SCR updates the spec for 128/132b DP capable supporting only one stream and not supporting single stream sideband MSG. The underlying protocol will be MST to enable use of MTP. Signed-off-by: Arun R Murthy --- drivers/gpu/drm/i915/display/intel_dp.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 9ff0cbd9c0df..40d3280f8d98 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4038,8 +4038,13 @@ intel_dp_configure_mst(struct intel_dp *intel_dp) if (!intel_dp_mst_source_support(intel_dp)) return; - intel_dp->is_mst = sink_can_mst && - i915->display.params.enable_dp_mst; + /* +* Even if dpcd reg MSTM_CAP is 0, if the sink supports UHBR rates then +* DP2.1 can be enabled with underlying protocol using MST for MTP +*/ + intel_dp->is_mst = (sink_can_mst || + drm_dp_is_uhbr_rate(intel_dp_max_common_rate(intel_dp))) + && i915->display.params.enable_dp_mst; drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr, intel_dp->is_mst); -- 2.25.1
