[Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on Nightfury board
Customer report random display flicker issue on Nightfury board.
And we found this problem might be caused by VT-d and FBC are
both enabled. According to sighting report, it recommend to turn
drm/i915/fbc: disable FBC on Nightfury board
Customer report random display flicker issue on Nightfury board.
And we found this problem might be caused by VT-d and FBC are
both enabled. According to sighting report, it recommend to turn
FBC off to workaround this kind of issue.
This change refer to DMI BOARD_VENDOR and BOARD_NAME information
to disable FBC.
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Mika Kuoppala
Cc: Jani Nikula
Cc: William Tseng
Cc: Cooper Chiou
Signed-off-by: Lee Shawn C
---
drivers/gpu/drm/i915/display/intel_fbc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 327af428d73f..20660fdbab36 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -39,6 +39,7 @@
*/
#include
+#include
#include "i915_drv.h"
#include "i915_trace.h"
@@ -1439,6 +1440,24 @@ static int intel_sanitize_fbc_option(struct
drm_i915_private *dev_priv)
return 0;
}
+static int intel_fbc_vtd_callback(const struct dmi_system_id *id)
+{
+ DRM_DEBUG_KMS("Disabling FBC to prevent screen flicker on %s device\n",
id->ident);
+ return 1;
+}
+
+static const struct dmi_system_id intel_fbc_vtd_detect[] = {
+ {
+ .callback = intel_fbc_vtd_callback,
+ .ident = "Google Nightfury",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Google"),
+ DMI_MATCH(DMI_BOARD_NAME, "Nightfury"),
+ },
+ },
+ { }
+};
+
static bool need_fbc_vtd_wa(struct drm_i915_private *dev_priv)
{
/* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */
@@ -1450,6 +1469,9 @@ static bool need_fbc_vtd_wa(struct drm_i915_private
*dev_priv)
return true;
}
+ if (dmi_check_system(intel_fbc_vtd_detect))
+ return true;
+
return false;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
Hi Ville,
> On Aug 27, 2020, at 12:24 AM, Ville Syrjälä
> wrote:
>
> On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
>> LSPCON only supports 8 bpc for RGB/YCbCr444.
>>
>> Set the correct bpp otherwise it renders blank screen.
>
> Hmm. Does
> git://github.com/vsyrjala/linux.git dp_downstream_ports_5
> work?
>
> Actually better make that dp_downstream_ports_5^^^ aka.
> 54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
> converters") to avoid the experiments and hacks I have sitting on top.
Can you please rebase it to mainline master or drm-tip?
I am getting errors on the branch:
DESCEND objtool
CALLscripts/atomic/check-atomics.sh
CALLscripts/checksyscalls.sh
CHK include/generated/compile.h
Building modules, stage 2.
MODPOST 166 modules
LD arch/x86/boot/compressed/vmlinux
ld: arch/x86/boot/compressed/pgtable_64.o:(.bss+0x0): multiple definition of
`__force_order'; arch/x86/boot/compressed/kaslr_64.o:(.bss+0x0): first defined
here
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only
section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
make[2]: *** [arch/x86/boot/compressed/Makefile:119:
arch/x86/boot/compressed/vmlinux] Error 1
make[1]: *** [arch/x86/boot/Makefile:113: arch/x86/boot/compressed/vmlinux]
Error 2
make: *** [arch/x86/Makefile:284: bzImage] Error 2
make: *** Waiting for unfinished jobs
Kai-Heng
>
>>
>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
>> Signed-off-by: Kai-Heng Feng
>> ---
>> drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
>> b/drivers/gpu/drm/i915/display/intel_lspcon.c
>> index b781bf469644..c7a44fcaade8 100644
>> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
>> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
>> @@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector
>> *connector,
>> crtc_state->port_clock /= 2;
>> crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
>> crtc_state->lspcon_downsampling = true;
>> -}
>> +} else
>> +crtc_state->pipe_bpp = 24;
>> }
>>
>> static bool lspcon_probe(struct intel_lspcon *lspcon)
>> --
>> 2.17.1
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support (rev2)
== Series Details == Series: series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support (rev2) URL : https://patchwork.freedesktop.org/series/81083/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8930_full -> Patchwork_18414_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18414_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18414_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18414_full: ### IGT changes ### Possible regressions * igt@gem_exec_whisper@basic-queues-priority-all: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-iclb8/igt@gem_exec_whis...@basic-queues-priority-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/shard-iclb7/igt@gem_exec_whis...@basic-queues-priority-all.html * igt@i915_pm_rps@waitboost: - shard-hsw: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-hsw5/igt@i915_pm_...@waitboost.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/shard-hsw1/igt@i915_pm_...@waitboost.html Known issues Here are the changes found in Patchwork_18414_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-contexts-10ms: - shard-snb: [PASS][5] -> [INCOMPLETE][6] ([i915#82]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-snb2/igt@gem_...@in-flight-contexts-10ms.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/shard-snb5/igt@gem_...@in-flight-contexts-10ms.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][7] -> [TIMEOUT][8] ([i915#1958]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk4/igt@gem_exec_re...@basic-concurrent0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/shard-glk1/igt@gem_exec_re...@basic-concurrent0.html - shard-kbl: [PASS][9] -> [TIMEOUT][10] ([i915#1958]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-kbl2/igt@gem_exec_re...@basic-concurrent0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/shard-kbl1/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-fds-forked: - shard-apl: [PASS][11] -> [TIMEOUT][12] ([i915#1635] / [i915#1958]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-apl6/igt@gem_exec_whis...@basic-fds-forked.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/shard-apl1/igt@gem_exec_whis...@basic-fds-forked.html * igt@gem_sync@basic-store-all: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#1635] / [i915#2356]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-apl8/igt@gem_s...@basic-store-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/shard-apl7/igt@gem_s...@basic-store-all.html - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2356]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk8/igt@gem_s...@basic-store-all.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/shard-glk4/igt@gem_s...@basic-store-all.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][17] -> [TIMEOUT][18] ([i915#1521] / [i915#1958]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk9/igt@gem_tiled_swapp...@non-threaded.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/shard-glk6/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-hsw: [PASS][19] -> [WARN][20] ([i915#1519]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-hsw8/igt@i915_pm_rc6_reside...@rc6-fence.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/shard-hsw6/igt@i915_pm_rc6_reside...@rc6-fence.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-glk: [PASS][21] -> [DMESG-FAIL][22] ([i915#118] / [i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk5/igt@kms_big...@y-tiled-64bpp-rotate-0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +5 similar issues [23]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/4] drm/i915/display/dp: Attach and set drm connector VRR property (rev2)
== Series Details == Series: series starting with [v2,1/4] drm/i915/display/dp: Attach and set drm connector VRR property (rev2) URL : https://patchwork.freedesktop.org/series/81081/ State : success == Summary == CI Bug Log - changes from CI_DRM_8930_full -> Patchwork_18413_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18413_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@bcs0: - shard-glk: [PASS][1] -> [FAIL][2] ([i915#2374]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk9/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/shard-glk7/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][3] -> [TIMEOUT][4] ([i915#1958]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk4/igt@gem_exec_re...@basic-concurrent0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/shard-glk5/igt@gem_exec_re...@basic-concurrent0.html - shard-apl: [PASS][5] -> [TIMEOUT][6] ([i915#1635] / [i915#1958]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-apl1/igt@gem_exec_re...@basic-concurrent0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/shard-apl4/igt@gem_exec_re...@basic-concurrent0.html - shard-kbl: [PASS][7] -> [TIMEOUT][8] ([i915#1958]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-kbl2/igt@gem_exec_re...@basic-concurrent0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/shard-kbl1/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-contexts-forked-all: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk7/igt@gem_exec_whis...@basic-contexts-forked-all.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/shard-glk4/igt@gem_exec_whis...@basic-contexts-forked-all.html * igt@gem_exec_whisper@basic-forked: - shard-iclb: [PASS][11] -> [TIMEOUT][12] ([i915#1958]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-iclb5/igt@gem_exec_whis...@basic-forked.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/shard-iclb5/igt@gem_exec_whis...@basic-forked.html * igt@gem_sync@basic-store-all: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#2356]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk8/igt@gem_s...@basic-store-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/shard-glk1/igt@gem_s...@basic-store-all.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][15] -> [TIMEOUT][16] ([i915#1521] / [i915#1958]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk9/igt@gem_tiled_swapp...@non-threaded.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/shard-glk9/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rps@basic-api: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#1635] / [i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-apl4/igt@i915_pm_...@basic-api.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/shard-apl6/igt@i915_pm_...@basic-api.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][19] -> [DMESG-FAIL][20] ([i915#118] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk3/igt@kms_big...@linear-64bpp-rotate-180.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#300]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-xtiled: - shard-glk: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk5/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-xtiled.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/shard-glk3/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-xtiled.html * igt@kms_flip@2x-dpms-vs-vblank-race@ab-vga1-hdmi-a1: - shard-hsw: [PASS][25] -> [DMESG-WARN][26] ([i915#1982]) [25]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev7)
== Series Details == Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev7) URL : https://patchwork.freedesktop.org/series/80542/ State : success == Summary == CI Bug Log - changes from CI_DRM_8930_full -> Patchwork_18410_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18410_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@all: - shard-kbl: [PASS][1] -> [TIMEOUT][2] ([i915#1958]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-kbl1/igt@gem_exec_gttf...@all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/shard-kbl7/igt@gem_exec_gttf...@all.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][3] -> [TIMEOUT][4] ([i915#1958]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk4/igt@gem_exec_re...@basic-concurrent0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/shard-glk3/igt@gem_exec_re...@basic-concurrent0.html - shard-apl: [PASS][5] -> [TIMEOUT][6] ([i915#1635] / [i915#1958]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-apl1/igt@gem_exec_re...@basic-concurrent0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/shard-apl4/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-forked: - shard-iclb: [PASS][7] -> [TIMEOUT][8] ([i915#1958]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-iclb5/igt@gem_exec_whis...@basic-forked.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/shard-iclb1/igt@gem_exec_whis...@basic-forked.html * igt@gem_sync@basic-store-all: - shard-apl: [PASS][9] -> [FAIL][10] ([i915#1635] / [i915#2356]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-apl8/igt@gem_s...@basic-store-all.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/shard-apl6/igt@gem_s...@basic-store-all.html - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2356]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk8/igt@gem_s...@basic-store-all.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/shard-glk2/igt@gem_s...@basic-store-all.html - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2356]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-kbl2/igt@gem_s...@basic-store-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/shard-kbl2/igt@gem_s...@basic-store-all.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1436] / [i915#716]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-skl2/igt@gen9_exec_pa...@allowed-single.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/shard-skl4/igt@gen9_exec_pa...@allowed-single.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#2346]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-skl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/shard-skl5/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-ytiled: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#1635] / [i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-apl3/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-ytiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/shard-apl8/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-ytiled.html * igt@kms_flip@2x-modeset-vs-vblank-race@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-glk5/igt@kms_flip@2x-modeset-vs-vblank-r...@ab-hdmi-a1-hdmi-a2.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/shard-glk5/igt@kms_flip@2x-modeset-vs-vblank-r...@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-blocking-wf-vblank@a-edp1: - shard-skl: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +18 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/shard-skl4/igt@kms_flip@flip-vs-blocking-wf-vbl...@a-edp1.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/shard-skl8/igt@kms_flip@flip-vs-blocking-wf-vbl...@a-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][25] -> [DMESG-WARN][26] ([i915#180]) +8 similar issues [25]:
[Intel-gfx] [PULL] drm-intel-next
Hi Dave and Daniel, here goes the first pull request towards 5.10: As requested, the gem patches have been separated into a drm-intel/topic/drm-intel-gem-next that will be sent separately by the gem team later. Thanks, Rodrigo. drm-intel-next-2020-08-24-1: UAPI Changes: - Introduce a mechanism to extend execbuf2 (Lionel) - Add syncobj timeline support (Lionel) Driver Changes: - Limit stolen mem usage on the compressed frame buffer (Ville) - Some clean-up around display's cdclk (Ville) - Some DDI changes for better DP link training according to spec (Imre) - Provide the perf pmu.module (Chris) - Remove dobious Valleyview PCI IDs (Alexei) - Add new display power saving feature for gen12+ called HOBL (Jose) - Move SKL's clock gating w/a to skl_init_clock_gating() (Ville) - Rocket Lake display additions (Matt) - Selftest: temporarily downgrade on severity of frequency scaling tests (Chris) - Introduce a new display workaround for fixing FLR related issues on new PCH. (Jose) - Temporarily disable FBC on TGL. It was the culprit of random underruns. (Uma). - Copy default modparams to mock i915_device (Chris) - Add compiler paranoia for checking HWSP values (Chris) - Remove useless gen check before calling intel_rps_boost (Chris) - Fix a null pointer dereference (Chris) - Add a couple of missing i915_active_fini() (Chris) - Update TGL display power's bw_buddy table according to update spec (Matt) - Fix couple wrong return values (Tianjia) - Selftest: Avoid passing random 0 into ilog2 (George) - Many Tiger Lake display fixes and improvements for Type-C and DP compliance (Imre, Jose) - Start the addition of PSR2 selective fetch (Jose) - Update a few DMC and HuC firmware versions (Jose) - Add gen11+ w/a to fix underuns (Matt) - Fix cmd parser desc matching with mask (Mika) The following changes since commit 62975d27d647a40c58d3b96c29b911fc4f33c310: drm/ttm: revert "drm/ttm: make TT creation purely optional v3" (2020-08-12 13:26:28 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-08-24-1 for you to fetch changes up to ced026e959bec5046afa310d6474e147b6294da2: drm/i915: Update DRIVER_DATE to 20200824 (2020-08-24 14:26:38 -0400) UAPI Changes: - Introduce a mechanism to extend execbuf2 (Lionel) - Add syncobj timeline support (Lionel) Driver Changes: - Limit stolen mem usage on the compressed frame buffer (Ville) - Some clean-up around display's cdclk (Ville) - Some DDI changes for better DP link training according to spec (Imre) - Provide the perf pmu.module (Chris) - Remove dobious Valleyview PCI IDs (Alexei) - Add new display power saving feature for gen12+ called HOBL (Jose) - Move SKL's clock gating w/a to skl_init_clock_gating() (Ville) - Rocket Lake display additions (Matt) - Selftest: temporarily downgrade on severity of frequency scaling tests (Chris) - Introduce a new display workaround for fixing FLR related issues on new PCH. (Jose) - Temporarily disable FBC on TGL. It was the culprit of random underruns. (Uma). - Copy default modparams to mock i915_device (Chris) - Add compiler paranoia for checking HWSP values (Chris) - Remove useless gen check before calling intel_rps_boost (Chris) - Fix a null pointer dereference (Chris) - Add a couple of missing i915_active_fini() (Chris) - Update TGL display power's bw_buddy table according to update spec (Matt) - Fix couple wrong return values (Tianjia) - Selftest: Avoid passing random 0 into ilog2 (George) - Many Tiger Lake display fixes and improvements for Type-C and DP compliance (Imre, Jose) - Start the addition of PSR2 selective fetch (Jose) - Update a few DMC and HuC firmware versions (Jose) - Add gen11+ w/a to fix underuns (Matt) - Fix cmd parser desc matching with mask (Mika) Alexei Podtelezhnikov (1): drm/i915: Remove dubious Valleyview PCI IDs Chris Wilson (7): drm/i915: Provide the perf pmu.module drm/i915/selftests: Downgrade severity of CS/SRM frequency scaling tests drm/i915: Copy default modparams to mock i915_device drm/i915/selftests: Add compiler paranoia for checking HWSP values drm/i915: Remove gen check before calling intel_rps_boost drm/i915/display: Check for an LPSP encoder before dereferencing drm/i915: Add a couple of missing i915_active_fini() George Spelvin (1): drm/i915/selftests: Avoid passing a random 0 into ilog2 Imre Deak (4): drm/i915/ddi: Don't frob the DP link scramble disabling flag drm/i915/ddi: Don't rewrite DDI_BUF_CTL reg during DP link training drm/i915/tgl: Make sure TC-cold is blocked before enabling TC AUX power wells drm/i915/tgl: Fix TC-cold block/unblock sequence José Roberto de Souza (8): drm/i915/display: Implement HOBL drm/i915: Implement WA 14011294188
Re: [Intel-gfx] [PATCH 4/4] i915: POC use dynamic_debug_exec_queries to control pr_debugs in gvt
Hi Jim,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on linux/master tegra-drm/drm/tegra/for-next
drm-tip/drm-tip linus/master v5.9-rc2 next-20200826]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jim-Cromie/dyndbg-POC-use-dynamic_debug_exec_queries-in-DRM/20200827-010409
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_params.c: In function 'param_set_dyndbg':
>> drivers/gpu/drm/i915/i915_params.c:307:11: error: implicit declaration of
>> function 'dynamic_debug_exec_queries' [-Werror=implicit-function-declaration]
307 | chgct = dynamic_debug_exec_queries(query, "i915");
| ^~
cc1: some warnings being treated as errors
#
https://github.com/0day-ci/linux/commit/1b9bcd2cceed427d96bc9bf4eae6619201d645d6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jim-Cromie/dyndbg-POC-use-dynamic_debug_exec_queries-in-DRM/20200827-010409
git checkout 1b9bcd2cceed427d96bc9bf4eae6619201d645d6
vim +/dynamic_debug_exec_queries +307 drivers/gpu/drm/i915/i915_params.c
283
284 static int param_set_dyndbg(const char *instr, const struct
kernel_param *kp)
285 {
286 static unsigned long int old_val;
287 unsigned int val;
288 unsigned long int changes, result;
289 int rc, chgct = 0, totct = 0, bitpos;
290 char query[OUR_QUERY_SIZE];
291
292 rc = kstrtouint(instr, 0, );
293 if (rc) {
294 pr_err("set_dyndbg: failed\n");
295 return -EINVAL;
296 }
297 result = val;
298 pr_info("set_dyndbg: result:0x%lx from %s\n", result, instr);
299
300 changes = result ^ old_val;
301
302 for_each_set_bit(bitpos, , NUM_CLASSES) {
303
304 sprintf(query, "format='^%s' %cp",
pr_debug_classes[bitpos],
305 test_bit(bitpos, ) ? '+' : '-');
306
> 307 chgct = dynamic_debug_exec_queries(query, "i915");
308 totct += chgct;
309 pr_info("change ct:%d on format='%s'\n", chgct,
310 pr_debug_classes[bitpos]);
311 }
312 old_val = result;
313 pr_info("change ct:%d\n", totct);
314 return 0;
315 }
316 static int param_get_dyndbg(char *buffer, const struct kernel_param *kp)
317 {
318 return scnprintf(buffer, PAGE_SIZE, "%u\n",
319 *((unsigned int *)kp->arg));
320 }
321 static const struct kernel_param_ops param_ops_dyndbg = {
322 .set = param_set_dyndbg,
323 .get = param_get_dyndbg,
324 };
325
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
Hi Tom, On 2019-12-21 15:03, Tom Murphy wrote: This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the driver not respecting the return value of the dma_map_ops::map_sg function. You can see the driver ignoring the return value here: https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 Previously this didn’t cause issues because the intel map_sg always returned the same number of elements as the input scatter gather list but with the change to this dma-iommu api this is no longer the case. I wasn’t able to track the bug down to a specific line of code unfortunately. Could someone from the intel team look at this? I have been testing on a lenovo x1 carbon 5th generation. Let me know if there’s any more information you need. To allow my patch set to be tested I have added a patch (patch 8/8) in this series to disable combining sg segments in the dma-iommu api which fixes the bug but it doesn't fix the actual problem. As part of this patch series I copied the intel bounce buffer code to the dma-iommu path. The addition of the bounce buffer code took me by surprise. I did most of my development on this patch series before the bounce buffer code was added and my reimplementation in the dma-iommu path is very rushed and not properly tested but I’m running out of time to work on this patch set. On top of that I also didn’t port over the intel tracing code from this commit: https://github.com/torvalds/linux/commit/3b53034c268d550d9e8522e613a14ab53b8840d8#diff-6b3e7c4993f05e76331e463ab1fc87e1 So all the work in that commit is now wasted. The code will need to be removed and reimplemented in the dma-iommu path. I would like to take the time to do this but I really don’t have the time at the moment and I want to get these changes out before the iommu code changes any more. Further to what we just discussed at LPC, I've realised that tracepoints are actually something I could do with *right now* for debugging my Arm DMA ops series, so if I'm going to hack something up anyway I may as well take responsibility for polishing it into a proper patch as well :) Robin. Tom Murphy (8): iommu/vt-d: clean up 32bit si_domain assignment iommu/vt-d: Use default dma_direct_* mapping functions for direct mapped devices iommu/vt-d: Remove IOVA handling code from non-dma_ops path iommu: Handle freelists when using deferred flushing in iommu drivers iommu: Add iommu_dma_free_cpu_cached_iovas function iommu: allow the dma-iommu api to use bounce buffers iommu/vt-d: Convert intel iommu driver to the iommu ops DO NOT MERGE: iommu: disable list appending in dma-iommu drivers/iommu/Kconfig | 1 + drivers/iommu/amd_iommu.c | 14 +- drivers/iommu/arm-smmu-v3.c | 3 +- drivers/iommu/arm-smmu.c| 3 +- drivers/iommu/dma-iommu.c | 183 +-- drivers/iommu/exynos-iommu.c| 3 +- drivers/iommu/intel-iommu.c | 936 drivers/iommu/iommu.c | 39 +- drivers/iommu/ipmmu-vmsa.c | 3 +- drivers/iommu/msm_iommu.c | 3 +- drivers/iommu/mtk_iommu.c | 3 +- drivers/iommu/mtk_iommu_v1.c| 3 +- drivers/iommu/omap-iommu.c | 3 +- drivers/iommu/qcom_iommu.c | 3 +- drivers/iommu/rockchip-iommu.c | 3 +- drivers/iommu/s390-iommu.c | 3 +- drivers/iommu/tegra-gart.c | 3 +- drivers/iommu/tegra-smmu.c | 3 +- drivers/iommu/virtio-iommu.c| 3 +- drivers/vfio/vfio_iommu_type1.c | 2 +- include/linux/dma-iommu.h | 3 + include/linux/intel-iommu.h | 1 - include/linux/iommu.h | 32 +- 23 files changed, 345 insertions(+), 908 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
That would be great! On Wed., Aug. 26, 2020, 2:14 p.m. Robin Murphy, wrote: > Hi Tom, > > On 2019-12-21 15:03, Tom Murphy wrote: > > This patchset converts the intel iommu driver to the dma-iommu api. > > > > While converting the driver I exposed a bug in the intel i915 driver > which causes a huge amount of artifacts on the screen of my laptop. You can > see a picture of it here: > > > https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg > > > > This issue is most likely in the i915 driver and is most likely caused > by the driver not respecting the return value of the dma_map_ops::map_sg > function. You can see the driver ignoring the return value here: > > > https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 > > > > Previously this didn’t cause issues because the intel map_sg always > returned the same number of elements as the input scatter gather list but > with the change to this dma-iommu api this is no longer the case. I wasn’t > able to track the bug down to a specific line of code unfortunately. > > > > Could someone from the intel team look at this? > > > > > > I have been testing on a lenovo x1 carbon 5th generation. Let me know if > there’s any more information you need. > > > > To allow my patch set to be tested I have added a patch (patch 8/8) in > this series to disable combining sg segments in the dma-iommu api which > fixes the bug but it doesn't fix the actual problem. > > > > As part of this patch series I copied the intel bounce buffer code to > the dma-iommu path. The addition of the bounce buffer code took me by > surprise. I did most of my development on this patch series before the > bounce buffer code was added and my reimplementation in the dma-iommu path > is very rushed and not properly tested but I’m running out of time to work > on this patch set. > > > > On top of that I also didn’t port over the intel tracing code from this > commit: > > > https://github.com/torvalds/linux/commit/3b53034c268d550d9e8522e613a14ab53b8840d8#diff-6b3e7c4993f05e76331e463ab1fc87e1 > > So all the work in that commit is now wasted. The code will need to be > removed and reimplemented in the dma-iommu path. I would like to take the > time to do this but I really don’t have the time at the moment and I want > to get these changes out before the iommu code changes any more. > > Further to what we just discussed at LPC, I've realised that tracepoints > are actually something I could do with *right now* for debugging my Arm > DMA ops series, so if I'm going to hack something up anyway I may as > well take responsibility for polishing it into a proper patch as well :) > > Robin. > > > > > Tom Murphy (8): > >iommu/vt-d: clean up 32bit si_domain assignment > >iommu/vt-d: Use default dma_direct_* mapping functions for direct > > mapped devices > >iommu/vt-d: Remove IOVA handling code from non-dma_ops path > >iommu: Handle freelists when using deferred flushing in iommu drivers > >iommu: Add iommu_dma_free_cpu_cached_iovas function > >iommu: allow the dma-iommu api to use bounce buffers > >iommu/vt-d: Convert intel iommu driver to the iommu ops > >DO NOT MERGE: iommu: disable list appending in dma-iommu > > > > drivers/iommu/Kconfig | 1 + > > drivers/iommu/amd_iommu.c | 14 +- > > drivers/iommu/arm-smmu-v3.c | 3 +- > > drivers/iommu/arm-smmu.c| 3 +- > > drivers/iommu/dma-iommu.c | 183 +-- > > drivers/iommu/exynos-iommu.c| 3 +- > > drivers/iommu/intel-iommu.c | 936 > > drivers/iommu/iommu.c | 39 +- > > drivers/iommu/ipmmu-vmsa.c | 3 +- > > drivers/iommu/msm_iommu.c | 3 +- > > drivers/iommu/mtk_iommu.c | 3 +- > > drivers/iommu/mtk_iommu_v1.c| 3 +- > > drivers/iommu/omap-iommu.c | 3 +- > > drivers/iommu/qcom_iommu.c | 3 +- > > drivers/iommu/rockchip-iommu.c | 3 +- > > drivers/iommu/s390-iommu.c | 3 +- > > drivers/iommu/tegra-gart.c | 3 +- > > drivers/iommu/tegra-smmu.c | 3 +- > > drivers/iommu/virtio-iommu.c| 3 +- > > drivers/vfio/vfio_iommu_type1.c | 2 +- > > include/linux/dma-iommu.h | 3 + > > include/linux/intel-iommu.h | 1 - > > include/linux/iommu.h | 32 +- > > 23 files changed, 345 insertions(+), 908 deletions(-) > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support (rev2)
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables
for eDP ports without low power support (rev2)
URL : https://patchwork.freedesktop.org/series/81083/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8930 -> Patchwork_18414
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/index.html
Known issues
Here are the changes found in Patchwork_18414 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- fi-icl-y: [PASS][3] -> [INCOMPLETE][4] ([i915#2276])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-icl-y/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/fi-icl-y/igt@i915_selftest@l...@execlists.html
Possible fixes
* igt@gem_exec_parallel@engines@fds:
- fi-kbl-x1275: [INCOMPLETE][5] ([i915#794]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-x1275/igt@gem_exec_parallel@engi...@fds.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/fi-kbl-x1275/igt@gem_exec_parallel@engi...@fds.html
* igt@i915_module_load@reload:
- fi-tgl-u2: [TIMEOUT][7] ([i915#1418]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-tgl-u2: [SKIP][9] ([i915#579]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/fi-tgl-u2/igt@i915_pm_...@module-reload.html
* igt@kms_setmode@basic-clone-single-crtc:
- {fi-kbl-7560u}: [WARN][11] ([i915#2100]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-7560u/igt@kms_setm...@basic-clone-single-crtc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/fi-kbl-7560u/igt@kms_setm...@basic-clone-single-crtc.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#62] / [i915#92]) +3 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][15] ([i915#62]) -> [SKIP][16]
([fdo#109271])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18414/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.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#1418]: https://gitlab.freedesktop.org/drm/intel/issues/1418
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2100]: https://gitlab.freedesktop.org/drm/intel/issues/2100
[i915#2276]: https://gitlab.freedesktop.org/drm/intel/issues/2276
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#794]: https://gitlab.freedesktop.org/drm/intel/issues/794
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (39 -> 34)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper
Build changes
-
* Linux: CI_DRM_8930 -> Patchwork_18414
CI-20190529: 20190529
CI_DRM_8930:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support (rev2)
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables
for eDP ports without low power support (rev2)
URL : https://patchwork.freedesktop.org/series/81083/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1ad237a81b4b drm/i915/display/tgl: Use TGL DP tables for eDP ports without low
power support
-:44: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#44: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1101:
+ *n_entries =
ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
-:63: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthrough;' over fallthrough comment
#63: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1113:
+ /* fall through */
total: 0 errors, 2 warnings, 0 checks, 63 lines checked
65cd4a136d4a drm/i915/display/ehl: Use EHL DP tables for eDP ports without low
power support
-:42: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#42: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1088:
+ return icl_combo_phy_ddi_translations_edp_hbr3;
+ } else {
-:47: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthrough;' over fallthrough comment
#47: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1093:
+ /* fall through */
total: 0 errors, 2 warnings, 0 checks, 31 lines checked
0e96f7e9cca1 drm/i915/ehl: Update voltage swing table
-:9: WARNING:TYPO_SPELLING: 'tunning' may be misspelled - perhaps 'tuning'?
#9:
Update with latest tunning in the table.
total: 0 errors, 1 warnings, 0 checks, 18 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline
On Wed, Aug 26, 2020 at 1:53 PM Harald Arnesen wrote: > > It's a Thinkpad T520. Oh, so this is a 64-bit machine? Yeah, that patch to flush vmalloc ranges won't make any difference on x86-64. Or are you for some reason running a 32-bit kernel on that thing? Have you tried building a 64-bit one (user-space can be 32-bit, it should all just work. Knock wood). Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/i915/display/dp: Attach and set drm connector VRR property (rev2)
== Series Details ==
Series: series starting with [v2,1/4] drm/i915/display/dp: Attach and set drm
connector VRR property (rev2)
URL : https://patchwork.freedesktop.org/series/81081/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8930 -> Patchwork_18413
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/index.html
Known issues
Here are the changes found in Patchwork_18413 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
Possible fixes
* igt@gem_exec_parallel@engines@fds:
- fi-kbl-x1275: [INCOMPLETE][3] ([i915#794]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-x1275/igt@gem_exec_parallel@engi...@fds.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/fi-kbl-x1275/igt@gem_exec_parallel@engi...@fds.html
* igt@i915_module_load@reload:
- fi-tgl-u2: [TIMEOUT][5] ([i915#1418]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-tgl-u2: [SKIP][7] ([i915#579]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/fi-tgl-u2/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [INCOMPLETE][9] ([i915#2045]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@kms_setmode@basic-clone-single-crtc:
- {fi-kbl-7560u}: [WARN][11] ([i915#2100]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-7560u/igt@kms_setm...@basic-clone-single-crtc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/fi-kbl-7560u/igt@kms_setm...@basic-clone-single-crtc.html
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/fi-kbl-x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18413/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1418]: https://gitlab.freedesktop.org/drm/intel/issues/1418
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2045]: https://gitlab.freedesktop.org/drm/intel/issues/2045
[i915#2100]: https://gitlab.freedesktop.org/drm/intel/issues/2100
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#794]: https://gitlab.freedesktop.org/drm/intel/issues/794
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (39 -> 34)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper
Build changes
-
* Linux: CI_DRM_8930 -> Patchwork_18413
CI-20190529: 20190529
CI_DRM_8930: 7e191fed58953c4ed05181997ead358f58b69cf8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5772: 53dfd92f87ecf44251948025533c88f6b889ffeb @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18413: d1fbd676554027417452bf196de463c9d26d0390 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d1fbd6765540 drm/i915/display/dp: Do not enable PSR if VRR is enabled
b585409ae795
Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline
Dave Airlie [26.08.2020 22:47]: > On Thu, 27 Aug 2020 at 06:44, Harald Arnesen wrote: >> >> Linus Torvalds [26.08.2020 20:04]: >> >> > On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote: >> >> Somehow related to lightdm or xfce4? However, it is a regression, since >> >> kernel 5.8 works. >> > Yeah, apparently there's something else wrong with the relocation changes >> > too. >> > >> > That said, does that patch at >> > >> > https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/ >> > >> > change things at all? If there are two independent bugs, maybe >> > applying that patch might at least give you an oops that gets saved in >> > the logs? >> > >> > (it might be worth waiting a bit after the machine locks up in case >> > the machine is alive enough so sync logs after a bit.. If ssh works, >> > that's obviously better yet) >> >> No, doesn't help. And I was wrong, ssh does not work at all when the >> display locks up. > > Did you say what hw you had? is it the same hw as Pavel or different? > > Dave. > It's a Thinkpad T520. Output from 'lspci' attached. -- Hilsen Harald 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04) 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b4) 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4) 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port Mobile SATA AHCI Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04) 03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35) 0d:00.0 System peripheral: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 08) 0d:00.3 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller (rev 04) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline
On Thu, 27 Aug 2020 at 06:44, Harald Arnesen wrote: > > Linus Torvalds [26.08.2020 20:04]: > > > On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote: > >> Somehow related to lightdm or xfce4? However, it is a regression, since > >> kernel 5.8 works. > > Yeah, apparently there's something else wrong with the relocation changes > > too. > > > > That said, does that patch at > > > > https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/ > > > > change things at all? If there are two independent bugs, maybe > > applying that patch might at least give you an oops that gets saved in > > the logs? > > > > (it might be worth waiting a bit after the machine locks up in case > > the machine is alive enough so sync logs after a bit.. If ssh works, > > that's obviously better yet) > > No, doesn't help. And I was wrong, ssh does not work at all when the > display locks up. Did you say what hw you had? is it the same hw as Pavel or different? Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline
Linus Torvalds [26.08.2020 20:04]: > On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote: >> Somehow related to lightdm or xfce4? However, it is a regression, since >> kernel 5.8 works. > Yeah, apparently there's something else wrong with the relocation changes too. > > That said, does that patch at > > https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/ > > change things at all? If there are two independent bugs, maybe > applying that patch might at least give you an oops that gets saved in > the logs? > > (it might be worth waiting a bit after the machine locks up in case > the machine is alive enough so sync logs after a bit.. If ssh works, > that's obviously better yet) No, doesn't help. And I was wrong, ssh does not work at all when the display locks up. -- Hilsen Harald ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/39] drm/i915/gem: Avoid implicit vmap for highmem on x86-32
Chris Wilson [26.08.2020 15:27]:
> On 32b, highmem uses a finite set of indirect PTE (i.e. vmap) to provide
> virtual mappings of the high pages. As these are finite, map_new_virtual()
> must wait for some other kmap() to finish when it runs out. If we map a
> large number of objects, there is no method for it to tell us to release
> the mappings, and we deadlock.
>
> However, if we make an explicit vmap of the page, that uses a larger
> vmalloc arena, and also has the ability to tell us to release unwanted
> mappings. Most importantly, it will fail and propagate an error instead
> of waiting forever.
>
> Fixes: fb8621d3bee8 ("drm/i915: Avoid allocating a vmap arena for a single
> page") #x86-32
> References: e87666b52f00 ("drm/i915/shrinker: Hook up vmap allocation failure
> notifier")
> Signed-off-by: Chris Wilson
> Cc: Harald Arnesen
> Cc: # v4.7+
Sorry, doesn't help on my machine (Thinkpad T520).
--
Hilsen Harald
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/4] drm/i915/display/dp: Attach and set drm connector VRR property (rev2)
== Series Details == Series: series starting with [v2,1/4] drm/i915/display/dp: Attach and set drm connector VRR property (rev2) URL : https://patchwork.freedesktop.org/series/81081/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables
for eDP ports without low power support
URL : https://patchwork.freedesktop.org/series/81083/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8930 -> Patchwork_18412
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18412 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18412, please notify your bug team 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_18412/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18412:
### IGT changes ###
Possible regressions
* igt@gem_exec_parallel@engines@contexts:
- fi-cml-s: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-cml-s/igt@gem_exec_parallel@engi...@contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18412/fi-cml-s/igt@gem_exec_parallel@engi...@contexts.html
Known issues
Here are the changes found in Patchwork_18412 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-icl-y: [PASS][3] -> [INCOMPLETE][4] ([i915#2276])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-icl-y/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18412/fi-icl-y/igt@i915_selftest@l...@execlists.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18412/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@gem_exec_parallel@engines@fds:
- fi-kbl-x1275: [INCOMPLETE][7] ([i915#794]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-x1275/igt@gem_exec_parallel@engi...@fds.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18412/fi-kbl-x1275/igt@gem_exec_parallel@engi...@fds.html
* igt@i915_module_load@reload:
- fi-tgl-u2: [TIMEOUT][9] ([i915#1418]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18412/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-tgl-u2: [SKIP][11] ([i915#579]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18412/fi-tgl-u2/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [INCOMPLETE][13] ([i915#2045]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18412/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18412/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][17] ([i915#2203]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18412/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
* igt@kms_setmode@basic-clone-single-crtc:
- {fi-kbl-7560u}: [WARN][19] ([i915#2100]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-7560u/igt@kms_setm...@basic-clone-single-crtc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18412/fi-kbl-7560u/igt@kms_setm...@basic-clone-single-crtc.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[21]:
[Intel-gfx] [PATCH v2 1/4] drm/i915/display/dp: Attach and set drm connector VRR property
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v6:
* Remove unset of prop
v5:
* Fix the vrr prop not being set in kernel (Manasi)
* Unset the prop on connector disconnect (Manasi)
v4:
* Rebase (Mansi)
v3:
* intel_dp_is_vrr_capable can be used for debugfs, make it
non static (Manasi)
v2:
* Just set this in intel_dp_get_modes instead of new hook (Jani)
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Aditya Swarup
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_dp.c | 24
drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 79c27f91f42c..26657b40aaf1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6276,6 +6276,23 @@ intel_dp_force(struct drm_connector *connector)
intel_display_power_put(dev_priv, aux_domain, wakeref);
}
+bool intel_dp_is_vrr_capable(struct drm_connector *connector)
+{
+ struct intel_dp *intel_dp =
intel_attached_dp(to_intel_connector(connector));
+ const struct drm_display_info *info = >display_info;
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+ /*
+* DP Sink is capable of Variable refresh video timings if
+* Ignore MSA bit is set in DPCD.
+* EDID monitor range also should be atleast 10 for reasonable
+* Adaptive sync/ VRR end user experience.
+*/
+ return INTEL_GEN(dev_priv) >= 12 &&
+ drm_dp_sink_can_do_video_without_timing_msa(intel_dp->dpcd) &&
+ info->monitor_range.max_vfreq - info->monitor_range.min_vfreq >
10;
+}
+
static int intel_dp_get_modes(struct drm_connector *connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -6284,6 +6301,10 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
edid = intel_connector->detect_edid;
if (edid) {
int ret = intel_connector_update_modes(connector, edid);
+
+ if (intel_dp_is_vrr_capable(connector))
+ drm_connector_set_vrr_capable_property(connector,
+ true);
if (ret)
return ret;
}
@@ -7348,6 +7369,9 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
}
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ drm_connector_attach_vrr_capable_property(connector);
}
static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index b901ab850cbd..1fbdb46b26ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -14,6 +14,7 @@ enum pipe;
enum port;
struct drm_connector_state;
struct drm_encoder;
+struct drm_connector;
struct drm_i915_private;
struct drm_modeset_acquire_ctx;
struct drm_dp_vsc_sdp;
@@ -120,6 +121,7 @@ void intel_read_dp_sdp(struct intel_encoder *encoder,
unsigned int type);
bool intel_digital_port_connected(struct intel_encoder *encoder);
void intel_dp_process_phy_request(struct intel_dp *intel_dp);
+bool intel_dp_is_vrr_capable(struct drm_connector *connector);
static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
{
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display/tgl: Use TGL DP tables
for eDP ports without low power support
URL : https://patchwork.freedesktop.org/series/81083/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8017026c4d9e drm/i915/display/tgl: Use TGL DP tables for eDP ports without low
power support
-:44: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#44: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1101:
+ *n_entries =
ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
-:63: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthrough;' over fallthrough comment
#63: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1113:
+ /* fall through */
total: 0 errors, 2 warnings, 0 checks, 63 lines checked
e9e33a64daf7 drm/i915/display/ehl: Use EHL DP tables for eDP ports without low
power support
-:42: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#42: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1088:
+ return icl_combo_phy_ddi_translations_edp_hbr3;
+ } else {
-:47: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthrough;' over fallthrough comment
#47: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1093:
+ /* fall through */
total: 0 errors, 2 warnings, 0 checks, 31 lines checked
bafdc7600734 drm/i915/ehl: Update voltage swing table
-:9: WARNING:TYPO_SPELLING: 'tunning' may be misspelled - perhaps 'tuning'?
#9:
Update with latest tunning in the table.
total: 0 errors, 1 warnings, 0 checks, 18 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/3] drm/i915/display/ehl: Use EHL DP tables for eDP ports without low power support
Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
being used when the eDP port don't support low power voltage swing table.
v2: Only use icl_combo_phy_ddi_translations_edp_hbr3 if low_vswing is
set as EHL combo phy supports HBR3 (Matt R)
Reviewed-by: Matt Roper
Cc: Lee Shawn C
Cc: Khaled Almahallawy
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9a035bb7bd06..699511872290 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1074,12 +1074,28 @@ static const struct cnl_ddi_buf_trans *
ehl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
int *n_entries)
{
- if (type != INTEL_OUTPUT_HDMI && type != INTEL_OUTPUT_EDP) {
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ switch (type) {
+ case INTEL_OUTPUT_HDMI:
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
+ return icl_combo_phy_ddi_translations_hdmi;
+ case INTEL_OUTPUT_EDP:
+ if (dev_priv->vbt.edp.low_vswing) {
+ if (rate > 54) {
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
+ return icl_combo_phy_ddi_translations_edp_hbr3;
+ } else {
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
+ return icl_combo_phy_ddi_translations_edp_hbr2;
+ }
+ }
+ /* fall through */
+ default:
+ /* All combo DP and eDP ports that do not support low_vswing */
*n_entries = ARRAY_SIZE(ehl_combo_phy_ddi_translations_dp);
return ehl_combo_phy_ddi_translations_dp;
}
-
- return icl_get_combo_buf_trans(encoder, type, rate, n_entries);
}
static const struct cnl_ddi_buf_trans *
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 3/3] drm/i915/ehl: Update voltage swing table
Update with latest tunning in the table.
v3: Fix values of to last columns.
BSpec: 21257
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 699511872290..82c1846d9be1 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -572,13 +572,13 @@ static const struct cnl_ddi_buf_trans
ehl_combo_phy_ddi_translations_dp[] = {
/* NT mV Trans mV db*/
{ 0xA, 0x33, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
{ 0xA, 0x47, 0x36, 0x00, 0x09 },/* 350 500 3.1 */
- { 0xC, 0x64, 0x30, 0x00, 0x0F },/* 350 700 6.0 */
- { 0x6, 0x7F, 0x2C, 0x00, 0x13 },/* 350 900 8.2 */
+ { 0xC, 0x64, 0x34, 0x00, 0x0B },/* 350 700 6.0 */
+ { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 350 900 8.2 */
{ 0xA, 0x46, 0x3F, 0x00, 0x00 },/* 500 500 0.0 */
- { 0xC, 0x64, 0x36, 0x00, 0x09 },/* 500 700 2.9 */
- { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 500 900 5.1 */
+ { 0xC, 0x64, 0x38, 0x00, 0x07 },/* 500 700 2.9 */
+ { 0x6, 0x7F, 0x32, 0x00, 0x0D },/* 500 900 5.1 */
{ 0xC, 0x61, 0x3F, 0x00, 0x00 },/* 650 700 0.6 */
- { 0x6, 0x7F, 0x37, 0x00, 0x08 },/* 600 900 3.5 */
+ { 0x6, 0x7F, 0x38, 0x00, 0x07 },/* 600 900 3.5 */
{ 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
};
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/3] drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support
Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
being used when the eDP port don't support low power voltage swing table.
Reviewed-by: Matt Roper
Cc: Lee Shawn C
Cc: Khaled Almahallawy
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 52 +++-
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index de5b216561d8..9a035bb7bd06 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1088,30 +1088,44 @@ tgl_get_combo_buf_trans(struct intel_encoder *encoder,
int type, int rate,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.hobl) {
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-
- if (!intel_dp->hobl_failed && rate <= 54) {
- /* Same table applies to TGL, RKL and DG1 */
- *n_entries =
ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
- return tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
+ switch (type) {
+ case INTEL_OUTPUT_HDMI:
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
+ return icl_combo_phy_ddi_translations_hdmi;
+ case INTEL_OUTPUT_EDP:
+ if (dev_priv->vbt.edp.hobl) {
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+ if (!intel_dp->hobl_failed && rate <= 54) {
+ /* Same table applies to TGL, RKL and DG1 */
+ *n_entries =
ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
+ return
tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
+ }
}
- }
- if (type == INTEL_OUTPUT_HDMI || type == INTEL_OUTPUT_EDP) {
- return icl_get_combo_buf_trans(encoder, type, rate, n_entries);
- } else if (rate > 27) {
- if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
- *n_entries =
ARRAY_SIZE(tgl_uy_combo_phy_ddi_translations_dp_hbr2);
- return tgl_uy_combo_phy_ddi_translations_dp_hbr2;
+ if (rate > 54) {
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
+ return icl_combo_phy_ddi_translations_edp_hbr3;
+ } else if (dev_priv->vbt.edp.low_vswing) {
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
+ return icl_combo_phy_ddi_translations_edp_hbr2;
+ }
+ /* fall through */
+ default:
+ /* All combo DP and eDP ports that do not support low_vswing */
+ if (rate > 27) {
+ if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
+ *n_entries =
ARRAY_SIZE(tgl_uy_combo_phy_ddi_translations_dp_hbr2);
+ return
tgl_uy_combo_phy_ddi_translations_dp_hbr2;
+ }
+
+ *n_entries =
ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr2);
+ return tgl_combo_phy_ddi_translations_dp_hbr2;
}
- *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr2);
- return tgl_combo_phy_ddi_translations_dp_hbr2;
+ *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr);
+ return tgl_combo_phy_ddi_translations_dp_hbr;
}
-
- *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr);
- return tgl_combo_phy_ddi_translations_dp_hbr;
}
static const struct tgl_dkl_phy_ddi_buf_trans *
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/ehl: Update voltage swing table
On Tue, 2020-08-25 at 15:54 -0700, Matt Roper wrote:
> On Tue, Aug 25, 2020 at 11:43:43AM -0700, José Roberto de Souza wrote:
> > Update with latest tunning in the table.
> >
> > BSpec: 21257
> > Cc: Matt Roper <
> > matthew.d.ro...@intel.com
> > >
> > Signed-off-by: José Roberto de Souza <
> > jose.so...@intel.com
> > >
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 699511872290..c7e64e20a772 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -572,14 +572,14 @@ static const struct cnl_ddi_buf_trans
> > ehl_combo_phy_ddi_translations_dp[] = {
> > /* NT mV Trans mV db*/
> > { 0xA, 0x33, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> > { 0xA, 0x47, 0x36, 0x00, 0x09 },/* 350 500 3.1 */
> > - { 0xC, 0x64, 0x30, 0x00, 0x0F },/* 350 700 6.0 */
> > - { 0x6, 0x7F, 0x2C, 0x00, 0x13 },/* 350 900 8.2 */
> > + { 0xC, 0x64, 0x34, 0x00, 0x0B },/* 350 700 6.0 */
> > + { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 350 900 8.2 */
> > { 0xA, 0x46, 0x3F, 0x00, 0x00 },/* 500 500 0.0 */
> > - { 0xC, 0x64, 0x36, 0x00, 0x09 },/* 500 700 2.9 */
> > - { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 500 900 5.1 */
> > + { 0xC, 0x64, 0x38, 0x00, 0x07 },/* 500 700 2.9 */
> > + { 0x6, 0x7F, 0x32, 0x00, 0x0D },/* 500 900 5.1 */
> > { 0xC, 0x61, 0x3F, 0x00, 0x00 },/* 650 700 0.6 */
> > - { 0x6, 0x7F, 0x37, 0x00, 0x08 },/* 600 900 3.5 */
> > - { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> > + { 0x6, 0x7F, 0x37, 0x00, 0x07 },/* 600 900 3.5 */
> > + { 0x6, 0x7F, 0x38, 0x00, 0x00 },/* 900 900 0.0 */
>
> I think it got missed at the bottom of my last response, but I see
> slightly different values for the last two rows here in the EHL table.
> Specifically the third column (cursor coeff dw4) -- I see 0x38 and 0x3F
> as the last two values?
Ops, my bad. Fixing it
>
>
> Matt
>
> > };
> >
> > struct icl_mg_phy_ddi_buf_trans {
> > --
> > 2.28.0
> >
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915/display/dp: Attach and set drm connector VRR property
== Series Details ==
Series: series starting with [1/4] drm/i915/display/dp: Attach and set drm
connector VRR property
URL : https://patchwork.freedesktop.org/series/81081/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8930 -> Patchwork_18411
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18411 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18411, please notify your bug team 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_18411/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18411:
### IGT changes ###
Possible regressions
* igt@kms_chamelium@dp-hpd-fast:
- fi-cml-u2: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-cml-u2/igt@kms_chamel...@dp-hpd-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18411/fi-cml-u2/igt@kms_chamel...@dp-hpd-fast.html
Known issues
Here are the changes found in Patchwork_18411 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18411/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
Possible fixes
* igt@i915_module_load@reload:
- fi-tgl-u2: [TIMEOUT][5] ([i915#1418]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18411/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-tgl-u2: [SKIP][7] ([i915#579]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18411/fi-tgl-u2/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1418]: https://gitlab.freedesktop.org/drm/intel/issues/1418
[i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
Participating hosts (39 -> 10)
--
ERROR: It appears as if the changes made in Patchwork_18411 prevented too
many machines from booting.
Missing(29): fi-bdw-gvtdvm fi-icl-u2 fi-apl-guc fi-snb-2520m fi-icl-y
fi-skl-lmem fi-skl-6600u fi-snb-2600 fi-bxt-dsi fi-cml-s fi-bsw-n3050
fi-byt-j1900 fi-hsw-4770 fi-ivb-3770 fi-elk-e7500 fi-bsw-nick fi-skl-6700k2
fi-kbl-r fi-ilk-m540 fi-ehl-1 fi-skl-guc fi-cfl-8700k fi-hsw-4200u
fi-byt-squawks fi-bsw-cyan fi-kbl-guc fi-kbl-x1275 fi-bsw-kefka fi-byt-clapper
Build changes
-
* Linux: CI_DRM_8930 -> Patchwork_18411
CI-20190529: 20190529
CI_DRM_8930: 7e191fed58953c4ed05181997ead358f58b69cf8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5772: 53dfd92f87ecf44251948025533c88f6b889ffeb @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18411: f73842c16e12de386f65e8dfa9275bc0760b264b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f73842c16e12 drm/i915/display/dp: Do not enable PSR if VRR is enabled
ed38adbd12b4 drm/i915/display/dp: Compute VRR state in atomic_check
14b818af8b2a drm/i915/display/dp: Add VRR crtc state variables
e6eeec55c1f1 drm/i915/display/dp: Attach and set drm connector VRR property
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18411/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/xen-front: Add support for EDID based configuration
== Series Details == Series: drm/xen-front: Add support for EDID based configuration URL : https://patchwork.freedesktop.org/series/81068/ State : success == Summary == CI Bug Log - changes from CI_DRM_8928_full -> Patchwork_18409_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18409_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +8 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/shard-kbl2/igt@gem_ctx_isolation@preservation...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_exec_reloc@basic-concurrent0: - shard-kbl: [PASS][3] -> [TIMEOUT][4] ([i915#1958]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/shard-kbl1/igt@gem_exec_re...@basic-concurrent0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/shard-kbl4/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-contexts-all: - shard-apl: [PASS][5] -> [TIMEOUT][6] ([i915#1635] / [i915#1958]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/shard-apl3/igt@gem_exec_whis...@basic-contexts-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/shard-apl2/igt@gem_exec_whis...@basic-contexts-all.html * igt@gem_exec_whisper@basic-fds-priority: - shard-glk: [PASS][7] -> [TIMEOUT][8] ([i915#1958]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/shard-glk8/igt@gem_exec_whis...@basic-fds-priority.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/shard-glk6/igt@gem_exec_whis...@basic-fds-priority.html * igt@gem_exec_whisper@basic-forked: - shard-iclb: [PASS][9] -> [TIMEOUT][10] ([i915#1958]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/shard-iclb3/igt@gem_exec_whis...@basic-forked.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/shard-iclb3/igt@gem_exec_whis...@basic-forked.html * igt@gem_exec_whisper@basic-queues-forked-all: - shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#118] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/shard-glk2/igt@gem_exec_whis...@basic-queues-forked-all.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/shard-glk5/igt@gem_exec_whis...@basic-queues-forked-all.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1436] / [i915#716]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/shard-skl6/igt@gen9_exec_pa...@allowed-single.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/shard-skl7/igt@gen9_exec_pa...@allowed-single.html * igt@i915_selftest@perf@request: - shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([i915#1823]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/shard-tglb3/igt@i915_selftest@p...@request.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/shard-tglb3/igt@i915_selftest@p...@request.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][17] -> [DMESG-FAIL][18] ([i915#118] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/shard-glk4/igt@kms_big...@y-tiled-64bpp-rotate-180.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_cursor_edge_walk@pipe-b-64x64-right-edge: - shard-hsw: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/shard-hsw6/igt@kms_cursor_edge_w...@pipe-b-64x64-right-edge.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/shard-hsw6/igt@kms_cursor_edge_w...@pipe-b-64x64-right-edge.html * igt@kms_draw_crc@draw-method-xrgb2101010-render-xtiled: - shard-skl: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +9 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/shard-skl5/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/shard-skl1/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html * igt@kms_draw_crc@draw-method-xrgb2101010-render-ytiled: - shard-glk: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/shard-glk5/igt@kms_draw_...@draw-method-xrgb2101010-render-ytiled.html [24]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/display/dp: Attach and set drm connector VRR property
== Series Details == Series: series starting with [1/4] drm/i915/display/dp: Attach and set drm connector VRR property URL : https://patchwork.freedesktop.org/series/81081/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev7)
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev7)
URL : https://patchwork.freedesktop.org/series/80542/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8930 -> Patchwork_18410
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/index.html
Known issues
Here are the changes found in Patchwork_18410 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- fi-icl-y: [PASS][3] -> [INCOMPLETE][4] ([i915#2276])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-icl-y/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/fi-icl-y/igt@i915_selftest@l...@execlists.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
Possible fixes
* igt@gem_exec_parallel@engines@fds:
- fi-kbl-x1275: [INCOMPLETE][7] ([i915#794]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-x1275/igt@gem_exec_parallel@engi...@fds.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/fi-kbl-x1275/igt@gem_exec_parallel@engi...@fds.html
* igt@i915_module_load@reload:
- fi-tgl-u2: [TIMEOUT][9] ([i915#1418]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-tgl-u2: [SKIP][11] ([i915#579]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-tgl-u2/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/fi-tgl-u2/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][15] ([i915#2203]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
Warnings
* igt@i915_module_load@reload:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-x1275/igt@i915_module_l...@reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/fi-kbl-x1275/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][19] ([i915#62]) -> [SKIP][20]
([fdo#109271])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +6 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8930/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18410/fi-kbl-x1275/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
[i915#1418]: https://gitlab.freedesktop.org/drm/intel/issues/1418
[i915#1982]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev7)
== Series Details == Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev7) URL : https://patchwork.freedesktop.org/series/80542/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:expected unsigned int [addressable] [usertype] ulClockParams +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:got restricted __le32 [usertype] +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1028:50: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1029:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1037:47: warning: too many warnings +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:184:44: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:283:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:320:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:323:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:326:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:329:18: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:330:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:338:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:340:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:342:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:346:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:348:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:353:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:367:43: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:369:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:374:67: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:375:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:378:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:389:80: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:395:57: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:402:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:403:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:406:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:414:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:423:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:424:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:473:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:476:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:477:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:484:54: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:52:28: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:531:35: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:53:29: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:533:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:54:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:55:27: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:56:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:57:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:577:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:581:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:58:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:583:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:586:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:590:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:59:26: warning: cast to restricted __le16
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915 (rev7)
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev7)
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b76b4b6f3675 drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 21 lines checked
376f1358fe13 drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc()
-:102: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct
nouveau_connector *' should also have an identifier name
#102: FILE: drivers/gpu/drm/nouveau/nouveau_encoder.h:109:
+int nouveau_dp_detect(struct nouveau_connector *, struct nouveau_encoder *);
-:102: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct
nouveau_encoder *' should also have an identifier name
#102: FILE: drivers/gpu/drm/nouveau/nouveau_encoder.h:109:
+int nouveau_dp_detect(struct nouveau_connector *, struct nouveau_encoder *);
total: 0 errors, 2 warnings, 0 checks, 74 lines checked
bb5629743bd6 drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c
5a0c0ceff3b9 drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c
ed53a7f096cc drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new()
-:7: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit fa3cdf8d0b09 ("drm/nouveau:
Reset MST branching unit before enabling")'
#7:
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
total: 1 errors, 0 warnings, 0 checks, 17 lines checked
2e212bc94c2b drm/nouveau/kms: Search for encoders' connectors properly
d5c0b632ff50 drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in
nv50_sor_disable()
a494bdb7a99a drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling
-:53: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#53:
* Enabling bits in MSTM_CTRL before calling drm_dp_mst_topology_mgr_set_mst().
-:465: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct
drm_device *' should also have an identifier name
#465: FILE: drivers/gpu/drm/nouveau/nouveau_display.h:21:
+ void (*fini)(struct drm_device *, bool suspend, bool runtime);
total: 0 errors, 2 warnings, 0 checks, 574 lines checked
93c32b56a998 drm/i915/dp: Extract drm_dp_read_mst_cap()
ab23bfd0015b drm/nouveau/kms: Use new drm_dp_read_mst_cap() helper for checking
MST caps
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 29 lines checked
d218727b4477 drm/nouveau/kms: Move drm_dp_cec_unset_edid() into
nouveau_connector_detect()
375b0f4cdd81 drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths
-:279: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment
#279: FILE: drivers/gpu/drm/nouveau/nouveau_drv.h:201:
+ struct mutex hpd_lock;
total: 0 errors, 0 warnings, 1 checks, 219 lines checked
0134505297a1 drm/i915/dp: Extract drm_dp_read_downstream_info()
-:38: WARNING:BAD_SIGN_OFF: Duplicate signature
#38:
Signed-off-by: Lyude Paul
total: 0 errors, 1 warnings, 0 checks, 109 lines checked
c4728875a1e1 drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode
validation
-:63: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#63: FILE: drivers/gpu/drm/nouveau/nouveau_dp.c:194:
+ unsigned max_clock, ds_clock, clock;
total: 0 errors, 1 warnings, 0 checks, 57 lines checked
21a1acc8b05d drm/i915/dp: Extract drm_dp_read_sink_count_cap()
b10ed3135378 drm/i915/dp: Extract drm_dp_read_sink_count()
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#12:
* Add back comment and move back sink_count assignment in intel_dp_get_dpcd()
total: 0 errors, 1 warnings, 0 checks, 74 lines checked
9de8d3818bd8 drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#11:
plugged into it currently results in a bogus EDID retrieval error in the kernel
log.
total: 0 errors, 1 warnings, 0 checks, 107 lines checked
b2ef4135a827 drm/nouveau/kms: Don't change EDID when it hasn't actually changed
6da06b467e41 drm/i915/dp: Extract drm_dp_read_dpcd_caps()
02383c82b60a drm/nouveau/kms: Start using drm_dp_read_dpcd_caps()
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/display/dp: Do not enable PSR if VRR is enabled
Even though our HW supports PSR + VRR, the available panels do not work reliably with PSR and VRR together. So if user requested VRR and is supported by HW enable that and do not enable PSR in that case. Cc: Ville Syrjälä Cc: Gwan-gyeong Mun Cc: Imre Deak Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/display/intel_psr.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index 2b004ee9619c..f37d17569009 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -811,6 +811,13 @@ void intel_psr_compute_config(struct intel_dp *intel_dp, _state->hw.adjusted_mode; int psr_setup_time; + /* +* Current PSR panels dont work reliably with VRR enabled +* So if VRR is enabled, do not enable PSR. +*/ + if (crtc_state->vrr.enable) + return; + if (!CAN_PSR(dev_priv)) return; -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/display/dp: Compute VRR state in atomic_check
This forces a complete modeset if vrr drm crtc state goes
from enabled to disabled and vice versa.
This patch also computes vrr state variables from the mode timings
and based on the vrr property set by userspace as well as hardware's
vrr capability.
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 12 +--
drivers/gpu/drm/i915/display/intel_dp.c | 33
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c8b1dd1a9e46..4caa4cb16b5c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14033,6 +14033,10 @@ intel_pipe_config_compare(const struct
intel_crtc_state *current_config,
PIPE_CONF_CHECK_I(mst_master_transcoder);
+ PIPE_CONF_CHECK_BOOL(vrr.enable);
+ PIPE_CONF_CHECK_I(vrr.vtotalmin);
+ PIPE_CONF_CHECK_I(vrr.vtotalmax);
+
#undef PIPE_CONF_CHECK_X
#undef PIPE_CONF_CHECK_I
#undef PIPE_CONF_CHECK_BOOL
@@ -14899,7 +14903,9 @@ static int intel_atomic_check(struct drm_device *dev,
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
- if (!needs_modeset(new_crtc_state)) {
+ if (!needs_modeset(new_crtc_state) &&
+ old_crtc_state->uapi.vrr_enabled ==
+ new_crtc_state->uapi.vrr_enabled) {
/* Light copy */
intel_crtc_copy_uapi_to_hw_state_nomodeset(new_crtc_state);
@@ -14920,7 +14926,9 @@ static int intel_atomic_check(struct drm_device *dev,
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
- if (!needs_modeset(new_crtc_state))
+ if (!needs_modeset(new_crtc_state) &&
+ old_crtc_state->uapi.vrr_enabled ==
+ new_crtc_state->uapi.vrr_enabled)
continue;
ret = intel_modeset_pipe_config_late(new_crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3a7129a8ca8a..af2f8fc4f9b1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2575,6 +2575,38 @@ intel_dp_compute_hdr_metadata_infoframe_sdp(struct
intel_dp *intel_dp,
intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA);
}
+static void
+intel_dp_vrr_config(struct intel_dp *intel_dp,
+ struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = _connector->base;
+ struct drm_display_mode *adjusted_mode = _state->hw.adjusted_mode;
+ const struct drm_display_info *info = >display_info;
+
+ if (!intel_dp_is_vrr_capable(connector) ||
+ !crtc_state->uapi.vrr_enabled)
+ return;
+
+ crtc_state->vrr.enable = true;
+ crtc_state->vrr.vtotalmin =
+ min_t(u16, adjusted_mode->crtc_vtotal,
+ DIV_ROUND_CLOSEST(adjusted_mode->crtc_clock * 1000,
+ adjusted_mode->crtc_htotal *
+ info->monitor_range.max_vfreq));
+ crtc_state->vrr.vtotalmax =
+ max_t(u16, adjusted_mode->crtc_vtotal,
+ DIV_ROUND_UP(adjusted_mode->crtc_clock * 1000,
+ adjusted_mode->crtc_htotal *
+ info->monitor_range.min_vfreq));
+
+ drm_info(_priv->drm,
+"VRR Config: Enable = %s Vtotal Min = %d Vtotal Max = %d",
+yesno(crtc_state->vrr.enable), crtc_state->vrr.vtotalmin,
+crtc_state->vrr.vtotalmax);
+}
+
int
intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
@@ -2671,6 +2703,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (!HAS_DDI(dev_priv))
intel_dp_set_clock(encoder, pipe_config);
+ intel_dp_vrr_config(intel_dp, pipe_config);
intel_psr_compute_config(intel_dp, pipe_config);
intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, pipe_config,
conn_state);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/display/dp: Attach and set drm connector VRR property
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v5:
* Fix the vrr prop not being set in kernel (Manasi)
* Unset the prop on connector disconnect (Manasi)
v4:
* Rebase (Mansi)
v3:
* intel_dp_is_vrr_capable can be used for debugfs, make it
non static (Manasi)
v2:
* Just set this in intel_dp_get_modes instead of new hook (Jani)
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Aditya Swarup
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_dp.c | 27 +
drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 79c27f91f42c..3a7129a8ca8a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6160,6 +6160,9 @@ intel_dp_detect(struct drm_connector *connector,
if (status == connector_status_disconnected) {
memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
+ /*Reset the immutable VRR Capable property */
+ drm_connector_set_vrr_capable_property(connector,
+ false);
if (intel_dp->is_mst) {
drm_dbg_kms(_priv->drm,
@@ -6276,6 +6279,23 @@ intel_dp_force(struct drm_connector *connector)
intel_display_power_put(dev_priv, aux_domain, wakeref);
}
+bool intel_dp_is_vrr_capable(struct drm_connector *connector)
+{
+ struct intel_dp *intel_dp =
intel_attached_dp(to_intel_connector(connector));
+ const struct drm_display_info *info = >display_info;
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+ /*
+* DP Sink is capable of Variable refresh video timings if
+* Ignore MSA bit is set in DPCD.
+* EDID monitor range also should be atleast 10 for reasonable
+* Adaptive sync/ VRR end user experience.
+*/
+ return INTEL_GEN(dev_priv) >= 12 &&
+ drm_dp_sink_can_do_video_without_timing_msa(intel_dp->dpcd) &&
+ info->monitor_range.max_vfreq - info->monitor_range.min_vfreq >
10;
+}
+
static int intel_dp_get_modes(struct drm_connector *connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -6284,6 +6304,10 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
edid = intel_connector->detect_edid;
if (edid) {
int ret = intel_connector_update_modes(connector, edid);
+
+ if (intel_dp_is_vrr_capable(connector))
+ drm_connector_set_vrr_capable_property(connector,
+ true);
if (ret)
return ret;
}
@@ -7348,6 +7372,9 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
}
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ drm_connector_attach_vrr_capable_property(connector);
}
static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index b901ab850cbd..1fbdb46b26ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -14,6 +14,7 @@ enum pipe;
enum port;
struct drm_connector_state;
struct drm_encoder;
+struct drm_connector;
struct drm_i915_private;
struct drm_modeset_acquire_ctx;
struct drm_dp_vsc_sdp;
@@ -120,6 +121,7 @@ void intel_read_dp_sdp(struct intel_encoder *encoder,
unsigned int type);
bool intel_digital_port_connected(struct intel_encoder *encoder);
void intel_dp_process_phy_request(struct intel_dp *intel_dp);
+bool intel_dp_is_vrr_capable(struct drm_connector *connector);
static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
{
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/display/dp: Add VRR crtc state variables
Introduce VRR struct in intel_crtc_state and add
VRR crtc state variables Enable, Vtotalmin and Vtotalmax
to be derived from mode timings and VRR crtc property.
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display_types.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9349b15afff6..ab57f225706b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1076,6 +1076,13 @@ struct intel_crtc_state {
struct intel_dsb *dsb;
u32 psr2_man_track_ctl;
+
+ /* Variable Refresh Rate state */
+ struct {
+ bool enable;
+ u16 vtotalmin;
+ u16 vtotalmax;
+ } vrr;
};
enum intel_pipe_crc_source {
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [igt-gpu-tools] Fixing the latency of hrtimer
The blocking/polling parameterized tests were introduced to test
different hrtimer configurations.These tests check how many times the
process wakes up to read the reports with different hrtimer values (=
duration of test / hrtimer value). A user is more likely to choose a
larger hrtimer value than the default 5ms to avoid wake up too frequently.
Signed-off-by: Sowmya Kaparthi
---
tests/i915/perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/i915/perf.c b/tests/i915/perf.c
index a894fd38..5fd1193f 100644
--- a/tests/i915/perf.c
+++ b/tests/i915/perf.c
@@ -4995,7 +4995,7 @@ igt_main
40 * 1000 * 1000 /* default 40ms hrtimer */);
test_blocking(500 * 1000 /* 500us oa period */,
true /* set_kernel_hrtimer */,
- 2 * 1000 * 1000 /* default 2ms hrtimer */);
+ 10 * 1000 * 1000 /* default 10ms hrtimer */);
}
igt_describe("Test polled read with default hrtimer frequency");
@@ -5014,7 +5014,7 @@ igt_main
40 * 1000 * 1000 /* default 40ms hrtimer */);
test_polling(500 * 1000 /* 500us oa period */,
true /* set_kernel_hrtimer */,
-2 * 1000 * 1000 /* default 2ms hrtimer */);
+10 * 1000 * 1000 /* default 10ms hrtimer */);
}
igt_describe("Test polled read with buffer size smaller than available
data");
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 16/20] drm/i915/dp: Extract drm_dp_read_sink_count()
And of course, we'll also need to read the sink count from other drivers
as well if we're checking whether or not it's supported. So, let's
extract the code for this into another helper.
v2:
* Fix drm_dp_dpcd_readb() ret check
* Add back comment and move back sink_count assignment in intel_dp_get_dpcd()
v5:
* Change name from drm_dp_get_sink_count() to drm_dp_read_sink_count()
* Also, add "See also:" section to kdocs
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_dp_helper.c | 26 +
drivers/gpu/drm/i915/display/intel_dp.c | 11 +--
include/drm/drm_dp_helper.h | 1 +
3 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 65ff21ae0c271..46d88ef4f59ac 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -733,6 +733,8 @@ EXPORT_SYMBOL(drm_dp_set_subconnector_property);
* @dpcd: A cached copy of the connector's DPCD RX capabilities
* @desc: A cached copy of the connector's DP descriptor
*
+ * See also: drm_dp_read_sink_count()
+ *
* Returns: %True if the (e)DP connector has a valid sink count that should
* be probed, %false otherwise.
*/
@@ -748,6 +750,30 @@ bool drm_dp_read_sink_count_cap(struct drm_connector
*connector,
}
EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
+/**
+ * drm_dp_read_sink_count() - Retrieve the sink count for a given sink
+ * @aux: The DP AUX channel to use
+ *
+ * See also: drm_dp_read_sink_count_cap()
+ *
+ * Returns: The current sink count reported by @aux, or a negative error code
+ * otherwise.
+ */
+int drm_dp_read_sink_count(struct drm_dp_aux *aux)
+{
+ u8 count;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_SINK_COUNT, );
+ if (ret < 0)
+ return ret;
+ if (ret != 1)
+ return -EIO;
+
+ return DP_GET_SINK_COUNT(count);
+}
+EXPORT_SYMBOL(drm_dp_read_sink_count);
+
/*
* I2C-over-AUX implementation
*/
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 38318ae935f88..0de94fc6289be 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4648,6 +4648,8 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
static bool
intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
+ int ret;
+
if (!intel_dp_read_dpcd(intel_dp))
return false;
@@ -4664,11 +4666,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
}
if (intel_dp_has_sink_count(intel_dp)) {
- u8 count;
- ssize_t r;
-
- r = drm_dp_dpcd_readb(_dp->aux, DP_SINK_COUNT, );
- if (r < 1)
+ ret = drm_dp_read_sink_count(_dp->aux);
+ if (ret < 0)
return false;
/*
@@ -4676,7 +4675,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
* a member variable in intel_dp will track any changes
* between short pulse interrupts.
*/
- intel_dp->sink_count = DP_GET_SINK_COUNT(count);
+ intel_dp->sink_count = ret;
/*
* SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4c56ce4dc54fc..bc5cb8c503fbc 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1635,6 +1635,7 @@ struct drm_dp_desc;
bool drm_dp_read_sink_count_cap(struct drm_connector *connector,
const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const struct drm_dp_desc *desc);
+int drm_dp_read_sink_count(struct drm_dp_aux *aux);
void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
void drm_dp_aux_init(struct drm_dp_aux *aux);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 17/20] drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT
This is another bit that we never implemented for nouveau: dongle
detection. When a "dongle", e.g. an active display adaptor, is hooked up
to the system and causes an HPD to be fired, we don't actually know
whether or not there's anything plugged into the dongle without checking
the sink count. As a result, plugging in a dongle without anything
plugged into it currently results in a bogus EDID retrieval error in the kernel
log.
Additionally, most dongles won't send another long HPD signal if the
user suddenly plugs something in, they'll only send a short HPD IRQ with
the expectation that the source will check the sink count and reprobe
the connector if it's changed - something we don't actually do. As a
result, nothing will happen if the user plugs the dongle in before
plugging something into the dongle.
So, let's fix this by checking the sink count in both
nouveau_dp_probe_dpcd() and nouveau_dp_irq(), and reprobing the
connector if things change.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 53 ---
drivers/gpu/drm/nouveau/nouveau_encoder.h | 2 +
2 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index ad852e572cfec..59be357b17e00 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -36,12 +36,21 @@ MODULE_PARM_DESC(mst, "Enable DisplayPort multi-stream
(default: enabled)");
static int nouveau_mst = 1;
module_param_named(mst, nouveau_mst, int, 0400);
+static bool
+nouveau_dp_has_sink_count(struct drm_connector *connector,
+ struct nouveau_encoder *outp)
+{
+ return drm_dp_read_sink_count_cap(connector, outp->dp.dpcd,
>dp.desc);
+}
+
static enum drm_connector_status
nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
struct nouveau_encoder *outp)
{
+ struct drm_connector *connector = _connector->base;
struct drm_dp_aux *aux = _connector->aux;
struct nv50_mstm *mstm = NULL;
+ enum drm_connector_status status = connector_status_disconnected;
int ret;
u8 *dpcd = outp->dp.dpcd;
@@ -50,9 +59,9 @@ nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
ret = drm_dp_read_desc(aux, >dp.desc,
drm_dp_is_branch(dpcd));
if (ret < 0)
- return connector_status_disconnected;
+ goto out;
} else {
- return connector_status_disconnected;
+ goto out;
}
if (nouveau_mst) {
@@ -61,12 +70,33 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
*nv_connector,
mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
}
+ if (nouveau_dp_has_sink_count(connector, outp)) {
+ ret = drm_dp_read_sink_count(aux);
+ if (ret < 0)
+ goto out;
+
+ outp->dp.sink_count = ret;
+
+ /*
+* Dongle connected, but no display. Don't bother reading
+* downstream port info
+*/
+ if (!outp->dp.sink_count)
+ return connector_status_disconnected;
+ }
+
ret = drm_dp_read_downstream_info(aux, dpcd,
outp->dp.downstream_ports);
if (ret < 0)
- return connector_status_disconnected;
+ goto out;
- return connector_status_connected;
+ status = connector_status_connected;
+out:
+ if (status != connector_status_connected) {
+ /* Clear any cached info */
+ outp->dp.sink_count = 0;
+ }
+ return status;
}
int
@@ -159,6 +189,8 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
struct drm_connector *connector = _connector->base;
struct nouveau_encoder *outp = find_encoder(connector, DCB_OUTPUT_DP);
struct nv50_mstm *mstm;
+ int ret;
+ bool send_hpd = false;
if (!outp)
return;
@@ -170,12 +202,23 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
if (mstm && mstm->is_mst) {
if (!nv50_mstm_service(drm, nv_connector, mstm))
- nouveau_connector_hpd(connector);
+ send_hpd = true;
} else {
drm_dp_cec_irq(_connector->aux);
+
+ if (nouveau_dp_has_sink_count(connector, outp)) {
+ ret = drm_dp_read_sink_count(_connector->aux);
+ if (ret != outp->dp.sink_count)
+ send_hpd = true;
+ if (ret >= 0)
+ outp->dp.sink_count = ret;
+ }
}
mutex_unlock(>dp.hpd_irq_lock);
+
+ if (send_hpd)
+
Re: [Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
On Mon, Aug 24, 2020 at 2:56 AM Tom Murphy wrote:
>
> Hi Logan/All,
>
> I have added a check for the sg_dma_len == 0 :
> """
> } __sgt_iter(struct scatterlist *sgl, bool dma) {
> struct sgt_iter s = { .sgp = sgl };
>
> + if (sgl && sg_dma_len(sgl) == 0)
> + s.sgp = NULL;
>
> if (s.sgp) {
> .
> """
> at location [1].
> but it doens't fix the problem.
>
> You're right though, this change does need to be made, this code
> doesn't handle pages of sg_dma_len(sg) == 0 correctly
> So my guess is that we have more bugs in other parts of the i915
> driver (or there is a problem with my "sg_dma_len == 0" fix above).
> I have been trying to spot where else the code might be buggy but I
> haven't had any luck so far.
>
> I'm doing a microconfernce (at LPC 2020) this wednesdays [1] on this
> if you're interested in attending.
> I'm hoping I can chat about it with a few people and find how can
> reproduce and fix this issues. I don't have any more time I can give
> to this unfortunately and it would be a shame for the work to go to
> waste.
>
> [0]
> https://github.com/torvalds/linux/blob/d012a7190fc1fd72ed48911e77ca97ba4521bccd/drivers/gpu/drm/i915/i915_scatterlist.h#L28
> [1] https://linuxplumbersconf.org/event/7/contributions/846/
>
> On Fri, 29 May 2020 at 22:21, Logan Gunthorpe wrote:
> >
> >
> >
> > On 2020-05-29 3:11 p.m., Marek Szyprowski wrote:
> > > Patches are pending:
> > > https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@samsung.com/T/
> >
> > Cool, nice! Though, I still don't think that fixes the issue in
> > i915_scatterlist.h given it still ignores sg_dma_len() and strictly
> > relies on sg_next()/sg_is_last() to stop iterating -- and I suspect this
> > is the bug that got in Tom's way.
> >
> > >> However, as Robin pointed out, there are other ugly tricks like stopping
> > >> iterating through the SGL when sg_dma_len() is zero. For example, the
> > >> AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does
> > >> this trick and thus likely isn't buggy (otherwise, I'd expect someone to
> > >> have complained by now seeing AMD has already switched to IOMMU-DMA.
We ran into the same issue with amdgpu and radeon when the AMD IOMMU
driver was converted and had to fix it as well. The relevant fixes
were:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42e67b479eab6d26459b80b4867298232b0435e7
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0199172f933342d8b1011aae2054a695c25726f4
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47f7826c520ecd92ffbffe59ecaa2fe61e42ec70
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c0f83d164fb8f3a2b7bc379a6c1e27d1123a9eab
Alex
> > >
> > > I'm not sure that this is a trick. Stopping at zero sg_dma_len() was
> > > somewhere documented.
> >
> > Well whatever you want to call it, it is ugly to have some drivers doing
> > one thing with the returned value and others assuming there's an extra
> > zero at the end. It just causes confusion for people reading/copying the
> > code. It would be better if they are all consistent. However, I concede
> > stopping at zero should not be broken, presently.
> >
> > Logan
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 20/20] drm/nouveau/kms: Start using drm_dp_read_dpcd_caps()
Now that we've extracted i915's code for reading both the normal DPCD
caps and extended DPCD caps into a shared helper, let's start using this
in nouveau to enable us to start checking extended DPCD caps for free.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 59be357b17e00..810bf69565683 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -54,15 +54,13 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
*nv_connector,
int ret;
u8 *dpcd = outp->dp.dpcd;
- ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
- if (ret == DP_RECEIVER_CAP_SIZE && dpcd[DP_DPCD_REV]) {
- ret = drm_dp_read_desc(aux, >dp.desc,
- drm_dp_is_branch(dpcd));
- if (ret < 0)
- goto out;
- } else {
+ ret = drm_dp_read_dpcd_caps(aux, dpcd);
+ if (ret < 0)
+ goto out;
+
+ ret = drm_dp_read_desc(aux, >dp.desc, drm_dp_is_branch(dpcd));
+ if (ret < 0)
goto out;
- }
if (nouveau_mst) {
mstm = outp->dp.mstm;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 18/20] drm/nouveau/kms: Don't change EDID when it hasn't actually changed
Currently in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds(), we start the connector probing process
by releasing the previous EDID and informing DRM of the change. However,
since commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") drm_connector_update_edid_property() actually checks
whether the new EDID we've specified is different from the previous one,
and updates the connector's epoch accordingly if it is. But, because we
always set the EDID to NULL first in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds() we end up making DRM think that the EDID
changes every single time we do a connector probe - which isn't needed.
So, let's fix this by not clearing the EDID at the start of the
connector probing process, and instead simply changing or removing it
once near the end of the probing process. This will help prevent us from
sending unneeded hotplug events to userspace when nothing has actually
changed.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 54 ++---
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 637e91594fbe8..49dd0cbc332ff 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -528,6 +528,17 @@ nouveau_connector_set_encoder(struct drm_connector
*connector,
}
}
+static void
+nouveau_connector_set_edid(struct nouveau_connector *nv_connector,
+ struct edid *edid)
+{
+ struct edid *old_edid = nv_connector->edid;
+
+ drm_connector_update_edid_property(_connector->base, edid);
+ kfree(old_edid);
+ nv_connector->edid = edid;
+}
+
static enum drm_connector_status
nouveau_connector_detect(struct drm_connector *connector, bool force)
{
@@ -541,13 +552,6 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
int ret;
enum drm_connector_status conn_status = connector_status_disconnected;
- /* Cleanup the previous EDID block. */
- if (nv_connector->edid) {
- drm_connector_update_edid_property(connector, NULL);
- kfree(nv_connector->edid);
- nv_connector->edid = NULL;
- }
-
/* Outputs are only polled while runtime active, so resuming the
* device here is unnecessary (and would deadlock upon runtime suspend
* because it waits for polling to finish). We do however, want to
@@ -560,22 +564,23 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
ret = pm_runtime_get_sync(dev->dev);
if (ret < 0 && ret != -EACCES) {
pm_runtime_put_autosuspend(dev->dev);
+ nouveau_connector_set_edid(nv_connector, NULL);
return conn_status;
}
}
nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
+ struct edid *new_edid;
+
if ((vga_switcheroo_handler_flags() &
VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
nv_connector->type == DCB_CONNECTOR_LVDS)
- nv_connector->edid = drm_get_edid_switcheroo(connector,
-i2c);
+ new_edid = drm_get_edid_switcheroo(connector, i2c);
else
- nv_connector->edid = drm_get_edid(connector, i2c);
+ new_edid = drm_get_edid(connector, i2c);
- drm_connector_update_edid_property(connector,
- nv_connector->edid);
+ nouveau_connector_set_edid(nv_connector, new_edid);
if (!nv_connector->edid) {
NV_ERROR(drm, "DDC responded, but no EDID for %s\n",
connector->name);
@@ -609,6 +614,8 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
conn_status = connector_status_connected;
drm_dp_cec_set_edid(_connector->aux, nv_connector->edid);
goto out;
+ } else {
+ nouveau_connector_set_edid(nv_connector, NULL);
}
nv_encoder = nouveau_connector_of_detect(connector);
@@ -652,18 +659,12 @@ nouveau_connector_detect_lvds(struct drm_connector
*connector, bool force)
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_encoder *nv_encoder = NULL;
+ struct edid *edid = NULL;
enum drm_connector_status status = connector_status_disconnected;
- /* Cleanup the previous EDID block. */
- if (nv_connector->edid) {
-
[Intel-gfx] [PATCH v5 12/20] drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths
Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a connector hotplug happens to occur in parallel
with a modeset.
I haven't seen this actually happen yet, but since we're cleaning up
nouveau's hotplug handling code anyway and we already have a hpd worker,
we can simply fix this by only relying on the HPD worker to actually
reprobe connectors when we receive a HPD IRQ. We also add a mask to
nouveau_drm to keep track of which connectors are waiting to be reprobed
in response to an HPD IRQ.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 42 +
drivers/gpu/drm/nouveau/nouveau_connector.h | 1 +
drivers/gpu/drm/nouveau/nouveau_display.c | 70 ++---
drivers/gpu/drm/nouveau/nouveau_display.h | 1 +
drivers/gpu/drm/nouveau/nouveau_dp.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
7 files changed, 86 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 4a29f691c08e4..637e91594fbe8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1138,6 +1138,20 @@ nouveau_connector_funcs_lvds = {
.early_unregister = nouveau_connector_early_unregister,
};
+void
+nouveau_connector_hpd(struct drm_connector *connector)
+{
+ struct nouveau_drm *drm = nouveau_drm(connector->dev);
+ u32 mask = drm_connector_mask(connector);
+
+ mutex_lock(>hpd_lock);
+ if (!(drm->hpd_pending & mask)) {
+ drm->hpd_pending |= mask;
+ schedule_work(>hpd_work);
+ }
+ mutex_unlock(>hpd_lock);
+}
+
static int
nouveau_connector_hotplug(struct nvif_notify *notify)
{
@@ -1147,8 +1161,6 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
struct drm_device *dev = connector->dev;
struct nouveau_drm *drm = nouveau_drm(dev);
const struct nvif_notify_conn_rep_v0 *rep = notify->data;
- const char *name = connector->name;
- int ret;
bool plugged = (rep->mask != NVIF_NOTIFY_CONN_V0_UNPLUG);
if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) {
@@ -1156,31 +1168,9 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
return NVIF_NOTIFY_KEEP;
}
- ret = pm_runtime_get(drm->dev->dev);
- if (ret == 0) {
- /* We can't block here if there's a pending PM request
-* running, as we'll deadlock nouveau_display_fini() when it
-* calls nvif_put() on our nvif_notify struct. So, simply
-* defer the hotplug event until the device finishes resuming
-*/
- NV_DEBUG(drm, "Deferring HPD on %s until runtime resume\n",
-name);
- schedule_work(>hpd_work);
-
- pm_runtime_put_noidle(drm->dev->dev);
- return NVIF_NOTIFY_KEEP;
- } else if (ret != 1 && ret != -EACCES) {
- NV_WARN(drm, "HPD on %s dropped due to RPM failure: %d\n",
- name, ret);
- return NVIF_NOTIFY_DROP;
- }
-
- NV_DEBUG(drm, "%splugged %s\n", plugged ? "" : "un", name);
-
- drm_helper_hpd_irq_event(connector->dev);
+ NV_DEBUG(drm, "%splugged %s\n", plugged ? "" : "un", connector->name);
+ nouveau_connector_hpd(connector);
- pm_runtime_mark_last_busy(drm->dev->dev);
- pm_runtime_put_autosuspend(drm->dev->dev);
return NVIF_NOTIFY_KEEP;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index d6de5cb8e2238..d0b859c4a80ea 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -187,6 +187,7 @@ nouveau_crtc_connector_get(struct nouveau_crtc *nv_crtc)
struct drm_connector *
nouveau_connector_create(struct drm_device *, const struct dcb_output *);
+void nouveau_connector_hpd(struct drm_connector *connector);
extern int nouveau_tv_disable;
extern int nouveau_ignorelid;
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 13016769a194b..bceb48a2dfca6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -457,16 +457,70 @@ static struct nouveau_drm_prop_enum_list dither_depth[] =
{
} \
} while(0)
+void
+nouveau_display_hpd_resume(struct drm_device *dev)
+{
+ struct nouveau_drm *drm = nouveau_drm(dev);
+
+ mutex_lock(>hpd_lock);
+ drm->hpd_pending =
[Intel-gfx] [PATCH v5 13/20] drm/i915/dp: Extract drm_dp_read_downstream_info()
We're going to be doing the same probing process in nouveau for
determining downstream DP port capabilities, so let's deduplicate the
work by moving i915's code for handling this into a shared helper:
drm_dp_read_downstream_info().
Note that when we do this, we also do make some functional changes while
we're at it:
* We always clear the downstream port info before trying to read it,
just to make things easier for the caller
* We skip reading downstream port info if the DPCD indicates that we
don't support downstream port info
* We only read as many bytes as needed for the reported number of
downstream ports, no sense in reading the whole thing every time
v2:
* Fixup logic for calculating the downstream port length to account for
the fact that downstream port caps can be either 1 byte or 4 bytes
long. We can actually skip fixing the max_clock/max_bpc helpers here
since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway.
* Fix ret code check for drm_dp_dpcd_read
v5:
* Change name from drm_dp_downstream_read_info() to
drm_dp_read_downstream_info()
* Also, add "See Also" sections for the various downstream info
functions (drm_dp_read_downstream_info(), drm_dp_downstream_max_clock(),
drm_dp_downstream_max_bpc())
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
squash! drm/i915/dp: Extract drm_dp_read_downstream_info()
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 62 -
drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
include/drm/drm_dp_helper.h | 3 ++
3 files changed, 65 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4c21cf69dad5a..f3643894ad951 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -423,6 +423,56 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
}
EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
+static u8 drm_dp_downstream_port_count(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ u8 port_count = dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_PORT_COUNT_MASK;
+
+ if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE &&
port_count > 4)
+ port_count = 4;
+
+ return port_count;
+}
+
+/**
+ * drm_dp_read_downstream_info() - read DPCD downstream port info if available
+ * @aux: DisplayPort AUX channel
+ * @dpcd: A cached copy of the port's DPCD
+ * @downstream_ports: buffer to store the downstream port info in
+ *
+ * See also:
+ * drm_dp_downstream_max_clock()
+ * drm_dp_downstream_max_bpc()
+ *
+ * Returns: 0 if either the downstream port info was read successfully or
+ * there was no downstream info to read, or a negative error code otherwise.
+ */
+int drm_dp_read_downstream_info(struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS])
+{
+ int ret;
+ u8 len;
+
+ memset(downstream_ports, 0, DP_MAX_DOWNSTREAM_PORTS);
+
+ /* No downstream info to read */
+ if (!drm_dp_is_branch(dpcd) ||
+ dpcd[DP_DPCD_REV] < DP_DPCD_REV_10 ||
+ !(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
+ return 0;
+
+ len = drm_dp_downstream_port_count(dpcd);
+ if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE)
+ len *= 4;
+
+ ret = drm_dp_dpcd_read(aux, DP_DOWNSTREAM_PORT_0, downstream_ports,
len);
+ if (ret < 0)
+ return ret;
+
+ return ret == len ? 0 : -EIO;
+}
+EXPORT_SYMBOL(drm_dp_read_downstream_info);
+
/**
* drm_dp_downstream_max_clock() - extract branch device max
* pixel rate for legacy VGA
@@ -431,7 +481,11 @@ EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
* @dpcd: DisplayPort configuration data
* @port_cap: port capabilities
*
- * Returns max clock in kHz on success or 0 if max clock not defined
+ * See also:
+ * drm_dp_read_downstream_info()
+ * drm_dp_downstream_max_bpc()
+ *
+ * Returns: Max clock in kHz on success or 0 if max clock not defined
*/
int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4])
@@ -462,7 +516,11 @@ EXPORT_SYMBOL(drm_dp_downstream_max_clock);
* @dpcd: DisplayPort configuration data
* @port_cap: port capabilities
*
- * Returns max bpc on success or 0 if max bpc not defined
+ * See also:
+ * drm_dp_read_downstream_info()
+ * drm_dp_downstream_max_clock()
+ *
+ * Returns: Max bpc on success or 0 if max bpc not defined
*/
int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4])
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4c7314b7a84e4..9c4b806af8c79 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++
[Intel-gfx] [PATCH v5 07/20] drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in nv50_sor_disable()
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 255a281249bc8..612d98fa0a2dc 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1630,19 +1630,22 @@ nv50_sor_disable(struct drm_encoder *encoder,
{
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
+ struct nouveau_connector *nv_connector =
+ nv50_outp_get_old_connector(nv_encoder, state);
nv_encoder->crtc = NULL;
if (nv_crtc) {
- struct nvkm_i2c_aux *aux = nv_encoder->aux;
+ struct drm_dp_aux *aux = _connector->aux;
u8 pwr;
- if (aux) {
- int ret = nvkm_rdaux(aux, DP_SET_POWER, , 1);
+ if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
+ int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
+
if (ret == 0) {
pwr &= ~DP_SET_POWER_MASK;
pwr |= DP_SET_POWER_D3;
- nvkm_wraux(aux, DP_SET_POWER, , 1);
+ drm_dp_dpcd_writeb(aux, DP_SET_POWER, pwr);
}
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 11/20] drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect()
For whatever reason we currently unset the EDID for DP CEC support when responding to the connector being unplugged, instead of just doing it in nouveau_connector_detect() where we set the CEC EDID. This isn't really needed and could even potentially cause us to forget to unset the EDID if the connector is removed without a corresponding hpd event, so let's fix that. Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_connector.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index b90591114faaf..4a29f691c08e4 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -633,10 +633,11 @@ nouveau_connector_detect(struct drm_connector *connector, bool force) conn_status = connector_status_connected; goto out; } - } out: + if (!nv_connector->edid) + drm_dp_cec_unset_edid(_connector->aux); pm_runtime_mark_last_busy(dev->dev); pm_runtime_put_autosuspend(dev->dev); @@ -1174,8 +1175,6 @@ nouveau_connector_hotplug(struct nvif_notify *notify) return NVIF_NOTIFY_DROP; } - if (!plugged) - drm_dp_cec_unset_edid(_connector->aux); NV_DEBUG(drm, "%splugged %s\n", plugged ? "" : "un", name); drm_helper_hpd_irq_event(connector->dev); -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 04/20] drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c
No functional changes. Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 8db9216d52c69..4030806e3522b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -50,11 +50,13 @@ nouveau_dp_detect(struct nouveau_connector *nv_connector, if (ret != sizeof(dpcd)) return ret; - nv_encoder->dp.link_bw = 27000 * dpcd[1]; - nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK; + nv_encoder->dp.link_bw = 27000 * dpcd[DP_MAX_LINK_RATE]; + nv_encoder->dp.link_nr = + dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK; NV_DEBUG(drm, "display: %dx%d dpcd 0x%02x\n", -nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, dpcd[0]); +nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, +dpcd[DP_DPCD_REV]); NV_DEBUG(drm, "encoder: %dx%d\n", nv_encoder->dcb->dpconf.link_nr, nv_encoder->dcb->dpconf.link_bw); -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 19/20] drm/i915/dp: Extract drm_dp_read_dpcd_caps()
Since DP 1.3, it's been possible for DP receivers to specify an
additional set of DPCD capabilities, which can take precedence over the
capabilities reported at DP_DPCD_REV.
Basically any device supporting DP is going to need to read these in an
identical manner, in particular nouveau, so let's go ahead and just move
this code out of i915 into a shared DRM DP helper that we can use in
other drivers.
v2:
* Remove redundant dpcd[DP_DPCD_REV] == 0 check
* Fix drm_dp_dpcd_read() ret checks
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_dp_helper.c | 77 +
drivers/gpu/drm/i915/display/intel_dp.c | 60 +---
drivers/gpu/drm/i915/display/intel_dp.h | 1 -
drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +-
include/drm/drm_dp_helper.h | 3 +
5 files changed, 83 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 46d88ef4f59ac..9ca88e6c78820 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -433,6 +433,83 @@ static u8 drm_dp_downstream_port_count(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
return port_count;
}
+static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
+ u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ u8 dpcd_ext[6];
+ int ret;
+
+ /*
+* Prior to DP1.3 the bit represented by
+* DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
+* If it is set DP_DPCD_REV at h could be at a value less than
+* the true capability of the panel. The only way to check is to
+* then compare h and 2200h.
+*/
+ if (!(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT))
+ return 0;
+
+ ret = drm_dp_dpcd_read(aux, DP_DP13_DPCD_REV, _ext,
+ sizeof(dpcd_ext));
+ if (ret < 0)
+ return ret;
+ if (ret != sizeof(dpcd_ext))
+ return -EIO;
+
+ if (dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV]) {
+ DRM_DEBUG_KMS("%s: Extended DPCD rev less than base DPCD rev
(%d > %d)\n",
+ aux->name, dpcd[DP_DPCD_REV],
+ dpcd_ext[DP_DPCD_REV]);
+ return 0;
+ }
+
+ if (!memcmp(dpcd, dpcd_ext, sizeof(dpcd_ext)))
+ return 0;
+
+ DRM_DEBUG_KMS("%s: Base DPCD: %*ph\n",
+ aux->name, DP_RECEIVER_CAP_SIZE, dpcd);
+
+ memcpy(dpcd, dpcd_ext, sizeof(dpcd_ext));
+
+ return 0;
+}
+
+/**
+ * drm_dp_read_dpcd_caps() - read DPCD caps and extended DPCD caps if
+ * available
+ * @aux: DisplayPort AUX channel
+ * @dpcd: Buffer to store the resulting DPCD in
+ *
+ * Attempts to read the base DPCD caps for @aux. Additionally, this function
+ * checks for and reads the extended DPRX caps (%DP_DP13_DPCD_REV) if
+ * present.
+ *
+ * Returns: %0 if the DPCD was read successfully, negative error code
+ * otherwise.
+ */
+int drm_dp_read_dpcd_caps(struct drm_dp_aux *aux,
+ u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ int ret;
+
+ ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
+ if (ret < 0)
+ return ret;
+ if (ret != DP_RECEIVER_CAP_SIZE || dpcd[DP_DPCD_REV] == 0)
+ return -EIO;
+
+ ret = drm_dp_read_extended_dpcd_caps(aux, dpcd);
+ if (ret < 0)
+ return ret;
+
+ DRM_DEBUG_KMS("%s: DPCD: %*ph\n",
+ aux->name, DP_RECEIVER_CAP_SIZE, dpcd);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_dp_read_dpcd_caps);
+
/**
* drm_dp_read_downstream_info() - read DPCD downstream port info if available
* @aux: DisplayPort AUX channel
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0de94fc6289be..284b15f845926 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4449,62 +4449,6 @@ intel_dp_link_down(struct intel_encoder *encoder,
}
}
-static void
-intel_dp_extended_receiver_capabilities(struct intel_dp *intel_dp)
-{
- struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- u8 dpcd_ext[6];
-
- /*
-* Prior to DP1.3 the bit represented by
-* DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
-* if it is set DP_DPCD_REV at h could be at a value less than
-* the true capability of the panel. The only way to check is to
-* then compare h and 2200h.
-*/
- if (!(intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
- DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT))
- return;
-
- if (drm_dp_dpcd_read(_dp->aux, DP_DP13_DPCD_REV,
-_ext, sizeof(dpcd_ext)) != sizeof(dpcd_ext)) {
- drm_err(>drm,
-
[Intel-gfx] [PATCH v5 15/20] drm/i915/dp: Extract drm_dp_read_sink_count_cap()
Since other drivers are also going to need to be aware of the sink count
in order to do proper dongle detection, we might as well steal i915's
DP_SINK_COUNT helpers and move them into DRM helpers so that other
dirvers can use them as well.
Note that this also starts using intel_dp_has_sink_count() in
intel_dp_detect_dpcd(), which is a functional change.
v5:
* Change name from drm_dp_has_sink_count() to
drm_dp_read_sink_count_cap()
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_dp_helper.c | 22 ++
drivers/gpu/drm/i915/display/intel_dp.c | 21 -
include/drm/drm_dp_helper.h | 8 +++-
3 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f3643894ad951..65ff21ae0c271 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -726,6 +726,28 @@ void drm_dp_set_subconnector_property(struct drm_connector
*connector,
}
EXPORT_SYMBOL(drm_dp_set_subconnector_property);
+/**
+ * drm_dp_read_sink_count_cap() - Check whether a given connector has a valid
sink
+ * count
+ * @connector: The DRM connector to check
+ * @dpcd: A cached copy of the connector's DPCD RX capabilities
+ * @desc: A cached copy of the connector's DP descriptor
+ *
+ * Returns: %True if the (e)DP connector has a valid sink count that should
+ * be probed, %false otherwise.
+ */
+bool drm_dp_read_sink_count_cap(struct drm_connector *connector,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const struct drm_dp_desc *desc)
+{
+ /* Some eDP panels don't set a valid value for the sink count */
+ return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
+ dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
+ dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
+ !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+}
+EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
+
/*
* I2C-over-AUX implementation
*/
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 9c4b806af8c79..38318ae935f88 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4634,6 +4634,16 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
return true;
}
+static bool
+intel_dp_has_sink_count(struct intel_dp *intel_dp)
+{
+ if (!intel_dp->attached_connector)
+ return false;
+
+ return drm_dp_read_sink_count_cap(_dp->attached_connector->base,
+ intel_dp->dpcd,
+ _dp->desc);
+}
static bool
intel_dp_get_dpcd(struct intel_dp *intel_dp)
@@ -4653,13 +4663,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
intel_dp_set_common_rates(intel_dp);
}
- /*
-* Some eDP panels do not set a valid value for sink count, that is why
-* it don't care about read it here and in intel_edp_init_dpcd().
-*/
- if (!intel_dp_is_edp(intel_dp) &&
- !drm_dp_has_quirk(_dp->desc, 0,
- DP_DPCD_QUIRK_NO_SINK_COUNT)) {
+ if (intel_dp_has_sink_count(intel_dp)) {
u8 count;
ssize_t r;
@@ -5939,9 +5943,8 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
return connector_status_connected;
/* If we're HPD-aware, SINK_COUNT changes dynamically */
- if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
+ if (intel_dp_has_sink_count(intel_dp) &&
intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
-
return intel_dp->sink_count ?
connector_status_connected : connector_status_disconnected;
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index b8716b200666f..4c56ce4dc54fc 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1631,6 +1631,11 @@ void drm_dp_set_subconnector_property(struct
drm_connector *connector,
const u8 *dpcd,
const u8 port_cap[4]);
+struct drm_dp_desc;
+bool drm_dp_read_sink_count_cap(struct drm_connector *connector,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const struct drm_dp_desc *desc);
+
void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
void drm_dp_aux_init(struct drm_dp_aux *aux);
int drm_dp_aux_register(struct drm_dp_aux *aux);
@@ -1689,7 +1694,8 @@ enum drm_dp_quirk {
* @DP_DPCD_QUIRK_NO_SINK_COUNT:
*
* The device does not set SINK_COUNT to a non-zero value.
-* The driver should ignore SINK_COUNT during detection.
+* The driver should ignore SINK_COUNT during detection. Note that
+* drm_dp_read_sink_count_cap() automatically
[Intel-gfx] [PATCH v5 10/20] drm/nouveau/kms: Use new drm_dp_read_mst_cap() helper for checking MST caps
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 032afc73e2a33..a5934064a75ea 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -44,7 +44,6 @@ nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
struct nv50_mstm *mstm = NULL;
int ret;
u8 *dpcd = outp->dp.dpcd;
- u8 tmp;
ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
if (ret == DP_RECEIVER_CAP_SIZE && dpcd[DP_DPCD_REV]) {
@@ -56,19 +55,10 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
*nv_connector,
return connector_status_disconnected;
}
- if (nouveau_mst)
+ if (nouveau_mst) {
mstm = outp->dp.mstm;
-
- if (mstm) {
- if (dpcd[DP_DPCD_REV] >= DP_DPCD_REV_12) {
- ret = drm_dp_dpcd_readb(aux, DP_MSTM_CAP, );
- if (ret < 0)
- return connector_status_disconnected;
-
- mstm->can_mst = !!(tmp & DP_MST_CAP);
- } else {
- mstm->can_mst = false;
- }
+ if (mstm)
+ mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
}
return connector_status_connected;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 08/20] drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.
Back when I originally wrote this, I did this piggy-backing with the
intention that I'd eventually be teaching our MST helpers how to recover
when an MST device has stopped responding, which in turn would require
the MST helpers having a way of disabling MST independently of the
driver. Note that this was before I reworked locking in the MST helpers,
so at the time we were sticking random things under >lock - which
grabbing this lock was meant to protect against.
This never came to fruition because doing such a reset safely turned out
to be a lot more painful and impossible then it sounds, and also just
risks us working around issues with our MST handlers that should be
properly fixed instead. Even if it did though, simply calling
drm_dp_mst_topology_mgr_set_mst() from the MST helpers (with the
exception of when we're tearing down our MST managers, that's always OK)
wouldn't have been a bad idea, since drivers like nouveau and i915 need
to do their own book keeping immediately after disabling MST.
So-implementing that would likely require adding a hook for
helper-triggered MST disables anyway.
So, fast forward to now - we want to start adding support for all of the
miscellaneous bits of the DP protocol (for both SST and MST) we're
missing before moving on to supporting more complicated features like
supporting different BPP values on MST, DSC, etc. Since many of these
features only exist on SST and make use of DP HPD IRQs, we want to be
able to atomically check whether we're servicing an MST IRQ or SST IRQ
in nouveau_connector_hotplug(). Currently we literally don't do this at
all, and just handle any kind of possible DP IRQ we could get including
ESIs - even if MST isn't actually enabled.
This would be very complicated and difficult to fix if we need to hold
>lock while handling SST IRQs to ensure that the MST topology
state doesn't change under us. What we really want here is to do our own
tracking of whether MST is enabled or not, similar to drivers like i915,
and define our own locking order to decomplicate things and avoid
hitting locking issues in the future.
So, let's do this by refactoring our MST probing/enabling code to use
our own MST bookkeeping, along with adding a lock for protecting DP
state that needs to be checked outside of our connector probing
functions. While we're at it, we also remove a bunch of unneeded steps
we perform when probing/enabling MST:
* Enabling bits in MSTM_CTRL before calling drm_dp_mst_topology_mgr_set_mst().
I don't think these ever actually did anything, since the nvif methods
for enabling MST don't actually do anything DPCD related and merely
indicate to nvkm that we've turned on MST.
* Checking the MSTM_CTRL bit is intact when checking the state of an
enabled MST topology in nv50_mstm_detect(). I just added this to be safe
originally, but now that we try reading the DPCD when probing DP
connectors it shouldn't be needed as that will abort our hotplug probing
if the device was removed well before we start checking for MST..
* All of the duplicate DPCD version checks.
This leaves us with much nicer looking code, a much more sensible
locking scheme, and an easy way of checking whether MST is enabled or
not for handling DP HPD IRQs.
v2:
* Get rid of accidental newlines
v4:
* Fix uninitialized usage of mstm in nv50_mstm_detect() - thanks kernel
bot!
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 6 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 192 +---
drivers/gpu/drm/nouveau/nouveau_connector.c | 14 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_display.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_dp.c| 132 --
drivers/gpu/drm/nouveau/nouveau_encoder.h | 33 +++-
7 files changed, 244 insertions(+), 137 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 3f046b917c85c..3ee836dc5058f 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -54,8 +54,9 @@ nv04_encoder_get_connector(struct nouveau_encoder *encoder)
}
static void
-nv04_display_fini(struct drm_device *dev, bool suspend)
+nv04_display_fini(struct drm_device *dev, bool runtime, bool suspend)
{
+ struct nouveau_drm *drm = nouveau_drm(dev);
struct nv04_display *disp = nv04_display(dev);
struct drm_crtc *crtc;
@@ -67,6 +68,9 @@ nv04_display_fini(struct drm_device *dev, bool suspend)
if (nv_two_heads(dev))
NVWriteCRTC(dev, 1, NV_PCRTC_INTR_EN_0, 0);
+ if (!runtime)
+ cancel_work_sync(>hpd_work);
+
if
[Intel-gfx] [PATCH v5 09/20] drm/i915/dp: Extract drm_dp_read_mst_cap()
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.
v5:
* Drop !!()
* Move drm_dp_has_mst() out of header
* Change name from drm_dp_has_mst() to drm_dp_read_mst_cap()
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 22 ++
drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
include/drm/drm_dp_mst_helper.h | 3 +--
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 67dd72ea200e0..17dbed0a9800d 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3486,6 +3486,28 @@ static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8
dp_link_count)
return dp_link_bw * dp_link_count / 2;
}
+/**
+ * drm_dp_read_mst_cap() - check whether or not a sink supports MST
+ * @aux: The DP AUX channel to use
+ * @dpcd: A cached copy of the DPCD capabilities for this sink
+ *
+ * Returns: %True if the sink supports MST, %false otherwise
+ */
+bool drm_dp_read_mst_cap(struct drm_dp_aux *aux,
+const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ u8 mstm_cap;
+
+ if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
+ return false;
+
+ if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, _cap) != 1)
+ return false;
+
+ return mstm_cap & DP_MST_CAP;
+}
+EXPORT_SYMBOL(drm_dp_read_mst_cap);
+
/**
* drm_dp_mst_topology_mgr_set_mst() - Set the MST state for a topology manager
* @mgr: manager to set state for
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 79c27f91f42c0..4c7314b7a84e4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4699,20 +4699,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
return true;
}
-static bool
-intel_dp_sink_can_mst(struct intel_dp *intel_dp)
-{
- u8 mstm_cap;
-
- if (intel_dp->dpcd[DP_DPCD_REV] < 0x12)
- return false;
-
- if (drm_dp_dpcd_readb(_dp->aux, DP_MSTM_CAP, _cap) != 1)
- return false;
-
- return mstm_cap & DP_MST_CAP;
-}
-
static bool
intel_dp_can_mst(struct intel_dp *intel_dp)
{
@@ -4720,7 +4706,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
return i915->params.enable_dp_mst &&
intel_dp->can_mst &&
- intel_dp_sink_can_mst(intel_dp);
+ drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
}
static void
@@ -4729,7 +4715,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_encoder *encoder =
_to_dig_port(intel_dp)->base;
- bool sink_can_mst = intel_dp_sink_can_mst(intel_dp);
+ bool sink_can_mst = drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
drm_dbg_kms(>drm,
"[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
%s\n",
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 8b9eb4db3381c..6ae5860d8644e 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -728,10 +728,9 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr);
-
+bool drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE]);
int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool
mst_state);
-
int drm_dp_mst_hpd_irq(struct drm_dp_mst_topology_mgr *mgr, u8 *esi, bool
*handled);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 14/20] drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation
This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.
Note as well, we also start marking the connector as disconnected if we
can't read the DPCD, since we wouldn't be able to do anything without
DPCD access anyway.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 +++
drivers/gpu/drm/nouveau/nouveau_dp.c | 15 +++
drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 +
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 8e1effb10425d..d2141ca16107b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1258,7 +1258,10 @@ nv50_mstc_detect(struct drm_connector *connector,
ret = drm_dp_mst_detect_port(connector, ctx, mstc->port->mgr,
mstc->port);
+ if (ret != connector_status_connected)
+ goto out;
+out:
pm_runtime_mark_last_busy(connector->dev->dev);
pm_runtime_put_autosuspend(connector->dev->dev);
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 005750aeb6d4f..ad852e572cfec 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -61,6 +61,11 @@ nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
}
+ ret = drm_dp_read_downstream_info(aux, dpcd,
+ outp->dp.downstream_ports);
+ if (ret < 0)
+ return connector_status_disconnected;
+
return connector_status_connected;
}
@@ -176,8 +181,6 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
/* TODO:
* - Use the minimum possible BPC here, once we add support for the max bpc
* property.
- * - Validate the mode against downstream port caps (see
- * drm_dp_downstream_max_clock())
* - Validate against the DP caps advertised by the GPU (we don't check these
* yet)
*/
@@ -188,15 +191,19 @@ nv50_dp_mode_valid(struct drm_connector *connector,
unsigned *out_clock)
{
const unsigned min_clock = 25000;
- unsigned max_clock, clock;
+ unsigned max_clock, ds_clock, clock;
enum drm_mode_status ret;
if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
return MODE_NO_INTERLACE;
max_clock = outp->dp.link_nr * outp->dp.link_bw;
- clock = mode->clock * (connector->display_info.bpc * 3) / 10;
+ ds_clock = drm_dp_downstream_max_clock(outp->dp.dpcd,
+ outp->dp.downstream_ports);
+ if (ds_clock)
+ max_clock = min(max_clock, ds_clock);
+ clock = mode->clock * (connector->display_info.bpc * 3) / 10;
ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
);
if (out_clock)
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h
b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index eef4643f5f982..c1924a4529a7b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -72,6 +72,7 @@ struct nouveau_encoder {
struct mutex hpd_irq_lock;
u8 dpcd[DP_RECEIVER_CAP_SIZE];
+ u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
struct drm_dp_desc desc;
} dp;
};
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 02/20] drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc()
Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 3 ++-
drivers/gpu/drm/nouveau/nouveau_dp.c| 30 +++--
drivers/gpu/drm/nouveau/nouveau_encoder.h | 4 ++-
3 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 7674025a4bfe8..e12957e6faa7c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -435,7 +435,8 @@ nouveau_connector_ddc_detect(struct drm_connector
*connector)
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_DP:
- ret = nouveau_dp_detect(nv_encoder);
+ ret = nouveau_dp_detect(nouveau_connector(connector),
+ nv_encoder);
if (ret == NOUVEAU_DP_MST)
return NULL;
else if (ret == NOUVEAU_DP_SST)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index ee778ddc95fae..c4e9c21d4dd2b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -36,27 +36,9 @@ MODULE_PARM_DESC(mst, "Enable DisplayPort multi-stream
(default: enabled)");
static int nouveau_mst = 1;
module_param_named(mst, nouveau_mst, int, 0400);
-static void
-nouveau_dp_probe_oui(struct drm_device *dev, struct nvkm_i2c_aux *aux, u8
*dpcd)
-{
- struct nouveau_drm *drm = nouveau_drm(dev);
- u8 buf[3];
-
- if (!(dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
- return;
-
- if (!nvkm_rdaux(aux, DP_SINK_OUI, buf, 3))
- NV_DEBUG(drm, "Sink OUI: %02hx%02hx%02hx\n",
-buf[0], buf[1], buf[2]);
-
- if (!nvkm_rdaux(aux, DP_BRANCH_OUI, buf, 3))
- NV_DEBUG(drm, "Branch OUI: %02hx%02hx%02hx\n",
-buf[0], buf[1], buf[2]);
-
-}
-
int
-nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
+nouveau_dp_detect(struct nouveau_connector *nv_connector,
+ struct nouveau_encoder *nv_encoder)
{
struct drm_device *dev = nv_encoder->base.base.dev;
struct nouveau_drm *drm = nouveau_drm(dev);
@@ -89,7 +71,13 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
NV_DEBUG(drm, "maximum: %dx%d\n",
nv_encoder->dp.link_nr, nv_encoder->dp.link_bw);
- nouveau_dp_probe_oui(dev, aux, dpcd);
+ ret = drm_dp_read_desc(_connector->aux, _encoder->dp.desc,
+ drm_dp_is_branch(dpcd));
+ if (ret) {
+ NV_ERROR(drm, "Failed to read DP descriptor on %s: %d\n",
+nv_connector->base.name, ret);
+ return ret;
+ }
ret = nv50_mstm_detect(nv_encoder->dp.mstm, dpcd, nouveau_mst);
if (ret == 1)
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h
b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index a72c412ac8b14..6424cdcb4913f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -33,6 +33,7 @@
#include
#include "dispnv04/disp.h"
struct nv50_head_atom;
+struct nouveau_connector;
#define NV_DPMS_CLEARED 0x80
@@ -64,6 +65,7 @@ struct nouveau_encoder {
struct nv50_mstm *mstm;
int link_nr;
int link_bw;
+ struct drm_dp_desc desc;
} dp;
};
@@ -104,7 +106,7 @@ enum nouveau_dp_status {
NOUVEAU_DP_MST,
};
-int nouveau_dp_detect(struct nouveau_encoder *);
+int nouveau_dp_detect(struct nouveau_connector *, struct nouveau_encoder *);
enum drm_mode_status nv50_dp_mode_valid(struct drm_connector *,
struct nouveau_encoder *,
const struct drm_display_mode *,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 03/20] drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c
Since this actually logs accesses, we should probably always be using
this imho…
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index c4e9c21d4dd2b..8db9216d52c69 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -42,16 +42,12 @@ nouveau_dp_detect(struct nouveau_connector *nv_connector,
{
struct drm_device *dev = nv_encoder->base.base.dev;
struct nouveau_drm *drm = nouveau_drm(dev);
- struct nvkm_i2c_aux *aux;
- u8 dpcd[8];
+ struct drm_dp_aux *aux = _connector->aux;
+ u8 dpcd[DP_RECEIVER_CAP_SIZE];
int ret;
- aux = nv_encoder->aux;
- if (!aux)
- return -ENODEV;
-
- ret = nvkm_rdaux(aux, DP_DPCD_REV, dpcd, sizeof(dpcd));
- if (ret)
+ ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
+ if (ret != sizeof(dpcd))
return ret;
nv_encoder->dp.link_bw = 27000 * dpcd[1];
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 00/20] drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915
Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code is just really unoptimized in general: * We handle connector probing in the same context that we handle short IRQs in for DP, which means connector probing could potentially block ESI handling for MST * When we receive a hotplug event from a connector, we reprobe every single connector instead of just the connector that was hotplugged * Additionally because of the above reason, combined with the fact I had the bad idea of reusing some of the MST locks when I last rewrote nouveau's DP MST detection, trying to handle any other events that require short HPD IRQs is a bit awkward to actually implement. * We don't actually properly check whether EDIDs change or not when reprobing, which means we basically send out a hotplug event every single time we receive one even if nothing has changed Additionally, the code for handling DP that we have in nouveau is also quite unoptimized in general, doesn't use a lot of helpers that have been added since it was written, and is also missing quite a number of features: * Downstream port capability probing * Extended DPRX cap parsing * SINK_COUNT handling for hpd on dongles Luckily for us - all of these are implemented in i915 already. Since there's no reason for us to reinvent the wheel, and having more shared code is always nice, I decided to take the opportunity to extract the code for all of these features from i915 into a set of core DP helpers, which both i915 and nouveau (and hopefully other drivers in the future) can use. As well, this patch series also addesses the other general connector probing related issues I mentioned above, along with rewriting how we handle MST probing so we don't hit any surprise locking design issues in the future. As a note - most of this work is motivated by the fact that I'm planning on adding max_bpc/output_bpc prop support, DSC support (for both MST and SST, along with proper helpers for handling bandwidth limitations and DSC), and fallback link retraining. I figured I might as clean this code up and implement missing DP features like the ones mentioned here before moving on to those tasks. Lyude Paul (20): drm/nouveau/kms: Fix some indenting in nouveau_dp_detect() drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc() drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new() drm/nouveau/kms: Search for encoders' connectors properly drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in nv50_sor_disable() drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling drm/i915/dp: Extract drm_dp_read_mst_cap() drm/nouveau/kms: Use new drm_dp_read_mst_cap() helper for checking MST caps drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect() drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths drm/i915/dp: Extract drm_dp_read_downstream_info() drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation drm/i915/dp: Extract drm_dp_read_sink_count_cap() drm/i915/dp: Extract drm_dp_read_sink_count() drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT drm/nouveau/kms: Don't change EDID when it hasn't actually changed drm/i915/dp: Extract drm_dp_read_dpcd_caps() drm/nouveau/kms: Start using drm_dp_read_dpcd_caps() drivers/gpu/drm/drm_dp_helper.c | 187 +++- drivers/gpu/drm/drm_dp_mst_topology.c | 22 ++ drivers/gpu/drm/i915/display/intel_dp.c | 124 ++-- drivers/gpu/drm/i915/display/intel_dp.h | 1 - drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/dac.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/dfp.c | 7 +- drivers/gpu/drm/nouveau/dispnv04/disp.c | 24 +- drivers/gpu/drm/nouveau/dispnv04/disp.h | 4 + drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 305 +++- drivers/gpu/drm/nouveau/nouveau_connector.c | 132 - drivers/gpu/drm/nouveau/nouveau_connector.h | 1 + drivers/gpu/drm/nouveau/nouveau_display.c | 72 - drivers/gpu/drm/nouveau/nouveau_display.h | 3 +- drivers/gpu/drm/nouveau/nouveau_dp.c| 210 +++--- drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +- drivers/gpu/drm/nouveau/nouveau_drv.h | 2 + drivers/gpu/drm/nouveau/nouveau_encoder.h | 48 ++- include/drm/drm_dp_helper.h | 15 +-
[Intel-gfx] [PATCH v5 06/20] drm/nouveau/kms: Search for encoders' connectors properly
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with nv04_encoder_get_connector(), nv50_outp_get_old_connector(), and
nv50_outp_get_new_connector().
v2:
* Don't line-wrap for_each_(old|new)_connector_in_state in
nv50_outp_get_(old|new)_connector() - sravn
v3:
* Fix potential uninitialized usage of nv_connector (needs to be
initialized to NULL at the start). Thanks kernel test robot!
v4:
* Actually fix uninitialized nv_connector usage in
nv50_audio_component_get_eld(). The previous fix wouldn't have worked
since we would have started out with nv_connector == NULL, but
wouldn't clear it after a single drm_for_each_encoder() iteration.
Thanks again Kernel bot!
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv04/dac.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/dfp.c | 7 +-
drivers/gpu/drm/nouveau/dispnv04/disp.c | 18 +
drivers/gpu/drm/nouveau/dispnv04/disp.h | 4 +
drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 88 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 14
drivers/gpu/drm/nouveau/nouveau_encoder.h | 6 +-
9 files changed, 105 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dac.c
b/drivers/gpu/drm/nouveau/dispnv04/dac.c
index ffdd447d87068..22d10f3285597 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dac.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dac.c
@@ -419,7 +419,7 @@ static void nv04_dac_commit(struct drm_encoder *encoder)
helper->dpms(encoder, DRM_MODE_DPMS_ON);
NV_DEBUG(drm, "Output %s is running on CRTC %d using output %c\n",
-nouveau_encoder_connector_get(nv_encoder)->base.name,
+nv04_encoder_get_connector(nv_encoder)->base.name,
nv_crtc->index, '@' + ffs(nv_encoder->dcb->or));
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index f9f4482c79b54..42687ea2a4ca3 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -184,7 +184,8 @@ static bool nv04_dfp_mode_fixup(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
{
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
- struct nouveau_connector *nv_connector =
nouveau_encoder_connector_get(nv_encoder);
+ struct nouveau_connector *nv_connector =
+ nv04_encoder_get_connector(nv_encoder);
if (!nv_connector->native_mode ||
nv_connector->scaling_mode == DRM_MODE_SCALE_NONE ||
@@ -478,7 +479,7 @@ static void nv04_dfp_commit(struct drm_encoder *encoder)
helper->dpms(encoder, DRM_MODE_DPMS_ON);
NV_DEBUG(drm, "Output %s is running on CRTC %d using output %c\n",
-nouveau_encoder_connector_get(nv_encoder)->base.name,
+nv04_encoder_get_connector(nv_encoder)->base.name,
nv_crtc->index, '@' + ffs(nv_encoder->dcb->or));
}
@@ -591,7 +592,7 @@ static void nv04_dfp_restore(struct drm_encoder *encoder)
if (nv_encoder->dcb->type == DCB_OUTPUT_LVDS) {
struct nouveau_connector *connector =
- nouveau_encoder_connector_get(nv_encoder);
+ nv04_encoder_get_connector(nv_encoder);
if (connector && connector->native_mode)
call_lvds_script(dev, nv_encoder->dcb, head,
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 900ab69df7e8f..3f046b917c85c 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -35,6 +35,24 @@
#include
+struct nouveau_connector *
+nv04_encoder_get_connector(struct nouveau_encoder *encoder)
+{
+ struct drm_device *dev = to_drm_encoder(encoder)->dev;
+ struct drm_connector *connector;
+ struct drm_connector_list_iter conn_iter;
+ struct nouveau_connector *nv_connector = NULL;
+
+ drm_connector_list_iter_begin(dev, _iter);
+ drm_for_each_connector_iter(connector, _iter) {
+ if (connector->encoder == to_drm_encoder(encoder))
+ nv_connector = nouveau_connector(connector);
+ }
+ drm_connector_list_iter_end(_iter);
+
+ return nv_connector;
+}
+
static void
nv04_display_fini(struct drm_device *dev, bool suspend)
{
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.h
b/drivers/gpu/drm/nouveau/dispnv04/disp.h
index 495d3284e8766..5ace5e906949a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.h
@@ -6,6 +6,8 @@
[Intel-gfx] [PATCH v5 01/20] drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()
Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_dp.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 8a0f7994e1aeb..ee778ddc95fae 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -76,10 +76,10 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder) nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK; NV_DEBUG(drm, "display: %dx%d dpcd 0x%02x\n", -nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, dpcd[0]); +nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, dpcd[0]); NV_DEBUG(drm, "encoder: %dx%d\n", -nv_encoder->dcb->dpconf.link_nr, -nv_encoder->dcb->dpconf.link_bw); +nv_encoder->dcb->dpconf.link_nr, +nv_encoder->dcb->dpconf.link_bw); if (nv_encoder->dcb->dpconf.link_nr < nv_encoder->dp.link_nr) nv_encoder->dp.link_nr = nv_encoder->dcb->dpconf.link_nr; @@ -87,7 +87,7 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder) nv_encoder->dp.link_bw = nv_encoder->dcb->dpconf.link_bw; NV_DEBUG(drm, "maximum: %dx%d\n", -nv_encoder->dp.link_nr, nv_encoder->dp.link_bw); +nv_encoder->dp.link_nr, nv_encoder->dp.link_bw); nouveau_dp_probe_oui(dev, aux, dpcd); -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 05/20] drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new()
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
enabling") we've been clearing DP_MST_CTRL before we start enabling MST.
Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary
and redundant, so let's remove it.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index e7874877da858..c4d138f0ca054 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1535,17 +1535,6 @@ nv50_mstm_new(struct nouveau_encoder *outp, struct
drm_dp_aux *aux, int aux_max,
struct drm_device *dev = outp->base.base.dev;
struct nv50_mstm *mstm;
int ret;
- u8 dpcd;
-
- /* This is a workaround for some monitors not functioning
-* correctly in MST mode on initial module load. I think
-* some bad interaction with the VBIOS may be responsible.
-*
-* A good ol' off and on again seems to work here ;)
-*/
- ret = drm_dp_dpcd_readb(aux, DP_DPCD_REV, );
- if (ret >= 0 && dpcd >= 0x12)
- drm_dp_dpcd_writeb(aux, DP_MSTM_CTRL, 0);
if (!(mstm = *pmstm = kzalloc(sizeof(*mstm), GFP_KERNEL)))
return -ENOMEM;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Implement WA_1406941453 (rev4)
On Wed, 2020-08-26 at 05:44 +, Patchwork wrote: > Patch Details > Series: drm/i915/gt: Implement WA_1406941453 (rev4) > URL: https://patchwork.freedesktop.org/series/78243/ > State:failure > Details: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18404/index.html > CI Bug Log - changes from CI_DRM_8925_full -> Patchwork_18404_full > Summary > FAILURE > > Serious unknown changes coming with Patchwork_18404_full absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_18404_full, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > Possible new issues > Here are the unknown changes that may have been introduced in > Patchwork_18404_full: > > IGT changes > Possible regressions > igt@kms_vblank@pipe-c-ts-continuation-modeset-hang: > > shard-hsw: PASS -> INCOMPLETE > igt@sysfs_preempt_timeout@timeout@rcs0: > This regressions are not related to the changes so pushed to dinq, thanks for the patch Clint. > shard-skl: PASS -> FAIL > Known issues > Here are the changes found in Patchwork_18404_full that come from known > issues: > > IGT changes > Issues hit > igt@gem_exec_reloc@basic-concurrent0: > > shard-kbl: PASS -> TIMEOUT (i915#1958) +3 similar issues > igt@gem_exec_reloc@basic-concurrent16: > > shard-apl: PASS -> TIMEOUT (i915#1635 / i915#1958) > igt@gem_exec_whisper@basic-contexts-priority: > > shard-iclb: PASS -> TIMEOUT (i915#1958) +1 similar issue > igt@gem_exec_whisper@basic-fds-priority: > > shard-glk: PASS -> TIMEOUT (i915#1958) +3 similar issues > igt@gem_exec_whisper@basic-normal: > > shard-tglb: PASS -> TIMEOUT (i915#1958) > igt@gem_exec_whisper@basic-queues-forked: > > shard-skl: PASS -> TIMEOUT (i915#1958) > igt@gem_sync@basic-store-all: > > shard-apl: PASS -> FAIL (i915#1635 / i915#2356) > > shard-glk: PASS -> FAIL (i915#2356) > > shard-skl: PASS -> FAIL (i915#2356) > > igt@i915_selftest@mock@contexts: > > shard-skl: PASS -> INCOMPLETE (i915#198 / i915#2278) > igt@kms_big_fb@x-tiled-64bpp-rotate-0: > > shard-apl: PASS -> DMESG-WARN (i915#1635 / i915#1982) > igt@kms_cursor_edge_walk@pipe-c-64x64-left-edge: > > shard-glk: PASS -> DMESG-WARN (i915#1982) +1 similar issue > igt@kms_draw_crc@draw-method-xrgb-blt-untiled: > > shard-snb: PASS -> SKIP (fdo#109271) > igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a2: > > shard-glk: PASS -> FAIL (i915#79) > igt@kms_flip@flip-vs-expired-vblank@b-edp1: > > shard-skl: PASS -> FAIL (i915#79) > igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: > > shard-kbl: PASS -> DMESG-WARN (i915#180) +12 similar issues > igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-wc: > > shard-tglb: PASS -> DMESG-WARN (i915#1982) +2 similar issues > igt@kms_hdr@bpc-switch: > > shard-skl: PASS -> FAIL (i915#1188) > igt@kms_psr@no_drrs: > > shard-iclb: PASS -> FAIL (i915#173) > igt@kms_psr@psr2_cursor_plane_move: > > shard-iclb: PASS -> SKIP (fdo#109441) +1 similar issue > igt@kms_psr@suspend: > > shard-skl: PASS -> INCOMPLETE (i915#198) > igt@perf@polling-parameterized: > > shard-tglb: PASS -> FAIL (i915#1542) > igt@perf@polling-small-buf: > > shard-skl: PASS -> DMESG-WARN (i915#1982) +15 similar issues > igt@sysfs_timeslice_duration@timeout@vecs0: > > shard-tglb: PASS -> FAIL (i915#1755) > Possible fixes > igt@gem_exec_reloc@basic-concurrent0: > > shard-apl: TIMEOUT (i915#1635 / i915#1958) -> PASS +3 similar issues > igt@gem_exec_suspend@basic-s3: > > shard-kbl: DMESG-WARN (i915#180) -> PASS +4 similar issues > igt@gem_exec_whisper@basic-contexts-all: > > shard-glk: TIMEOUT (i915#1958) -> PASS +2 similar issues > igt@gem_exec_whisper@basic-fds-priority: > > shard-kbl: TIMEOUT (i915#1958) -> PASS +1 similar issue > igt@gem_exec_whisper@basic-queues: > > shard-tglb: TIMEOUT (i915#1958) -> PASS > igt@i915_module_load@reload: > > shard-tglb: DMESG-WARN (i915#1982) -> PASS +1 similar issue > igt@i915_selftest@mock@contexts: > > shard-apl: INCOMPLETE (i915#1635 / i915#2278) -> PASS > igt@kms_flip@2x-blocking-wf_vblank@ab-vga1-hdmi-a1: > > shard-hsw: DMESG-WARN (i915#1982) -> PASS > igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@a-dp1: > > shard-kbl: DMESG-WARN (i915#1982) -> PASS +1 similar issue > igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1: > > shard-skl: FAIL (i915#79) -> PASS > igt@kms_flip@flip-vs-suspend@a-edp1: > > shard-skl: INCOMPLETE (i915#198) -> PASS > igt@kms_flip@plain-flip-fb-recreate@b-edp1: > > shard-skl: FAIL (i915#2122) -> PASS > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-pgflip-blt: > > shard-iclb: DMESG-WARN (i915#1982) -> PASS > igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-render: > > shard-iclb: TIMEOUT (i915#123 / i915#1958) -> PASS > igt@kms_frontbuffer_tracking@psr-rgb565-draw-mmap-wc: > > shard-skl: DMESG-WARN (i915#1982) -> PASS +4 similar issues >
Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline
On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote: > > Somehow related to lightdm or xfce4? However, it is a regression, since > kernel 5.8 works. Yeah, apparently there's something else wrong with the relocation changes too. That said, does that patch at https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/ change things at all? If there are two independent bugs, maybe applying that patch might at least give you an oops that gets saved in the logs? (it might be worth waiting a bit after the machine locks up in case the machine is alive enough so sync logs after a bit.. If ssh works, that's obviously better yet) Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] i915: add -DDYNAMIC_DEBUG_MODULE to i915/gvt/Makefile
This addition to cflags enables dyndbg in the gvt component of the
i915 module, on a CONFIG_DYNAMIC_DEBUG_CORE build.
So here are the message classifications that the gvt driver uses.
cut -d= -f2 | cut -d\ -f2,3 | \
perl -ne 'chomp $_ && $h{$_}++; END{print "$_\" \tseen $h{$_}\n" for sort
keys %h}'
"gvt: cmd:" seen 11
"gvt: core:"seen 48
"gvt: dpy:" seen 4
"gvt: el:" seen 21
"gvt: irq:" seen 1
"gvt: mm:" seen 6
"gvt: mmio:"seen 9
"gvt: render:" seen 1
"gvt: sched:" seen 15
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/i915/gvt/Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index ea8324abc784..2c581e910688 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -5,5 +5,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o
trace_points.o firmware.o \
execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o
debugfs.o \
fb_decoder.o dmabuf.o page_track.o
-ccflags-y += -I $(srctree)/$(src) -I
$(srctree)/$(src)/$(GVT_DIR)/
-i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
+ccflags-y += -I $(srctree)/$(src) -I $(srctree)/$(src)/$(GVT_DIR)/
+ccflags-y += -DDYNAMIC_DEBUG_MODULE
+i915-y += $(addprefix $(GVT_DIR)/, $(GVT_SOURCE))
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] i915: POC use dynamic_debug_exec_queries to control pr_debugs in gvt
The gvt component of this driver has ~120 pr_debugs, in 9 "classes".
Add a "knob", like drm.debug, to map bits to these classes.
bash-5.0# echo 0x01 > /sys/module/i915/parameters/debug_dyn
set_dyndbg: result:0x1 from 0x01
dyndbg: query 0: "format='^gvt: cmd: ' +p"
dyndbg: entry, buf:'format='^gvt: cmd: ' +p'
dyndbg: start-of-word:0 'format='^gvt: cmd: ' +p'
dyndbg: start-of-word:1 ''^gvt: cmd: ' +p'
dyndbg: start-of-word:2 '+p'
dyndbg: split into words: "format" "^gvt: cmd: " "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: key:'format' arg:'^gvt: cmd: '
dyndbg: parsed: func="" file="" module="i915" format="^gvt: cmd: " lineno=0-0
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:3081
[i915]init_cmd_table =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:1376
[i915]gen8_check_mi_display_flip =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:1373
[i915]gen8_check_mi_display_flip =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:745
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:744
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:742
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:733
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:729
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:722
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:716
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:691 [i915]print_opcode =p
dyndbg: applied: func="" file="" module="i915" format="^gvt: cmd: " lineno=0-0
dyndbg: processed 1 queries, with 11 matches, 0 errs
change ct:11 on format='gvt: cmd: '
change ct:11
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/i915/i915_params.c | 76 ++
1 file changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 8d8db9ff0a48..4e1f01ab4865 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -255,3 +255,79 @@ void i915_params_free(struct i915_params *params)
I915_PARAMS_FOR_EACH(FREE);
#undef FREE
}
+
+/* POC for callback -> dynamic_debug_exec_queries */
+unsigned long __new_knob;
+EXPORT_SYMBOL(__new_knob);
+
+static char *pr_debug_classes[] = {
+ "gvt: cmd: ",
+ "gvt: core: ",
+ "gvt: dpy: ",
+ "gvt: el: ",
+ "gvt: irq: ",
+ "gvt: mm: ",
+ "gvt: mmio: ",
+ "gvt: render: ",
+ "gvt: sched: "
+};
+#define NUM_CLASSESARRAY_SIZE(pr_debug_classes)
+#define OUR_QUERY_SIZE 128 /* we need about 20 */
+
+#include
+
+static int param_set_dyndbg(const char *instr, const struct kernel_param *kp)
+{
+ static unsigned long int old_val;
+unsigned int val;
+ unsigned long int changes, result;
+ int rc, chgct = 0, totct = 0, bitpos;
+ char query[OUR_QUERY_SIZE];
+
+ rc = kstrtouint(instr, 0, );
+ if (rc) {
+ pr_err("set_dyndbg: failed\n");
+ return -EINVAL;
+ }
+ result = val;
+ pr_info("set_dyndbg: result:0x%lx from %s\n", result, instr);
+
+ changes = result ^ old_val;
+
+ for_each_set_bit(bitpos, , NUM_CLASSES) {
+
+ sprintf(query, "format='^%s' %cp", pr_debug_classes[bitpos],
+ test_bit(bitpos, ) ? '+' : '-');
+
+ chgct = dynamic_debug_exec_queries(query, "i915");
+ totct += chgct;
+ pr_info("change ct:%d on format='%s'\n", chgct,
+ pr_debug_classes[bitpos]);
+ }
+ old_val = result;
+ pr_info("change ct:%d\n", totct);
+ return 0;
+}
+static int param_get_dyndbg(char *buffer, const struct kernel_param *kp)
+{
+ return scnprintf(buffer, PAGE_SIZE, "%u\n",
+*((unsigned int *)kp->arg));
+}
+static const struct kernel_param_ops param_ops_dyndbg = {
+ .set = param_set_dyndbg,
+ .get = param_get_dyndbg,
+};
+
+MODULE_PARM_DESC(debug_dyn, " enable dynamic-debug by format-string
classifications.\n"
+"\t\twhich are:"
+"\n\t\t gvt: cmd:"
+"\n\t\t gvt: core:"
+"\n\t\t gvt: dpy:"
+"\n\t\t gvt: el:"
+"\n\t\t gvt: irq:"
+"\n\t\t gvt: mm:"
+"\n\t\t gvt: mmio:"
+"\n\t\t gvt: render:"
+"\n\t\t gvt: sched:" "\n");
+
+module_param_cb(debug_dyn, _ops_dyndbg, &__new_knob, 0644);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/39] drm/i915/gt: Clear the buffer pool age before use
On Wed, 26 Aug 2020 at 14:28, Chris Wilson wrote:
>
> If we create a new node, it is possible for the slab allocator to return
> us a recently freed node. If that node was just retired, it will retain
> the current jiffy as its node->age. There is then a miniscule window,
> where as that node is retired, it will appear on the free list with an
> incorrect age and be eligible for reuse by one thread, and then by a
> second thread as the correct node->age is written.
>
> Fixes: 8080ffd81600 ("drm/i915/gt: Delay taking the spinlock for grabbing
> from the buffer pool")
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 16/20] drm/i915/dp: Extract drm_dp_get_sink_count()
On Wed, 2020-08-26 at 10:05 +0300, Jani Nikula wrote:
> On Tue, 25 Aug 2020, Lyude Paul wrote:
> > And of course, we'll also need to read the sink count from other drivers
> > as well if we're checking whether or not it's supported. So, let's
> > extract the code for this into another helper.
> >
> > v2:
> > * Fix drm_dp_dpcd_readb() ret check
> > * Add back comment and move back sink_count assignment in
> > intel_dp_get_dpcd()
> >
> > Signed-off-by: Lyude Paul
> > Reviewed-by: Sean Paul
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 22 ++
> > drivers/gpu/drm/i915/display/intel_dp.c | 11 +--
> > include/drm/drm_dp_helper.h | 1 +
> > 3 files changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 863e0babc1903..67ad05eb05b7e 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -736,6 +736,28 @@ bool drm_dp_has_sink_count(struct drm_connector
> > *connector,
> > }
> > EXPORT_SYMBOL(drm_dp_has_sink_count);
> >
> > +/**
> > + * drm_dp_get_sink_count() - Retrieve the sink count for a given sink
>
> From the department of bikeshedding...
>
> Should we have a naming scheme where it's obvious whether a function
> will do DPCD access, or just shuffle existing data?
>
> For example, drm_dp_read_foo() for anything with DPCD access
> vs. drm_dp_get_foo() or even simpler for anything that only processes
> pre-read data?
Forgot to address this comment - yeah, I think that would be a good idea. I'll
go through my previous patches and make sure that they match this naming scheme
as well.
>
> > + * @aux: The DP AUX channel to use
> > + *
> > + * Returns: The current sink count reported by @aux, or a negative error
> > code
> > + * otherwise.
> > + */
> > +int drm_dp_get_sink_count(struct drm_dp_aux *aux)
> > +{
> > + u8 count;
> > + int ret;
> > +
> > + ret = drm_dp_dpcd_readb(aux, DP_SINK_COUNT, );
> > + if (ret < 0)
> > + return ret;
> > + if (ret != 1)
> > + return -EIO;
>
> Makes me wonder if that shouldn't be at drm_dp_dpcd_read() level, for
> reads returning 0..len-1 bytes. Not necessarily part of this series, but
> seems silly to set a precedent to start handling that return value all
> over the place.
>
> BR,
> Jani.
>
> > +
> > + return DP_GET_SINK_COUNT(count);
> > +}
> > +EXPORT_SYMBOL(drm_dp_get_sink_count);
> > +
> > /*
> > * I2C-over-AUX implementation
> > */
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 35a4779a442e2..4337321a3be4f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4648,6 +4648,8 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
> > static bool
> > intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > {
> > + int ret;
> > +
> > if (!intel_dp_read_dpcd(intel_dp))
> > return false;
> >
> > @@ -4664,11 +4666,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > }
> >
> > if (intel_dp_has_sink_count(intel_dp)) {
> > - u8 count;
> > - ssize_t r;
> > -
> > - r = drm_dp_dpcd_readb(_dp->aux, DP_SINK_COUNT, );
> > - if (r < 1)
> > + ret = drm_dp_get_sink_count(_dp->aux);
> > + if (ret < 0)
> > return false;
> >
> > /*
> > @@ -4676,7 +4675,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > * a member variable in intel_dp will track any changes
> > * between short pulse interrupts.
> > */
> > - intel_dp->sink_count = DP_GET_SINK_COUNT(count);
> > + intel_dp->sink_count = ret;
> >
> > /*
> > * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index a1413a531eaf4..0c141fc81aaa8 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1635,6 +1635,7 @@ struct drm_dp_desc;
> > bool drm_dp_has_sink_count(struct drm_connector *connector,
> >const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> >const struct drm_dp_desc *desc);
> > +int drm_dp_get_sink_count(struct drm_dp_aux *aux);
> >
> > void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
> > void drm_dp_aux_init(struct drm_dp_aux *aux);
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 16/20] drm/i915/dp: Extract drm_dp_get_sink_count()
On Wed, 2020-08-26 at 10:05 +0300, Jani Nikula wrote:
> On Tue, 25 Aug 2020, Lyude Paul wrote:
> > And of course, we'll also need to read the sink count from other drivers
> > as well if we're checking whether or not it's supported. So, let's
> > extract the code for this into another helper.
> >
> > v2:
> > * Fix drm_dp_dpcd_readb() ret check
> > * Add back comment and move back sink_count assignment in
> > intel_dp_get_dpcd()
> >
> > Signed-off-by: Lyude Paul
> > Reviewed-by: Sean Paul
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 22 ++
> > drivers/gpu/drm/i915/display/intel_dp.c | 11 +--
> > include/drm/drm_dp_helper.h | 1 +
> > 3 files changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 863e0babc1903..67ad05eb05b7e 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -736,6 +736,28 @@ bool drm_dp_has_sink_count(struct drm_connector
> > *connector,
> > }
> > EXPORT_SYMBOL(drm_dp_has_sink_count);
> >
> > +/**
> > + * drm_dp_get_sink_count() - Retrieve the sink count for a given sink
>
> From the department of bikeshedding...
>
> Should we have a naming scheme where it's obvious whether a function
> will do DPCD access, or just shuffle existing data?
>
> For example, drm_dp_read_foo() for anything with DPCD access
> vs. drm_dp_get_foo() or even simpler for anything that only processes
> pre-read data?
>
> > + * @aux: The DP AUX channel to use
> > + *
> > + * Returns: The current sink count reported by @aux, or a negative error
> > code
> > + * otherwise.
> > + */
> > +int drm_dp_get_sink_count(struct drm_dp_aux *aux)
> > +{
> > + u8 count;
> > + int ret;
> > +
> > + ret = drm_dp_dpcd_readb(aux, DP_SINK_COUNT, );
> > + if (ret < 0)
> > + return ret;
> > + if (ret != 1)
> > + return -EIO;
>
> Makes me wonder if that shouldn't be at drm_dp_dpcd_read() level, for
> reads returning 0..len-1 bytes. Not necessarily part of this series, but
> seems silly to set a precedent to start handling that return value all
> over the place.
>
Yeah definitely - I'm probably going to keep this code here for now, but I would
like to convert drm_dp_dpcd_readb/writeb() to just return 0 on success (all
bytes written, I've never once seen a situation where we got less bytes than we
read - it's always all or nothing) and negative error code on failure. I'll get
to that soon
> BR,
> Jani.
>
> > +
> > + return DP_GET_SINK_COUNT(count);
> > +}
> > +EXPORT_SYMBOL(drm_dp_get_sink_count);
> > +
> > /*
> > * I2C-over-AUX implementation
> > */
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 35a4779a442e2..4337321a3be4f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4648,6 +4648,8 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
> > static bool
> > intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > {
> > + int ret;
> > +
> > if (!intel_dp_read_dpcd(intel_dp))
> > return false;
> >
> > @@ -4664,11 +4666,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > }
> >
> > if (intel_dp_has_sink_count(intel_dp)) {
> > - u8 count;
> > - ssize_t r;
> > -
> > - r = drm_dp_dpcd_readb(_dp->aux, DP_SINK_COUNT, );
> > - if (r < 1)
> > + ret = drm_dp_get_sink_count(_dp->aux);
> > + if (ret < 0)
> > return false;
> >
> > /*
> > @@ -4676,7 +4675,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > * a member variable in intel_dp will track any changes
> > * between short pulse interrupts.
> > */
> > - intel_dp->sink_count = DP_GET_SINK_COUNT(count);
> > + intel_dp->sink_count = ret;
> >
> > /*
> > * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index a1413a531eaf4..0c141fc81aaa8 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1635,6 +1635,7 @@ struct drm_dp_desc;
> > bool drm_dp_has_sink_count(struct drm_connector *connector,
> >const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> >const struct drm_dp_desc *desc);
> > +int drm_dp_get_sink_count(struct drm_dp_aux *aux);
> >
> > void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
> > void drm_dp_aux_init(struct drm_dp_aux *aux);
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/39] drm/i915/gem: Use set_pte_at() for assigning the vmapped PTE
Quoting Matthew Auld (2020-08-26 17:36:52)
> On Wed, 26 Aug 2020 at 14:28, Chris Wilson wrote:
> >
> > Use set_pte_at() to assign the PTE pointer returned by alloc_vm_area(),
> > rather than a direct assignment.
>
> and crucially add the missing sync stuff for the mapping?
Fortunately not for x86.
> > Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object maps")
> > Signed-off-by: Chris Wilson
> > Cc: Matthew Auld
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_pages.c | 33 +++
> > 1 file changed, 28 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > index 51b63e05dbe4..0c3d0d6429ae 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > @@ -241,6 +241,17 @@ static inline pte_t iomap_pte(resource_size_t base,
> > return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> > }
> >
> > +static void sync_vm_area(struct vm_struct *area)
> > +{
> > + unsigned long start = (unsigned long)area->addr;
> > + unsigned long end = start + area->size;
> > +
> > + if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PTE_MODIFIED)
> > + arch_sync_kernel_mappings(start, end); /* expected DCE */
>
> What is DCE again?
"Dead code eliminated." arch_sync_kernel_mappings() is not exported, so
if a platform were to require us to call it, we have a problem.
I figured it would be better get a complaint and know the problem
exists, having had the set_pmd() issue bite once.
I expect if the problem does arise, the alloc_vm_area() interface will
be changed to remove set_pte_at() from drivers. Just my guess. It could
just be as simple as removing that pte[] and requiring us to use
apply_to_page_range directly.
> > +
> > + flush_cache_vmap(start, end);
> > +}
> > +
> > /* The 'mapping' part of i915_gem_object_pin_map() below */
> > static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> > enum i915_map_type type)
> > @@ -308,24 +319,36 @@ static void *i915_gem_object_map(struct
> > drm_i915_gem_object *obj,
> > }
> >
> > if (i915_gem_object_has_struct_page(obj)) {
> > + unsigned long addr = (unsigned long)area->addr;
> > struct sgt_iter iter;
> > struct page *page;
> > pte_t **ptes = mem;
> >
> > - for_each_sgt_page(page, iter, sgt)
> > - **ptes++ = mk_pte(page, pgprot);
> > + for_each_sgt_page(page, iter, sgt) {
> > + set_pte_at(_mm, addr, *ptes, mk_pte(page,
> > pgprot));
>
> init_mm needs to be exported?
Odd, because I recall that's why we didn't use it previously... But it
compiles with i915.ko as a module. Hmm, that probably means set_pte_at()
expands to a macro that doesn't use init_mm on x86. Again, that will
cause a problem no doubt somewhere else, where it should be a problem
for whatever reason the mm_struct is required for writing the PTE.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/display: Compute has_drrs after compute has_psr
On Wed, 2020-08-26 at 12:56 +0530, Anshuman Gupta wrote:
> On 2020-08-25 at 10:13:29 -0700, José Roberto de Souza wrote:
> > DRRS and PSR can't be enable together, so giving preference to PSR
> > as it allows more power-savings by complete shutting down display,
> > so to guarantee this, it should compute DRRS state after compute PSR.
> >
> > Cc: Srinivas K <
> > srinivas...@intel.com
> > >
> > Cc: Hariom Pandey <
> > hariom.pan...@intel.com
> > >
> > Reviewed-by: Anshuman Gupta <
> > anshuman.gu...@intel.com
> > >
> > Signed-off-by: José Roberto de Souza <
> > jose.so...@intel.com
> > >
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 52 +++--
> > 1 file changed, 32 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 79c27f91f42c..a08d03c61b02 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -2575,6 +2575,34 @@ intel_dp_compute_hdr_metadata_infoframe_sdp(struct
> > intel_dp *intel_dp,
> > intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA);
> > }
> >
> > +static void
> > +intel_dp_drrs_compute_config(struct intel_dp *intel_dp,
> > +struct intel_crtc_state *pipe_config,
> > +int output_bpp, bool constant_n)
> > +{
> > + struct intel_connector *intel_connector = intel_dp->attached_connector;
> > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > + /*
> > +* DRRS and PSR can't be enable together, so giving preference to PSR
> > +* as it allows more power-savings by complete shutting down display,
> > +* so to guarantee this, intel_dp_drrs_compute_config() must be called
> > +* after intel_psr_compute_config().
> > +*/
> > + if (pipe_config->has_psr)
> > + return;
> > +
> > + if (!intel_connector->panel.downclock_mode ||
> > + dev_priv->drrs.type != SEAMLESS_DRRS_SUPPORT)
> > + return;
> > +
> > + pipe_config->has_drrs = true;
> > + intel_link_compute_m_n(output_bpp, pipe_config->lane_count,
> > + intel_connector->panel.downclock_mode->clock,
> > + pipe_config->port_clock, _config->dp_m2_n2,
> > + constant_n, pipe_config->fec_enable);
> > +}
> > +
> > int
> > intel_dp_compute_config(struct intel_encoder *encoder,
> > struct intel_crtc_state *pipe_config,
> > @@ -2605,7 +2633,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> > if (ret)
> > return ret;
> >
> > - pipe_config->has_drrs = false;
>
> IMHO this assignment is required, i was thinking a case, when a crtc is
> attached to more than
> one connector, suppose first eDP connector supports DRRS from
> panel.downclock_mode and
> drrs.type but another DP connector won't support it in that case has_drrs
> will be still
> true.
> Please correct me if i am wrong here.
i915 only supports one connector per pipe/CRTC, if that was the case all other
flags in intel_crtc_state would also have the same behaviour as
has_drrs.
> Thanks,
> Anshuman Gupta.
> > if (!intel_dp_port_has_audio(dev_priv, port))
> > pipe_config->has_audio = false;
> > else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
> > @@ -2657,21 +2684,12 @@ intel_dp_compute_config(struct intel_encoder
> > *encoder,
> >_config->dp_m_n,
> >constant_n, pipe_config->fec_enable);
> >
> > - if (intel_connector->panel.downclock_mode != NULL &&
> > - dev_priv->drrs.type == SEAMLESS_DRRS_SUPPORT) {
> > - pipe_config->has_drrs = true;
> > - intel_link_compute_m_n(output_bpp,
> > - pipe_config->lane_count,
> > -
> > intel_connector->panel.downclock_mode->clock,
> > - pipe_config->port_clock,
> > - _config->dp_m2_n2,
> > - constant_n,
> > pipe_config->fec_enable);
> > - }
> > -
> > if (!HAS_DDI(dev_priv))
> > intel_dp_set_clock(encoder, pipe_config);
> >
> > intel_psr_compute_config(intel_dp, pipe_config);
> > + intel_dp_drrs_compute_config(intel_dp, pipe_config, output_bpp,
> > +constant_n);
> > intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
> > intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, pipe_config,
> > conn_state);
> >
> > @@ -7730,16 +7748,10 @@ void intel_edp_drrs_enable(struct intel_dp
> > *intel_dp,
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> >
> > - if (!crtc_state->has_drrs) {
> > - drm_dbg_kms(_priv->drm, "Panel doesn't support DRRS\n");
> > + if
Re: [Intel-gfx] [PATCH 02/39] drm/i915/gem: Use set_pte_at() for assigning the vmapped PTE
On Wed, 26 Aug 2020 at 14:28, Chris Wilson wrote:
>
> Use set_pte_at() to assign the PTE pointer returned by alloc_vm_area(),
> rather than a direct assignment.
and crucially add the missing sync stuff for the mapping?
>
> Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object maps")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 33 +++
> 1 file changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 51b63e05dbe4..0c3d0d6429ae 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -241,6 +241,17 @@ static inline pte_t iomap_pte(resource_size_t base,
> return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> }
>
> +static void sync_vm_area(struct vm_struct *area)
> +{
> + unsigned long start = (unsigned long)area->addr;
> + unsigned long end = start + area->size;
> +
> + if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PTE_MODIFIED)
> + arch_sync_kernel_mappings(start, end); /* expected DCE */
What is DCE again?
> +
> + flush_cache_vmap(start, end);
> +}
> +
> /* The 'mapping' part of i915_gem_object_pin_map() below */
> static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> enum i915_map_type type)
> @@ -308,24 +319,36 @@ static void *i915_gem_object_map(struct
> drm_i915_gem_object *obj,
> }
>
> if (i915_gem_object_has_struct_page(obj)) {
> + unsigned long addr = (unsigned long)area->addr;
> struct sgt_iter iter;
> struct page *page;
> pte_t **ptes = mem;
>
> - for_each_sgt_page(page, iter, sgt)
> - **ptes++ = mk_pte(page, pgprot);
> + for_each_sgt_page(page, iter, sgt) {
> + set_pte_at(_mm, addr, *ptes, mk_pte(page,
> pgprot));
init_mm needs to be exported?
> + addr += PAGE_SIZE;
> + ptes++;
> + }
> + GEM_BUG_ON(addr != (unsigned long)area->addr +
> obj->base.size);
> } else {
> + unsigned long addr = (unsigned long)area->addr;
> resource_size_t iomap;
> struct sgt_iter iter;
> pte_t **ptes = mem;
> - dma_addr_t addr;
> + dma_addr_t offset;
>
> iomap = obj->mm.region->iomap.base;
> iomap -= obj->mm.region->region.start;
>
> - for_each_sgt_daddr(addr, iter, sgt)
> - **ptes++ = iomap_pte(iomap, addr, pgprot);
> + for_each_sgt_daddr(offset, iter, sgt) {
> + set_pte_at(_mm, addr, *ptes,
> + iomap_pte(iomap, offset, pgprot));
> + addr += PAGE_SIZE;
> + ptes++;
> + }
> + GEM_BUG_ON(addr != (unsigned long)area->addr +
> obj->base.size);
> }
> + sync_vm_area(area);
>
> if (mem != stack)
> kvfree(mem);
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] mm: Use find_get_swap_page in memcontrol
On Wed, Aug 26, 2020 at 03:54:14PM +0100, Matthew Wilcox wrote:
> On Wed, Aug 26, 2020 at 10:20:02AM -0400, Johannes Weiner wrote:
> > On Wed, Aug 19, 2020 at 07:48:44PM +0100, Matthew Wilcox (Oracle) wrote:
> > > + return find_get_swap_page(vma->vm_file->f_mapping,
> > > + linear_page_index(vma, addr));
> >
> > The refactor makes sense to me, but the name is confusing. We're not
> > looking for a swap page, we're primarily looking for a file page in
> > the page cache mapping that's handed in. Only in the special case
> > where it's a shmem mapping and there is a swap entry do we consult the
> > auxiliary swap cache.
> >
> > How about find_get_page_or_swapcache()? find_get_page_shmemswap()?
> > Maybe you have a better idea. It's a fairly specialized operation that
> > isn't widely used, so a longer name isn't a bad thing IMO.
>
> Yeah, I had trouble with the naming here too.
>
> get_page_even_from_swap()
> find_get_shmem_page()
>
> or maybe refactor the whole thing:
>
> struct page *page = find_get_entry(mapping, index);
> page = find_swap_page(mapping, page);
>
> struct page *find_swap_page(struct address_space *mapping, struct page *page)
> {
> swp_entry_t swp;
> struct swap_info_struct *si;
>
> if (!xa_is_value(page))
> return page;
> if (!shmem_mapping(mapping))
> return NULL;
>
> ...
> }
Yeah, I like the idea of two lookups if we can't find a good name for
the operation that combines them. I'd just bubble the control flow
that links them up to the callsite - that still seems plenty compact
for two callsites, and keeps all the shmem magic in shmem code:
page = find_get_entry(mapping, index);
if (xa_is_value(page))
if (shmem_mapping(mapping))
page = lookup_shmem_swap_cache(page);
else
page = NULL;
So close to making radix_to_swp_entry() & co. private to shmem.c, too
- if it weren't for force_shm_swapin_readahead(). Ah well.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
> LSPCON only supports 8 bpc for RGB/YCbCr444.
>
> Set the correct bpp otherwise it renders blank screen.
Hmm. Does
git://github.com/vsyrjala/linux.git dp_downstream_ports_5
work?
Actually better make that dp_downstream_ports_5^^^ aka.
54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
converters") to avoid the experiments and hacks I have sitting on top.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index b781bf469644..c7a44fcaade8 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector
> *connector,
> crtc_state->port_clock /= 2;
> crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
> crtc_state->lspcon_downsampling = true;
> - }
> + } else
> + crtc_state->pipe_bpp = 24;
> }
>
> static bool lspcon_probe(struct intel_lspcon *lspcon)
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] mm: Convert find_get_entry to return the head page
On Wed, Aug 26, 2020 at 11:09:25AM -0400, Johannes Weiner wrote:
> On Wed, Aug 19, 2020 at 07:48:48PM +0100, Matthew Wilcox (Oracle) wrote:
> > There are only three callers remaining of find_get_entry().
> > find_get_swap_page() is happy to get the head page instead of the subpage.
> > Add find_subpage() calls to find_lock_entry() and pagecache_get_page()
> > to avoid auditing all their callers.
>
> I believe this would cause a subtle bug in memcg charge moving for pte
> mapped huge pages. We currently skip over tail pages in the range
> (they don't have page->mem_cgroup set) and account for the huge page
> once from the headpage. After this change, we would see the headpage
> and account for it 512 times (or whatever the number is on non-x86).
Hmm ... so if you have the last 511 pages of a huge page mapped, you
actually don't charge for it at all today?
I think you're right that I'd introduce this bug, and so that needs to
be fixed.
> But that aside, I don't quite understand the intent.
>
> Before, all these functions simply return the base page at @index,
> whether it's a regular page or a tail page.
>
> Afterwards, find_lock_entry(), find_get_page() et al still do, but
> find_get_entry() returns headpage at @index & HPAGE_CACHE_INDEX_MASK.
>
> Shouldn't we be consistent about how we handle huge pages when
> somebody queries the tree for a given base page index?
>
> [ Wouldn't that mean that e.g. find_get_swap_page() would return tail
> pages for regular files and head pages for shmem files? ]
What I'd _like_ to do is convert all the callers to cope with tail
pages never being returned from all the find_* functions. That seems
like a lot of disruption.
My intent in this series is to get all the find_*_entr{y,ies}
functions to the point where they don't return tail pages.
Also find_get_pages_tag() because tags are only set on head pages.
This is generally what the callers want anyway. There's even a hack
in find_get_entries() in current to terminate early on finding a THP
(see commit 71725ed10c40696dc6bdccf8e225815dcef24dba). If I want
to remove that, I need to do _something_ to not put all the subpages
of a THP into the pagevec.
So the new rule will be that find_*_entry() don't return tail pages but
find_*_page() do. With the full THP patchset in place, THPs become quite
common, so bugs in this area will surface quickly instead of lingering
for years and only popping out in rare circumstances.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] block: convert tasklets to use new tasklet_setup() API
On Wed, Aug 26, 2020 at 12:55:28PM +0300, Dan Carpenter wrote: > On Wed, Aug 26, 2020 at 07:21:35AM +0530, Allen Pais wrote: > > On Thu, Aug 20, 2020 at 3:09 AM James Bottomley > > wrote: > > > > > > On Wed, 2020-08-19 at 21:54 +0530, Allen wrote: > > > > > [...] > > > > > > > Since both threads seem to have petered out, let me suggest in > > > > > > > kernel.h: > > > > > > > > > > > > > > #define cast_out(ptr, container, member) \ > > > > > > > container_of(ptr, typeof(*container), member) > > > > > > > > > > > > > > It does what you want, the argument order is the same as > > > > > > > container_of with the only difference being you name the > > > > > > > containing structure instead of having to specify its type. > > > > > > > > > > > > Not to incessantly bike shed on the naming, but I don't like > > > > > > cast_out, it's not very descriptive. And it has connotations of > > > > > > getting rid of something, which isn't really true. > > > > > > > > > > Um, I thought it was exactly descriptive: you're casting to the > > > > > outer container. I thought about following the C++ dynamic casting > > > > > style, so out_cast(), but that seemed a bit pejorative. What about > > > > > outer_cast()? > > > > > > > > > > > FWIW, I like the from_ part of the original naming, as it has > > > > > > some clues as to what is being done here. Why not just > > > > > > from_container()? That should immediately tell people what it > > > > > > does without having to look up the implementation, even before > > > > > > this becomes a part of the accepted coding norm. > > > > > > > > > > I'm not opposed to container_from() but it seems a little less > > > > > descriptive than outer_cast() but I don't really care. I always > > > > > have to look up container_of() when I'm using it so this would just > > > > > be another macro of that type ... > > > > > > > > > > > > > So far we have a few which have been suggested as replacement > > > > for from_tasklet() > > > > > > > > - out_cast() or outer_cast() > > > > - from_member(). > > > > - container_from() or from_container() > > > > > > > > from_container() sounds fine, would trimming it a bit work? like > > > > from_cont(). > > > > > > I'm fine with container_from(). It's the same form as container_of() > > > and I think we need urgent agreement to not stall everything else so > > > the most innocuous name is likely to get the widest acceptance. > > > > Kees, > > > > Will you be sending the newly proposed API to Linus? I have V2 > > which uses container_from() > > ready to be sent out. > > I liked that James swapped the first two arguments so that it matches > container_of(). Plus it's nice that when you have: > > struct whatever *foo = container_from(ptr, foo, member); > > Then it means that "ptr == >member". I'm a bit stalled right now -- the merge window was keeping me busy, and this week is the Linux Plumbers Conference. This is on my list, but I haven't gotten back around to it. If you want, feel free to send the container_from() patch; you might be able to unblock this faster than me right now. :) -Kees -- Kees Cook ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] mm: Convert find_get_entry to return the head page
On Wed, Aug 19, 2020 at 07:48:48PM +0100, Matthew Wilcox (Oracle) wrote: > There are only three callers remaining of find_get_entry(). > find_get_swap_page() is happy to get the head page instead of the subpage. > Add find_subpage() calls to find_lock_entry() and pagecache_get_page() > to avoid auditing all their callers. I believe this would cause a subtle bug in memcg charge moving for pte mapped huge pages. We currently skip over tail pages in the range (they don't have page->mem_cgroup set) and account for the huge page once from the headpage. After this change, we would see the headpage and account for it 512 times (or whatever the number is on non-x86). But that aside, I don't quite understand the intent. Before, all these functions simply return the base page at @index, whether it's a regular page or a tail page. Afterwards, find_lock_entry(), find_get_page() et al still do, but find_get_entry() returns headpage at @index & HPAGE_CACHE_INDEX_MASK. Shouldn't we be consistent about how we handle huge pages when somebody queries the tree for a given base page index? [ Wouldn't that mean that e.g. find_get_swap_page() would return tail pages for regular files and head pages for shmem files? ] ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] mm: Use find_get_swap_page in memcontrol
On Wed, Aug 26, 2020 at 10:20:02AM -0400, Johannes Weiner wrote:
> On Wed, Aug 19, 2020 at 07:48:44PM +0100, Matthew Wilcox (Oracle) wrote:
> > + return find_get_swap_page(vma->vm_file->f_mapping,
> > + linear_page_index(vma, addr));
>
> The refactor makes sense to me, but the name is confusing. We're not
> looking for a swap page, we're primarily looking for a file page in
> the page cache mapping that's handed in. Only in the special case
> where it's a shmem mapping and there is a swap entry do we consult the
> auxiliary swap cache.
>
> How about find_get_page_or_swapcache()? find_get_page_shmemswap()?
> Maybe you have a better idea. It's a fairly specialized operation that
> isn't widely used, so a longer name isn't a bad thing IMO.
Yeah, I had trouble with the naming here too.
get_page_even_from_swap()
find_get_shmem_page()
or maybe refactor the whole thing:
struct page *page = find_get_entry(mapping, index);
page = find_swap_page(mapping, page);
struct page *find_swap_page(struct address_space *mapping, struct page *page)
{
swp_entry_t swp;
struct swap_info_struct *si;
if (!xa_is_value(page))
return page;
if (!shmem_mapping(mapping))
return NULL;
...
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/xen-front: Add support for EDID based configuration
== Series Details ==
Series: drm/xen-front: Add support for EDID based configuration
URL : https://patchwork.freedesktop.org/series/81068/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8928 -> Patchwork_18409
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/index.html
Known issues
Here are the changes found in Patchwork_18409 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-cml-s: [PASS][1] -> [INCOMPLETE][2] ([i915#2035])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-cml-s/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/fi-cml-s/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-bsw-kefka/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/fi-bsw-kefka/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
Possible fixes
* igt@gem_exec_parallel@engines@basic:
- fi-bxt-dsi: [INCOMPLETE][5] ([i915#1635]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-bxt-dsi/igt@gem_exec_parallel@engi...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/fi-bxt-dsi/igt@gem_exec_parallel@engi...@basic.html
* igt@gem_exec_parallel@engines@fds:
- fi-cml-s: [INCOMPLETE][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-cml-s/igt@gem_exec_parallel@engi...@fds.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/fi-cml-s/igt@gem_exec_parallel@engi...@fds.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][13] ([i915#2203]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
Warnings
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18409/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2035]: https://gitlab.freedesktop.org/drm/intel/issues/2035
[i915#2100]: https://gitlab.freedesktop.org/drm/intel/issues/2100
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2249]: https://gitlab.freedesktop.org/drm/intel/issues/2249
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (37 -> 34)
--
Missing(3): fi-byt-clapper
Re: [Intel-gfx] [PATCH 5/8] i915: Use find_lock_page instead of find_lock_entry
On Wed, Aug 19, 2020 at 07:48:47PM +0100, Matthew Wilcox (Oracle) wrote: > i915 does not want to see value entries. Switch it to use > find_lock_page() instead, and remove the export of find_lock_entry(). > > Signed-off-by: Matthew Wilcox (Oracle) Acked-by: Johannes Weiner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] proc: Optimise smaps for shmem entries
On Wed, Aug 19, 2020 at 07:48:46PM +0100, Matthew Wilcox (Oracle) wrote: > Avoid bumping the refcount on pages when we're only interested in the > swap entries. > > Signed-off-by: Matthew Wilcox (Oracle) Acked-by: Johannes Weiner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] mm: Optimise madvise WILLNEED
On Wed, Aug 19, 2020 at 07:48:45PM +0100, Matthew Wilcox (Oracle) wrote: > Instead of calling find_get_entry() for every page index, use an XArray > iterator to skip over NULL entries, and avoid calling get_page(), > because we only want the swap entries. > > Signed-off-by: Matthew Wilcox (Oracle) Acked-by: Johannes Weiner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/39] drm/i915/gem: Avoid implicit vmap for highmem on x86-32
On Wed, 26 Aug 2020 at 14:29, Chris Wilson wrote:
>
> On 32b, highmem uses a finite set of indirect PTE (i.e. vmap) to provide
> virtual mappings of the high pages. As these are finite, map_new_virtual()
> must wait for some other kmap() to finish when it runs out. If we map a
> large number of objects, there is no method for it to tell us to release
> the mappings, and we deadlock.
>
> However, if we make an explicit vmap of the page, that uses a larger
> vmalloc arena, and also has the ability to tell us to release unwanted
> mappings. Most importantly, it will fail and propagate an error instead
> of waiting forever.
>
> Fixes: fb8621d3bee8 ("drm/i915: Avoid allocating a vmap arena for a single
> page") #x86-32
> References: e87666b52f00 ("drm/i915/shrinker: Hook up vmap allocation failure
> notifier")
> Signed-off-by: Chris Wilson
> Cc: Harald Arnesen
> Cc: # v4.7+
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] mm: Use find_get_swap_page in memcontrol
On Wed, Aug 19, 2020 at 07:48:44PM +0100, Matthew Wilcox (Oracle) wrote:
> The current code does not protect against swapoff of the underlying
> swap device, so this is a bug fix as well as a worthwhile reduction in
> code complexity.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> ---
> mm/memcontrol.c | 25 ++---
> 1 file changed, 2 insertions(+), 23 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index b807952b4d43..4075f214a841 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5539,35 +5539,14 @@ static struct page *mc_handle_swap_pte(struct
> vm_area_struct *vma,
> static struct page *mc_handle_file_pte(struct vm_area_struct *vma,
> unsigned long addr, pte_t ptent, swp_entry_t *entry)
> {
> - struct page *page = NULL;
> - struct address_space *mapping;
> - pgoff_t pgoff;
> -
> if (!vma->vm_file) /* anonymous vma */
> return NULL;
> if (!(mc.flags & MOVE_FILE))
> return NULL;
>
> - mapping = vma->vm_file->f_mapping;
> - pgoff = linear_page_index(vma, addr);
> -
> /* page is moved even if it's not RSS of this task(page-faulted). */
> -#ifdef CONFIG_SWAP
> - /* shmem/tmpfs may report page out on swap: account for that too. */
> - if (shmem_mapping(mapping)) {
> - page = find_get_entry(mapping, pgoff);
> - if (xa_is_value(page)) {
> - swp_entry_t swp = radix_to_swp_entry(page);
> - *entry = swp;
> - page = find_get_page(swap_address_space(swp),
> - swp_offset(swp));
> - }
> - } else
> - page = find_get_page(mapping, pgoff);
> -#else
> - page = find_get_page(mapping, pgoff);
> -#endif
> - return page;
> + return find_get_swap_page(vma->vm_file->f_mapping,
> + linear_page_index(vma, addr));
The refactor makes sense to me, but the name is confusing. We're not
looking for a swap page, we're primarily looking for a file page in
the page cache mapping that's handed in. Only in the special case
where it's a shmem mapping and there is a swap entry do we consult the
auxiliary swap cache.
How about find_get_page_or_swapcache()? find_get_page_shmemswap()?
Maybe you have a better idea. It's a fairly specialized operation that
isn't widely used, so a longer name isn't a bad thing IMO.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/39] drm/i915/gem: Avoid implicit vmap for highmem on x86-32
== Series Details == Series: series starting with [01/39] drm/i915/gem: Avoid implicit vmap for highmem on x86-32 URL : https://patchwork.freedesktop.org/series/81064/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8928 -> Patchwork_18408 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18408 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18408, please notify your bug team 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_18408/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18408: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s0: - fi-byt-j1900: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-byt-j1900/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18408/fi-byt-j1900/igt@gem_exec_susp...@basic-s0.html Known issues Here are the changes found in Patchwork_18408 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-tgl-u2: [PASS][3] -> [TIMEOUT][4] ([i915#1418]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-tgl-u2/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18408/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-tgl-u2: [PASS][5] -> [SKIP][6] ([i915#579]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-tgl-u2/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18408/fi-tgl-u2/igt@i915_pm_...@module-reload.html - fi-bsw-n3050: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-bsw-n3050/igt@i915_pm_...@module-reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18408/fi-bsw-n3050/igt@i915_pm_...@module-reload.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18408/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Possible fixes * igt@gem_exec_parallel@engines@basic: - fi-bxt-dsi: [INCOMPLETE][11] ([i915#1635]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-bxt-dsi/igt@gem_exec_parallel@engi...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18408/fi-bxt-dsi/igt@gem_exec_parallel@engi...@basic.html * igt@gem_exec_parallel@engines@fds: - fi-cml-s: [INCOMPLETE][13] -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-cml-s/igt@gem_exec_parallel@engi...@fds.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18408/fi-cml-s/igt@gem_exec_parallel@engi...@fds.html * igt@i915_selftest@live@execlists: - fi-icl-y: [INCOMPLETE][15] ([i915#2271] / [i915#2276]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-icl-y/igt@i915_selftest@l...@execlists.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18408/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gem_contexts: - fi-tgl-u2: [INCOMPLETE][17] ([i915#2045]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18408/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-n3050: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18408/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8928/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18408/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [DMESG-FAIL][23]
[Intel-gfx] [PATCH] drm/xen-front: Add support for EDID based configuration
From: Oleksandr Andrushchenko
Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID
request which allows frontends to request EDID structure per
connector. This request is optional and if not supported by the
backend then visible area is still defined by the relevant
XenStore's "resolution" property.
If backend provides EDID with XENDISPL_OP_GET_EDID request then
its values must take precedence over the resolutions defined in
XenStore.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 62
drivers/gpu/drm/xen/xen_drm_front.h | 9 ++-
drivers/gpu/drm/xen/xen_drm_front_cfg.c | 82 +
drivers/gpu/drm/xen/xen_drm_front_cfg.h | 7 ++
drivers/gpu/drm/xen/xen_drm_front_conn.c| 26 ++-
drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 4 +
drivers/gpu/drm/xen/xen_drm_front_evtchnl.h | 3 +
drivers/gpu/drm/xen/xen_drm_front_kms.c | 5 ++
8 files changed, 195 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 013c9e0e412c..cc5981bdbfb3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -381,6 +381,59 @@ void xen_drm_front_on_frame_done(struct xen_drm_front_info
*front_info,
fb_cookie);
}
+int xen_drm_front_get_edid(struct xen_drm_front_info *front_info,
+ int conn_idx, struct page **pages,
+ u32 buffer_sz, u32 *edid_sz)
+{
+ struct xen_drm_front_evtchnl *evtchnl;
+ struct xen_front_pgdir_shbuf_cfg buf_cfg;
+ struct xen_front_pgdir_shbuf shbuf;
+ struct xendispl_req *req;
+ unsigned long flags;
+ int ret;
+
+ if (unlikely(conn_idx >= front_info->num_evt_pairs))
+ return -EINVAL;
+
+ memset(_cfg, 0, sizeof(buf_cfg));
+ buf_cfg.xb_dev = front_info->xb_dev;
+ buf_cfg.num_pages = DIV_ROUND_UP(buffer_sz, PAGE_SIZE);
+ buf_cfg.pages = pages;
+ buf_cfg.pgdir =
+ buf_cfg.be_alloc = false;
+
+ ret = xen_front_pgdir_shbuf_alloc(_cfg);
+ if (ret < 0)
+ return ret;
+
+ evtchnl = _info->evt_pairs[conn_idx].req;
+
+ mutex_lock(>u.req.req_io_lock);
+
+ spin_lock_irqsave(_info->io_lock, flags);
+ req = be_prepare_req(evtchnl, XENDISPL_OP_GET_EDID);
+ req->op.get_edid.gref_directory =
+ xen_front_pgdir_shbuf_get_dir_start();
+ req->op.get_edid.buffer_sz = buffer_sz;
+
+ ret = be_stream_do_io(evtchnl, req);
+ spin_unlock_irqrestore(_info->io_lock, flags);
+
+ if (ret < 0)
+ goto fail;
+
+ ret = be_stream_wait_io(evtchnl);
+ if (ret < 0)
+ goto fail;
+
+ *edid_sz = evtchnl->u.req.resp.get_edid.edid_sz;
+
+fail:
+ mutex_unlock(>u.req.req_io_lock);
+ xen_front_pgdir_shbuf_free();
+ return ret;
+}
+
static int xen_drm_drv_dumb_create(struct drm_file *filp,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
@@ -466,6 +519,7 @@ static void xen_drm_drv_release(struct drm_device *dev)
xenbus_switch_state(front_info->xb_dev,
XenbusStateInitialising);
+ xen_drm_front_cfg_free(front_info, _info->cfg);
kfree(drm_info);
}
@@ -562,6 +616,7 @@ static int xen_drm_drv_init(struct xen_drm_front_info
*front_info)
drm_mode_config_cleanup(drm_dev);
drm_dev_put(drm_dev);
fail:
+ xen_drm_front_cfg_free(front_info, _info->cfg);
kfree(drm_info);
return ret;
}
@@ -622,7 +677,14 @@ static int displback_initwait(struct xen_drm_front_info
*front_info)
static int displback_connect(struct xen_drm_front_info *front_info)
{
+ int ret;
+
xen_drm_front_evtchnl_set_state(front_info, EVTCHNL_STATE_CONNECTED);
+
+ /* We are all set to read additional configuration from the backend. */
+ ret = xen_drm_front_cfg_tail(front_info, _info->cfg);
+ if (ret < 0)
+ return ret;
return xen_drm_drv_init(front_info);
}
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
b/drivers/gpu/drm/xen/xen_drm_front.h
index 54486d89650e..be0c982f4d82 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -112,9 +112,12 @@ struct xen_drm_front_drm_pipeline {
struct drm_simple_display_pipe pipe;
struct drm_connector conn;
- /* These are only for connector mode checking */
+ /* These are only for connector mode checking if no EDID present */
int width, height;
+ /* Is not NULL if EDID is used for connector configuration. */
+ struct edid *edid;
+
struct drm_pending_vblank_event *pending_event;
struct delayed_work pflip_to_worker;
@@ -160,4 +163,8 @@ int
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/39] drm/i915/gem: Avoid implicit vmap for highmem on x86-32
== Series Details == Series: series starting with [01/39] drm/i915/gem: Avoid implicit vmap for highmem on x86-32 URL : https://patchwork.freedesktop.org/series/81064/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1328:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1441:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1495:15: warning: memset with byte count of 16777216 +./include/linux/seqlock.h:752:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:778:16: warning: trying to copy expression type 31 +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 01/17] drm/i915: Fix sha_text population code
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.8.2, v5.7.16, v5.4.59, v4.19.140.
v5.8.2: Build OK!
v5.7.16: Build OK!
v5.4.59: Failed to apply! Possible dependencies:
65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging
macros.")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
692059318c0f ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
v4.19.140: Failed to apply! Possible dependencies:
09d7e46b97c6 ("drm/i915: Pull VM lists under the VM mutex.")
16e4dd0342a8 ("drm/i915: Markup paired operations on wakerefs")
1d455f8de8e8 ("drm/i915: rename intel_drv.h to
display/intel_display_types.h")
27fec1f9734d ("drm/i915: extract intel_dp.h from intel_drv.h")
39e2f501c1b4 ("drm/i915: Split struct intel_context definition to its own
header")
480cd6dd9287 ("drm/i915/selftests: Track evict objects explicitly")
499197dc1696 ("drm/i915: Stop tracking MRU activity on VMA")
528cbd17ceff ("drm/i915: Move vma lookup to its own lock")
531747b8200a ("drm/i915/dvo: rename dvo.h to intel_dvo_dev.h and make
self-contained")
64d6c500a384 ("drm/i915: Generalise GPU activity tracking")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
692059318c0f ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
71fc448c1aaf ("drm/i915/selftests: Make evict tolerant of foreign objects")
a037121c3c7f ("drm/i915: Mark up debugfs with rpm wakeref tracking")
c2400ec3b6d1 ("drm/i915: add Makefile magic for testing headers are
self-contained")
d2ee2e8afeea ("drm/i915: extract intel_crt.h from intel_drv.h")
d4225a535b3b ("drm/i915: Syntatic sugar for using intel_runtime_pm")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 02/17] drm/i915: Clear the repeater bit on HDCP disable
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.8.2, v5.7.16, v5.4.59, v4.19.140.
v5.8.2: Failed to apply! Possible dependencies:
53de0a20c8cd ("drm/i915: Add {preemph,voltage}_max() vfuncs")
7801f3b792b0 ("drm/i915/display: prefer dig_port to reference
intel_digital_port")
d1d08a4994a8 ("drm/i915: Fix cpt/ppt max pre-emphasis")
da882e6bb968 ("drm/i915: Fix ibx max vswing/preemph")
v5.7.16: Failed to apply! Possible dependencies:
47bdb1caba0b ("drm/i915/ddi: use struct drm_device based logging")
589a4cd6cc43 ("drm/i915: Move TRANS_DDI_FUNC_CTL2 programming where it
belongs")
7801f3b792b0 ("drm/i915/display: prefer dig_port to reference
intel_digital_port")
7c2fedd7608f ("drm/i915: Push TRANS_DDI_FUNC_CTL into the encoder->enable()
hook")
8b4f2137cc0f ("drm/i915/display/ddi: Prefer drm_WARN* over WARN*")
8fdda3854967 ("drm/i915: Introduce .set_idle_link_train() vfunc")
c38730987b4a ("drm/i915: Move the TRANS_DDI_FUNC_CTL enable to a later
point")
eed22a46b979 ("drm/i915: Pass encoder all the way to
intel_ddi_transcoder_func_reg_val_get()")
eee3f91195ad ("drm/i915: Introduce .set_link_train() vfunc")
fb83f72c48a5 ("drm/i915: Introduce .set_signal_levels() vfunc")
v5.4.59: Failed to apply! Possible dependencies:
0456417ef680 ("drm: Add for_each_oldnew_intel_crtc_in_state_reverse()")
0486513935ef ("drm/i915/dsi: take compression into account in afe_clk()")
1326a92c3466 ("drm/i915: Perform automated conversions for crtc uapi/hw
split, base -> hw.")
2225f3c6f1d7 ("drm/i915: Perform automated conversions for crtc uapi/hw
split, base -> uapi.")
2b808b3a27d1 ("drm/i915: Add aliases for uapi and hw to crtc_state")
3e30d70805d5 ("drm/i915: Make .modeset_calc_cdclk() mandatory")
486bba4524e0 ("drm/i915/hdcp: Clean up local variables")
50003bf50d32 ("drm/i915/dsi: set pipe_bpp on ICL configure config")
54ed6902cabc ("drm/i915/dsi: abstract afe_clk calculation")
5d1db3f61aa9 ("drm/i915: Rename conn_to_dig_port() to
intel_attached_dig_port()")
adf1bd3dfbae ("drm/i915/dsi: use afe_clk() instead of intel_dsi_bitrate()")
af9fbfa657c8 ("drm/i915: Introduce and use
intel_atomic_crtc_state_for_each_plane_state.")
b7d02c3a124d ("drm/i915: Pass intel_encoder to enc_to_*()")
c47b7ddbcb29 ("drm/i915: Rename planar linked plane variables")
d06a79d33e0f ("drm/i915: Use enum pipe instead of crtc index to track
active pipes")
fe4709a8d033 ("drm/i915: Extract intel_modeset_calc_cdclk()")
v4.19.140: Failed to apply! Possible dependencies:
07d805721938 ("drm/i915: Introduce intel_runtime_pm_disable to pair
intel_runtime_pm_enable")
2cd9a689e97b ("drm/i915: Refactor intel_display_set_init_power() logic")
486bba4524e0 ("drm/i915/hdcp: Clean up local variables")
48a287ed9d62 ("drm/i915: Rename intel_power_domains_fini() to
intel_power_domains_fini_hw()")
49a630b00bac ("drm/i915: Enable and Disable of HDCP2.2")
6dfc4a8f134f ("drm/i915: Verify power domains after enabling them")
9055aac76589 ("drm/i915: MEI interface implementation")
bd780f37a361 ("drm/i915: Track all held rpm wakerefs")
f28ec6f4ea48 ("drm/i915: Constify power well descriptors")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gem: Always test execution status on closing the context
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via
sysfs").
The bot has tested the following trees: v5.8.2, v5.7.16.
v5.8.2: Failed to apply! Possible dependencies:
1b90e4a43b74 ("drm/i915/selftests: Enable selftesting of busy-stats")
2d3879950f8a ("drm/i915: Add psr_safest_params")
4fe13f28d66a ("drm/i915/selftests: Add tests for timeslicing virtual
engines")
67a64e51ba92 ("drm/i915/selftests: Refactor sibling selection")
8a25c4be583d ("drm/i915/params: switch to device specific parameters")
9199c070cdde ("drm/i915/selftests: Exercise far preemption rollbacks")
ad6586850b6d ("drm/i915/selftests: Change priority overflow detection")
d4b02a4c613e ("drm/i915/selftests: Trim execlists runtime")
f4bb45f72734 ("drm/i915: Trim set_timer_ms() intervals")
v5.7.16: Failed to apply! Possible dependencies:
0c1abaa7fbfb ("drm: Constify adjusted_mode a bit")
13ea6db2cf24 ("drm/i915/edp: Ignore short pulse when panel powered off")
3dfd8d710419 ("drm/i915/display: use struct drm_device based logging")
81b55ef1f47b ("drm/i915: drop a bunch of superfluous inlines")
8a25c4be583d ("drm/i915/params: switch to device specific parameters")
af67009c1439 ("drm/i915/dp: use struct drm_device based logging")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/39] drm/i915/gem: Avoid implicit vmap for highmem on x86-32
== Series Details ==
Series: series starting with [01/39] drm/i915/gem: Avoid implicit vmap for
highmem on x86-32
URL : https://patchwork.freedesktop.org/series/81064/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4d11ca4aabc3 drm/i915/gem: Avoid implicit vmap for highmem on x86-32
-:18: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#18:
References: e87666b52f00 ("drm/i915/shrinker: Hook up vmap allocation failure
notifier")
-:18: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e87666b52f00
("drm/i915/shrinker: Hook up vmap allocation failure notifier")'
#18:
References: e87666b52f00 ("drm/i915/shrinker: Hook up vmap allocation failure
notifier")
total: 1 errors, 1 warnings, 0 checks, 32 lines checked
2da2b39afc76 drm/i915/gem: Use set_pte_at() for assigning the vmapped PTE
30590df29a8d drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not
supported
0dfcb8899225 drm/i915/gt: Clear the buffer pool age before use
57381cfc1d88 drm/i915/gt: Widen CSB pointer to u64 for the parsers
536206d193db drm/i915/gt: Wait for CSB entries on Tigerlake
-:24: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit d8f505311717 ("drm/i915/icl:
Forcibly evict stale csb entries")'
#24:
References: d8f505311717 ("drm/i915/icl: Forcibly evict stale csb entries")
-:50: ERROR:ASSIGN_IN_IF: do not use assignment in if condition
#50: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2509:
+ if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50))
total: 2 errors, 0 warnings, 0 checks, 33 lines checked
82f82623922e drm/i915/gt: Apply the CSB w/a for all
-:12: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit d8f505311717 ("drm/i915/icl:
Forcibly evict stale csb entries")'
#12:
References: d8f505311717 ("drm/i915/icl: Forcibly evict stale csb entries")
-:93: ERROR:ASSIGN_IN_IF: do not use assignment in if condition
#93: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2548:
+ if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50))
total: 2 errors, 0 warnings, 0 checks, 115 lines checked
19df6f774f8f drm/i915/gt: Show engine properties in the pretty printer
-:48: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#48: FILE: drivers/gpu/drm/i915/gt/intel_engine_cs.c:1618:
+}
+ P(heartbeat_interval_ms),
total: 0 errors, 0 warnings, 1 checks, 48 lines checked
a37d770b0cfe drm/i915/gem: Hold request reference for canceling an active
context
-:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#16:
<4> [582.745252] general protection fault, probably for non-canonical address
0xcd5c: [#1] PREEMPT SMP PTI
total: 0 errors, 1 warnings, 0 checks, 40 lines checked
75b9fbba0fbb drm/i915: Cancel outstanding work after disabling heartbeats on an
engine
c44aed4680a7 drm/i915/gt: Always send a pulse down the engine after disabling
heartbeat
0afa1a535c74 drm/i915/gem: Always test execution status on closing the context
1bbff171d997 drm/i915/gt: Signal cancelled requests
0da106fcbd2a drm/i915/selftests: Finish pending mock requests on cancellation.
1d3e743a294e drm/i915/gt: Retire cancelled requests on unload
b549527fccdb drm/i915/gt: Remove defunct intel_virtual_engine_get_sibling()
13c4f6affac1 drm/i915/gt: Defer enabling the breadcrumb interrupt to after
submission
a91f4c9f1716 drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb
spinlock
5cf5de2a0510 drm/i915/gt: Don't cancel the interrupt shadow too early
95b18580a943 drm/i915/gt: Free stale request on destroying the virtual engine
4677dfe83ecf drm/i915/gt: Protect context lifetime with RCU
1b5b69bce739 drm/i915/gt: Split the breadcrumb spinlock between global and
contexts
-:21: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#21:
<4>[ 416.208555] list_add corruption. prev->next should be next
(8881951d5910), but was dead0100. (prev=8882781bb870).
total: 0 errors, 1 warnings, 0 checks, 354 lines checked
2402fe2e390e drm/i915/gt: Move the breadcrumb to the signaler if completed upon
cancel
b622fb3a7ea1 drm/i915/gt: Decouple completed requests on unwind
d2a5b17f11f8 drm/i915/gt: Check for a completed last request once
d8c09ebb8832 drm/i915/gt: Replace direct submit with direct call to tasklet
27e3ad18e225 drm/i915/gt: ce->inflight updates are now serialised
1c34cf8eff85 drm/i915/gt: Use virtual_engine during execlists_dequeue
8c9c5e79fefc drm/i915/gt: Decouple inflight virtual engines
29827c6800f0 drm/i915/gt: Defer schedule_out until after the next dequeue
a9e4e457612d drm/i915/gt: Remove virtual breadcrumb before transfer
-:17: WARNING:COMMIT_LOG_LONG_LINE: Possible
[Intel-gfx] [PATCH 38/39] drm/i915: Break up error capture compression loops with cond_resched()
As the error capture will compress user buffers as directed to by the user, it can take an arbitrary amount of time and space. Break up the compression loops with a call to cond_resched(), that will allow other processes to schedule (avoiding the soft lockups) and also serve as a warning should we try to make this loop atomic in the future. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: sta...@vger.kernel.org Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 2d76f3ddc571..70274fa0664d 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -311,6 +311,8 @@ static int compress_page(struct i915_vma_compress *c, if (zlib_deflate(zstream, Z_NO_FLUSH) != Z_OK) return -EIO; + + cond_resched(); } while (zstream->avail_in); /* Fallback to uncompressed if we increase size? */ @@ -397,6 +399,7 @@ static int compress_page(struct i915_vma_compress *c, if (!(wc && i915_memcpy_from_wc(ptr, src, PAGE_SIZE))) memcpy(ptr, src, PAGE_SIZE); dst->pages[dst->page_count++] = ptr; + cond_resched(); return 0; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/39] drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported
Let's not try and use PAT attributes for I915_MAP_WC is the CPU doesn't
support PAT.
Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object maps")
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
Cc: # v5.6+
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 0c3d0d6429ae..d729f6d05b97 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -265,6 +265,9 @@ static void *i915_gem_object_map(struct drm_i915_gem_object
*obj,
if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
return NULL;
+ if (GEM_WARN_ON(type == I915_MAP_WC && !boot_cpu_has(X86_FEATURE_PAT)))
+ return NULL;
+
/* A single page can always be kmapped */
if (n_pte == 1 && type == I915_MAP_WB) {
struct page *page = sg_page(sgt->sgl);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 37/39] drm/i915/gt: Consolidate the CS timestamp clocks
Pull the GT clock information [used to derive CS timestamps and PM
interval] under the GT so that is it local to the users. In doing so, we
consolidate the two references for the same information, of which the
runtime-info took note of a potential clock source override and scaling
factors.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 20 +-
drivers/gpu/drm/i915/gt/intel_context.h | 6 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 4 +-
.../gpu/drm/i915/gt/intel_gt_clock_utils.c| 197 ++
.../gpu/drm/i915/gt/intel_gt_clock_utils.h| 8 +-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 1 +
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 6 +-
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 8 +-
drivers/gpu/drm/i915/i915_debugfs.c | 19 +-
drivers/gpu/drm/i915/i915_drv.h | 12 --
drivers/gpu/drm/i915/i915_getparam.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 11 +-
drivers/gpu/drm/i915/intel_device_info.c | 157 --
drivers/gpu/drm/i915/intel_device_info.h | 3 -
drivers/gpu/drm/i915/selftests/i915_perf.c| 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 3 +-
17 files changed, 205 insertions(+), 256 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index 174a24553322..f12ef37cef08 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -403,34 +403,34 @@ static int frequency_show(struct seq_file *m, void
*unused)
seq_printf(m, "RPDECLIMIT: 0x%08x\n", rpdeclimit);
seq_printf(m, "RPNSWREQ: %dMHz\n", reqf);
seq_printf(m, "CAGF: %dMHz\n", cagf);
- seq_printf(m, "RP CUR UP EI: %d (%dns)\n",
+ seq_printf(m, "RP CUR UP EI: %d (%lldns)\n",
rpcurupei,
intel_gt_pm_interval_to_ns(gt, rpcurupei));
- seq_printf(m, "RP CUR UP: %d (%dns)\n",
+ seq_printf(m, "RP CUR UP: %d (%lldns)\n",
rpcurup, intel_gt_pm_interval_to_ns(gt, rpcurup));
- seq_printf(m, "RP PREV UP: %d (%dns)\n",
+ seq_printf(m, "RP PREV UP: %d (%lldns)\n",
rpprevup, intel_gt_pm_interval_to_ns(gt, rpprevup));
seq_printf(m, "Up threshold: %d%%\n",
rps->power.up_threshold);
- seq_printf(m, "RP UP EI: %d (%dns)\n",
+ seq_printf(m, "RP UP EI: %d (%lldns)\n",
rpupei, intel_gt_pm_interval_to_ns(gt, rpupei));
- seq_printf(m, "RP UP THRESHOLD: %d (%dns)\n",
+ seq_printf(m, "RP UP THRESHOLD: %d (%lldns)\n",
rpupt, intel_gt_pm_interval_to_ns(gt, rpupt));
- seq_printf(m, "RP CUR DOWN EI: %d (%dns)\n",
+ seq_printf(m, "RP CUR DOWN EI: %d (%lldns)\n",
rpcurdownei,
intel_gt_pm_interval_to_ns(gt, rpcurdownei));
- seq_printf(m, "RP CUR DOWN: %d (%dns)\n",
+ seq_printf(m, "RP CUR DOWN: %d (%lldns)\n",
rpcurdown,
intel_gt_pm_interval_to_ns(gt, rpcurdown));
- seq_printf(m, "RP PREV DOWN: %d (%dns)\n",
+ seq_printf(m, "RP PREV DOWN: %d (%lldns)\n",
rpprevdown,
intel_gt_pm_interval_to_ns(gt, rpprevdown));
seq_printf(m, "Down threshold: %d%%\n",
rps->power.down_threshold);
- seq_printf(m, "RP DOWN EI: %d (%dns)\n",
+ seq_printf(m, "RP DOWN EI: %d (%lldns)\n",
rpdownei, intel_gt_pm_interval_to_ns(gt, rpdownei));
- seq_printf(m, "RP DOWN THRESHOLD: %d (%dns)\n",
+ seq_printf(m, "RP DOWN THRESHOLD: %d (%lldns)\n",
rpdownt, intel_gt_pm_interval_to_ns(gt, rpdownt));
max_freq = (IS_GEN9_LP(i915) ? rp_state_cap >> 0 :
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index fda2eba81e22..2ce2ec639ba2 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -248,16 +248,14 @@ intel_context_clear_nopreempt(struct intel_context *ce)
static inline u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
{
- const u32 period =
- RUNTIME_INFO(ce->engine->i915)->cs_timestamp_period_ns;
+ const u32 period = ce->engine->gt->clock_period_ns;
return READ_ONCE(ce->runtime.total) * period;
}
static inline u64 intel_context_get_avg_runtime_ns(struct intel_context *ce)
{
- const u32 period =
-
[Intel-gfx] [PATCH 01/39] drm/i915/gem: Avoid implicit vmap for highmem on x86-32
On 32b, highmem uses a finite set of indirect PTE (i.e. vmap) to provide
virtual mappings of the high pages. As these are finite, map_new_virtual()
must wait for some other kmap() to finish when it runs out. If we map a
large number of objects, there is no method for it to tell us to release
the mappings, and we deadlock.
However, if we make an explicit vmap of the page, that uses a larger
vmalloc arena, and also has the ability to tell us to release unwanted
mappings. Most importantly, it will fail and propagate an error instead
of waiting forever.
Fixes: fb8621d3bee8 ("drm/i915: Avoid allocating a vmap arena for a single
page") #x86-32
References: e87666b52f00 ("drm/i915/shrinker: Hook up vmap allocation failure
notifier")
Signed-off-by: Chris Wilson
Cc: Harald Arnesen
Cc: # v4.7+
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 26 +--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 7050519c87a4..51b63e05dbe4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -255,8 +255,30 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
return NULL;
/* A single page can always be kmapped */
- if (n_pte == 1 && type == I915_MAP_WB)
- return kmap(sg_page(sgt->sgl));
+ if (n_pte == 1 && type == I915_MAP_WB) {
+ struct page *page = sg_page(sgt->sgl);
+
+ /*
+* On 32b, highmem uses a finite set of indirect PTE (i.e.
+* vmap) to provide virtual mappings of the high pages.
+* As these are finite, map_new_virtual() must wait for some
+* other kmap() to finish when it runs out. If we map a large
+* number of objects, there is no method for it to tell us
+* to release the mappings, and we deadlock.
+*
+* However, if we make an explicit vmap of the page, that
+* uses a larger vmalloc arena, and also has the ability
+* to tell us to release unwanted mappings. Most importantly,
+* it will fail and propagate an error instead of waiting
+* forever.
+*
+* So if the page is beyond the 32b boundary, make an explicit
+* vmap. On 64b, this check will be optimised away as we can
+* directly kmap any page on the system.
+*/
+ if (!PageHighMem(page))
+ return kmap(page);
+ }
mem = stack;
if (n_pte > ARRAY_SIZE(stack)) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/39] drm/i915/gem: Use set_pte_at() for assigning the vmapped PTE
Use set_pte_at() to assign the PTE pointer returned by alloc_vm_area(),
rather than a direct assignment.
Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object maps")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 33 +++
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 51b63e05dbe4..0c3d0d6429ae 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -241,6 +241,17 @@ static inline pte_t iomap_pte(resource_size_t base,
return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
}
+static void sync_vm_area(struct vm_struct *area)
+{
+ unsigned long start = (unsigned long)area->addr;
+ unsigned long end = start + area->size;
+
+ if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PTE_MODIFIED)
+ arch_sync_kernel_mappings(start, end); /* expected DCE */
+
+ flush_cache_vmap(start, end);
+}
+
/* The 'mapping' part of i915_gem_object_pin_map() below */
static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
enum i915_map_type type)
@@ -308,24 +319,36 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
}
if (i915_gem_object_has_struct_page(obj)) {
+ unsigned long addr = (unsigned long)area->addr;
struct sgt_iter iter;
struct page *page;
pte_t **ptes = mem;
- for_each_sgt_page(page, iter, sgt)
- **ptes++ = mk_pte(page, pgprot);
+ for_each_sgt_page(page, iter, sgt) {
+ set_pte_at(_mm, addr, *ptes, mk_pte(page, pgprot));
+ addr += PAGE_SIZE;
+ ptes++;
+ }
+ GEM_BUG_ON(addr != (unsigned long)area->addr + obj->base.size);
} else {
+ unsigned long addr = (unsigned long)area->addr;
resource_size_t iomap;
struct sgt_iter iter;
pte_t **ptes = mem;
- dma_addr_t addr;
+ dma_addr_t offset;
iomap = obj->mm.region->iomap.base;
iomap -= obj->mm.region->region.start;
- for_each_sgt_daddr(addr, iter, sgt)
- **ptes++ = iomap_pte(iomap, addr, pgprot);
+ for_each_sgt_daddr(offset, iter, sgt) {
+ set_pte_at(_mm, addr, *ptes,
+ iomap_pte(iomap, offset, pgprot));
+ addr += PAGE_SIZE;
+ ptes++;
+ }
+ GEM_BUG_ON(addr != (unsigned long)area->addr + obj->base.size);
}
+ sync_vm_area(area);
if (mem != stack)
kvfree(mem);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 26/39] drm/i915/gt: Replace direct submit with direct call to tasklet
Rather than having special case code for opportunistically calling
process_csb() and performing a direct submit while holding the engine
spinlock for submitting the request, simply call the tasklet directly.
This allows us to retain the direct submission path, including the CS
draining to allow fast/immediate submissions, without requiring any
duplicated code paths, and most importantly greatly simplifying the
control flow by removing reentrancy. This will enable us to close a few
races in the virtual engines in the next few patches.
The trickiest part here is to ensure that paired operations (such as
schedule_in/schedule_out) remain under consistent locking domains,
e.g. when pulled outside of the engine->active.lock
v2: Use bh kicking, see commit 3c53776e29f8 ("Mark HI and TASKLET
softirq synchronous").
v3: Update engine-reset to be tasklet aware
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 35 +++--
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 3 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 136 +++---
drivers/gpu/drm/i915/gt/intel_reset.c | 60 +---
drivers/gpu/drm/i915/gt/intel_reset.h | 2 +
drivers/gpu/drm/i915/gt/selftest_context.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 7 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 27 ++--
drivers/gpu/drm/i915/gt/selftest_reset.c | 8 +-
drivers/gpu/drm/i915/i915_request.c | 12 +-
drivers/gpu/drm/i915/i915_request.h | 1 +
drivers/gpu/drm/i915/i915_scheduler.c | 4 -
drivers/gpu/drm/i915/selftests/i915_request.c | 6 +-
14 files changed, 157 insertions(+), 148 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1579a80bc8cb..d7ad953b3933 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1000,32 +1000,39 @@ static unsigned long stop_timeout(const struct
intel_engine_cs *engine)
return READ_ONCE(engine->props.stop_timeout_ms);
}
-int intel_engine_stop_cs(struct intel_engine_cs *engine)
+static int __intel_engine_stop_cs(struct intel_engine_cs *engine,
+ int fast_timeout_us,
+ int slow_timeout_ms)
{
struct intel_uncore *uncore = engine->uncore;
- const u32 base = engine->mmio_base;
- const i915_reg_t mode = RING_MI_MODE(base);
+ const i915_reg_t mode = RING_MI_MODE(engine->mmio_base);
int err;
+ intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
+ err = __intel_wait_for_register_fw(engine->uncore, mode,
+ MODE_IDLE, MODE_IDLE,
+ fast_timeout_us,
+ slow_timeout_ms,
+ NULL);
+
+ /* A final mmio read to let GPU writes be hopefully flushed to memory */
+ intel_uncore_posting_read_fw(uncore, mode);
+ return err;
+}
+
+int intel_engine_stop_cs(struct intel_engine_cs *engine)
+{
+ int err = 0;
+
if (INTEL_GEN(engine->i915) < 3)
return -ENODEV;
ENGINE_TRACE(engine, "\n");
-
- intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
-
- err = 0;
- if (__intel_wait_for_register_fw(uncore,
-mode, MODE_IDLE, MODE_IDLE,
-1000, stop_timeout(engine),
-NULL)) {
+ if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
ENGINE_TRACE(engine, "timed out on STOP_RING -> IDLE\n");
err = -ETIMEDOUT;
}
- /* A final mmio read to let GPU writes be hopefully flushed to memory */
- intel_uncore_posting_read_fw(uncore, mode);
-
return err;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index f7b2e07e2229..6145d16576c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -123,7 +123,7 @@ __queue_and_release_pm(struct i915_request *rq,
list_add_tail(>link, >active_list);
/* Hand the request over to HW and so engine_retire() */
- __i915_request_queue(rq, NULL);
+ __i915_request_queue_bh(rq);
/* Let new submissions commence (and maybe retire this timeline) */
__intel_wakeref_defer_park(>wakeref);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index ee6312601c56..e71eef157231 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -183,7 +183,8 @@ struct intel_engine_execlists {
[Intel-gfx] [PATCH 22/39] drm/i915/gt: Split the breadcrumb spinlock between global and contexts
As we funnel more and more contexts into the breadcrumbs on an engine, the hold time of b->irq_lock grows. As we may then contend with the b->irq_lock during request submission, this increases the burden upon the engine->active.lock and so directly impacts both our execution latency and client latency. If we split the b->irq_lock by introducing a per-context spinlock to manage the signalers within a context, we then only need the b->irq_lock for enabling/disabling the interrupt and can avoid taking the lock for walking the list of contexts within the signal worker. Even with the current setup, this greatly reduces the number of times we have to take and fight for b->irq_lock. Furthermore, this closes the race between enabling the signaling context while it is in the process of being signaled and removed: <4>[ 416.208555] list_add corruption. prev->next should be next (8881951d5910), but was dead0100. (prev=8882781bb870). <4>[ 416.208573] WARNING: CPU: 7 PID: 0 at lib/list_debug.c:28 __list_add_valid+0x4d/0x70 <4>[ 416.208575] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio mei_hdcp x86_pkg_temp_thermal coretemp ax88179_178a usbnet mii crct10dif_pclmul snd_intel_dspcfg crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel snd_hda_core e1000e snd_pcm ptp pps_core mei_me mei prime_numbers intel_lpss_pci [last unloaded: i915] <4>[ 416.208611] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G U 5.8.0-CI-CI_DRM_8852+ #1 <4>[ 416.208614] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake Y LPDDR4x T4 RVP TLC, BIOS ICLSFWR1.R00.3212.A00.1905212112 05/21/2019 <4>[ 416.208627] RIP: 0010:__list_add_valid+0x4d/0x70 <4>[ 416.208631] Code: c3 48 89 d1 48 c7 c7 60 18 33 82 48 89 c2 e8 ea e0 b6 ff 0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 b0 18 33 82 e8 d3 e0 b6 ff <0f> 0b 31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 00 19 33 82 e8 <4>[ 416.208633] RSP: 0018:c9280e18 EFLAGS: 00010086 <4>[ 416.208636] RAX: RBX: 888250a44880 RCX: 0105 <4>[ 416.208639] RDX: 0105 RSI: 82320c5b RDI: <4>[ 416.208641] RBP: 8882781bb870 R08: R09: 0001 <4>[ 416.208643] R10: 054d2957 R11: 6abbd991 R12: 8881951d58c8 <4>[ 416.208646] R13: 888286073880 R14: 888286073848 R15: 8881951d5910 <4>[ 416.208669] FS: () GS:88829c18() knlGS: <4>[ 416.208671] CS: 0010 DS: ES: CR0: 80050033 <4>[ 416.208673] CR2: 556231326c48 CR3: 05610001 CR4: 00760ee0 <4>[ 416.208675] PKRU: 5554 <4>[ 416.208677] Call Trace: <4>[ 416.208679] <4>[ 416.208751] i915_request_enable_breadcrumb+0x278/0x400 [i915] <4>[ 416.208839] __i915_request_submit+0xca/0x2a0 [i915] <4>[ 416.208892] __execlists_submission_tasklet+0x480/0x1830 [i915] <4>[ 416.208942] execlists_submission_tasklet+0xc4/0x130 [i915] <4>[ 416.208947] tasklet_action_common.isra.17+0x6c/0x1c0 <4>[ 416.208954] __do_softirq+0xdf/0x498 <4>[ 416.208960] ? handle_fasteoi_irq+0x150/0x150 <4>[ 416.208964] asm_call_on_stack+0xf/0x20 <4>[ 416.208966] <4>[ 416.208969] do_softirq_own_stack+0xa1/0xc0 <4>[ 416.208972] irq_exit_rcu+0xb5/0xc0 <4>[ 416.208976] common_interrupt+0xf7/0x260 <4>[ 416.208980] asm_common_interrupt+0x1e/0x40 <4>[ 416.208985] RIP: 0010:cpuidle_enter_state+0xb6/0x410 <4>[ 416.208987] Code: 00 31 ff e8 9c 3e 89 ff 80 7c 24 0b 00 74 12 9c 58 f6 c4 02 0f 85 31 03 00 00 31 ff e8 e3 6c 90 ff e8 fe a4 94 ff fb 45 85 ed <0f> 88 c7 02 00 00 49 63 c5 4c 2b 24 24 48 8d 14 40 48 8d 14 90 48 <4>[ 416.208989] RSP: 0018:c9143e70 EFLAGS: 0206 <4>[ 416.208991] RAX: 0007 RBX: e8da8070 RCX: <4>[ 416.208993] RDX: RSI: 8238b4ee RDI: 8233184f <4>[ 416.208995] RBP: 826b4e00 R08: R09: <4>[ 416.208997] R10: 0001 R11: R12: 0060e7f24a8f <4>[ 416.208998] R13: 0003 R14: 0003 R15: 0003 <4>[ 416.209012] cpuidle_enter+0x24/0x40 <4>[ 416.209016] do_idle+0x22f/0x2d0 <4>[ 416.209022] cpu_startup_entry+0x14/0x20 <4>[ 416.209025] start_secondary+0x158/0x1a0 <4>[ 416.209030] secondary_startup_64+0xa4/0xb0 <4>[ 416.209039] irq event stamp: 10186977 <4>[ 416.209042] hardirqs last enabled at (10186976): [] tasklet_action_common.isra.17+0xe3/0x1c0 <4>[ 416.209044] hardirqs last disabled at (10186977): [] _raw_spin_lock_irqsave+0xd/0x50 <4>[ 416.209047] softirqs last enabled at (10186968): [] irq_enter_rcu+0x6a/0x70 <4>[ 416.209049] softirqs last disabled at (10186969): [] asm_call_on_stack+0xf/0x20 <4>[ 416.209317] list_del corruption, 8882781bb870->next is LIST_POISON1 (dead0100) <4>[ 416.209317] WARNING: CPU: 7
[Intel-gfx] [PATCH 07/39] drm/i915/gt: Apply the CSB w/a for all
Since we expect to inline the csb_parse() routines, the w/a for the
stale CSB data on Tigerlake will be pulled into process_csb(), and so we
might as well simply reuse the logic for all, and so will hopefully
avoid any strange behaviour on Icelake that was not covered by our
previous w/a.
References: d8f505311717 ("drm/i915/icl: Forcibly evict stale csb entries")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Bruce Chang
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 71 +
1 file changed, 43 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d75712a503b7..b69b77ae294d 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2496,25 +2496,11 @@ invalidate_csb_entries(const u64 *first, const u64
*last)
* bits 47-57: sw context id of the lrc the GT switched away from
* bits 58-63: sw counter of the lrc the GT switched away from
*/
-static inline bool gen12_csb_parse(const u64 *csb)
+static inline bool gen12_csb_parse(const u64 csb)
{
- bool ctx_away_valid;
- bool new_queue;
- u64 entry;
-
- /* HSD#22011248461 */
- entry = READ_ONCE(*csb);
- if (unlikely(entry == -1)) {
- preempt_disable();
- if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50))
- GEM_WARN_ON("50us CSB timeout");
- preempt_enable();
- }
- WRITE_ONCE(*(u64 *)csb, -1);
-
- ctx_away_valid = GEN12_CSB_CTX_VALID(upper_32_bits(entry));
- new_queue =
- lower_32_bits(entry) & GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE;
+ bool ctx_away_valid = GEN12_CSB_CTX_VALID(upper_32_bits(csb));
+ bool new_queue =
+ lower_32_bits(csb) & GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE;
/*
* The context switch detail is not guaranteed to be 5 when a preemption
@@ -2524,7 +2510,7 @@ static inline bool gen12_csb_parse(const u64 *csb)
* would require some extra handling, but we don't support that.
*/
if (!ctx_away_valid || new_queue) {
- GEM_BUG_ON(!GEN12_CSB_CTX_VALID(lower_32_bits(entry)));
+ GEM_BUG_ON(!GEN12_CSB_CTX_VALID(lower_32_bits(csb)));
return true;
}
@@ -2533,19 +2519,48 @@ static inline bool gen12_csb_parse(const u64 *csb)
* context switch on an unsuccessful wait instruction since we always
* use polling mode.
*/
- GEM_BUG_ON(GEN12_CTX_SWITCH_DETAIL(upper_32_bits(entry)));
+ GEM_BUG_ON(GEN12_CTX_SWITCH_DETAIL(upper_32_bits(csb)));
return false;
}
-static inline bool gen8_csb_parse(const u64 *csb)
+static inline bool gen8_csb_parse(const u64 csb)
+{
+ return csb & (GEN8_CTX_STATUS_IDLE_ACTIVE | GEN8_CTX_STATUS_PREEMPTED);
+}
+
+static inline u64 csb_read(u64 * const csb)
{
- return *csb & (GEN8_CTX_STATUS_IDLE_ACTIVE | GEN8_CTX_STATUS_PREEMPTED);
+ u64 entry = READ_ONCE(*csb);
+
+ /*
+* Unfortunately, the GPU does not always serialise its write
+* of the CSB entries before its write of the CSB pointer, at least
+* from the perspective of the CPU, using what is known as a Global
+* Observation Point. We may read a new CSB tail pointer, but then
+* read the stale CSB entries, causing us to misinterpret the
+* context-switch events, and eventually declare the GPU hung.
+*
+* icl:HSDES#1806554093
+* tgl:HSDES#22011248461
+*/
+ if (unlikely(entry == -1)) {
+ preempt_disable();
+ if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50))
+ GEM_WARN_ON("50us CSB timeout");
+ preempt_enable();
+ }
+
+ /* Consume this entry so that we can spot its future reuse. */
+ WRITE_ONCE(*csb, -1);
+
+ /* ELSP is an implicit wmb() before the GPU wraps and overwrites csb */
+ return entry;
}
static void process_csb(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = >execlists;
- const u64 * const buf = execlists->csb_status;
+ u64 * const buf = execlists->csb_status;
const u8 num_entries = execlists->csb_size;
u8 head, tail;
@@ -2603,6 +2618,7 @@ static void process_csb(struct intel_engine_cs *engine)
rmb();
do {
bool promote;
+ u64 csb;
if (++head == num_entries)
head = 0;
@@ -2625,15 +2641,14 @@ static void process_csb(struct intel_engine_cs *engine)
* status notifier.
*/
+ csb = csb_read(buf + head);
ENGINE_TRACE(engine, "csb[%d]: status=0x%08x:0x%08x\n",
-head,
-upper_32_bits(buf[head]),
-
[Intel-gfx] [PATCH 31/39] drm/i915/gt: Remove virtual breadcrumb before transfer
The issue with stale virtual breadcrumbs remain. Now we have the problem
that if the irq-signaler is still referencing the stale breadcrumb as we
transfer it to a new sibling, the list becomes spaghetti. This is a very
small window, but that doesn't stop it being hit infrequently. To
prevent the lists being tangled (the iterator starting on one engine's
b->signalers but walking onto another list), always decouple the virtual
breadcrumb on schedule-out and make sure that the walker has stepped out
of the lists.
Otherwise, we end up corrupting the lists upon signaling:
<4> [412.623150] list_add corruption. prev->next should be next
(888284a98470), but was dead0100. (prev=8882586fb870).
<4> [412.623167] WARNING: CPU: 7 PID: 0 at lib/list_debug.c:28
__list_add_valid+0x4d/0x70
<4> [412.623169] Modules linked in: i915(+) vgem snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio mei_hdcp
x86_pkg_temp_thermal ax88179_178a usbnet coretemp snd_intel_dspcfg mii
snd_hda_codec crct10dif_pclmul crc32_pclmul snd_hwdep snd_hda_core
ghash_clmulni_intel snd_pcm e1000e mei_me mei ptp pps_core prime_numbers
intel_lpss_pci [last unloaded: i915]
<4> [412.623191] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G U
5.9.0-rc2-CI-CI_DRM_8925+ #1
<4> [412.623194] Hardware name: Intel Corporation Ice Lake Client
Platform/IceLake Y LPDDR4x T4 RVP TLC, BIOS ICLSFWR1.R00.3212.A00.1905212112
05/21/2019
<4> [412.623197] RIP: 0010:__list_add_valid+0x4d/0x70
<4> [412.623200] Code: c3 48 89 d1 48 c7 c7 18 57 33 82 48 89 c2 e8 fa 78 b6 ff
0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 68 57 33 82 e8 e3 78 b6 ff <0f> 0b 31
c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 b8 57 33 82 e8
<4> [412.623202] RSP: 0018:c9280e18 EFLAGS: 00010086
<4> [412.623205] RAX: RBX: 88828dbd8d00 RCX:
0105
<4> [412.623208] RDX: 0105 RSI: 82324b63 RDI:
<4> [412.623210] RBP: 8882586fb870 R08: 88829a144998 R09:
fffe
<4> [412.623212] R10: c4bbeb58 R11: eb0f6cb0 R12:
888284a98428
<4> [412.623215] R13: 88827d7db880 R14: 88827d7db848 R15:
888284a98470
<4> [412.623217] FS: () GS:88829c18()
knlGS:
<4> [412.623220] CS: 0010 DS: ES: CR0: 80050033
<4> [412.623222] CR2: 561612b6e6e0 CR3: 05610002 CR4:
00770ee0
<4> [412.623224] PKRU: 5554
<4> [412.623227] Call Trace:
<4> [412.623229]
<4> [412.623307] i915_request_enable_breadcrumb+0x278/0x400 [i915]
<4> [412.623391] __i915_request_submit+0xca/0x2a0 [i915]
<4> [412.623461] __execlists_submission_tasklet+0x480/0x1830 [i915]
<4> [412.623572] execlists_submission_tasklet+0xc4/0x130 [i915]
<4> [412.623585] tasklet_action_common.isra.17+0x198/0x1d0
<4> [412.623606] __do_softirq+0xe0/0x497
<4> [412.623619] ? handle_fasteoi_irq+0x150/0x150
<4> [412.623622] asm_call_on_stack+0xf/0x20
<4> [412.623630]
<4> [412.623634] do_softirq_own_stack+0x73/0x90
<4> [412.623645] irq_exit_rcu+0xa9/0xb0
<4> [412.623648] common_interrupt+0xdd/0x210
<4> [412.623652] asm_common_interrupt+0x1e/0x40
So far this has only been seen in our selftests that emphasize lots of
fast sibling switches for the virtual engines.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 5 +++--
drivers/gpu/drm/i915/gt/intel_lrc.c | 15 +++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index f5f6feed0fa6..5b84f51931d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -461,15 +461,16 @@ void i915_request_cancel_breadcrumb(struct i915_request
*rq)
{
struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
struct intel_context *ce = rq->context;
+ unsigned long flags;
bool release;
if (!test_and_clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags))
return;
- spin_lock(>signal_lock);
+ spin_lock_irqsave(>signal_lock, flags);
list_del_rcu(>signal_link);
release = remove_signaling_context(b, ce);
- spin_unlock(>signal_lock);
+ spin_unlock_irqrestore(>signal_lock, flags);
if (release)
intel_context_put(ce);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f89e4f62c88d..6e57f30c80f0 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1387,6 +1387,21 @@ static inline void execlists_schedule_in(struct
i915_request *rq, int idx)
static void kick_siblings(struct i915_request *rq, struct intel_context *ce)
{
struct virtual_engine *ve = container_of(ce, typeof(*ve), context);
+ struct intel_engine_cs *engine = rq->engine;
+
+ /* Flush concurrent rcu
[Intel-gfx] [PATCH 23/39] drm/i915/gt: Move the breadcrumb to the signaler if completed upon cancel
If while we are cancelling the breadcrumb signaling, we find that the
request is already completed, move it to the irq signaler and let it be
signaled.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index a24cc1ff08a0..f5f6feed0fa6 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -363,6 +363,14 @@ void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
kfree(b);
}
+static void irq_signal_request(struct i915_request *rq,
+ struct intel_breadcrumbs *b)
+{
+ if (__signal_request(rq) &&
+ llist_add(>signal_node, >signaled_requests))
+ irq_work_queue(>irq_work);
+}
+
static void insert_breadcrumb(struct i915_request *rq)
{
struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
@@ -380,9 +388,7 @@ static void insert_breadcrumb(struct i915_request *rq)
* its signal completion.
*/
if (__request_completed(rq)) {
- if (__signal_request(rq) &&
- llist_add(>signal_node, >signaled_requests))
- irq_work_queue(>irq_work);
+ irq_signal_request(rq, b);
return;
}
@@ -453,6 +459,7 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
void i915_request_cancel_breadcrumb(struct i915_request *rq)
{
+ struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
struct intel_context *ce = rq->context;
bool release;
@@ -461,11 +468,16 @@ void i915_request_cancel_breadcrumb(struct i915_request
*rq)
spin_lock(>signal_lock);
list_del_rcu(>signal_link);
- release = remove_signaling_context(rq->engine->breadcrumbs, ce);
+ release = remove_signaling_context(b, ce);
spin_unlock(>signal_lock);
if (release)
intel_context_put(ce);
+ if (__request_completed(rq)) {
+ irq_signal_request(rq, b);
+ return;
+ }
+
i915_request_put(rq);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 28/39] drm/i915/gt: Use virtual_engine during execlists_dequeue
Rather than going back and forth between the rb_node entry and the
virtual_engine type, store the ve local and reuse it. As the
container_of conversion from rb_node to virtual_engine requires a
variable offset, performing that conversion just once shaves off a bit
of code.
v2: Keep a single virtual engine lookup, for typical use.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 238
1 file changed, 104 insertions(+), 134 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 231fe39c88d5..10f1f945f097 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -454,9 +454,15 @@ static int queue_prio(const struct intel_engine_execlists
*execlists)
return ((p->priority + 1) << I915_USER_PRIORITY_SHIFT) - ffs(p->used);
}
+static int virtual_prio(const struct intel_engine_execlists *el)
+{
+ struct rb_node *rb = rb_first_cached(>virtual);
+
+ return rb ? rb_entry(rb, struct ve_node, rb)->prio : INT_MIN;
+}
+
static inline bool need_preempt(const struct intel_engine_cs *engine,
- const struct i915_request *rq,
- struct rb_node *rb)
+ const struct i915_request *rq)
{
int last_prio;
@@ -493,25 +499,6 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
rq_prio(list_next_entry(rq, sched.link)) > last_prio)
return true;
- if (rb) {
- struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
- bool preempt = false;
-
- if (engine == ve->siblings[0]) { /* only preempt one sibling */
- struct i915_request *next;
-
- rcu_read_lock();
- next = READ_ONCE(ve->request);
- if (next)
- preempt = rq_prio(next) > last_prio;
- rcu_read_unlock();
- }
-
- if (preempt)
- return preempt;
- }
-
/*
* If the inflight context did not trigger the preemption, then maybe
* it was the set of queued requests? Pick the highest priority in
@@ -522,7 +509,8 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
* ELSP[0] or ELSP[1] as, thanks again to PI, if it was the same
* context, it's priority would not exceed ELSP[0] aka last_prio.
*/
- return queue_prio(>execlists) > last_prio;
+ return max(virtual_prio(>execlists),
+ queue_prio(>execlists)) > last_prio;
}
__maybe_unused static inline bool
@@ -1805,6 +1793,35 @@ static bool virtual_matches(const struct virtual_engine
*ve,
return true;
}
+static struct virtual_engine *
+first_virtual_engine(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *el = >execlists;
+ struct rb_node *rb = rb_first_cached(>virtual);
+
+ while (rb) {
+ struct virtual_engine *ve =
+ rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
+ struct i915_request *rq = READ_ONCE(ve->request);
+
+ /* lazily cleanup after another engine handled rq */
+ if (!rq) {
+ rb_erase_cached(rb, >virtual);
+ RB_CLEAR_NODE(rb);
+ rb = rb_first_cached(>virtual);
+ continue;
+ }
+
+ if (!virtual_matches(ve, rq, engine)) {
+ rb = rb_next(rb);
+ continue;
+ }
+ return ve;
+ }
+
+ return NULL;
+}
+
static void virtual_xfer_context(struct virtual_engine *ve,
struct intel_engine_cs *engine)
{
@@ -1903,32 +1920,15 @@ static void defer_active(struct intel_engine_cs *engine)
static bool
need_timeslice(const struct intel_engine_cs *engine,
- const struct i915_request *rq,
- const struct rb_node *rb)
+ const struct i915_request *rq)
{
int hint;
if (!intel_engine_has_timeslices(engine))
return false;
- hint = engine->execlists.queue_priority_hint;
-
- if (rb) {
- const struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
- const struct intel_engine_cs *inflight =
- intel_context_inflight(>context);
-
- if (!inflight || inflight == engine) {
- struct i915_request *next;
-
- rcu_read_lock();
- next = READ_ONCE(ve->request);
- if (next)
- hint = max(hint, rq_prio(next));
[Intel-gfx] [PATCH 15/39] drm/i915/gt: Retire cancelled requests on unload
If we manage to hit the intel_gt_set_wedged_on_fini() while active, i.e.
module unload during a stress test, we may cancel the requests but not
clean up. This leads to a slow module unload as we wait for something or
other to trigger the retirement flushing. Instead if we explicitly
cancel then cleanup on an active unload, it should be instant.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_reset.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index ac36b67fb46b..4e5e13dc95da 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -19,6 +19,7 @@
#include "intel_engine_pm.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
#include "intel_reset.h"
#include "uc/intel_guc.h"
@@ -1370,6 +1371,7 @@ void intel_gt_set_wedged_on_fini(struct intel_gt *gt)
{
intel_gt_set_wedged(gt);
set_bit(I915_WEDGED_ON_FINI, >reset.flags);
+ intel_gt_retire_requests(gt); /* cleanup any wedged requests */
}
void intel_gt_init_reset(struct intel_gt *gt)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/39] drm/i915/gt: Widen CSB pointer to u64 for the parsers
A CSB entry is 64b, and it is simpler for us to treat it as an array of
64b entries than as an array of pairs of 32b entries.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 33 ++--
2 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index c400aaa2287b..ee6312601c56 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -278,7 +278,7 @@ struct intel_engine_execlists {
*
* Note these register may be either mmio or HWSP shadow.
*/
- u32 *csb_status;
+ u64 *csb_status;
/**
* @csb_size: context status buffer FIFO size
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 0412a44f25f2..d6e0f62337b4 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2464,7 +2464,7 @@ cancel_port_requests(struct intel_engine_execlists *
const execlists)
}
static inline void
-invalidate_csb_entries(const u32 *first, const u32 *last)
+invalidate_csb_entries(const u64 *first, const u64 *last)
{
clflush((void *)first);
clflush((void *)last);
@@ -2496,14 +2496,12 @@ invalidate_csb_entries(const u32 *first, const u32
*last)
* bits 47-57: sw context id of the lrc the GT switched away from
* bits 58-63: sw counter of the lrc the GT switched away from
*/
-static inline bool
-gen12_csb_parse(const struct intel_engine_execlists *execlists, const u32 *csb)
+static inline bool gen12_csb_parse(const u64 *csb)
{
- u32 lower_dw = csb[0];
- u32 upper_dw = csb[1];
- bool ctx_to_valid = GEN12_CSB_CTX_VALID(lower_dw);
- bool ctx_away_valid = GEN12_CSB_CTX_VALID(upper_dw);
- bool new_queue = lower_dw & GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE;
+ u64 entry = READ_ONCE(*csb);
+ bool ctx_away_valid = GEN12_CSB_CTX_VALID(upper_32_bits(entry));
+ bool new_queue =
+ lower_32_bits(entry) & GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE;
/*
* The context switch detail is not guaranteed to be 5 when a preemption
@@ -2513,7 +2511,7 @@ gen12_csb_parse(const struct intel_engine_execlists
*execlists, const u32 *csb)
* would require some extra handling, but we don't support that.
*/
if (!ctx_away_valid || new_queue) {
- GEM_BUG_ON(!ctx_to_valid);
+ GEM_BUG_ON(!GEN12_CSB_CTX_VALID(lower_32_bits(entry)));
return true;
}
@@ -2522,12 +2520,11 @@ gen12_csb_parse(const struct intel_engine_execlists
*execlists, const u32 *csb)
* context switch on an unsuccessful wait instruction since we always
* use polling mode.
*/
- GEM_BUG_ON(GEN12_CTX_SWITCH_DETAIL(upper_dw));
+ GEM_BUG_ON(GEN12_CTX_SWITCH_DETAIL(upper_32_bits(entry)));
return false;
}
-static inline bool
-gen8_csb_parse(const struct intel_engine_execlists *execlists, const u32 *csb)
+static inline bool gen8_csb_parse(const u64 *csb)
{
return *csb & (GEN8_CTX_STATUS_IDLE_ACTIVE | GEN8_CTX_STATUS_PREEMPTED);
}
@@ -2535,7 +2532,7 @@ gen8_csb_parse(const struct intel_engine_execlists
*execlists, const u32 *csb)
static void process_csb(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = >execlists;
- const u32 * const buf = execlists->csb_status;
+ const u64 * const buf = execlists->csb_status;
const u8 num_entries = execlists->csb_size;
u8 head, tail;
@@ -2616,12 +2613,14 @@ static void process_csb(struct intel_engine_cs *engine)
*/
ENGINE_TRACE(engine, "csb[%d]: status=0x%08x:0x%08x\n",
-head, buf[2 * head + 0], buf[2 * head + 1]);
+head,
+upper_32_bits(buf[head]),
+lower_32_bits(buf[head]));
if (INTEL_GEN(engine->i915) >= 12)
- promote = gen12_csb_parse(execlists, buf + 2 * head);
+ promote = gen12_csb_parse(buf + head);
else
- promote = gen8_csb_parse(execlists, buf + 2 * head);
+ promote = gen8_csb_parse(buf + head);
if (promote) {
struct i915_request * const *old = execlists->active;
@@ -5157,7 +5156,7 @@ int intel_execlists_submission_setup(struct
intel_engine_cs *engine)
}
execlists->csb_status =
- >status_page.addr[I915_HWS_CSB_BUF0_INDEX];
+ (u64 *)>status_page.addr[I915_HWS_CSB_BUF0_INDEX];
execlists->csb_write =
>status_page.addr[intel_hws_csb_write_index(i915)];
