[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Infoframe precompute/check (rev6)
== Series Details ==
Series: drm/i915: Infoframe precompute/check (rev6)
URL : https://patchwork.freedesktop.org/series/49983/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5397_full -> Patchwork_11276_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11276_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11276_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_11276_full:
### IGT changes ###
Possible regressions
* igt@kms_plane_lowres@pipe-b-tiling-yf:
- shard-apl: PASS -> DMESG-WARN
Warnings
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite:
- shard-hsw: {SKIP} -> PASS
Known issues
Here are the changes found in Patchwork_11276_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_schedule@pi-ringfull-bsd:
- shard-iclb: NOTRUN -> FAIL [fdo#103158]
* igt@kms_atomic_transition@plane-all-transition:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#109225]
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_chv_cursor_fail@pipe-c-128x128-left-edge:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +6
* igt@kms_content_protection@legacy:
- shard-kbl: NOTRUN -> FAIL [fdo#108597]
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-skl: NOTRUN -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-64x64-dpms:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-iclb: PASS -> FAIL [fdo#103355]
* igt@kms_draw_crc@draw-method-xrgb2101010-blt-ytiled:
- shard-iclb: PASS -> WARN [fdo#108336] +2
* igt@kms_flip@dpms-vs-vblank-race:
- shard-glk: PASS -> FAIL [fdo#103060]
* igt@kms_flip@flip-vs-expired-vblank:
- shard-glk: PASS -> FAIL [fdo#102887] / [fdo#105363]
* igt@kms_flip@flip-vs-modeset-vs-hang-interruptible:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +7
* igt@kms_flip_tiling@flip-changes-tiling-yf:
- shard-skl: NOTRUN -> FAIL [fdo#108228] / [fdo#108303]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-gtt:
- shard-skl: NOTRUN -> FAIL [fdo#105682] +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-gtt:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-blt:
- shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +1
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move:
- shard-skl: NOTRUN -> FAIL [fdo#103167] +2
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move:
- shard-iclb: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@psr-suspend:
- shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#106978] /
[fdo#107773]
* igt@kms_plane@pixel-format-pipe-b-planes-source-clamping:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713]
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-iclb: NOTRUN -> FAIL [fdo#103166]
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166] +2
* igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724]
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-glk: PASS -> DMESG-FAIL [fdo#105763] / [fdo#106538]
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
* igt@pm_backlight@fade_with_suspend:
- shard-skl: NOT
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable Y2xx and Y4xx (xx:10/12/16 bits) packed formats for ICL
== Series Details ==
Series: Enable Y2xx and Y4xx (xx:10/12/16 bits) packed formats for ICL
URL : https://patchwork.freedesktop.org/series/55035/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5401 -> Patchwork_11279
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11279 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11279, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55035/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11279:
### IGT changes ###
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: PASS -> {SKIP} +33
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: {SKIP} -> PASS
Known issues
Here are the changes found in Patchwork_11279 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-ivb-3520m: NOTRUN -> FAIL [fdo#103375] +2
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
* igt@pm_backlight@basic-brightness:
- fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: FAIL [fdo#108800] -> PASS
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (46 -> 41)
--
Additional (1): fi-ivb-3520m
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-icl-u3 fi-blb-e6850
Build changes
-
* Linux: CI_DRM_5401 -> Patchwork_11279
CI_DRM_5401: e1ca1a2f27aa669c656fd6f53a0b77fd96e6ade6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4759: 478452fece3997dfacaa4d6babe6b8bf6fef784f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11279: 3aee6165af4caa29254efc855c00bdbf121d5db4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3aee6165af4c drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for
universal planes
288965e797ac drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control
definitions
74f4fde246cb drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11279/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable Y2xx and Y4xx (xx:10/12/16 bits) packed formats for ICL
== Series Details ==
Series: Enable Y2xx and Y4xx (xx:10/12/16 bits) packed formats for ICL
URL : https://patchwork.freedesktop.org/series/55035/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
74f4fde246cb drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
-:46: WARNING:LONG_LINE: line over 100 characters
#46: FILE: drivers/gpu/drm/drm_fourcc.c:229:
+ { .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:47: WARNING:LONG_LINE: line over 100 characters
#47: FILE: drivers/gpu/drm/drm_fourcc.c:230:
+ { .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:48: WARNING:LONG_LINE: line over 100 characters
#48: FILE: drivers/gpu/drm/drm_fourcc.c:231:
+ { .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:49: WARNING:LONG_LINE: line over 100 characters
#49: FILE: drivers/gpu/drm/drm_fourcc.c:232:
+ { .format = DRM_FORMAT_Y410,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-:50: WARNING:LONG_LINE: line over 100 characters
#50: FILE: drivers/gpu/drm/drm_fourcc.c:233:
+ { .format = DRM_FORMAT_Y412,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-:51: WARNING:LONG_LINE: line over 100 characters
#51: FILE: drivers/gpu/drm/drm_fourcc.c:234:
+ { .format = DRM_FORMAT_Y416,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-:64: WARNING:LONG_LINE_COMMENT: line over 100 characters
#64: FILE: include/uapi/drm/drm_fourcc.h:154:
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0]
X:Y:Cb:Cr 8:8:8:8 little endian */
-:70: WARNING:LONG_LINE_COMMENT: line over 100 characters
#70: FILE: include/uapi/drm/drm_fourcc.h:160:
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian */
-:71: WARNING:LONG_LINE_COMMENT: line over 100 characters
#71: FILE: include/uapi/drm/drm_fourcc.h:161:
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian */
-:72: WARNING:LONG_LINE_COMMENT: line over 100 characters
#72: FILE: include/uapi/drm/drm_fourcc.h:162:
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
-:78: WARNING:LONG_LINE_COMMENT: line over 100 characters
#78: FILE: include/uapi/drm/drm_fourcc.h:168:
+#define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /* [31:0]
X:V:Y:U 2:10:10:10 little endian */
-:79: WARNING:LONG_LINE_COMMENT: line over 100 characters
#79: FILE: include/uapi/drm/drm_fourcc.h:169:
+#define DRM_FORMAT_Y412 fourcc_code('Y', '4', '1', '2') /* [64:0]
X:x:V:x:Y:x:U:x 12:4:12:4:12:4:12:4 little endian */
-:80: WARNING:LONG_LINE_COMMENT: line over 100 characters
#80: FILE: include/uapi/drm/drm_fourcc.h:170:
+#define DRM_FORMAT_Y416 fourcc_code('Y', '4', '1', '6') /* [64:0]
X:V:Y:U 16:16:16:16 little endian */
total: 0 errors, 13 warnings, 0 checks, 36 lines checked
288965e797ac drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control
definitions
3aee6165af4c drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for
universal planes
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 133 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal planes
From: Swati Sharma
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/intel_display.c | 30 ++
drivers/gpu/drm/i915/intel_sprite.c | 61 ++--
2 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1cc441f..e7a86c6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2633,6 +2633,18 @@ int skl_format_to_fourcc(int format, bool rgb_order,
bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+ case PLANE_CTL_FORMAT_Y210:
+ return DRM_FORMAT_Y210;
+ case PLANE_CTL_FORMAT_Y212:
+ return DRM_FORMAT_Y212;
+ case PLANE_CTL_FORMAT_Y216:
+ return DRM_FORMAT_Y216;
+ case PLANE_CTL_FORMAT_Y410:
+ return DRM_FORMAT_Y410;
+ case PLANE_CTL_FORMAT_Y412:
+ return DRM_FORMAT_Y412;
+ case PLANE_CTL_FORMAT_Y416:
+ return DRM_FORMAT_Y416;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3529,6 +3541,18 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_Y210:
+ return PLANE_CTL_FORMAT_Y210;
+ case DRM_FORMAT_Y212:
+ return PLANE_CTL_FORMAT_Y212;
+ case DRM_FORMAT_Y216:
+ return PLANE_CTL_FORMAT_Y216;
+ case DRM_FORMAT_Y410:
+ return PLANE_CTL_FORMAT_Y410;
+ case DRM_FORMAT_Y412:
+ return PLANE_CTL_FORMAT_Y412;
+ case DRM_FORMAT_Y416:
+ return PLANE_CTL_FORMAT_Y416;
default:
MISSING_CASE(pixel_format);
}
@@ -5022,6 +5046,12 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
+ case DRM_FORMAT_Y410:
+ case DRM_FORMAT_Y412:
+ case DRM_FORMAT_Y416:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format
0x%x\n",
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 8f3982c..f1bc46d 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1750,6 +1750,27 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device
*dev, void *data,
DRM_FORMAT_VYUY,
};
+static const uint32_t icl_plane_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+ DRM_FORMAT_Y410,
+ DRM_FORMAT_Y412,
+ DRM_FORMAT_Y416,
+};
+
static const uint32_t skl_planar_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -1766,6 +1787,28 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device
*dev, void *data,
DRM_FORMAT_NV12,
};
+static const uint32_t icl_planar_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+ DRM_FORMAT_Y410,
+ DRM_FORMAT_Y412,
+ DRM_FORMAT_Y416,
+};
+
static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1904,6 +1947,12 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
+ case DRM_FORMAT_Y410:
+ case DRM_FORMAT_Y412:
+ case DRM_FORMAT_Y416:
case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
@@ -2045,8 +2094,16 @@ struct intel_plane *
plane->update_slave = icl_update_slave;
if (skl_plane_has_planar(dev_priv, pipe, plane_id)) {
- formats = skl_planar_formats;
- num_formats = ARRAY_SIZE(skl_planar_formats);
+
[Intel-gfx] [PATCH 1/3] drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
From: Swati Sharma
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies 32bit.
Y210: For each component, valid data occupies MSB 10 bits.
LSB 6 bits are filled with zeroes.
Y212: For each component, valid data occupies MSB 12 bits.
LSB 4 bits are filled with zeroes.
Y216: For each component valid data occupies 16 bits,
doesn't require any padding bits.
First 16 bits stores the Y value and the next 16 bits stores one
of the chroma samples alternatively. The first luma sample will
be accompanied by first U sample and second luma sample is
accompanied by the first V sample.
The following pixel formats are packed format that follows 4:4:4
chroma sampling. Channels are arranged in the order UYVA in
increasing memory order.
Y410: Each color component occupies 10 bits and X component
takes 2 bits, thus each pixel occupies 32 bits.
Y412: Each color component is 16 bits where valid data
occupies MSB 12 bits. LSB 4 bits are filled with zeroes.
Thus, each pixel occupies 64 bits.
Y416: Each color component occupies 16 bits for valid data,
doesn't require any padding bits. Thus, each pixel
occupies 64 bits.
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/drm_fourcc.c | 6 ++
include/uapi/drm/drm_fourcc.h | 18 +-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index d90ee03..639ab93 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -226,6 +226,12 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_XYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y410,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y412,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y416,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y0L0,.depth = 0,
.num_planes = 1,
.char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
.hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0b44260..97249a5 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -151,7 +151,23 @@
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
-#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /*
[31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0]
X:Y:Cb:Cr 8:8:8:8 little endian */
+
+/*
+ * packed Y2xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb
+ */
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian */
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian */
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
+
+/*
+ * packed Y4xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb except Y410
+ */
+#define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /* [31:0]
X:V:Y:U 2:10:10:10 little endian */
+#define DRM_FORMAT_Y412 fourcc_code('Y', '4', '1', '2') /* [64:0]
X:x:V:x:Y:x:U:x 12:4:12:4:12:4:12:4 little endian */
+#define DRM_FORMAT_Y416 fourcc_code('Y', '4', '1', '6') /* [64:0]
X:V:Y:U 16:16:16:16 little endian */
[Intel-gfx] [PATCH 2/3] drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions
From: Swati Sharma
Added needed plane control flag definitions for Y2xx and Y4xx (10, 12 and
16 bits)
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 44958d9..7150bc5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6546,6 +6546,12 @@ enum {
#define PLANE_CTL_FORMAT_RGB_565 (14 << 24)
#define ICL_PLANE_CTL_FORMAT_MASK(0x1f << 23)
#define PLANE_CTL_PIPE_CSC_ENABLE(1 << 23) /* Pre-GLK */
+#define PLANE_CTL_FORMAT_Y210 (1 << 23)
+#define PLANE_CTL_FORMAT_Y212 (3 << 23)
+#define PLANE_CTL_FORMAT_Y216 (5 << 23)
+#define PLANE_CTL_FORMAT_Y410 (7 << 23)
+#define PLANE_CTL_FORMAT_Y412 (9 << 23)
+#define PLANE_CTL_FORMAT_Y416 (0xb << 23)
#define PLANE_CTL_KEY_ENABLE_MASK(0x3 << 21)
#define PLANE_CTL_KEY_ENABLE_SOURCE (1 << 21)
#define PLANE_CTL_KEY_ENABLE_DESTINATION (2 << 21)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] Enable Y2xx and Y4xx (xx:10/12/16 bits) packed formats for ICL
From: Swati Sharma These patches enable packed format YUV422-Y210, Y212 and Y216 and YUV444-Y410, Y412, Y416 for 10, 12 and 16 bits for ICL+. IGT needs libraries for Pixman and Cairo to support more than 8bpc. Work going on from Maarten Lankhorst. Initial review for Y2xx done https://patchwork.freedesktop.org/series/48729/ However, submitting new patch series consolidating Y2xx and Y4xx. Swati Sharma (3): drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal planes drivers/gpu/drm/drm_fourcc.c | 6 drivers/gpu/drm/i915/i915_reg.h | 6 drivers/gpu/drm/i915/intel_display.c | 30 ++ drivers/gpu/drm/i915/intel_sprite.c | 61 ++-- include/uapi/drm/drm_fourcc.h| 18 ++- 5 files changed, 118 insertions(+), 3 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for MST refcounting/atomic helpers cleanup (rev6)
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev6)
URL : https://patchwork.freedesktop.org/series/54030/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5396_full -> Patchwork_11275_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11275_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11275_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_11275_full:
### IGT changes ###
Warnings
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite:
- shard-hsw: PASS -> {SKIP}
Known issues
Here are the changes found in Patchwork_11275_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_cpu_reloc@full:
- shard-skl: PASS -> TIMEOUT [fdo#108248]
* igt@gem_exec_schedule@pi-ringfull-bsd:
- shard-iclb: NOTRUN -> FAIL [fdo#103158]
- shard-skl: NOTRUN -> FAIL [fdo#103158] +1
* igt@gem_exec_schedule@pi-ringfull-vebox:
- shard-kbl: NOTRUN -> FAIL [fdo#103158]
* igt@gem_exec_whisper@normal:
- shard-skl: NOTRUN -> TIMEOUT [fdo#108592]
* igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-skl: PASS -> TIMEOUT [fdo#108039]
* igt@gem_userptr_blits@readonly-unsync:
- shard-skl: PASS -> TIMEOUT [fdo#108887]
* igt@gem_workarounds@suspend-resume:
- shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]
* igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +3
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-hang-newfb-render-b:
- shard-glk: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic:
- shard-iclb: NOTRUN -> FAIL [fdo#107725]
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-iclb: NOTRUN -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-64x64-dpms:
- shard-skl: PASS -> FAIL [fdo#103232] +1
* igt@kms_draw_crc@fill-fb:
- shard-skl: PASS -> FAIL [fdo#103184]
* igt@kms_fbcon_fbt@psr:
- shard-skl: NOTRUN -> FAIL [fdo#107882]
* igt@kms_flip@flip-vs-expired-vblank:
- shard-glk: PASS -> FAIL [fdo#105363]
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: PASS -> FAIL [fdo#105363]
* igt@kms_flip_tiling@flip-changes-tiling-yf:
- shard-skl: NOTRUN -> FAIL [fdo#108228] / [fdo#108303]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu:
- shard-skl: NOTRUN -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-pwrite:
- shard-skl: PASS -> FAIL [fdo#103167] / [fdo#105682]
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-wc:
- shard-skl: PASS -> FAIL [fdo#105682]
* igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-skl: NOTRUN -> FAIL [fdo#105683]
* igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
- shard-iclb: PASS -> FAIL [fdo#105683] / [fdo#108040]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-pwrite:
- shard-skl: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-blt:
- shard-iclb: PASS -> FAIL [fdo#103167] +2
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- shard-skl: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-iclb: NOTRUN -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +4
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-iclb: PASS -> FAIL [fdo#103166] +2
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@pm_rpm@cursor-dpms:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724] +1
* igt@pm_rpm@universal-planes:
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/4] tests/gem_media_vme: Simple test to exercise the VME block
On 1/10/2019 10:02 PM, Michał Winiarski wrote: On Tue, Jan 08, 2019 at 03:13:02PM +, Tvrtko Ursulin wrote: From: Tony Ye Simple test which exercises the VME fixed function block. v2: (Tvrtko Ursulin) * Small cleanups like copyright date, tabs, remove unused bits. v3: (Tony Ye) * Added curbe data entry for dst surface. * Read the dst surface after the VME kernel being executed. v4: (Tony Ye) * Added the media_vme.gxa kernel source code and compile instructions. v5: (Tvrtko Ursulin) * Added hang detector. v6: (Tvrtko Ursulin) * Replace gem_read with gem_sync. (Chris Wilson) Signed-off-by: Tony Ye Signed-off-by: Tvrtko Ursulin Cc: Tony Ye Reviewed-by: Joonas Lahtinen --- lib/gpu_cmds.c | 136 lib/gpu_cmds.h | 20 ++- lib/i915/shaders/media/README_media_vme.txt | 65 ++ lib/i915/shaders/media/media_vme.gxa| 51 lib/intel_batchbuffer.c | 9 ++ lib/intel_batchbuffer.h | 7 + lib/media_fill.c| 110 lib/media_fill.h| 6 + lib/surfaceformat.h | 2 + tests/Makefile.sources | 3 + tests/i915/gem_media_vme.c | 117 + tests/meson.build | 1 + 12 files changed, 525 insertions(+), 2 deletions(-) create mode 100755 lib/i915/shaders/media/README_media_vme.txt create mode 100755 lib/i915/shaders/media/media_vme.gxa create mode 100644 tests/i915/gem_media_vme.c diff --git a/lib/i915/shaders/media/README_media_vme.txt b/lib/i915/shaders/media/README_media_vme.txt new file mode 100755 index ..2470fdd89825 --- /dev/null +++ b/lib/i915/shaders/media/README_media_vme.txt @@ -0,0 +1,65 @@ +Step1: Building IGA (Intel Graphics Assembler) + + +1. Download or clone IGC (Intel Graphics Compiler) + + https://github.com/intel/intel-graphics-compiler.git + +2. Chdir into 'intel-graphics-compiler' (or any other workspace folder of choice) + + It should read the following folder strucutre: + + workspace + |- visa + |- IGC + |- inc + |- 3d + |- skuwa + +3. Chdir into IGA sub-component + + cd visa/iga + +4. Create build directory + +mkdir build + +5. Change into build directory + +cd build + +6. Run cmake + + cmake ../ + +7. Run make to build IGA project + + make + +8. Get the output executable "iga64" in IGAExe folder + + usage: ./iga64 OPTIONS ARGS + where OPTIONS: + -h --help shows help on an option + -d --disassemble disassembles the input file + -a --assemble assembles the input file + -n --numeric-labels use numeric labels + -p --platformDEVICE specifies the platform (e.g. "GEN9") + -o --output FILE specifies the output file + + EXAMPLES: + ./iga64 file.gxa -p=11 -a -o file.krn + +Step2: Building ASM code + +1. Command line to convert asm code to binary: + + iga64 media_vme.gxa -p=11 -a -o media_vme.krn + +2. Pad 128 bytes zeros to the kernel: + + dd if=/dev/zero bs=1 count=128 >> media_vme.krn Why we're padding it with 128B zeroes? We don't seem to do that for any other shaders. Could you modify this instruction to use lib/i915/shaders/converter.py and rather than adding yet another README, update lib/i915/shaders/README instead? -Michał Padding 128 bytes of zeros are required by Gen HW. It is required for all shaders unless your compiler did it quietly. It makes sense to combine the instructions into lib/i915/shaders/README and use existing python script to dump hex. But the README seems to be outdated. I could not find intel-gen4asm when I follow the instructions to build intel-graphics-compiler. Can you update the README firstly to make it workable with latest https://github.com/intel/intel-graphics-compiler? Regards, --Tony + +3. Generate hexdump: + + hexdump -v -e '4/4 "0x%08x " "\n"' media_vme.krn > media_vme.hex ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On Mon, 2019-01-07 at 16:58 +, Tvrtko Ursulin wrote: > On 07/01/2019 13:57, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-01-07 13:43:29) > > > > > > On 07/01/2019 11:58, Tvrtko Ursulin wrote: > > > > > > [snip] > > > > > > > > Note about future interaction with preemption: Preemption > > > > > could happen > > > > > in a command sequence prior to watchdog counter getting > > > > > disabled, > > > > > resulting in watchdog being triggered following preemption > > > > > (e.g. when > > > > > watchdog had been enabled in the low priority batch). The > > > > > driver will > > > > > need to explicitly disable the watchdog counter as part of > > > > > the > > > > > preemption sequence. > > > > > > > > Does the series take care of preemption? > > > > > > I did not find that it does. > > > > Oh. I hoped that the watchdog was saved as part of the context... > > Then > > despite preemption, the timeout would resume from where we left off > > as > > soon as it was back on the gpu. > > > > If the timeout remaining was context saved it would be much simpler > > (at > > least on first glance), please say it is. The watchdog timeout gets saved as part of the register state context so it will still be enabled after coming back from preemption but the timeout value will be reset back to the original MAX value that it was programmed. At least that's what I remember from a discussion with Michel but I can check again... Regards, Carlos > > I made my comments going only by the text from the commit message > and > the absence of any preemption special handling. > > Having read the spec, the situation seems like this: > > * Watchdog control and threshold register are context saved and > restored. > > * On a context switch watchdog counter is reset to zero and > automatically disabled until enabled by a context restore or > explicitly. > > So it sounds the commit message could be wrong that special handling > is > needed from this direction. But read till the end on the restriction > listed. > > * Watchdog counter is reset to zero and is not accumulated across > multiple submission of the same context (due preemption). > > I read this as - after preemption contexts gets a new full timeout > allocation. Or in other words, if a context is preempted N times, > it's > cumulative watchdog timeout will be N * set value. > > This could be theoretically exploitable to bypass the timeout. If a > client sets up two contexts with prio -1 and -2, and keeps > submitting > periodical no-op batches against prio -1 context, while prio -2 is > it's > own hog, then prio -2 context defeats the watchdog timer. I think.. > would appreciate is someone challenged this conclusion. > > And finally there is one programming restriction which says: > > * SW must not preempt the workload which has watchdog enabled. > Either > it must: > > a) disable preemption for that workload completely, or > b) disable the watchdog via mmio write before any write to ELSP > > This seems it contradiction with the statement that the counter gets > disabled on context switch and stays disabled. > > I did not spot anything like this in the series. So it would seem > the > commit message is correct after all. > > It would be good if someone could re-read the bspec text on register > 0x2178 to double check what I wrote. > > Regards, > > Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915/watchdog: move emit_stop_watchdog until the very end of the ring commands
On Mon, 2019-01-07 at 12:50 +, Tvrtko Ursulin wrote:
> On 05/01/2019 02:40, Carlos Santa wrote:
> > From: Michel Thierry
> >
> > On command streams that could potentially hang the GPU after a last
> > flush command, it's best not to cancel the watchdog
> > until after all commands have executed.
> >
> > Patch shared by Michel Thierry through IIRC after reproduction on
>
> Joonas pointed out on IRC that IRC is called IRC. :)
>
> > my local setup.
> >
> > Tested-by: Carlos Santa
> > CC: Antonio Argenziano
> > Cc: Tvrtko Ursulin
> > Signed-off-by: Michel Thierry
> > Signed-off-by: Carlos Santa
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 53
> > +++-
> > 1 file changed, 45 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 0afcbeb18329..25ba5fcc9466 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1885,8 +1885,8 @@ static int gen8_emit_bb_start(struct
> > i915_request *rq,
> > GEM_BUG_ON(!engine->emit_start_watchdog ||
> >!engine->emit_stop_watchdog);
> >
> > - /* + start_watchdog (6) + stop_watchdog (4) */
> > - num_dwords += 10;
> > + /* + start_watchdog (6) */
> > + num_dwords += 6;
> > watchdog_running = true;
> > }
> >
> > @@ -1927,10 +1927,7 @@ static int gen8_emit_bb_start(struct
> > i915_request *rq,
> > *cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
> > *cs++ = MI_NOOP;
> >
> > - if (watchdog_running) {
> > - /* Cancel watchdog timer */
> > - cs = engine->emit_stop_watchdog(rq, cs);
> > - }
> > + // XXX: emit_stop_watchdog happens in gen8_emit_breadcrumb_vcs
>
> No C++ comments please. And what does XXX mean? Doesn't feel like it
> belongs.
>
> >
> > intel_ring_advance(rq, cs);
> > return 0;
> > @@ -2189,6 +2186,37 @@ static void gen8_emit_breadcrumb(struct
> > i915_request *request, u32 *cs)
> > }
> > static const int gen8_emit_breadcrumb_sz = 6 + WA_TAIL_DWORDS;
> >
> > +static void gen8_emit_breadcrumb_vcs(struct i915_request *request,
> > u32 *cs)
> > +{
> > + /* w/a: bit 5 needs to be zero for MI_FLUSH_DW address. */
> > + BUILD_BUG_ON(I915_GEM_HWS_INDEX_ADDR & (1 << 5));
> > +
> > + cs = gen8_emit_ggtt_write(cs, request->global_seqno,
> > + intel_hws_seqno_address(request-
> > >engine));
> > + *cs++ = MI_USER_INTERRUPT;
> > + *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
> > +
> > + // stop_watchdog at the very end of the ring commands
> > + if (request->gem_context->__engine[VCS].watchdog_threshold !=
> > 0)
>
> VCS is wrong. Whole check needs to be to_intel_context(ctx,
> engine)->watchdog_threshold I think.
>
> > + {
> > + /* Cancel watchdog timer */
> > + GEM_BUG_ON(!request->engine->emit_stop_watchdog);
> > + cs = request->engine->emit_stop_watchdog(request, cs);
> > + }
> > + else
> > + {
>
> Coding style is wrong (curly braces for if else).
>
> > + *cs++ = MI_NOOP;
> > + *cs++ = MI_NOOP;
> > + *cs++ = MI_NOOP;
> > + *cs++ = MI_NOOP;
> > + }
> > +
> > + request->tail = intel_ring_offset(request, cs);
> > + assert_ring_tail_valid(request->ring, request->tail);
> > + gen8_emit_wa_tail(request, cs);
> > +}
> > +static const int gen8_emit_breadcrumb_vcs_sz = 6 + WA_TAIL_DWORDS
> > + 4; //+4 for optional stop_watchdog
> > +
> > static void gen8_emit_breadcrumb_rcs(struct i915_request
> > *request, u32 *cs)
> > {
> > /* We're using qword write, seqno should be aligned to 8 bytes.
> > */
> > @@ -2306,8 +2334,17 @@ logical_ring_default_vfuncs(struct
> > intel_engine_cs *engine)
> > engine->request_alloc = execlists_request_alloc;
> >
> > engine->emit_flush = gen8_emit_flush;
> > - engine->emit_breadcrumb = gen8_emit_breadcrumb;
> > - engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_sz;
> > +
> > + if (engine->id == VCS || engine->id == VCS2)
>
> What about VCS3 or 4? Hint use engine class.
>
> And what about RCS and VECS?
>
> > + {
> > + engine->emit_breadcrumb = gen8_emit_breadcrumb_vcs;
> > + engine->emit_breadcrumb_sz =
> > gen8_emit_breadcrumb_vcs_sz;
> > + }
> > + else
> > + {
> > + engine->emit_breadcrumb = gen8_emit_breadcrumb;
> > + engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_sz;
> > + }
> >
> > engine->set_default_submission =
> > intel_execlists_set_default_submission;
> >
> >
>
> Looks like the patch should be squashed with the one which
> implements
> watchdog emit start/end? I mean if the whole setup has broken edge
> cases
> without this..
Ok, I'll rework the above and squash it with the watchdog emit/start
patch
thx, CS
>
> Regards,
>
> Tvrtko
___
Intel-gfx mailing list
Intel-gfx@l
[Intel-gfx] ✓ Fi.CI.BAT: success for MST refcounting/atomic helpers cleanup (rev7)
== Series Details == Series: MST refcounting/atomic helpers cleanup (rev7) URL : https://patchwork.freedesktop.org/series/54030/ State : success == Summary == CI Bug Log - changes from CI_DRM_5400 -> Patchwork_11278 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/54030/revisions/7/mbox/ Known issues Here are the changes found in Patchwork_11278 that come from known issues: ### IGT changes ### Issues hit * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] Possible fixes * igt@kms_frontbuffer_tracking@basic: - fi-byt-clapper: FAIL [fdo#103167] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 Participating hosts (47 -> 43) -- Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan Build changes - * Linux: CI_DRM_5400 -> Patchwork_11278 CI_DRM_5400: 4982584021f0b046841f196efc25735bd71ebdcf @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4759: 478452fece3997dfacaa4d6babe6b8bf6fef784f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11278: 7058ad33b999acee846993440df70c8759da6c5e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7058ad33b999 drm/nouveau: Use atomic VCPI helpers for MST 96f08bd75cd3 drm/dp_mst: Check payload count in drm_dp_mst_atomic_check() 6dc4e60a7f77 drm/dp_mst: Start tracking per-port VCPI allocations 9f0550204390 drm/dp_mst: Add some atomic state iterator macros 9d1a374f3b0a drm/nouveau: Grab payload lock in nv50_msto_payload() fb2916eaf801 drm/nouveau: Stop unsetting mstc->port, use malloc refs f6bc6e58cb36 drm/nouveau: Keep malloc references to MST ports fa65fc6573ef drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup() e22b33d521e3 drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector() 1659ca4c5976 drm/amdgpu/display: Keep malloc ref to MST port 1215e951d338 drm/i915: Keep malloc references to MST ports f44216dab40f drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs 5432def72627 drm/dp_mst: Stop releasing VCPI when removing ports from topology 33ed2b8bf69c drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails f3167088bed1 drm/dp_mst: Introduce new refcounting scheme for mstbs and ports 48650b1b91ef drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends 3e64f7a83561 drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi() bab922f7f6c4 drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi() 5613e665e2e0 drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg() 4dc81bd3d040 drm/dp_mst: Fix some formatting in drm_dp_add_port() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11278/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/21] drm/i915/dp: Markup pps lock power well
Quoting John Harrison (2019-01-11 00:16:16)
> On 1/10/2019 02:11, Chris Wilson wrote:
> > Track where and when we acquire and release the power well for pps
> > access along the dp aux link, with a view to detecting if we leak any
> > wakerefs.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Jani Nikula
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 231 +---
> > 1 file changed, 121 insertions(+), 110 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index fc85fd77a661..db0f3a4402f5 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -601,30 +601,39 @@ intel_dp_init_panel_power_sequencer_registers(struct
> > intel_dp *intel_dp,
> > static void
> > intel_dp_pps_init(struct intel_dp *intel_dp);
> >
> > -static void pps_lock(struct intel_dp *intel_dp)
> > +static intel_wakeref_t
> > +pps_lock(struct intel_dp *intel_dp)
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> Any particular reason for leaving these as dev_priv when the earlier
> patches converted everything in sight to i915?
It usually meant I hit a I915_READ early on that dissuaded me from
trying to sneak the change in, or that I didn't think it was going to be
as large a conversion as it turned out to be. So no reason other than
reticence.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for MST refcounting/atomic helpers cleanup (rev7)
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev7)
URL : https://patchwork.freedesktop.org/series/54030/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4dc81bd3d040 drm/dp_mst: Fix some formatting in drm_dp_add_port()
5613e665e2e0 drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg()
bab922f7f6c4 drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi()
3e64f7a83561 drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi()
48650b1b91ef drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and
friends
-:84: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#84: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:990:
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
-:102: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#102: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1006:
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
-:150: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#150: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1379:
+ mstb_child = drm_dp_mst_topology_get_mstb_validated(
total: 0 errors, 0 warnings, 3 checks, 401 lines checked
f3167088bed1 drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
-:27: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#27:
commit 263efde31f97 ("drm/dp/mst: Get validated port ref in
drm_dp_update_payload_part1()")
-:51: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 9765635b3075 ("Revert
"drm/dp_mst: Skip validating ports during destruction, just ref"")'
#51:
commit 9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during
destruction, just ref"")
-:142: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#142:
new file mode 100644
-:848: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#848: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1330:
+ mport = drm_dp_mst_topology_get_port_validated_locked(
-:862: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#862: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1347:
+ rport = drm_dp_mst_topology_get_port_validated_locked(
total: 1 errors, 2 warnings, 2 checks, 916 lines checked
33ed2b8bf69c drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref
fails
5432def72627 drm/dp_mst: Stop releasing VCPI when removing ports from topology
f44216dab40f drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
-:97: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#97: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:2269:
+ port = drm_dp_mst_topology_get_port_validated(
total: 0 errors, 0 warnings, 1 checks, 124 lines checked
1215e951d338 drm/i915: Keep malloc references to MST ports
1659ca4c5976 drm/amdgpu/display: Keep malloc ref to MST port
e22b33d521e3 drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector()
-:13: WARNING:BAD_SIGN_OFF: 'Reviewed-by:' is the preferred signature form
#13:
Reviewed-By: Ben Skeggs
total: 0 errors, 1 warnings, 0 checks, 12 lines checked
fa65fc6573ef drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup()
-:20: WARNING:BAD_SIGN_OFF: 'Reviewed-by:' is the preferred signature form
#20:
Reviewed-By: Ben Skeggs
total: 0 errors, 1 warnings, 0 checks, 23 lines checked
f6bc6e58cb36 drm/nouveau: Keep malloc references to MST ports
-:19: WARNING:BAD_SIGN_OFF: 'Reviewed-by:' is the preferred signature form
#19:
Reviewed-By: Ben Skeggs
total: 0 errors, 1 warnings, 0 checks, 25 lines checked
fb2916eaf801 drm/nouveau: Stop unsetting mstc->port, use malloc refs
-:12: WARNING:BAD_SIGN_OFF: 'Reviewed-by:' is the preferred signature form
#12:
Reviewed-By: Ben Skeggs
total: 0 errors, 1 warnings, 0 checks, 54 lines checked
9d1a374f3b0a drm/nouveau: Grab payload lock in nv50_msto_payload()
-:12: WARNING:BAD_SIGN_OFF: 'Reviewed-by:' is the preferred signature form
#12:
Reviewed-By: Ben Skeggs
total: 0 errors, 1 warnings, 0 checks, 25 lines checked
9f0550204390 drm/dp_mst: Add some atomic state iterator macros
-:110: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__state' - possible
side-effects?
#110: FILE: include/drm/drm_dp_mst_helper.h:711:
+#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state,
__i) \
+ for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+ for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr),
&(old_state), &(new_state), (__i)))
-:110: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i' - possible
side-effects?
#110: FILE: include/drm/drm_dp_mst_helper.h:711:
+#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state,
__i) \
+ for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+ for_each_if(__drm_dp_mst_state_iter_get((__state
[Intel-gfx] [PATCH v7 12/20] drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector()
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
Reviewed-By: Ben Skeggs
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index bc06aa79363f..800213be76ea 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1098,11 +1098,8 @@ nv50_mstm_add_connector(struct drm_dp_mst_topology_mgr
*mgr,
int ret;
ret = nv50_mstc_new(mstm, port, path, &mstc);
- if (ret) {
- if (mstc)
- mstc->connector.funcs->destroy(&mstc->connector);
+ if (ret)
return NULL;
- }
return &mstc->connector;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 18/20] drm/dp_mst: Start tracking per-port VCPI allocations
There has been a TODO waiting for quite a long time in drm_dp_mst_topology.c: /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent * branch device was unplugged. This should be fixed by tracking * per-port slot allocation in drm_dp_mst_topology_state instead of * depending on the caller to tell us how many slots to release. */ That's not the only reason we should fix this: forcing the driver to track the VCPI allocations throughout a state's atomic check is error prone, because it means that extra care has to be taken with the order that drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release_vcpi_slots() are called in in order to ensure idempotency. Currently the only driver actually using these helpers, i915, doesn't even do this correctly: multiple ->best_encoder() checks with i915's current implementation would not be idempotent and would over-allocate VCPI slots, something I learned trying to implement fallback retraining in MST. So: simplify this whole mess, and teach drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release_vcpi_slots() to track the VCPI allocations for each port. This allows us to ensure idempotency without having to rely on the driver as much. Additionally: the driver doesn't need to do any kind of VCPI slot tracking anymore if it doesn't need it for it's own internal state. Additionally; this adds a new drm_dp_mst_atomic_check() helper which must be used by atomic drivers to perform validity checks for the new VCPI allocations incurred by a state. Also: update the documentation and make it more obvious that these /must/ be called by /all/ atomic drivers supporting MST. Changes since v9: * Add some missing changes that were requested by danvet that I forgot about after I redid all of the kref stuff: * Remove unnecessary state changes in intel_dp_mst_atomic_check * Cleanup atomic check logic for VCPI allocations - all we need to check in compute_config is whether or not this state disables a CRTC, then free VCPI based off that Changes since v8: * Fix compile errors, whoops! Changes since v7: - Don't check for mixed stale/valid VCPI allocations, just rely on connector registration to stop such erroneous modesets Changes since v6: - Keep a kref to all of the ports we have allocations on. This required a good bit of changing to when we call drm_dp_find_vcpi_slots(), mainly that we need to ensure that we only redo VCPI allocations on actual mode or CRTC changes, not crtc_state->active changes. Additionally, we no longer take the registration of the DRM connector for each port into account because so long as we have a kref to the port in the new or previous atomic state, the connector will stay registered. - Use the small changes to drm_dp_put_port() to add even more error checking to make misusage of the helpers more obvious. I added this after having to chase down various use-after-free conditions that started popping up from the new helpers so no one else has to troubleshoot that. - Move some accidental DRM_DEBUG_KMS() calls to DRM_DEBUG_ATOMIC() - Update documentation again, note that find/release() should both not be called on the same port in a single atomic check phase (but multiple calls to one or the other is OK) Changes since v4: - Don't skip the atomic checks for VCPI allocations if no new VCPI allocations happen in a state. This makes the next change I'm about to list here a lot easier to implement. - Don't ignore VCPI allocations on destroyed ports, instead ensure that when ports are destroyed and still have VCPI allocations in the topology state, the only state changes allowed are releasing said ports' VCPI. This prevents a state with a mix of VCPI allocations from destroyed ports, and allocations from valid ports. Changes since v3: - Don't release VCPI allocations in the topology state immediately in drm_dp_atomic_release_vcpi_slots(), instead mark them as 0 and skip over them in drm_dp_mst_duplicate_state(). This makes it so drm_dp_atomic_release_vcpi_slots() is still idempotent while also throwing warnings if the driver messes up it's book keeping and tries to release VCPI slots on a port that doesn't have any pre-existing VCPI allocation - danvet - Change mst_state/state in some debugging messages to "mst state" Changes since v2: - Use kmemdup() for duplicating MST state - danvet - Move port validation out of duplicate state callback - danvet - Handle looping through MST topology states in drm_dp_mst_atomic_check() so the driver doesn't have to do it - Fix documentation in drm_dp_atomic_find_vcpi_slots() - Move the atomic check for each individual topology state into it's own function, reduces indenting - Don't consider "stale" MST ports when calculating the bandwidth requirements. This is needed because originally we reli
[Intel-gfx] [PATCH v7 15/20] drm/nouveau: Stop unsetting mstc->port, use malloc refs
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
Reviewed-By: Ben Skeggs
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 15f378902fcb..6f8a54e81727 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -708,8 +708,7 @@ nv50_msto_cleanup(struct nv50_msto *msto)
NV_ATOMIC(drm, "%s: msto cleanup\n", msto->encoder.name);
- if (mstc->port)
- drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
+ drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
msto->mstc = NULL;
msto->head = NULL;
@@ -734,7 +733,7 @@ nv50_msto_prepare(struct nv50_msto *msto)
};
NV_ATOMIC(drm, "%s: msto prepare\n", msto->encoder.name);
- if (mstc->port && mstc->port->vcpi.vcpi > 0) {
+ if (mstc->port->vcpi.vcpi > 0) {
struct drm_dp_payload *payload = nv50_msto_payload(msto);
if (payload) {
args.vcpi.start_slot = payload->start_slot;
@@ -831,8 +830,7 @@ nv50_msto_disable(struct drm_encoder *encoder)
struct nv50_mstc *mstc = msto->mstc;
struct nv50_mstm *mstm = mstc->mstm;
- if (mstc->port)
- drm_dp_mst_reset_vcpi_slots(&mstm->mgr, mstc->port);
+ drm_dp_mst_reset_vcpi_slots(&mstm->mgr, mstc->port);
mstm->outp->update(mstm->outp, msto->head->base.index, NULL, 0, 0);
mstm->modified = true;
@@ -944,7 +942,7 @@ nv50_mstc_detect(struct drm_connector *connector, bool
force)
enum drm_connector_status conn_status;
int ret;
- if (!mstc->port)
+ if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
ret = pm_runtime_get_sync(connector->dev->dev);
@@ -965,8 +963,7 @@ nv50_mstc_destroy(struct drm_connector *connector)
struct nv50_mstc *mstc = nv50_mstc(connector);
drm_connector_cleanup(&mstc->connector);
- if (mstc->port)
- drm_dp_mst_put_port_malloc(mstc->port);
+ drm_dp_mst_put_port_malloc(mstc->port);
kfree(mstc);
}
@@ -1080,11 +1077,6 @@ nv50_mstm_destroy_connector(struct
drm_dp_mst_topology_mgr *mgr,
drm_fb_helper_remove_one_connector(&drm->fbcon->helper,
&mstc->connector);
- drm_modeset_lock(&drm->dev->mode_config.connection_mutex, NULL);
- drm_dp_mst_put_port_malloc(mstc->port);
- mstc->port = NULL;
- drm_modeset_unlock(&drm->dev->mode_config.connection_mutex);
-
drm_connector_put(&mstc->connector);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 19/20] drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 88db6d7e1a36..196ebba8af5f 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3641,7 +3641,7 @@ drm_dp_mst_atomic_check_topology_state(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state
*mst_state)
{
struct drm_dp_vcpi_allocation *vcpi;
- int avail_slots = 63;
+ int avail_slots = 63, payload_count = 0;
list_for_each_entry(vcpi, &mst_state->vcpis, next) {
/* Releasing VCPI is always OK-even if the port is gone */
@@ -3661,6 +3661,12 @@ drm_dp_mst_atomic_check_topology_state(struct
drm_dp_mst_topology_mgr *mgr,
avail_slots + vcpi->vcpi);
return -ENOSPC;
}
+
+ if (++payload_count > mgr->max_payloads) {
+ DRM_DEBUG_ATOMIC("[MST MGR:%p] state %p has too many
payloads (max=%d)\n",
+mgr, mst_state, mgr->max_payloads);
+ return -EINVAL;
+ }
}
DRM_DEBUG_ATOMIC("[MST MGR:%p] mst state %p VCPI avail=%d used=%d\n",
mgr, mst_state, avail_slots,
--
2.20.1
___
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/i915/cnl: Fix CNL macros for Voltage Swing programming (rev2)
== Series Details == Series: drm/i915/cnl: Fix CNL macros for Voltage Swing programming (rev2) URL : https://patchwork.freedesktop.org/series/54092/ State : success == Summary == CI Bug Log - changes from CI_DRM_5400 -> Patchwork_11277 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/54092/revisions/2/mbox/ Known issues Here are the changes found in Patchwork_11277 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] Possible fixes * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: FAIL [fdo#108767] -> PASS [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767 Participating hosts (47 -> 41) -- Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-icl-y Build changes - * Linux: CI_DRM_5400 -> Patchwork_11277 CI_DRM_5400: 4982584021f0b046841f196efc25735bd71ebdcf @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4759: 478452fece3997dfacaa4d6babe6b8bf6fef784f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11277: 8b810fada4b5414a7d0aff0b90ada0bb178ccaee @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8b810fada4b5 drm/i915/cnl: Fix CNL macros for Voltage Swing programming == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11277/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 17/20] drm/dp_mst: Add some atomic state iterator macros
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 5 +-
include/drm/drm_dp_mst_helper.h | 96 +++
2 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index b5976f8c318c..e3497bc49494 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3521,10 +3521,11 @@ static void drm_dp_mst_destroy_state(struct
drm_private_obj *obj,
kfree(mst_state);
}
-static const struct drm_private_state_funcs mst_state_funcs = {
+const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs = {
.atomic_duplicate_state = drm_dp_mst_duplicate_state,
.atomic_destroy_state = drm_dp_mst_destroy_state,
};
+EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
/**
* drm_atomic_get_mst_topology_state: get MST topology state
@@ -3608,7 +3609,7 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
drm_atomic_private_obj_init(dev, &mgr->base,
&mst_state->base,
- &mst_state_funcs);
+ &drm_dp_mst_topology_state_funcs);
return 0;
}
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 70ec452f2a47..fa533571b16c 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -651,4 +651,100 @@ int drm_dp_send_power_updown_phy(struct
drm_dp_mst_topology_mgr *mgr,
void drm_dp_mst_get_port_malloc(struct drm_dp_mst_port *port);
void drm_dp_mst_put_port_malloc(struct drm_dp_mst_port *port);
+extern const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs;
+
+/**
+ * __drm_dp_mst_state_iter_get - private atomic state iterator function for
+ * macro-internal use
+ * @state: &struct drm_atomic_state pointer
+ * @mgr: pointer to the &struct drm_dp_mst_topology_mgr iteration cursor
+ * @old_state: optional pointer to the old &struct drm_dp_mst_topology_state
+ * iteration cursor
+ * @new_state: optional pointer to the new &struct drm_dp_mst_topology_state
+ * iteration cursor
+ * @i: int iteration cursor, for macro-internal use
+ *
+ * Used by for_each_oldnew_mst_mgr_in_state(),
+ * for_each_old_mst_mgr_in_state(), and for_each_new_mst_mgr_in_state(). Don't
+ * call this directly.
+ *
+ * Returns:
+ * True if the current &struct drm_private_obj is a &struct
+ * drm_dp_mst_topology_mgr, false otherwise.
+ */
+static inline bool
+__drm_dp_mst_state_iter_get(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr **mgr,
+ struct drm_dp_mst_topology_state **old_state,
+ struct drm_dp_mst_topology_state **new_state,
+ int i)
+{
+ struct __drm_private_objs_state *objs_state = &state->private_objs[i];
+
+ if (objs_state->ptr->funcs != &drm_dp_mst_topology_state_funcs)
+ return false;
+
+ *mgr = to_dp_mst_topology_mgr(objs_state->ptr);
+ if (old_state)
+ *old_state = to_dp_mst_topology_state(objs_state->old_state);
+ if (new_state)
+ *new_state = to_dp_mst_topology_state(objs_state->new_state);
+
+ return true;
+}
+
+/**
+ * for_each_oldnew_mst_mgr_in_state - iterate over all DP MST topology
+ * managers in an atomic update
+ * @__state: &struct drm_atomic_state pointer
+ * @mgr: &struct drm_dp_mst_topology_mgr iteration cursor
+ * @old_state: &struct drm_dp_mst_topology_state iteration cursor for the old
+ * state
+ * @new_state: &struct drm_dp_mst_topology_state iteration cursor for the new
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in an atomic update,
+ * tracking both old and new state. This is useful in places where the state
+ * delta needs to be considered, for example in atomic check functions.
+ */
+#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state,
__i) \
+ for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+ for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr),
&(old_state), &(new_state), (__i)))
+
+/**
+ * for_each_old_mst_mgr_in_state - iterate over all DP MST topology managers
+ * in an atomic update
+ * @__state: &struct drm_atomic_state pointer
+ * @mgr: &struct drm_dp_mst_topology_mgr iteration cursor
+ * @old_state: &struct drm_dp_mst_topology_state iteration cursor for the old
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in
[Intel-gfx] [PATCH v7 09/20] drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
Up until now, freeing payloads on remote MST hubs that just had ports
removed has almost never worked because we've been relying on port
validation in order to stop us from accessing ports that have already
been freed from memory, but ports which need their payloads released due
to being removed will never be a valid part of the topology after
they've been removed.
Since we've introduced malloc refs, we can replace all of the validation
logic in payload helpers which are used for deallocation with some
well-placed malloc krefs. This ensures that regardless of whether or not
the ports are still valid and in the topology, any port which has an
allocated payload will remain allocated in memory until it's payloads
have been removed - finally allowing us to actually release said
payloads correctly.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Reviewed-by: Harry Wentland
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 54 +++
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index bb9107852fed..b5976f8c318c 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2095,10 +2095,6 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
u8 sinks[DRM_DP_MAX_SDP_STREAMS];
int i;
- port = drm_dp_mst_topology_get_port_validated(mgr, port);
- if (!port)
- return -EINVAL;
-
port_num = port->port_num;
mstb = drm_dp_mst_topology_get_mstb_validated(mgr, port->parent);
if (!mstb) {
@@ -2106,10 +2102,8 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
port->parent,
&port_num);
- if (!mstb) {
- drm_dp_mst_topology_put_port(port);
+ if (!mstb)
return -EINVAL;
- }
}
txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
@@ -2146,7 +2140,6 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
kfree(txmsg);
fail_put:
drm_dp_mst_topology_put_mstb(mstb);
- drm_dp_mst_topology_put_port(port);
return ret;
}
@@ -2251,15 +2244,16 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
*/
int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
{
- int i, j;
- int cur_slots = 1;
struct drm_dp_payload req_payload;
struct drm_dp_mst_port *port;
+ int i, j;
+ int cur_slots = 1;
mutex_lock(&mgr->payload_lock);
for (i = 0; i < mgr->max_payloads; i++) {
struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
struct drm_dp_payload *payload = &mgr->payloads[i];
+ bool put_port = false;
/* solve the current payloads - compare to the hw ones
- update the hw view */
@@ -2267,12 +2261,20 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr)
if (vcpi) {
port = container_of(vcpi, struct drm_dp_mst_port,
vcpi);
- port = drm_dp_mst_topology_get_port_validated(mgr,
- port);
- if (!port) {
- mutex_unlock(&mgr->payload_lock);
- return -EINVAL;
+
+ /* Validated ports don't matter if we're releasing
+* VCPI
+*/
+ if (vcpi->num_slots) {
+ port = drm_dp_mst_topology_get_port_validated(
+ mgr, port);
+ if (!port) {
+ mutex_unlock(&mgr->payload_lock);
+ return -EINVAL;
+ }
+ put_port = true;
}
+
req_payload.num_slots = vcpi->num_slots;
req_payload.vcpi = vcpi->vcpi;
} else {
@@ -2304,7 +2306,7 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr)
}
cur_slots += req_payload.num_slots;
- if (port)
+ if (put_port)
drm_dp_mst_topology_put_port(port);
}
@@ -3120,6 +3122,8 @@ bool drm_dp_mst_allocate_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n",
pbn, port->vcpi.num_slots);
+ /* Keep port allocated until it's payload has been
[Intel-gfx] [PATCH v7 16/20] drm/nouveau: Grab payload lock in nv50_msto_payload()
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
Reviewed-By: Ben Skeggs
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 6f8a54e81727..8044ebba56a4 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -679,6 +679,8 @@ nv50_msto_payload(struct nv50_msto *msto)
struct nv50_mstm *mstm = mstc->mstm;
int vcpi = mstc->port->vcpi.vcpi, i;
+ WARN_ON(!mutex_is_locked(&mstm->mgr.payload_lock));
+
NV_ATOMIC(drm, "%s: vcpi %d\n", msto->encoder.name, vcpi);
for (i = 0; i < mstm->mgr.max_payloads; i++) {
struct drm_dp_payload *payload = &mstm->mgr.payloads[i];
@@ -732,6 +734,8 @@ nv50_msto_prepare(struct nv50_msto *msto)
(0x0100 << msto->head->base.index),
};
+ mutex_lock(&mstm->mgr.payload_lock);
+
NV_ATOMIC(drm, "%s: msto prepare\n", msto->encoder.name);
if (mstc->port->vcpi.vcpi > 0) {
struct drm_dp_payload *payload = nv50_msto_payload(msto);
@@ -747,7 +751,9 @@ nv50_msto_prepare(struct nv50_msto *msto)
msto->encoder.name, msto->head->base.base.name,
args.vcpi.start_slot, args.vcpi.num_slots,
args.vcpi.pbn, args.vcpi.aligned_pbn);
+
nvif_mthd(&drm->display->disp.object, 0, &args, sizeof(args));
+ mutex_unlock(&mstm->mgr.payload_lock);
}
static int
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 14/20] drm/nouveau: Keep malloc references to MST ports
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is allocated for
as long as we keep mstc around we can remove the connector registration
checks for codepaths which release payloads, allowing us to release
payloads on active topologies properly. These registration checks were
only required before in order to avoid situations where mstc->port could
technically be pointing at freed memory.
Signed-off-by: Lyude Paul
Reviewed-By: Ben Skeggs
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 28538ef19b71..15f378902fcb 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -963,7 +963,11 @@ static void
nv50_mstc_destroy(struct drm_connector *connector)
{
struct nv50_mstc *mstc = nv50_mstc(connector);
+
drm_connector_cleanup(&mstc->connector);
+ if (mstc->port)
+ drm_dp_mst_put_port_malloc(mstc->port);
+
kfree(mstc);
}
@@ -1011,6 +1015,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct
drm_dp_mst_port *port,
drm_object_attach_property(&mstc->connector.base,
dev->mode_config.path_property, 0);
drm_object_attach_property(&mstc->connector.base,
dev->mode_config.tile_property, 0);
drm_connector_set_path_property(&mstc->connector, path);
+ drm_dp_mst_get_port_malloc(port);
return 0;
}
@@ -1076,6 +1081,7 @@ nv50_mstm_destroy_connector(struct
drm_dp_mst_topology_mgr *mgr,
drm_fb_helper_remove_one_connector(&drm->fbcon->helper,
&mstc->connector);
drm_modeset_lock(&drm->dev->mode_config.connection_mutex, NULL);
+ drm_dp_mst_put_port_malloc(mstc->port);
mstc->port = NULL;
drm_modeset_unlock(&drm->dev->mode_config.connection_mutex);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 10/20] drm/i915: Keep malloc references to MST ports
So that the ports stay around until we've destroyed the connectors, in order to ensure that we don't pass an invalid pointer to any MST helpers once we introduce the new MST VCPI helpers. Changes since v1: * Move drm_dp_mst_get_port_malloc() to where we assign intel_connector->port - danvet Signed-off-by: Lyude Paul Reviewed-by: Daniel Vetter Cc: David Airlie Cc: Jerry Zuo Cc: Harry Wentland Cc: Juston Li --- drivers/gpu/drm/i915/intel_connector.c | 4 drivers/gpu/drm/i915/intel_dp_mst.c| 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_connector.c b/drivers/gpu/drm/i915/intel_connector.c index 4f4ffd1c8fd3..ee16758747c5 100644 --- a/drivers/gpu/drm/i915/intel_connector.c +++ b/drivers/gpu/drm/i915/intel_connector.c @@ -94,6 +94,10 @@ void intel_connector_destroy(struct drm_connector *connector) intel_panel_fini(&intel_connector->panel); drm_connector_cleanup(connector); + + if (intel_connector->port) + drm_dp_mst_put_port_malloc(intel_connector->port); + kfree(connector); } diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index 4eae81671b0e..cdce0c519f9a 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -456,6 +456,7 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo intel_connector->get_hw_state = intel_dp_mst_get_hw_state; intel_connector->mst_port = intel_dp; intel_connector->port = port; + drm_dp_mst_get_port_malloc(port); connector = &intel_connector->base; ret = drm_connector_init(dev, connector, &intel_dp_mst_connector_funcs, -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 13/20] drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup()
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks are meant to protect against.
More importantly though, we're about to stop clearing mstc->port in the
next commit, which means if we could potentially hit a use-after-free
error if we tried to check mstc->port->vcpi here. So to make life easier
for anyone who bisects this code in the future, use msto->disabled
instead to check whether or not we need to deallocate VCPI instead.
Signed-off-by: Lyude Paul
Reviewed-By: Ben Skeggs
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 800213be76ea..28538ef19b71 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -703,14 +703,17 @@ nv50_msto_cleanup(struct nv50_msto *msto)
struct nv50_mstc *mstc = msto->mstc;
struct nv50_mstm *mstm = mstc->mstm;
+ if (!msto->disabled)
+ return;
+
NV_ATOMIC(drm, "%s: msto cleanup\n", msto->encoder.name);
- if (mstc->port && mstc->port->vcpi.vcpi > 0 && !nv50_msto_payload(msto))
+
+ if (mstc->port)
drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
- if (msto->disabled) {
- msto->mstc = NULL;
- msto->head = NULL;
- msto->disabled = false;
- }
+
+ msto->mstc = NULL;
+ msto->head = NULL;
+ msto->disabled = false;
}
static void
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 11/20] drm/amdgpu/display: Keep malloc ref to MST port
Just like i915 and nouveau, it's a good idea for us to hold a malloc
reference to the port here so that we never pass a freed pointer to any
of the DP MST helper functions.
Also, we stop unsetting aconnector->port in
dm_dp_destroy_mst_connector(). There's literally no point to that
assignment that I can see anyway.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 5e7ca1f3a8d1..24632727e127 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -191,6 +191,7 @@ dm_dp_mst_connector_destroy(struct drm_connector *connector)
drm_encoder_cleanup(&amdgpu_encoder->base);
kfree(amdgpu_encoder);
drm_connector_cleanup(connector);
+ drm_dp_mst_put_port_malloc(amdgpu_dm_connector->port);
kfree(amdgpu_dm_connector);
}
@@ -363,7 +364,9 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
amdgpu_dm_connector_funcs_reset(connector);
DRM_INFO("DM_MST: added connector: %p [id: %d] [master: %p]\n",
- aconnector, connector->base.id, aconnector->mst_port);
+aconnector, connector->base.id, aconnector->mst_port);
+
+ drm_dp_mst_get_port_malloc(port);
DRM_DEBUG_KMS(":%d\n", connector->base.id);
@@ -379,12 +382,12 @@ static void dm_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
DRM_INFO("DM_MST: Disabling connector: %p [id: %d] [master: %p]\n",
- aconnector, connector->base.id,
aconnector->mst_port);
+aconnector, connector->base.id, aconnector->mst_port);
- aconnector->port = NULL;
if (aconnector->dc_sink) {
amdgpu_dm_update_freesync_caps(connector, NULL);
- dc_link_remove_remote_sink(aconnector->dc_link,
aconnector->dc_sink);
+ dc_link_remove_remote_sink(aconnector->dc_link,
+ aconnector->dc_sink);
dc_sink_release(aconnector->dc_sink);
aconnector->dc_sink = NULL;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 20/20] drm/nouveau: Use atomic VCPI helpers for MST
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actually check whether or not the topology still has
enough bandwidth to provide the VCPI tokens required.
So, drop usage of the old helpers and move entirely over to the atomic
helpers.
Changes since v6:
* Cleanup atomic check logic and remove a bunch of unneeded checks -
danvet
Changes since v5:
* Update nv50_msto_atomic_check() and nv50_mstc_atomic_check() to the
new requirements for drm_dp_atomic_find_vcpi_slots() and
drm_dp_atomic_release_vcpi_slots()
Signed-off-by: Lyude Paul
Reviewed-By: Ben Skeggs
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 54 ++---
1 file changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 8044ebba56a4..67107f0b1299 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -761,16 +761,23 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
- struct nv50_mstc *mstc = nv50_mstc(conn_state->connector);
+ struct drm_atomic_state *state = crtc_state->state;
+ struct drm_connector *connector = conn_state->connector;
+ struct nv50_mstc *mstc = nv50_mstc(connector);
struct nv50_mstm *mstm = mstc->mstm;
- int bpp = conn_state->connector->display_info.bpc * 3;
+ int bpp = connector->display_info.bpc * 3;
int slots;
- mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock, bpp);
+ mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
+bpp);
- slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn);
- if (slots < 0)
- return slots;
+ if (drm_atomic_crtc_needs_modeset(crtc_state) &&
+ !drm_connector_is_unregistered(connector)) {
+ slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr,
+ mstc->port, mstc->pbn);
+ if (slots < 0)
+ return slots;
+ }
return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
mstc->native);
@@ -933,12 +940,43 @@ nv50_mstc_get_modes(struct drm_connector *connector)
return ret;
}
+static int
+nv50_mstc_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *new_conn_state)
+{
+ struct drm_atomic_state *state = new_conn_state->state;
+ struct nv50_mstc *mstc = nv50_mstc(connector);
+ struct drm_dp_mst_topology_mgr *mgr = &mstc->mstm->mgr;
+ struct drm_connector_state *old_conn_state =
+ drm_atomic_get_old_connector_state(state, connector);
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc *new_crtc = new_conn_state->crtc;
+
+ if (!old_conn_state->crtc)
+ return 0;
+
+ /* We only want to free VCPI if this state disables the CRTC on this
+* connector
+*/
+ if (new_crtc) {
+ crtc_state = drm_atomic_get_new_crtc_state(state, new_crtc);
+
+ if (!crtc_state ||
+ !drm_atomic_crtc_needs_modeset(crtc_state) ||
+ crtc_state->enable)
+ return 0;
+ }
+
+ return drm_dp_atomic_release_vcpi_slots(state, mgr, mstc->port);
+}
+
static const struct drm_connector_helper_funcs
nv50_mstc_help = {
.get_modes = nv50_mstc_get_modes,
.mode_valid = nv50_mstc_mode_valid,
.best_encoder = nv50_mstc_best_encoder,
.atomic_best_encoder = nv50_mstc_atomic_best_encoder,
+ .atomic_check = nv50_mstc_atomic_check,
};
static enum drm_connector_status
@@ -2120,6 +2158,10 @@ nv50_disp_atomic_check(struct drm_device *dev, struct
drm_atomic_state *state)
return ret;
}
+ ret = drm_dp_mst_atomic_check(state);
+ if (ret)
+ return ret;
+
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 v7 07/20] drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails
While this isn't a complete fix, this will improve the reliability of
drm_dp_get_last_connected_port_and_mstb() pretty significantly during
hotplug events, since there's a chance that the in-memory topology tree
may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
is called and thus might end up causing our search to fail on an mstb
whose topology refcount has reached 0, but has not yet been removed from
it's parent.
Ideally, we should further fix this problem by ensuring that we deal
with the potential for racing with a hotplug event, which would look
like this:
* drm_dp_payload_send_msg() retrieves the last living relative of mstb
with drm_dp_get_last_connected_port_and_mstb()
* drm_dp_payload_send_msg() starts building payload message
At the same time, mstb gets unplugged from the topology and is no
longer the actual last living relative of the original mstb
* drm_dp_payload_send_msg() tries sending the payload message, hub times
out
* Hub timed out, we give up and run away-resulting in the payload being
leaked
This could be fixed by restarting the
drm_dp_get_last_connected_port_and_mstb() search whenever we get a
timeout, sending the payload to the new mstb, then repeating until
either the entire topology is removed from the system or
drm_dp_get_last_connected_port_and_mstb() fails. But since the above
race condition is not terribly likely, we'll address that in a later
patch series once we've improved the recovery handling for VCPI
allocations in the rest of the DP MST helpers.
Changes since v1:
* Convert kerneldoc for drm_dp_get_last_connected_port_and_mstb to
normal comment - danvet
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 44 +--
1 file changed, 34 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 796985609933..7a251905b3c4 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2048,24 +2048,40 @@ static struct drm_dp_mst_port
*drm_dp_get_last_connected_port_to_mstb(struct drm
return
drm_dp_get_last_connected_port_to_mstb(mstb->port_parent->parent);
}
-static struct drm_dp_mst_branch
*drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
-struct
drm_dp_mst_branch *mstb,
-int
*port_num)
+/*
+ * Searches upwards in the topology starting from mstb to try to find the
+ * closest available parent of mstb that's still connected to the rest of the
+ * topology. This can be used in order to perform operations like releasing
+ * payloads, where the branch device which owned the payload may no longer be
+ * around and thus would require that the payload on the last living relative
+ * be freed instead.
+ */
+static struct drm_dp_mst_branch *
+drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb,
+ int *port_num)
{
struct drm_dp_mst_branch *rmstb = NULL;
struct drm_dp_mst_port *found_port;
+
mutex_lock(&mgr->lock);
- if (mgr->mst_primary) {
+ if (!mgr->mst_primary)
+ goto out;
+
+ do {
found_port = drm_dp_get_last_connected_port_to_mstb(mstb);
+ if (!found_port)
+ break;
- if (found_port) {
+ if (drm_dp_mst_topology_try_get_mstb(found_port->parent)) {
rmstb = found_port->parent;
- if (drm_dp_mst_topology_try_get_mstb(rmstb))
- *port_num = found_port->port_num;
- else
- rmstb = NULL;
+ *port_num = found_port->port_num;
+ } else {
+ /* Search again, starting from this parent */
+ mstb = found_port->parent;
}
- }
+ } while (!rmstb);
+out:
mutex_unlock(&mgr->lock);
return rmstb;
}
@@ -2114,6 +2130,14 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
drm_dp_queue_down_tx(mgr, txmsg);
+ /*
+* FIXME: there is a small chance that between getting the last
+* connected mstb and sending the payload message, the last connected
+* mstb could also be removed from the topology. In the future, this
+* needs to be fixed by restarting the
+* drm_dp_get_last_connected_port_and_mstb() search in the event of a
+* timeout if the topology is still connected to the system.
+*/
ret = drm_dp_mst_wait_tx_reply(mstb, txmsg
[Intel-gfx] [PATCH v7 08/20] drm/dp_mst: Stop releasing VCPI when removing ports from topology
This has never actually worked, and isn't needed anyway: the driver's
always going to try to deallocate VCPI when it tears down the display
that the VCPI belongs to.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7a251905b3c4..bb9107852fed 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1177,8 +1177,6 @@ static void drm_dp_destroy_port(struct kref *kref)
struct drm_dp_mst_topology_mgr *mgr = port->mgr;
if (!port->input) {
- port->vcpi.num_slots = 0;
-
kfree(port->cached_edid);
/*
@@ -3487,12 +3485,6 @@ static void drm_dp_destroy_connector_work(struct
work_struct *work)
drm_dp_port_teardown_pdt(port, port->pdt);
port->pdt = DP_PEER_DEVICE_NONE;
- if (!port->input && port->vcpi.vcpi > 0) {
- drm_dp_mst_reset_vcpi_slots(mgr, port);
- drm_dp_update_payload_part1(mgr);
- drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
- }
-
drm_dp_mst_put_port_malloc(port);
send_hotplug = true;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 01/20] drm/dp_mst: Fix some formatting in drm_dp_add_port()
Reindent some stuff, and split some stuff across multiple lines so we
aren't going over the text width limit.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 2ab16c9e6243..c93bff5527fd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1184,11 +1184,13 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
if (old_ddps != port->ddps) {
if (port->ddps) {
- if (!port->input)
- drm_dp_send_enum_path_resources(mstb->mgr,
mstb, port);
+ if (!port->input) {
+ drm_dp_send_enum_path_resources(mstb->mgr,
+ mstb, port);
+ }
} else {
port->available_pbn = 0;
- }
+ }
}
if (old_pdt != port->pdt && !port->input) {
@@ -1202,8 +1204,11 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
if (created && !port->input) {
char proppath[255];
- build_mst_prop_path(mstb, port->port_num, proppath,
sizeof(proppath));
- port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr,
port, proppath);
+ build_mst_prop_path(mstb, port->port_num, proppath,
+ sizeof(proppath));
+ port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr,
+ port,
+ proppath);
if (!port->connector) {
/* remove it from the port list */
mutex_lock(&mstb->mgr->lock);
@@ -1216,7 +1221,8 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
if ((port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV ||
port->pdt == DP_PEER_DEVICE_SST_SINK) &&
port->port_num >= DP_MST_LOGICAL_PORT_0) {
- port->cached_edid = drm_get_edid(port->connector,
&port->aux.ddc);
+ port->cached_edid = drm_get_edid(port->connector,
+&port->aux.ddc);
drm_connector_set_tile_property(port->connector);
}
(*mstb->mgr->cbs->register_connector)(port->connector);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 00/20] MST refcounting/atomic helpers cleanup
This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a ton of magic in the atomic helpers to work around properly and in many situations just plain doesn't work as intended. There's still more cleanup that can be done, but I think this is a good place to start off for now :). Not available on gitlab, as this is the final version of the series before I push! hooray~ Lyude Paul (20): drm/dp_mst: Fix some formatting in drm_dp_add_port() drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg() drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi() drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi() drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends drm/dp_mst: Introduce new refcounting scheme for mstbs and ports drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails drm/dp_mst: Stop releasing VCPI when removing ports from topology drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs drm/i915: Keep malloc references to MST ports drm/amdgpu/display: Keep malloc ref to MST port drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector() drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup() drm/nouveau: Keep malloc references to MST ports drm/nouveau: Stop unsetting mstc->port, use malloc refs drm/nouveau: Grab payload lock in nv50_msto_payload() drm/dp_mst: Add some atomic state iterator macros drm/dp_mst: Start tracking per-port VCPI allocations drm/dp_mst: Check payload count in drm_dp_mst_atomic_check() drm/nouveau: Use atomic VCPI helpers for MST .../gpu/dp-mst/topology-figure-1.dot | 52 + .../gpu/dp-mst/topology-figure-2.dot | 56 ++ .../gpu/dp-mst/topology-figure-3.dot | 59 ++ Documentation/gpu/drm-kms-helpers.rst | 26 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 11 +- drivers/gpu/drm/drm_dp_mst_topology.c | 946 ++ drivers/gpu/drm/i915/intel_connector.c| 4 + drivers/gpu/drm/i915/intel_display.c | 4 + drivers/gpu/drm/i915/intel_dp_mst.c | 55 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 96 +- include/drm/drm_dp_mst_helper.h | 151 ++- 11 files changed, 1204 insertions(+), 256 deletions(-) create mode 100644 Documentation/gpu/dp-mst/topology-figure-1.dot create mode 100644 Documentation/gpu/dp-mst/topology-figure-2.dot create mode 100644 Documentation/gpu/dp-mst/topology-figure-3.dot -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 05/20] drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends
s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/
s/drm_dp_put_port/drm_dp_mst_topology_put_port/
s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/
s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/
This is a much more consistent naming scheme, and will make even more
sense once we redesign how the current refcounting scheme here works.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Reviewed-by: Harry Wentland
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 114 ++
1 file changed, 62 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 75cca6a843fb..074e985093ca 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -46,7 +46,7 @@ static bool dump_dp_payload_table(struct
drm_dp_mst_topology_mgr *mgr,
char *buf);
static int test_calc_pbn_mode(void);
-static void drm_dp_put_port(struct drm_dp_mst_port *port);
+static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
int id,
@@ -888,7 +888,7 @@ static void drm_dp_destroy_mst_branch_device(struct kref
*kref)
*/
list_for_each_entry_safe(port, tmp, &mstb->ports, next) {
list_del(&port->next);
- drm_dp_put_port(port);
+ drm_dp_mst_topology_put_port(port);
}
/* drop any tx slots msg */
@@ -911,7 +911,7 @@ static void drm_dp_destroy_mst_branch_device(struct kref
*kref)
kref_put(kref, drm_dp_free_mst_branch_device);
}
-static void drm_dp_put_mst_branch_device(struct drm_dp_mst_branch *mstb)
+static void drm_dp_mst_topology_put_mstb(struct drm_dp_mst_branch *mstb)
{
kref_put(&mstb->kref, drm_dp_destroy_mst_branch_device);
}
@@ -930,7 +930,7 @@ static void drm_dp_port_teardown_pdt(struct drm_dp_mst_port
*port, int old_pdt)
case DP_PEER_DEVICE_MST_BRANCHING:
mstb = port->mstb;
port->mstb = NULL;
- drm_dp_put_mst_branch_device(mstb);
+ drm_dp_mst_topology_put_mstb(mstb);
break;
}
}
@@ -970,12 +970,14 @@ static void drm_dp_destroy_port(struct kref *kref)
kfree(port);
}
-static void drm_dp_put_port(struct drm_dp_mst_port *port)
+static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
{
kref_put(&port->kref, drm_dp_destroy_port);
}
-static struct drm_dp_mst_branch
*drm_dp_mst_get_validated_mstb_ref_locked(struct drm_dp_mst_branch *mstb,
struct drm_dp_mst_branch *to_find)
+static struct drm_dp_mst_branch *
+drm_dp_mst_topology_get_mstb_validated_locked(struct drm_dp_mst_branch *mstb,
+ struct drm_dp_mst_branch *to_find)
{
struct drm_dp_mst_port *port;
struct drm_dp_mst_branch *rmstb;
@@ -985,7 +987,8 @@ static struct drm_dp_mst_branch
*drm_dp_mst_get_validated_mstb_ref_locked(struct
}
list_for_each_entry(port, &mstb->ports, next) {
if (port->mstb) {
- rmstb =
drm_dp_mst_get_validated_mstb_ref_locked(port->mstb, to_find);
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
+ port->mstb, to_find);
if (rmstb)
return rmstb;
}
@@ -993,12 +996,15 @@ static struct drm_dp_mst_branch
*drm_dp_mst_get_validated_mstb_ref_locked(struct
return NULL;
}
-static struct drm_dp_mst_branch *drm_dp_get_validated_mstb_ref(struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_branch *mstb)
+static struct drm_dp_mst_branch *
+drm_dp_mst_topology_get_mstb_validated(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb)
{
struct drm_dp_mst_branch *rmstb = NULL;
mutex_lock(&mgr->lock);
if (mgr->mst_primary)
- rmstb =
drm_dp_mst_get_validated_mstb_ref_locked(mgr->mst_primary, mstb);
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
+ mgr->mst_primary, mstb);
mutex_unlock(&mgr->lock);
return rmstb;
}
@@ -1021,7 +1027,9 @@ static struct drm_dp_mst_port
*drm_dp_mst_get_port_ref_locked(struct drm_dp_mst_
return NULL;
}
-static struct drm_dp_mst_port *drm_dp_get_validated_port_ref(struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port)
+static struct drm_dp_mst_port *
+drm_dp_mst_topology_get_port_validated(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port)
{
struct drm_dp_mst_port *rport = NULL;
mutex_lock(&mgr->lock);
@@ -1215,7 +1223,7 @@ static void drm_dp_add_port(s
[Intel-gfx] [PATCH v7 04/20] drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi()
Split some stuff across multiple lines
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index a63a4d32962a..75cca6a843fb 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2790,7 +2790,8 @@ EXPORT_SYMBOL(drm_dp_mst_reset_vcpi_slots);
* @mgr: manager for this port
* @port: unverified port to deallocate vcpi for
*/
-void drm_dp_mst_deallocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct
drm_dp_mst_port *port)
+void drm_dp_mst_deallocate_vcpi(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port)
{
port = drm_dp_get_validated_port_ref(mgr, port);
if (!port)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 02/20] drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg()
Split some stuff across multiple lines, remove some unnecessary braces
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index c93bff5527fd..fc93a71c42b0 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1331,9 +1331,9 @@ static struct drm_dp_mst_branch
*get_mst_branch_device_by_guid_helper(
return NULL;
}
-static struct drm_dp_mst_branch *drm_dp_get_mst_branch_device_by_guid(
- struct drm_dp_mst_topology_mgr *mgr,
- uint8_t *guid)
+static struct drm_dp_mst_branch *
+drm_dp_get_mst_branch_device_by_guid(struct drm_dp_mst_topology_mgr *mgr,
+uint8_t *guid)
{
struct drm_dp_mst_branch *mstb;
@@ -1739,7 +1739,9 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
port_num = port->port_num;
mstb = drm_dp_get_validated_mstb_ref(mgr, port->parent);
if (!mstb) {
- mstb = drm_dp_get_last_connected_port_and_mstb(mgr,
port->parent, &port_num);
+ mstb = drm_dp_get_last_connected_port_and_mstb(mgr,
+ port->parent,
+ &port_num);
if (!mstb) {
drm_dp_put_port(port);
@@ -1765,9 +1767,9 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
ret = drm_dp_mst_wait_tx_reply(mstb, txmsg);
if (ret > 0) {
- if (txmsg->reply.reply_type == 1) {
+ if (txmsg->reply.reply_type == 1)
ret = -EINVAL;
- } else
+ else
ret = 0;
}
kfree(txmsg);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 06/20] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current scheme works like this:
drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When
this refcount hits 0 for either of the two, they're removed from the
topology state, but not immediately freed. Both ports and branch devices
will reinitialize their kref once it's hit 0 before actually destroying
themselves. The intended purpose behind this is so that we can avoid
problems like not being able to free a remote payload that might still
be active, due to us having removed all of the port/branch device
structures in memory, as per:
commit 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
Which may have worked, but then it caused use-after-free errors. Being
new to MST at the time, I tried fixing it;
commit 263efde31f97 ("drm/dp/mst: Get validated port ref in
drm_dp_update_payload_part1()")
But, that was broken: both drm_dp_mst_port and drm_dp_mst_branch structs
are validated in almost every DP MST helper function. Simply put, this
means we go through the topology and try to see if the given
drm_dp_mst_branch or drm_dp_mst_port is still attached to something
before trying to use it in order to avoid dereferencing freed memory
(something that has happened a LOT in the past with this library).
Because of this it doesn't actually matter whether or not we keep keep
the ports and branches around in memory as that's not enough, because
any function that validates the branches and ports passed to it will
still reject them anyway since they're no longer in the topology
structure. So, use-after-free errors were fixed but payload deallocation
was completely broken.
Two years later, AMD informed me about this issue and I attempted to
come up with a temporary fix, pending a long-overdue cleanup of this
library:
commit c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction,
just ref")
But then that introduced use-after-free errors, so I quickly reverted
it:
commit 9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during
destruction, just ref"")
And in the process, learned that there is just no simple fix for this:
the design is just broken. Unfortunately, the usage of these helpers are
quite broken as well. Some drivers like i915 have been smart enough to
avoid accessing any kind of information from MST port structures, but
others like nouveau have assumed, understandably so, that
drm_dp_mst_port structures are normal and can just be accessed at any
time without worrying about use-after-free errors.
After a lot of discussion, me and Daniel Vetter came up with a better
idea to replace all of this.
To summarize, since this is documented far more indepth in the
documentation this patch introduces, we make it so that drm_dp_mst_port
and drm_dp_mst_branch structures have two different classes of
refcounts: topology_kref, and malloc_kref. topology_kref corresponds to
the lifetime of the given drm_dp_mst_port or drm_dp_mst_branch in it's
given topology. Once it hits zero, any associated connectors are removed
and the branch or port can no longer be validated. malloc_kref
corresponds to the lifetime of the memory allocation for the actual
structure, and will always be non-zero so long as the topology_kref is
non-zero. This gives us a way to allow callers to hold onto port and
branch device structures past their topology lifetime, and dramatically
simplifies the lifetimes of both structures. This also finally fixes the
port deallocation problem, properly.
Additionally: since this now means that we can keep ports and branch
devices allocated in memory for however long we need, we no longer need
a significant amount of the port validation that we currently do.
Additionally, there is one last scenario that this fixes, which couldn't
have been fixed properly beforehand:
- CPU1 unrefs port from topology (refcount 1->0)
- CPU2 refs port in topology(refcount 0->1)
Since we now can guarantee memory safety for ports and branches
as-needed, we also can make our main reference counting functions fix
this problem by using kref_get_unless_zero() internally so that topology
refcounts can only ever reach 0 once.
Changes since v4:
* Change the kernel-figure summary for dp-mst/topology-figure-1.dot a
bit - danvet
* Remove figure numbers - danvet
Changes since v3:
* Remove rebase detritus - danvet
* Split out purely style changes into separate patches - hwentlan
Changes since v2:
* Fix commit message - checkpatch
* s/)-1/) - 1/g - checkpatch
Changes since v1:
* Remove forward declarations - danvet
* Move "Branch device and port refcounting" section from documentation
into kernel-doc comments - danvet
* Export internal topology lifetime functions into their own section in
the kernel
[Intel-gfx] [PATCH v7 03/20] drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi()
Fix some indenting, split some stuff across multiple lines.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index fc93a71c42b0..a63a4d32962a 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2731,7 +2731,8 @@ bool drm_dp_mst_allocate_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
return false;
if (port->vcpi.vcpi > 0) {
- DRM_DEBUG_KMS("payload: vcpi %d already allocated for pbn %d -
requested pbn %d\n", port->vcpi.vcpi, port->vcpi.pbn, pbn);
+ DRM_DEBUG_KMS("payload: vcpi %d already allocated for pbn %d -
requested pbn %d\n",
+ port->vcpi.vcpi, port->vcpi.pbn, pbn);
if (pbn == port->vcpi.pbn) {
drm_dp_put_port(port);
return true;
@@ -2741,11 +2742,11 @@ bool drm_dp_mst_allocate_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
ret = drm_dp_init_vcpi(mgr, &port->vcpi, pbn, slots);
if (ret) {
DRM_DEBUG_KMS("failed to init vcpi slots=%d max=63 ret=%d\n",
- DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
+ DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
goto out;
}
DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n",
- pbn, port->vcpi.num_slots);
+ pbn, port->vcpi.num_slots);
drm_dp_put_port(port);
return true;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 07/01/19 08:58, Tvrtko Ursulin wrote: On 07/01/2019 13:57, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-07 13:43:29) On 07/01/2019 11:58, Tvrtko Ursulin wrote: [snip] Note about future interaction with preemption: Preemption could happen in a command sequence prior to watchdog counter getting disabled, resulting in watchdog being triggered following preemption (e.g. when watchdog had been enabled in the low priority batch). The driver will need to explicitly disable the watchdog counter as part of the preemption sequence. Does the series take care of preemption? I did not find that it does. Oh. I hoped that the watchdog was saved as part of the context... Then despite preemption, the timeout would resume from where we left off as soon as it was back on the gpu. If the timeout remaining was context saved it would be much simpler (at least on first glance), please say it is. I made my comments going only by the text from the commit message and the absence of any preemption special handling. Having read the spec, the situation seems like this: * Watchdog control and threshold register are context saved and restored. * On a context switch watchdog counter is reset to zero and automatically disabled until enabled by a context restore or explicitly. So it sounds the commit message could be wrong that special handling is needed from this direction. But read till the end on the restriction listed. * Watchdog counter is reset to zero and is not accumulated across multiple submission of the same context (due preemption). I read this as - after preemption contexts gets a new full timeout allocation. Or in other words, if a context is preempted N times, it's cumulative watchdog timeout will be N * set value. This could be theoretically exploitable to bypass the timeout. If a client sets up two contexts with prio -1 and -2, and keeps submitting periodical no-op batches against prio -1 context, while prio -2 is it's own hog, then prio -2 context defeats the watchdog timer. I think.. would appreciate is someone challenged this conclusion. I think you are right that is a possibility but, is that a problem? The client can just not set the threshold to bypass the timeout. Also because you need the hanging batch to be simply preemptible, you cannot disrupt any work from another client that is higher priority. This is pretty much the same behavior of hangcheck IIRC so something we already accept. And finally there is one programming restriction which says: * SW must not preempt the workload which has watchdog enabled. Either it must: a) disable preemption for that workload completely, or b) disable the watchdog via mmio write before any write to ELSP This seems it contradiction with the statement that the counter gets disabled on context switch and stays disabled. I did not spot anything like this in the series. So it would seem the commit message is correct after all. It would be good if someone could re-read the bspec text on register 0x2178 to double check what I wrote. The way I read it is that the restriction applies only to some platforms where the 'normal' description doesn't apply. Antonio Regards, Tvrtko ___ 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] [Nouveau] [PATCH v6 00/20] MST refcounting/atomic helpers cleanup
For the nouveau patches in the series: Reviewed-By: Ben Skeggs On Fri, 11 Jan 2019 at 05:59, Lyude Paul wrote: > > This is the series I've been working on for a while now to get all of > the atomic DRM drivers in the tree to use the atomic MST helpers, and to > make the atomic MST helpers actually idempotent. Turns out it's a lot > more difficult to do that without also fixing how port and branch device > refcounting works so that it actually makes sense, since the current > upstream implementation requires a ton of magic in the atomic helpers to > work around properly and in many situations just plain doesn't work as > intended. > > There's still more cleanup that can be done, but I think this is a good > place to start off for now :). > > Also available on gitlab: > > https://gitlab.freedesktop.org/lyudess/linux/commits/wip/mst-dual-kref-start-v6 > > Lyude Paul (20): > drm/dp_mst: Fix some formatting in drm_dp_add_port() > drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg() > drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi() > drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi() > drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and > friends > drm/dp_mst: Introduce new refcounting scheme for mstbs and ports > drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref > fails > drm/dp_mst: Stop releasing VCPI when removing ports from topology > drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs > drm/i915: Keep malloc references to MST ports > drm/amdgpu/display: Keep malloc ref to MST port > drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector() > drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup() > drm/nouveau: Keep malloc references to MST ports > drm/nouveau: Stop unsetting mstc->port, use malloc refs > drm/nouveau: Grab payload lock in nv50_msto_payload() > drm/dp_mst: Add some atomic state iterator macros > drm/dp_mst: Start tracking per-port VCPI allocations > drm/dp_mst: Check payload count in drm_dp_mst_atomic_check() > drm/nouveau: Use atomic VCPI helpers for MST > > .../gpu/dp-mst/topology-figure-1.dot | 52 + > .../gpu/dp-mst/topology-figure-2.dot | 56 ++ > .../gpu/dp-mst/topology-figure-3.dot | 59 ++ > Documentation/gpu/drm-kms-helpers.rst | 26 +- > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 11 +- > drivers/gpu/drm/drm_dp_mst_topology.c | 946 ++ > drivers/gpu/drm/i915/intel_connector.c| 4 + > drivers/gpu/drm/i915/intel_display.c | 4 + > drivers/gpu/drm/i915/intel_dp_mst.c | 55 +- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 96 +- > include/drm/drm_dp_mst_helper.h | 151 ++- > 11 files changed, 1204 insertions(+), 256 deletions(-) > create mode 100644 Documentation/gpu/dp-mst/topology-figure-1.dot > create mode 100644 Documentation/gpu/dp-mst/topology-figure-2.dot > create mode 100644 Documentation/gpu/dp-mst/topology-figure-3.dot > > -- > 2.20.1 > > ___ > Nouveau mailing list > nouv...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/cnl: Fix CNL macros for Voltage Swing programming (rev2)
== Series Details == Series: drm/i915/cnl: Fix CNL macros for Voltage Swing programming (rev2) URL : https://patchwork.freedesktop.org/series/54092/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8b810fada4b5 drm/i915/cnl: Fix CNL macros for Voltage Swing programming -:26: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #26: FILE: drivers/gpu/drm/i915/i915_reg.h:1817: +#define _CNL_PORT_TX_DW_GRP(dw, port) (_PICK((port), \ _CNL_PORT_TX_AE_GRP_OFFSET, \ _CNL_PORT_TX_B_GRP_OFFSET, \ _CNL_PORT_TX_B_GRP_OFFSET, \ -:35: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #35: FILE: drivers/gpu/drm/i915/i915_reg.h:1825: +#define _CNL_PORT_TX_DW_LN0(dw, port) (_PICK((port), \ _CNL_PORT_TX_AE_LN0_OFFSET, \ _CNL_PORT_TX_B_LN0_OFFSET, \ _CNL_PORT_TX_B_LN0_OFFSET, \ total: 2 errors, 0 warnings, 0 checks, 38 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/21] drm/i915/dp: Markup pps lock power well
On 1/10/2019 02:11, Chris Wilson wrote:
Track where and when we acquire and release the power well for pps
access along the dp aux link, with a view to detecting if we leak any
wakerefs.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 231 +---
1 file changed, 121 insertions(+), 110 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fc85fd77a661..db0f3a4402f5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -601,30 +601,39 @@ intel_dp_init_panel_power_sequencer_registers(struct
intel_dp *intel_dp,
static void
intel_dp_pps_init(struct intel_dp *intel_dp);
-static void pps_lock(struct intel_dp *intel_dp)
+static intel_wakeref_t
+pps_lock(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
Any particular reason for leaving these as dev_priv when the earlier
patches converted everything in sight to i915?
Otherwise:
Reviewed-by: John Harrison
+ intel_wakeref_t wakeref;
/*
* See intel_power_sequencer_reset() why we need
* a power domain reference here.
*/
- intel_display_power_get(dev_priv,
-
intel_aux_power_domain(dp_to_dig_port(intel_dp)));
+ wakeref = intel_display_power_get(dev_priv,
+
intel_aux_power_domain(dp_to_dig_port(intel_dp)));
mutex_lock(&dev_priv->pps_mutex);
+
+ return wakeref;
}
-static void pps_unlock(struct intel_dp *intel_dp)
+static intel_wakeref_t
+pps_unlock(struct intel_dp *intel_dp, intel_wakeref_t wakeref)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
mutex_unlock(&dev_priv->pps_mutex);
-
- intel_display_power_put_unchecked(dev_priv,
-
intel_aux_power_domain(dp_to_dig_port(intel_dp)));
+ intel_display_power_put(dev_priv,
+
intel_aux_power_domain(dp_to_dig_port(intel_dp)),
+ wakeref);
+ return 0;
}
+#define with_pps_lock(dp, wf) \
+ for (wf = pps_lock(dp); wf; wf = pps_unlock(dp, wf))
+
static void
vlv_power_sequencer_kick(struct intel_dp *intel_dp)
{
@@ -973,30 +982,30 @@ static int edp_notify_handler(struct notifier_block
*this, unsigned long code,
struct intel_dp *intel_dp = container_of(this, typeof(* intel_dp),
edp_notifier);
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+ intel_wakeref_t wakeref;
if (!intel_dp_is_edp(intel_dp) || code != SYS_RESTART)
return 0;
- pps_lock(intel_dp);
-
- if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
- enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
- i915_reg_t pp_ctrl_reg, pp_div_reg;
- u32 pp_div;
-
- pp_ctrl_reg = PP_CONTROL(pipe);
- pp_div_reg = PP_DIVISOR(pipe);
- pp_div = I915_READ(pp_div_reg);
- pp_div &= PP_REFERENCE_DIVIDER_MASK;
-
- /* 0x1F write to PP_DIV_REG sets max cycle delay */
- I915_WRITE(pp_div_reg, pp_div | 0x1F);
- I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
- msleep(intel_dp->panel_power_cycle_delay);
+ with_pps_lock(intel_dp, wakeref) {
+ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+ enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
+ i915_reg_t pp_ctrl_reg, pp_div_reg;
+ u32 pp_div;
+
+ pp_ctrl_reg = PP_CONTROL(pipe);
+ pp_div_reg = PP_DIVISOR(pipe);
+ pp_div = I915_READ(pp_div_reg);
+ pp_div &= PP_REFERENCE_DIVIDER_MASK;
+
+ /* 0x1F write to PP_DIV_REG sets max cycle delay */
+ I915_WRITE(pp_div_reg, pp_div | 0x1F);
+ I915_WRITE(pp_ctrl_reg,
+ PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
+ msleep(intel_dp->panel_power_cycle_delay);
+ }
}
- pps_unlock(intel_dp);
-
return 0;
}
@@ -1184,16 +1193,17 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
to_i915(intel_dig_port->base.base.dev);
i915_reg_t ch_ctl, ch_data[5];
uint32_t aux_clock_divider;
+ intel_wakeref_t wakeref;
int i, ret, recv_bytes;
- uint32_t status;
int try, clock = 0;
+ uint32_t status;
bool vdd;
ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
for (i = 0; i < ARRAY_SIZE(ch_data); i++)
ch_data[i] = intel_dp->aux_ch_data_reg(intel_dp, i);
- pps_lock(intel_dp);
+ wakeref = pps_lock(intel_dp);
[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/omapdrm/omap_encoder.c
between commit:
3c613a3bddd3 ("drm/omap: fix incorrect union usage")
from Linus' tree and commit:
13d0add333af ("drm/edid: Pass connector to AVI infoframe functions")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/omapdrm/omap_encoder.c
index 933ebc9f9faa,4566e0a75cb8..
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@@ -52,37 -52,6 +52,37 @@@ static const struct drm_encoder_funcs o
.destroy = omap_encoder_destroy,
};
+static void omap_encoder_hdmi_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct drm_device *dev = encoder->dev;
+ struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
+ struct omap_dss_device *dssdev = omap_encoder->output;
+ struct drm_connector *connector;
+ bool hdmi_mode;
+
+ hdmi_mode = false;
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ if (connector->encoder == encoder) {
+ hdmi_mode = omap_connector_get_hdmi_mode(connector);
+ break;
+ }
+ }
+
+ if (dssdev->ops->hdmi.set_hdmi_mode)
+ dssdev->ops->hdmi.set_hdmi_mode(dssdev, hdmi_mode);
+
+ if (hdmi_mode && dssdev->ops->hdmi.set_infoframe) {
+ struct hdmi_avi_infoframe avi;
+ int r;
+
- r = drm_hdmi_avi_infoframe_from_display_mode(&avi,
adjusted_mode,
-false);
++ r = drm_hdmi_avi_infoframe_from_display_mode(&avi, connector,
++ adjusted_mode);
+ if (r == 0)
+ dssdev->ops->hdmi.set_infoframe(dssdev, &avi);
+ }
+}
+
static void omap_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
pgpJBTjDbZ0LR.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ctx_isolation: Ignore the low bits of BB_OFFSET
Quoting Antonio Argenziano (2019-01-10 21:58:52)
>
>
> On 10/01/19 13:29, Chris Wilson wrote:
> > Quoting Chris Wilson (2019-01-10 21:27:54)
> >> Quoting Antonio Argenziano (2019-01-10 21:24:56)
> >>>
> >>>
> >>> On 07/01/19 04:41, Chris Wilson wrote:
> On Skylake, BB_OFFSET seems to be unstable. Since this is an
> offset into the batch at the time of CS execution, it should be actively
> written to as we read from the register so allow it a qword of
> discrepancy (since the CS should be reading in qwords). This still
> allows us to detect dirt across the rest of the register field, should
> that be required.
>
> Signed-off-by: Chris Wilson
> ---
> tests/i915/gem_ctx_isolation.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/i915/gem_ctx_isolation.c
> b/tests/i915/gem_ctx_isolation.c
> index 058cf3ec1..78a244382 100644
> --- a/tests/i915/gem_ctx_isolation.c
> +++ b/tests/i915/gem_ctx_isolation.c
> @@ -96,7 +96,7 @@ static const struct named_register {
> { "GPGPU_THREADS_DISPATCHED", GEN8, RCS0, 0x2290, 2 },
> { "PS_INVOCATION_COUNT_1", GEN8, RCS0, 0x22f0, 2 },
> { "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
> - { "BB_OFFSET", GEN8, RCS0, 0x2158 },
> + { "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
> >>>
> >>> The batch offset starts at bit 2. Do we observe changes in bit 0-1 as
> >>> well?
> >>
> >> Not, it is just off by bit 2 (0x4). Bit 0 is also set when I don't
> >> really expect it to be, I guess I really should just read what the
> >> register is meant to be rather than guessing solely on the basis of its
> >> name.
> >
> > Bit 2 flip flops between reference value and observed (test failure).
> >
> > Bit 0 simply differs from my own expectations.
>
> I guess if it gets overwritten we catch it even if we ignore the lowest
> 3 bits but something weird would have happened if 0-1 change.
>
> With or without modifying the mask,
> Reviewed-by: Antonio Argenziano
Restricted the mask to .ignore_bits=0x4 so that we only ignore the bit
that is fluctuating in testing.
Thanks,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/21] drm/i915: Track the wakeref used to initialise display power domains
Quoting John Harrison (2019-01-10 23:15:31)
> On 1/10/2019 02:11, Chris Wilson wrote:
> > @@ -4054,18 +4055,20 @@ void intel_power_domains_init_hw(struct
> > drm_i915_private *dev_priv, bool resume)
> >* resources powered until display HW readout is complete. We drop
> >* this reference in intel_power_domains_enable().
> >*/
> > - intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
> > + power_domains->wakeref =
> > + intel_display_power_get(i915, POWER_DOMAIN_INIT);
> > +
> > /* Disable power support if the user asked so. */
> > if (!i915_modparams.disable_power_well)
> > - intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
> > - intel_power_domains_sync_hw(dev_priv);
> > + intel_display_power_get(i915, POWER_DOMAIN_INIT);
> Why not save this cookie away somewhere too, e.g.
> power_domains->wakeref_disable? That way you can also get rid of the
> put_unchecked calls below.
Just seemed like a bit more hassle for the case where rpm was
intentionally disabled by the user. The system is going to leak the
wakerefs, tracking seemed pointless, so I just threw my hands up in the
air and gave up.
> > + intel_power_domains_sync_hw(i915);
> >
> > power_domains->initializing = false;
> > }
> >
> > /**
> >* intel_power_domains_fini_hw - deinitialize hw power domain state
> > - * @dev_priv: i915 device instance
> > + * @i915: i915 device instance
> >*
> >* De-initializes the display power domain HW state. It also ensures that
> > the
> >* device stays powered up so that the driver can be reloaded.
> > @@ -4074,21 +4077,24 @@ void intel_power_domains_init_hw(struct
> > drm_i915_private *dev_priv, bool resume)
> >* intel_power_domains_disable()) and must be paired with
> >* intel_power_domains_init_hw().
> >*/
> > -void intel_power_domains_fini_hw(struct drm_i915_private *dev_priv)
> > +void intel_power_domains_fini_hw(struct drm_i915_private *i915)
> > {
> > - /* Keep the power well enabled, but cancel its rpm wakeref. */
> > - intel_runtime_pm_put_unchecked(dev_priv);
> > + intel_wakeref_t wakeref __maybe_unused =
> > + fetch_and_zero(&i915->power_domains.wakeref);
> Why the '__maybe_unused'? The call to put is unconditional. Or is it
> about keeping the compiler happy in the case where the wakeref tracking
> is disabled? Although I don't recall seeing any 'maybe's in the earlier
> patches.
Just about keeping the compiler happy when the compiler complained.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/21] drm/i915: Track the wakeref used to initialise display power domains
On 1/10/2019 02:11, Chris Wilson wrote:
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
transfer them to the runtime-pm code. We can use our wakeref tracking to
verify that the wakeref is indeed passed from init to enable, and
disable to fini; and across suspend.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 151 +---
3 files changed, 88 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b7dcacf2a5d3..96717a23b32f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2699,6 +2699,9 @@ static int i915_runtime_pm_status(struct seq_file *m,
void *unused)
if (!HAS_RUNTIME_PM(dev_priv))
seq_puts(m, "Runtime power management not supported\n");
+ seq_printf(m, "Runtime power management: %s\n",
+ enableddisabled(!dev_priv->power_domains.wakeref));
+
seq_printf(m, "GPU idle: %s (epoch %u)\n",
yesno(!dev_priv->gt.awake), dev_priv->gt.epoch);
seq_printf(m, "IRQs disabled: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 44c1b21febba..259b91b62ff2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -822,6 +822,8 @@ struct i915_power_domains {
bool display_core_suspended;
int power_well_count;
+ intel_wakeref_t wakeref;
+
struct mutex lock;
int domain_use_count[POWER_DOMAIN_NUM];
struct i915_power_well *power_wells;
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index fd2fc10dd1e4..8d38f3e7fad1 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -4009,7 +4009,7 @@ static void intel_power_domains_verify_state(struct
drm_i915_private *dev_priv);
/**
* intel_power_domains_init_hw - initialize hardware power domain state
- * @dev_priv: i915 device instance
+ * @i915: i915 device instance
* @resume: Called from resume code paths or not
*
* This function initializes the hardware power domain state and enables all
@@ -4023,30 +4023,31 @@ static void intel_power_domains_verify_state(struct
drm_i915_private *dev_priv);
* intel_power_domains_enable()) and must be paired with
* intel_power_domains_fini_hw().
*/
-void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool
resume)
+void intel_power_domains_init_hw(struct drm_i915_private *i915, bool resume)
{
- struct i915_power_domains *power_domains = &dev_priv->power_domains;
+ struct i915_power_domains *power_domains = &i915->power_domains;
power_domains->initializing = true;
- if (IS_ICELAKE(dev_priv)) {
- icl_display_core_init(dev_priv, resume);
- } else if (IS_CANNONLAKE(dev_priv)) {
- cnl_display_core_init(dev_priv, resume);
- } else if (IS_GEN9_BC(dev_priv)) {
- skl_display_core_init(dev_priv, resume);
- } else if (IS_GEN9_LP(dev_priv)) {
- bxt_display_core_init(dev_priv, resume);
- } else if (IS_CHERRYVIEW(dev_priv)) {
+ if (IS_ICELAKE(i915)) {
+ icl_display_core_init(i915, resume);
+ } else if (IS_CANNONLAKE(i915)) {
+ cnl_display_core_init(i915, resume);
+ } else if (IS_GEN9_BC(i915)) {
+ skl_display_core_init(i915, resume);
+ } else if (IS_GEN9_LP(i915)) {
+ bxt_display_core_init(i915, resume);
+ } else if (IS_CHERRYVIEW(i915)) {
mutex_lock(&power_domains->lock);
- chv_phy_control_init(dev_priv);
+ chv_phy_control_init(i915);
mutex_unlock(&power_domains->lock);
- } else if (IS_VALLEYVIEW(dev_priv)) {
+ } else if (IS_VALLEYVIEW(i915)) {
mutex_lock(&power_domains->lock);
- vlv_cmnlane_wa(dev_priv);
+ vlv_cmnlane_wa(i915);
mutex_unlock(&power_domains->lock);
- } else if (IS_IVYBRIDGE(dev_priv) || INTEL_GEN(dev_priv) >= 7)
- intel_pch_reset_handshake(dev_priv, !HAS_PCH_NOP(dev_priv));
+ } else if (IS_IVYBRIDGE(i915) || INTEL_GEN(i915) >= 7) {
+ intel_pch_reset_handshake(i915, !HAS_PCH_NOP(i915));
+ }
/*
* Keep all power wells enabled for any dependent HW access during
@@ -4054,18 +4055,20 @@ void intel_power_domains_init_hw(struct
drm_i915_private *dev_priv, bool resume)
* resources powered until display HW readout is complete. We drop
* this reference in intel_power_domains_enable().
*/
- intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
+ power_domains->wakeref =
+ intel_display_power_get(i915,
[Intel-gfx] [PATCH v2] drm/i915/cnl: Fix CNL macros for Voltage Swing programming
CNL macros for register groups CNL_PORT_TX_DW2_* / CNL_PORT_TX_DW5_* are
configured incorrectly wrt definition of _CNL_PORT_TX_DW_GRP.
v2: Jani suggested to keep the macros organized semantically i.e., by
function, secondarily by port/pipe/transcoder.->(dw, port)
Cc: Clint Taylor
Cc: Imre Deak
Cc: Jani Nikula
Signed-off-by: Aditya Swarup
---
There are still inconsistencies in some macro definitions. The macros
for MG phy registers are (port, ln) e.g.,
MG_TX2_LINK_PARAMS(port, ln) and also CNL_PORT_TX_DW4_LN(port, ln)
whereas for ICL -> _ICL_PORT_PCS_DW_LN(dw, ln, port).
Do you feel that we need to make these definitions consistent and what
should be the sequence -> (dw, ln, port)/(ln, port) or (dw, port, ln)/
(port,ln)?
drivers/gpu/drm/i915/i915_reg.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 44958d994bfa..fad5a9e8b44d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1814,7 +1814,7 @@ enum i915_power_well_id {
#define _CNL_PORT_TX_C_LN0_OFFSET 0x162C40
#define _CNL_PORT_TX_D_LN0_OFFSET 0x162E40
#define _CNL_PORT_TX_F_LN0_OFFSET 0x162840
-#define _CNL_PORT_TX_DW_GRP(port, dw) (_PICK((port), \
+#define _CNL_PORT_TX_DW_GRP(dw, port) (_PICK((port), \
_CNL_PORT_TX_AE_GRP_OFFSET, \
_CNL_PORT_TX_B_GRP_OFFSET, \
_CNL_PORT_TX_B_GRP_OFFSET, \
@@ -1822,7 +1822,7 @@ enum i915_power_well_id {
_CNL_PORT_TX_AE_GRP_OFFSET, \
_CNL_PORT_TX_F_GRP_OFFSET) + \
4 * (dw))
-#define _CNL_PORT_TX_DW_LN0(port, dw) (_PICK((port), \
+#define _CNL_PORT_TX_DW_LN0(dw, port) (_PICK((port), \
_CNL_PORT_TX_AE_LN0_OFFSET, \
_CNL_PORT_TX_B_LN0_OFFSET, \
_CNL_PORT_TX_B_LN0_OFFSET, \
@@ -1858,9 +1858,9 @@ enum i915_power_well_id {
#define _CNL_PORT_TX_DW4_LN0_AE0x162450
#define _CNL_PORT_TX_DW4_LN1_AE0x1624D0
-#define CNL_PORT_TX_DW4_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP((port), 4))
-#define CNL_PORT_TX_DW4_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0((port), 4))
-#define CNL_PORT_TX_DW4_LN(port, ln) _MMIO(_CNL_PORT_TX_DW_LN0((port), 4) + \
+#define CNL_PORT_TX_DW4_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(4, (port)))
+#define CNL_PORT_TX_DW4_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(4, (port)))
+#define CNL_PORT_TX_DW4_LN(port, ln) _MMIO(_CNL_PORT_TX_DW_LN0(4, (port)) + \
((ln) * (_CNL_PORT_TX_DW4_LN1_AE - \
_CNL_PORT_TX_DW4_LN0_AE)))
#define ICL_PORT_TX_DW4_AUX(port) _MMIO(_ICL_PORT_TX_DW_AUX(4, port))
@@ -1888,8 +1888,8 @@ enum i915_power_well_id {
#define RTERM_SELECT(x) ((x) << 3)
#define RTERM_SELECT_MASK(0x7 << 3)
-#define CNL_PORT_TX_DW7_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP((port), 7))
-#define CNL_PORT_TX_DW7_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0((port), 7))
+#define CNL_PORT_TX_DW7_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(7, (port)))
+#define CNL_PORT_TX_DW7_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(7, (port)))
#define ICL_PORT_TX_DW7_AUX(port) _MMIO(_ICL_PORT_TX_DW_AUX(7, port))
#define ICL_PORT_TX_DW7_GRP(port) _MMIO(_ICL_PORT_TX_DW_GRP(7, port))
#define ICL_PORT_TX_DW7_LN0(port) _MMIO(_ICL_PORT_TX_DW_LN(7, 0, port))
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/psr: Do not print last attempted entry or exit in PSR debugfs while in PSR2
On Wed, 2019-01-09 at 17:24 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> > PSR2 only trigger interruptions for AUX error, so let's not print
> > useless information in debugfs.
> > Also adding a comment to intel_psr_irq_handler() about that.
> >
> Is it worth keeping this stuff for PSR1 if PSR2 is not supported, did
> not work well enough for PSR1 IGTs either. In any case, are these
> interrupts present on ICL?
The PSR1 interrupts are present for ICL.
I guess I only used this once to debug PSR1 do you have used it, it was
useful? If not we should remove it as you suggested.
But anyway as Maarten commented in the previous patch, he suggested us
to follow the approach to test the real path when changing PSR state
from debugfs after enable fastboot. So I will hold this patch and the
previous one.
>
>
> > v2: Warning and not letting user set PSR_DEBUG_IRQ when PSR2 is
> > enabled(Dhinakaran)
> >
> > Cc: Rodrigo Vivi
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 6 +-
> > drivers/gpu/drm/i915/intel_psr.c| 1 +
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 77b097b50fd5..5ebf0e647ac7 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2621,7 +2621,7 @@ static int i915_edp_psr_status(struct
> > seq_file
> > *m, void *data)
> > seq_printf(m, "Performance counter: %u\n", val);
> > }
> >
> > - if (psr->debug & I915_PSR_DEBUG_IRQ) {
> > + if ((psr->debug & I915_PSR_DEBUG_IRQ) && !psr->psr2_enabled) {
> Is there a case where PSR2 and IRQ debug are enabled now that you
> disallow setting of this value?
>
>
> > seq_printf(m, "Last attempted entry at: %lld\n",
> >psr->last_entry_attempt);
> > seq_printf(m, "Last exit at: %lld\n", psr->last_exit);
> > @@ -2676,6 +2676,10 @@ i915_edp_psr_debug_set(void *data, u64 val)
> > skip_mode:
> > if (!ret) {
> > mutex_lock(&dev_priv->psr.lock);
> > + if (dev_priv->psr.psr2_enabled && (val &
> > I915_PSR_DEBUG_IRQ)) {
> > + val &= ~I915_PSR_DEBUG_IRQ;
> > + DRM_WARN("PSR debug IRQ cannot be enabled with
> > PSR2");
>
> WARN is inconsistent with DEBUG level logging that this function
> already uses.
I guess in this case a warn is necessary otherwise if user din't had
increase the drm debug level and tried to enable PSR IRQ interruptions
while PSR2 is actived, this user would not get any error or warning.
>
> > + }
> > dev_priv->psr.debug = val;
> > intel_psr_irq_control(dev_priv, dev_priv->psr.debug);
> We are accessing hardware outside of rpm_get()/rpm_put() here.
nice catch.
Thanks
>
>
> > mutex_unlock(&dev_priv->psr.lock);
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index bba4f7da68b3..a875546880fa 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -201,6 +201,7 @@ void intel_psr_irq_handler(struct
> > drm_i915_private *dev_priv, u32 psr_iir)
> > mask |= EDP_PSR_ERROR(shift);
> > }
> >
> > + /* PSR2 don't trigger PRE_ENTRY and POST_EXIT
> > interruptions */
> > if (psr_iir & EDP_PSR_PRE_ENTRY(shift)) {
> > dev_priv->psr.last_entry_attempt = time_ns;
> > DRM_DEBUG_KMS("[transcoder %s] PSR entry
> > attempt in 2 vblanks\n",
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Add PSR2 selective update status registers and bits definitions
On Wed, 2019-01-09 at 18:18 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> > This register contains how many blocks was sent in the past
> > selective
> > updates.
> > Those registers are not kept set all the times but pulling it
> > after
> I suppose you mean 'polling'.
Exacly that, thanks for catching this up.
>
> > flip
> > can show that the expected values are set for the current frame and
> > the
> > previous ones too.
> The values correspond to the last 8 frames actually.
changed
>
> > v2: Improved macros(Dhinakaran)
> Reviewed-by: Dhinakaran Pandiyan
Thanks
>
> > Cc: Rodrigo Vivi
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 44958d994bfa..f9712d05314b 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4272,6 +4272,15 @@ enum {
> > #define EDP_PSR2_STATUS_STATE_MASK (0xf << 28)
> > #define EDP_PSR2_STATUS_STATE_SHIFT28
> >
> > +#define _PSR2_SU_STATUS_0 0x6F914
> > +#define _PSR2_SU_STATUS_1 0x6F918
> > +#define _PSR2_SU_STATUS_2 0x6F91C
> > +#define _PSR2_SU_STATUS(index) _MMIO(_PICK_EVEN((index
> > ), _PSR2_SU_STATUS_0, _PSR2_SU_STATUS_1))
> > +#define PSR2_SU_STATUS(frame) (_PSR2_SU_STATUS((frame
> > ) / 3))
> > +#define PSR2_SU_STATUS_SHIFT(frame)(((frame) % 3) * 10)
> > +#define PSR2_SU_STATUS_MASK(frame) (0x3ff <<
> > PSR2_SU_STATUS_SHIFT(frame))
> > +#define PSR2_SU_STATUS_FRAMES 8
> > +
> > /* VGA port control */
> > #define ADPA _MMIO(0x61100)
> > #define PCH_ADPA_MMIO(0xe1100)
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 2/6] drm/i915: Sanitize crtc gamma mode
On Tue, Jan 08, 2019 at 01:07:29PM +0530, Uma Shankar wrote:
> Sanitize crtc gamma mode and update the mode in driver in case
> BIOS has setup a different gamma mode as to what is expected by
> driver. There is restriction on HSW platform not to read/write
> color LUT's if ips is enabled. Handled the same accordingly.
>
> Credits-to: Matt Roper
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_display.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 696e6f5..03c8f68 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15401,6 +15401,23 @@ static void intel_sanitize_crtc(struct intel_crtc
> *crtc,
> }
> }
>
> + /*
> + * Sanitize gamma mode incase BIOS leaves it in SPLIT GAMMA MODE
> + * Workaround HSW : Do not read or write the pipe palette/gamma data
> + * while GAMMA_MODE is configured for split gamma and IPS_CTL has IPS
> + * enabled.
> + */
The other thing that might be worth noting here is that we don't
actually try to read out the LUT's and CTM that the BIOS setup, so at
the moment they stick around for a while until the get unexpectedly
clobbered by a subsequent modeset or fastset. The change here will
basically force them to be reset to standard/linear values at startup.
Maybe in the future we'll try to actually read out and preserve the
contents of the actual LUT's and CTM that the BIOS had setup, but we
don't do that yet today, so the change here at least makes the behavior
a little bit more consistent than what it has been.
Up to you whether you want to try to describe that in either the comment
and/or commit message.
> + if (IS_HASWELL(dev_priv)) {
> + if (crtc_state->ips_enabled)
It looks like both hsw_disable_ips() and hsw_enable_ips() have this test
inside of them already, so we can just call them unconditionally here.
Aside from that,
Reviewed-by: Matt Roper
> + hsw_disable_ips(crtc_state);
> +
> + intel_color_set_csc(crtc_state);
> + intel_color_load_luts(crtc_state);
> +
> + if (crtc_state->ips_enabled)
> + hsw_enable_ips(crtc_state);
> + }
> +
> /* Adjust the state of the output pipe according to whether we
>* have active connectors/encoders. */
> if (crtc_state->base.active && !intel_crtc_has_encoders(crtc))
> --
> 1.9.1
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/debugfs: Print PSR selective update status register values
On Wed, 2019-01-09 at 18:11 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> > The value of this registers will be used to test if PSR2 is doing
> > selective update and if the number of blocks match with the
> > expected.
> >
> > v2:
> > - Using new macros
> > - Changed the string output
> >
> > Cc: Rodrigo Vivi
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 32 +
> >
> > 1 file changed, 28 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 5ebf0e647ac7..4e92078bc65d 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2621,10 +2621,34 @@ static int i915_edp_psr_status(struct
> > seq_file *m, void *data)
> > seq_printf(m, "Performance counter: %u\n", val);
> > }
> >
> > - if ((psr->debug & I915_PSR_DEBUG_IRQ) && !psr->psr2_enabled) {
> > - seq_printf(m, "Last attempted entry at: %lld\n",
> > - psr->last_entry_attempt);
> > - seq_printf(m, "Last exit at: %lld\n", psr->last_exit);
> > + if (!psr->psr2_enabled) {
> > + if (psr->debug & I915_PSR_DEBUG_IRQ) {
> > + seq_printf(m, "Last attempted entry at:
> > %lld\n",
> > + psr->last_entry_attempt);
> > + seq_printf(m, "Last exit at: %lld\n", psr-
> > > last_exit);
> > + }
> > + } else {
> > + u8 frame;
> > +
> > + seq_puts(m, "Frame:\tPSR2 SU blocks:\n");
> > +
> > + for (frame = 0; frame < PSR2_SU_STATUS_FRAMES; frame++)
> > {
> > + u32 su_blocks;
> > +
> > + /*
> > +* Avoid register reads as each register
> > contains more
> > +* than one frame value
> > +*/
> I don't think the comment is needed, but if you want to retain it I
> suggest explicitly saying each register contains data for three
> frames?
The last one have only 2 frames.
>
> Not sure if it matters, how about completing all the three register
> reads before printing so that we reduce the chances of crossing a
> frame
> boundary between register reads?
Hum sounds good, I will do that.
>
> > + if ((frame % 3) == 0)
> > + val = I915_READ(PSR2_SU_STATUS(frame));
> > +
> > + su_blocks = val & PSR2_SU_STATUS_MASK(frame);
> > + su_blocks = su_blocks >>
> > PSR2_SU_STATUS_SHIFT(frame);
> > + /* Only printing frames with SU blocks */
> > + if (!su_blocks)
> > + continue;
> Why not print zero if that's the number of blocks updated in a frame?
I think 8 frames with value zero are not worth to print everytime and
IGT will only care about the frame 0 but I don't see any problem in
printing it.
>
> > + seq_printf(m, "%d\t%d\n", frame, su_blocks);
> > + }
> > }
> >
> > unlock:
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 1/6] drm/i915: Check for Null for color lut callbacks
On Tue, Jan 08, 2019 at 01:07:28PM +0530, Uma Shankar wrote: > Check if de-gamma/gamma lut callback is assigned before > calling the same. > > Signed-off-by: Uma Shankar Is it possible for this test to fail? intel_color_init() seems to always assign a value (even for platforms that don't actually support color management). It seem like if you're going to make this change, you'd also want to update intel_color_init() to only set the load_luts for platforms where we actually have color management? Matt > --- > drivers/gpu/drm/i915/intel_color.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_color.c > b/drivers/gpu/drm/i915/intel_color.c > index 37fd9dd..4ff4db6 100644 > --- a/drivers/gpu/drm/i915/intel_color.c > +++ b/drivers/gpu/drm/i915/intel_color.c > @@ -602,7 +602,8 @@ void intel_color_load_luts(struct intel_crtc_state > *crtc_state) > struct drm_device *dev = crtc_state->base.crtc->dev; > struct drm_i915_private *dev_priv = to_i915(dev); > > - dev_priv->display.load_luts(crtc_state); > + if (dev_priv->display.load_luts) > + dev_priv->display.load_luts(crtc_state); > } > > int intel_color_check(struct intel_crtc_state *crtc_state) > -- > 1.9.1 > -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/hangman: Skip if disabled by the kernel
On 10/01/19 01:19, Chris Wilson wrote: Some kernels may have to disable error capture for some hardware or by it being configured out. Since it is conditionally available, asserting it exists is not an actual requirement. For hardware where we are unable to provide error state capture, skip. Signed-off-by: Chris Wilson LGTM. Acked-by: Antonio Argenziano ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ctx_isolation: Ignore the low bits of BB_OFFSET
On 10/01/19 13:29, Chris Wilson wrote:
Quoting Chris Wilson (2019-01-10 21:27:54)
Quoting Antonio Argenziano (2019-01-10 21:24:56)
On 07/01/19 04:41, Chris Wilson wrote:
On Skylake, BB_OFFSET seems to be unstable. Since this is an
offset into the batch at the time of CS execution, it should be actively
written to as we read from the register so allow it a qword of
discrepancy (since the CS should be reading in qwords). This still
allows us to detect dirt across the rest of the register field, should
that be required.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_isolation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index 058cf3ec1..78a244382 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -96,7 +96,7 @@ static const struct named_register {
{ "GPGPU_THREADS_DISPATCHED", GEN8, RCS0, 0x2290, 2 },
{ "PS_INVOCATION_COUNT_1", GEN8, RCS0, 0x22f0, 2 },
{ "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
- { "BB_OFFSET", GEN8, RCS0, 0x2158 },
+ { "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
The batch offset starts at bit 2. Do we observe changes in bit 0-1 as well?
Not, it is just off by bit 2 (0x4). Bit 0 is also set when I don't
really expect it to be, I guess I really should just read what the
register is meant to be rather than guessing solely on the basis of its
name.
Bit 2 flip flops between reference value and observed (test failure).
Bit 0 simply differs from my own expectations.
I guess if it gets overwritten we catch it even if we ignore the lowest
3 bits but something weird would have happened if 0-1 change.
With or without modifying the mask,
Reviewed-by: Antonio Argenziano
-Chris
___
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/i915: Infoframe precompute/check (rev6)
== Series Details == Series: drm/i915: Infoframe precompute/check (rev6) URL : https://patchwork.freedesktop.org/series/49983/ State : success == Summary == CI Bug Log - changes from CI_DRM_5397 -> Patchwork_11276 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49983/revisions/6/mbox/ Known issues Here are the changes found in Patchwork_11276 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: INCOMPLETE [fdo#108602] / [fdo#108744] -> PASS * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: DMESG-WARN [fdo#102614] -> PASS - fi-byt-clapper: FAIL [fdo#103167] -> PASS * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1 [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 Participating hosts (45 -> 43) -- Additional (1): fi-cfl-guc Missing(3): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan Build changes - * Linux: CI_DRM_5397 -> Patchwork_11276 CI_DRM_5397: a1223ccb14ff4b404a9da093b1d7c6e004061f3d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4758: f01796214bbde31e37b0593e547ad9436fdd02ba @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11276: 9001c20d8b45bc656791084d0d1130bbd59368b9 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9001c20d8b45 drm/i915: Include infoframes in the crtc state dump f802c4ece27d drm/i915: Check infoframe state in intel_pipe_config_compare() fa53030c96bd drm/i915/sdvo: Read out HDMI infoframes 682f7057056f drm/i915/sdvo: Precompute HDMI infoframes de67cbe439b3 drm/i915: Read out HDMI infoframes 7e9d46898d0b drm/i915: Precompute HDMI infoframes 6e2a572a0cf7 drm/i915: Store mask of enabled infoframes in the crtc state 91809e28ac87 drm/i915: Return the mask of enabled infoframes from ->inforame_enabled() 94c8aca5d9c0 drm/i915: Add the missing HDMI gamut metadata packet stuff 5bf207115074 video/hdmi: Add an enum for HDMI packet types == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11276/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] tg3 vs commit 2b3e88ea6528 ("net: phy: improve phy state checking")
On 09.01.2019 14:11, Chris Wilson wrote: > Hi, we've hit a snag with > > commit 2b3e88ea65287ba738a798622405b15344871085 > Author: Heiner Kallweit > Date: Sun Dec 16 18:30:14 2018 +0100 > > net: phy: improve phy state checking > > as it is detecting that the call from tg3 during suspend is from the > HALTED state. > > <4> [74.170194] [ cut here ] > <4> [74.170220] called from state HALTED > <4> [74.170237] WARNING: CPU: 3 PID: 2473 at drivers/net/phy/phy.c:548 > phy_start_aneg+0xf1/0x140 > <4> [74.170239] Modules linked in: vgem snd_hda_codec_hdmi > snd_hda_codec_realtek snd_hda_codec_generic asix usbnet mii i915 > x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core > broadcom bcm_phy_lib snd_pcm tg3 mei_me i2c_i801 mei prime_numbers lpc_ich > <4> [74.170258] CPU: 3 PID: 2473 Comm: kworker/u16:22 Tainted: G U > 5.0.0-rc1-CI-CI_DRM_5366+ #1 > <4> [74.170260] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 > 10/17/2011 > <4> [74.170264] Workqueue: events_unbound async_run_entry_fn > <4> [74.170269] RIP: 0010:phy_start_aneg+0xf1/0x140 > <4> [74.170271] Code: 10 89 93 d0 04 00 00 0f b6 40 04 89 83 d4 04 00 00 e9 > 74 ff ff ff 48 8b 34 c5 20 a7 ed 81 48 c7 c7 a6 7c 11 82 e8 9f 94 9d ff <0f> > 0b 41 bc f0 ff ff ff eb 91 80 a3 c0 04 00 00 7f eb a3 48 b8 ff > <4> [74.170273] RSP: 0018:c944bc80 EFLAGS: 00010282 > <4> [74.170276] RAX: RBX: 888216e38958 RCX: > > <4> [74.170278] RDX: RSI: 8213044a RDI: > > <4> [74.170280] RBP: 888216e38f00 R08: c14614ba R09: > > <4> [74.170282] R10: c944bc80 R11: R12: > 888216e38958 > <4> [74.170284] R13: R14: 888223655f28 R15: > 88821af6da58 > <4> [74.170287] FS: () GS:888227ac() > knlGS: > <4> [74.170289] CS: 0010 DS: ES: CR0: 80050033 > <4> [74.170291] CR2: 55f1dae80d80 CR3: 02214006 CR4: > 000606e0 > <4> [74.170293] Call Trace: > <4> [74.170301] tg3_power_down_prepare+0x754/0xa30 [tg3] > <4> [74.170308] tg3_suspend+0x1e5/0x350 [tg3] > <4> [74.170316] pci_pm_suspend+0x6d/0x120 > <4> [74.170319] ? pci_pm_freeze+0xc0/0xc0 > <4> [74.170324] dpm_run_callback+0x64/0x280 > <4> [74.170330] __device_suspend+0x12a/0x5b0 > <4> [74.170335] ? dpm_watchdog_set+0x60/0x60 > <4> [74.170344] async_suspend+0x15/0x90 > <4> [74.170347] async_run_entry_fn+0x34/0x160 > <4> [74.170352] process_one_work+0x245/0x610 > <4> [74.170360] worker_thread+0x37/0x380 > <4> [74.170365] ? process_one_work+0x610/0x610 > <4> [74.170368] kthread+0x119/0x130 > <4> [74.170371] ? kthread_park+0x80/0x80 > <4> [74.170377] ret_from_fork+0x3a/0x50 > <4> [74.170388] irq event stamp: 648 > <4> [74.170392] hardirqs last enabled at (647): [] > vprintk_emit+0x302/0x320 > <4> [74.170396] hardirqs last disabled at (648): [] > trace_hardirqs_off_thunk+0x1a/0x1c > <4> [74.170399] softirqs last enabled at (626): [] > __do_softirq+0x33a/0x4b9 > <4> [74.170402] softirqs last disabled at (605): [] > do_softirq_own_stack+0x2a/0x40 > <4> [74.170405] WARNING: CPU: 3 PID: 2473 at drivers/net/phy/phy.c:548 > phy_start_aneg+0xf1/0x140 > <4> [74.170407] ---[ end trace e382359f2ec4f600 ]--- > > Previously phy_start_aneg() would handle the HALTED state but now it is > a warning. To maintain coverage in our (intel-gfx) CI, we've locally > reverted 2b3e88ea6528. > -Chris > We added a few warnings to detect wrong usage of the phylib API. This check seems to be a little bit too strict. I just submitted a fix. Still this helped to find an unneeded call to phy_start_aneg. In tg3_phy_start() there's no need to call phy_start_aneg() after phy_start(), this is done implicitly by phylib. Heiner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Infoframe precompute/check (rev6)
== Series Details == Series: drm/i915: Infoframe precompute/check (rev6) URL : https://patchwork.freedesktop.org/series/49983/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: video/hdmi: Add an enum for HDMI packet types Okay! Commit: drm/i915: Add the missing HDMI gamut metadata packet stuff Okay! Commit: drm/i915: Return the mask of enabled infoframes from ->inforame_enabled() Okay! Commit: drm/i915: Store mask of enabled infoframes in the crtc state Okay! Commit: drm/i915: Precompute HDMI infoframes Okay! Commit: drm/i915: Read out HDMI infoframes Okay! Commit: drm/i915/sdvo: Precompute HDMI infoframes Okay! Commit: drm/i915/sdvo: Read out HDMI infoframes +drivers/gpu/drm/i915/intel_sdvo.c:1020:21: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_sdvo.c:1020:21: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_sdvo.c:1026:47: warning: expression using sizeof(void) Commit: drm/i915: Check infoframe state in intel_pipe_config_compare() Okay! Commit: drm/i915: Include infoframes in the crtc state dump Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Infoframe precompute/check (rev6)
== Series Details ==
Series: drm/i915: Infoframe precompute/check (rev6)
URL : https://patchwork.freedesktop.org/series/49983/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5bf207115074 video/hdmi: Add an enum for HDMI packet types
94c8aca5d9c0 drm/i915: Add the missing HDMI gamut metadata packet stuff
-:46: WARNING:LONG_LINE: line over 100 characters
#46: FILE: drivers/gpu/drm/i915/i915_reg.h:8079:
+#define HSW_TVIDEO_DIP_GMP_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_GMP_DATA_A + (i) * 4)
total: 0 errors, 1 warnings, 0 checks, 64 lines checked
91809e28ac87 drm/i915: Return the mask of enabled infoframes from
->inforame_enabled()
6e2a572a0cf7 drm/i915: Store mask of enabled infoframes in the crtc state
7e9d46898d0b drm/i915: Precompute HDMI infoframes
de67cbe439b3 drm/i915: Read out HDMI infoframes
682f7057056f drm/i915/sdvo: Precompute HDMI infoframes
fa53030c96bd drm/i915/sdvo: Read out HDMI infoframes
f802c4ece27d drm/i915: Check infoframe state in intel_pipe_config_compare()
-:72: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible
side-effects?
#72: FILE: drivers/gpu/drm/i915/intel_display.c:11836:
+#define PIPE_CONF_CHECK_INFOFRAME(name) do { \
+ if (!intel_compare_infoframe(¤t_config->infoframes.name, \
+&pipe_config->infoframes.name)) { \
+ pipe_config_infoframe_err(dev_priv, adjust, __stringify(name), \
+ ¤t_config->infoframes.name, \
+ &pipe_config->infoframes.name); \
+ ret = false; \
+ } \
+} while (0)
total: 0 errors, 0 warnings, 1 checks, 67 lines checked
9001c20d8b45 drm/i915: Include infoframes in the crtc state dump
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ctx_isolation: Ignore the low bits of BB_OFFSET
Quoting Chris Wilson (2019-01-10 21:27:54)
> Quoting Antonio Argenziano (2019-01-10 21:24:56)
> >
> >
> > On 07/01/19 04:41, Chris Wilson wrote:
> > > On Skylake, BB_OFFSET seems to be unstable. Since this is an
> > > offset into the batch at the time of CS execution, it should be actively
> > > written to as we read from the register so allow it a qword of
> > > discrepancy (since the CS should be reading in qwords). This still
> > > allows us to detect dirt across the rest of the register field, should
> > > that be required.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > tests/i915/gem_ctx_isolation.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tests/i915/gem_ctx_isolation.c
> > > b/tests/i915/gem_ctx_isolation.c
> > > index 058cf3ec1..78a244382 100644
> > > --- a/tests/i915/gem_ctx_isolation.c
> > > +++ b/tests/i915/gem_ctx_isolation.c
> > > @@ -96,7 +96,7 @@ static const struct named_register {
> > > { "GPGPU_THREADS_DISPATCHED", GEN8, RCS0, 0x2290, 2 },
> > > { "PS_INVOCATION_COUNT_1", GEN8, RCS0, 0x22f0, 2 },
> > > { "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
> > > - { "BB_OFFSET", GEN8, RCS0, 0x2158 },
> > > + { "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
> >
> > The batch offset starts at bit 2. Do we observe changes in bit 0-1 as well?
>
> Not, it is just off by bit 2 (0x4). Bit 0 is also set when I don't
> really expect it to be, I guess I really should just read what the
> register is meant to be rather than guessing solely on the basis of its
> name.
Bit 2 flip flops between reference value and observed (test failure).
Bit 0 simply differs from my own expectations.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ctx_isolation: Ignore the low bits of BB_OFFSET
Quoting Antonio Argenziano (2019-01-10 21:24:56)
>
>
> On 07/01/19 04:41, Chris Wilson wrote:
> > On Skylake, BB_OFFSET seems to be unstable. Since this is an
> > offset into the batch at the time of CS execution, it should be actively
> > written to as we read from the register so allow it a qword of
> > discrepancy (since the CS should be reading in qwords). This still
> > allows us to detect dirt across the rest of the register field, should
> > that be required.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/i915/gem_ctx_isolation.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
> > index 058cf3ec1..78a244382 100644
> > --- a/tests/i915/gem_ctx_isolation.c
> > +++ b/tests/i915/gem_ctx_isolation.c
> > @@ -96,7 +96,7 @@ static const struct named_register {
> > { "GPGPU_THREADS_DISPATCHED", GEN8, RCS0, 0x2290, 2 },
> > { "PS_INVOCATION_COUNT_1", GEN8, RCS0, 0x22f0, 2 },
> > { "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
> > - { "BB_OFFSET", GEN8, RCS0, 0x2158 },
> > + { "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
>
> The batch offset starts at bit 2. Do we observe changes in bit 0-1 as well?
Not, it is just off by bit 2 (0x4). Bit 0 is also set when I don't
really expect it to be, I guess I really should just read what the
register is meant to be rather than guessing solely on the basis of its
name.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ctx_isolation: Ignore the low bits of BB_OFFSET
On 07/01/19 04:41, Chris Wilson wrote:
On Skylake, BB_OFFSET seems to be unstable. Since this is an
offset into the batch at the time of CS execution, it should be actively
written to as we read from the register so allow it a qword of
discrepancy (since the CS should be reading in qwords). This still
allows us to detect dirt across the rest of the register field, should
that be required.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_isolation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index 058cf3ec1..78a244382 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -96,7 +96,7 @@ static const struct named_register {
{ "GPGPU_THREADS_DISPATCHED", GEN8, RCS0, 0x2290, 2 },
{ "PS_INVOCATION_COUNT_1", GEN8, RCS0, 0x22f0, 2 },
{ "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
- { "BB_OFFSET", GEN8, RCS0, 0x2158 },
+ { "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
The batch offset starts at bit 2. Do we observe changes in bit 0-1 as well?
Antonio
{ "MI_PREDICATE_RESULT_1", GEN8, RCS0, 0x241c },
{ "CS_GPR", GEN8, RCS0, 0x2600, 32 },
{ "OA_CTX_CONTROL", GEN8, RCS0, 0x2360 },
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 02/10] drm/i915: Add the missing HDMI gamut metadata packet stuff
From: Ville Syrjälä
We have definitions and low level code for everything except the gamut
metadata HDMI packet. Add the missing bits.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h | 8 +---
drivers/gpu/drm/i915/intel_hdmi.c | 12
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 44958d994bfa..41d07bb847e3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4600,13 +4600,14 @@ enum {
#define VIDEO_DIP_ENABLE (1 << 31)
#define VIDEO_DIP_PORT(port) ((port) << 29)
#define VIDEO_DIP_PORT_MASK (3 << 29)
-#define VIDEO_DIP_ENABLE_GCP (1 << 25)
+#define VIDEO_DIP_ENABLE_GCP (1 << 25) /* ilk+ */
#define VIDEO_DIP_ENABLE_AVI (1 << 21)
#define VIDEO_DIP_ENABLE_VENDOR (2 << 21)
-#define VIDEO_DIP_ENABLE_GAMUT (4 << 21)
+#define VIDEO_DIP_ENABLE_GAMUT (4 << 21) /* ilk+ */
#define VIDEO_DIP_ENABLE_SPD (8 << 21)
#define VIDEO_DIP_SELECT_AVI (0 << 19)
#define VIDEO_DIP_SELECT_VENDOR (1 << 19)
+#define VIDEO_DIP_SELECT_GAMUT (2 << 19)
#define VIDEO_DIP_SELECT_SPD (3 << 19)
#define VIDEO_DIP_SELECT_MASK(3 << 19)
#define VIDEO_DIP_FREQ_ONCE (0 << 16)
@@ -8071,10 +8072,11 @@ enum {
#define _ICL_VIDEO_DIP_PPS_ECC_B 0x613D4
#define HSW_TVIDEO_DIP_CTL(trans) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_CTL_A)
+#define HSW_TVIDEO_DIP_GCP(trans) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_GCP_A)
#define HSW_TVIDEO_DIP_AVI_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_AVI_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_VS_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_VS_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_SPD_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_SPD_DATA_A + (i) * 4)
-#define HSW_TVIDEO_DIP_GCP(trans) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_GCP_A)
+#define HSW_TVIDEO_DIP_GMP_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_GMP_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_VSC_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_VSC_DATA_A + (i) * 4)
#define ICL_VIDEO_DIP_PPS_DATA(trans, i) _MMIO_TRANS2(trans,
_ICL_VIDEO_DIP_PPS_DATA_A + (i) * 4)
#define ICL_VIDEO_DIP_PPS_ECC(trans, i)_MMIO_TRANS2(trans,
_ICL_VIDEO_DIP_PPS_ECC_A + (i) * 4)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index f819027f3ae5..74b246fef08d 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -82,6 +82,8 @@ static struct intel_hdmi *intel_attached_hdmi(struct
drm_connector *connector)
static u32 g4x_infoframe_index(unsigned int type)
{
switch (type) {
+ case HDMI_PACKET_TYPE_GAMUT_METADATA:
+ return VIDEO_DIP_SELECT_GAMUT;
case HDMI_INFOFRAME_TYPE_AVI:
return VIDEO_DIP_SELECT_AVI;
case HDMI_INFOFRAME_TYPE_SPD:
@@ -97,6 +99,10 @@ static u32 g4x_infoframe_index(unsigned int type)
static u32 g4x_infoframe_enable(unsigned int type)
{
switch (type) {
+ case HDMI_PACKET_TYPE_GENERAL_CONTROL:
+ return VIDEO_DIP_ENABLE_GCP;
+ case HDMI_PACKET_TYPE_GAMUT_METADATA:
+ return VIDEO_DIP_ENABLE_GAMUT;
case HDMI_INFOFRAME_TYPE_AVI:
return VIDEO_DIP_ENABLE_AVI;
case HDMI_INFOFRAME_TYPE_SPD:
@@ -112,6 +118,10 @@ static u32 g4x_infoframe_enable(unsigned int type)
static u32 hsw_infoframe_enable(unsigned int type)
{
switch (type) {
+ case HDMI_PACKET_TYPE_GENERAL_CONTROL:
+ return VIDEO_DIP_ENABLE_GCP_HSW;
+ case HDMI_PACKET_TYPE_GAMUT_METADATA:
+ return VIDEO_DIP_ENABLE_GMP_HSW;
case DP_SDP_VSC:
return VIDEO_DIP_ENABLE_VSC_HSW;
case DP_SDP_PPS:
@@ -135,6 +145,8 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
int i)
{
switch (type) {
+ case HDMI_PACKET_TYPE_GAMUT_METADATA:
+ return HSW_TVIDEO_DIP_GMP_DATA(cpu_transcoder, i);
case DP_SDP_VSC:
return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i);
case DP_SDP_PPS:
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 06/10] drm/i915: Read out HDMI infoframes
From: Ville Syrjälä
Add code to read the infoframes from the video DIP and unpack them into
the crtc state.
v2: Make the read funcs return void (Daniel)
Drop the duplicate infoframe enabled checks (Daniel)
Add a FIXME for lspcon infoframe readout
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c| 12 ++
drivers/gpu/drm/i915/intel_drv.h| 14 +++
drivers/gpu/drm/i915/intel_hdmi.c | 172
drivers/gpu/drm/i915/intel_lspcon.c | 8 ++
4 files changed, 206 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 62125a4c130c..bec107646d3b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3812,6 +3812,18 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
bxt_ddi_phy_get_lane_lat_optim_mask(encoder);
intel_ddi_compute_min_voltage_level(dev_priv, pipe_config);
+
+ intel_hdmi_read_gcp_infoframe(encoder, pipe_config);
+
+ intel_read_infoframe(encoder, pipe_config,
+HDMI_INFOFRAME_TYPE_AVI,
+&pipe_config->infoframes.avi);
+ intel_read_infoframe(encoder, pipe_config,
+HDMI_INFOFRAME_TYPE_SPD,
+&pipe_config->infoframes.spd);
+ intel_read_infoframe(encoder, pipe_config,
+HDMI_INFOFRAME_TYPE_VENDOR,
+&pipe_config->infoframes.hdmi);
}
static enum intel_output_type
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fb7cf55865ea..9b165259f5ff 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1254,6 +1254,10 @@ struct intel_digital_port {
const struct intel_crtc_state *crtc_state,
unsigned int type,
const void *frame, ssize_t len);
+ void (*read_infoframe)(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ unsigned int type,
+ void *frame, ssize_t len);
void (*set_infoframes)(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
@@ -1995,6 +1999,12 @@ void intel_infoframe_init(struct intel_digital_port
*intel_dig_port);
u32 intel_hdmi_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state);
u32 intel_hdmi_infoframe_enable(unsigned int type);
+void intel_hdmi_read_gcp_infoframe(struct intel_encoder *encoder,
+ struct intel_crtc_state *crtc_state);
+void intel_read_infoframe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ enum hdmi_infoframe_type type,
+ union hdmi_infoframe *frame);
/* intel_lvds.c */
bool intel_lvds_port_enabled(struct drm_i915_private *dev_priv,
@@ -2359,6 +2369,10 @@ void lspcon_write_infoframe(struct intel_encoder
*encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
const void *buf, ssize_t len);
+void lspcon_read_infoframe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ unsigned int type,
+ void *frame, ssize_t len);
void lspcon_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index ab0ba24b9546..f860e37e6cb8 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -214,6 +214,26 @@ static void g4x_write_infoframe(struct intel_encoder
*encoder,
POSTING_READ(VIDEO_DIP_CTL);
}
+static void g4x_read_infoframe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ unsigned int type,
+ void *frame, ssize_t len)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ u32 val, *data = frame;
+ int i;
+
+ val = I915_READ(VIDEO_DIP_CTL);
+
+ val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
+ val |= g4x_infoframe_index(type);
+
+ I915_WRITE(VIDEO_DIP_CTL, val);
+
+ for (i = 0; i < len; i += 4)
+ *data++ = I915_READ(VIDEO_DIP_DATA);
+}
+
static u32 g4x_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pi
[Intel-gfx] [PATCH v2 04/10] drm/i915: Store mask of enabled infoframes in the crtc state
From: Ville Syrjälä
Store the mask of enabled infoframes in the crtc state. We'll start
with just the readout for HDMI encoder, and we'll expand this
to compute the bitmask in .compute_config() later. SDVO will also
follow later.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 5 -
drivers/gpu/drm/i915/intel_drv.h | 4
drivers/gpu/drm/i915/intel_hdmi.c | 5 -
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index b816ad11cb58..62125a4c130c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3745,7 +3745,10 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
pipe_config->has_hdmi_sink = true;
intel_dig_port = enc_to_dig_port(&encoder->base);
- if (intel_hdmi_infoframes_enabled(encoder, pipe_config))
+ pipe_config->infoframes.enable |=
+ intel_hdmi_infoframes_enabled(encoder, pipe_config);
+
+ if (pipe_config->infoframes.enable)
pipe_config->has_infoframe = true;
if (temp & TRANS_DDI_HDMI_SCRAMBLING)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7b3612007f50..a381b78f6722 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -934,6 +934,10 @@ struct intel_crtc_state {
/* bitmask of planes that will be updated during the commit */
u8 update_planes;
+ struct {
+ u32 enable;
+ } infoframes;
+
/* HDMI scrambling status */
bool hdmi_scrambling;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index fe6cf487e12e..a7d5bb43b835 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1274,7 +1274,10 @@ static void intel_hdmi_get_config(struct intel_encoder
*encoder,
if (tmp & HDMI_MODE_SELECT_HDMI)
pipe_config->has_hdmi_sink = true;
- if (intel_hdmi_infoframes_enabled(encoder, pipe_config))
+ pipe_config->infoframes.enable |=
+ intel_hdmi_infoframes_enabled(encoder, pipe_config);
+
+ if (pipe_config->infoframes.enable)
pipe_config->has_infoframe = true;
if (tmp & SDVO_AUDIO_ENABLE)
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 09/10] drm/i915: Check infoframe state in intel_pipe_config_compare()
From: Ville Syrjälä
Check the infoframes and infoframe enable state when comparing two
crtc states.
We'll use the infoframe logging functions from video/hdmi.c to
show the infoframes as part of the state dump.
TODO: Try to better integrate the infoframe dumps with
drm state dumps
v2: drm_printk() is no more
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 49 +++-
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1cc441f06c73..8c05084e5308 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11641,6 +11641,37 @@ intel_compare_link_m_n(const struct intel_link_m_n
*m_n,
return false;
}
+static bool
+intel_compare_infoframe(const union hdmi_infoframe *a,
+ const union hdmi_infoframe *b)
+{
+ return memcmp(a, b, sizeof(*a)) == 0;
+}
+
+static void
+pipe_config_infoframe_err(struct drm_i915_private *dev_priv,
+ bool adjust, const char *name,
+ const union hdmi_infoframe *a,
+ const union hdmi_infoframe *b)
+{
+ if (adjust) {
+ if ((drm_debug & DRM_UT_KMS) == 0)
+ return;
+
+ drm_dbg(DRM_UT_KMS, "mismatch in %s infoframe", name);
+ drm_dbg(DRM_UT_KMS, "expected:");
+ hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, a);
+ drm_dbg(DRM_UT_KMS, "found");
+ hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, b);
+ } else {
+ drm_err("mismatch in %s infoframe", name);
+ drm_err("expected:");
+ hdmi_infoframe_log(KERN_ERR, dev_priv->drm.dev, a);
+ drm_err("found");
+ hdmi_infoframe_log(KERN_ERR, dev_priv->drm.dev, b);
+ }
+}
+
static void __printf(3, 4)
pipe_config_err(bool adjust, const char *name, const char *format, ...)
{
@@ -11802,7 +11833,17 @@ intel_pipe_config_compare(struct drm_i915_private
*dev_priv,
} \
} while (0)
-#define PIPE_CONF_QUIRK(quirk) \
+#define PIPE_CONF_CHECK_INFOFRAME(name) do { \
+ if (!intel_compare_infoframe(¤t_config->infoframes.name, \
+&pipe_config->infoframes.name)) { \
+ pipe_config_infoframe_err(dev_priv, adjust, __stringify(name), \
+ ¤t_config->infoframes.name, \
+ &pipe_config->infoframes.name); \
+ ret = false; \
+ } \
+} while (0)
+
+#define PIPE_CONF_QUIRK(quirk) \
((current_config->quirks | pipe_config->quirks) & (quirk))
PIPE_CONF_CHECK_I(cpu_transcoder);
@@ -11931,6 +11972,12 @@ intel_pipe_config_compare(struct drm_i915_private
*dev_priv,
PIPE_CONF_CHECK_I(min_voltage_level);
+ PIPE_CONF_CHECK_X(infoframes.enable);
+ PIPE_CONF_CHECK_X(infoframes.gcp);
+ PIPE_CONF_CHECK_INFOFRAME(avi);
+ PIPE_CONF_CHECK_INFOFRAME(spd);
+ PIPE_CONF_CHECK_INFOFRAME(hdmi);
+
#undef PIPE_CONF_CHECK_X
#undef PIPE_CONF_CHECK_I
#undef PIPE_CONF_CHECK_BOOL
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/10] drm/i915/sdvo: Precompute HDMI infoframes
From: Ville Syrjälä
As with regular HDMI encoders, let's precompute the infoframes
(actually just AVI infoframe for the time being) with SDVO HDMI
encoders.
v2: Drop the WARN_ON() from drm_hdmi_avi_infoframe_from_display_mode()
return since that could genuinely fail due to user asking
for incompatible aspect ratio
Signed-off-by: Ville Syrjälä
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c | 60 ++-
1 file changed, 43 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 4db7aefa88f9..31d0c56cfcfc 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -978,34 +978,57 @@ static bool intel_sdvo_write_infoframe(struct intel_sdvo
*intel_sdvo,
&tx_rate, 1);
}
-static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo,
-const struct intel_crtc_state
*pipe_config,
-const struct drm_connector_state
*conn_state)
+static bool intel_sdvo_compute_avi_infoframe(struct intel_sdvo *intel_sdvo,
+struct intel_crtc_state
*crtc_state,
+struct drm_connector_state
*conn_state)
{
+ struct hdmi_avi_infoframe *frame = &crtc_state->infoframes.avi.avi;
const struct drm_display_mode *adjusted_mode =
- &pipe_config->base.adjusted_mode;
- uint8_t sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
- union hdmi_infoframe frame;
+ &crtc_state->base.adjusted_mode;
int ret;
- ssize_t len;
- ret = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
+ if (!crtc_state->has_hdmi_sink)
+ return true;
+
+ crtc_state->infoframes.enable |=
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI);
+
+ ret = drm_hdmi_avi_infoframe_from_display_mode(frame,
conn_state->connector,
adjusted_mode);
- if (ret < 0) {
- DRM_ERROR("couldn't fill AVI infoframe\n");
+ if (ret)
return false;
- }
- drm_hdmi_avi_infoframe_quant_range(&frame.avi,
+ drm_hdmi_avi_infoframe_quant_range(frame,
conn_state->connector,
adjusted_mode,
- pipe_config->limited_color_range ?
+ crtc_state->limited_color_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
HDMI_QUANTIZATION_RANGE_FULL);
- len = hdmi_infoframe_pack(&frame, sdvo_data, sizeof(sdvo_data));
- if (len < 0)
+ ret = hdmi_avi_infoframe_check(frame);
+ if (WARN_ON(ret))
+ return false;
+
+ return true;
+}
+
+static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo,
+const struct intel_crtc_state
*crtc_state)
+{
+ u8 sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
+ const union hdmi_infoframe *frame = &crtc_state->infoframes.avi;
+ ssize_t len;
+
+ if ((crtc_state->infoframes.enable &
+intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI)) == 0)
+ return true;
+
+ if (WARN_ON(frame->any.type != HDMI_INFOFRAME_TYPE_AVI))
+ return false;
+
+ len = hdmi_infoframe_pack_only(frame, sdvo_data, sizeof(sdvo_data));
+ if (WARN_ON(len < 0))
return false;
return intel_sdvo_write_infoframe(intel_sdvo, SDVO_HBUF_INDEX_AVI_IF,
@@ -1193,6 +1216,10 @@ static bool intel_sdvo_compute_config(struct
intel_encoder *encoder,
if (intel_sdvo_connector->is_hdmi)
adjusted_mode->picture_aspect_ratio =
conn_state->picture_aspect_ratio;
+ if (!intel_sdvo_compute_avi_infoframe(intel_sdvo,
+ pipe_config, conn_state))
+ return false;
+
return true;
}
@@ -1315,8 +1342,7 @@ static void intel_sdvo_pre_enable(struct intel_encoder
*intel_encoder,
intel_sdvo_set_encode(intel_sdvo, SDVO_ENCODE_HDMI);
intel_sdvo_set_colorimetry(intel_sdvo,
SDVO_COLORIMETRY_RGB256);
- intel_sdvo_set_avi_infoframe(intel_sdvo,
-crtc_state, conn_state);
+ intel_sdvo_set_avi_infoframe(intel_sdvo, crtc_state);
} else
intel_sdvo_set_encode(intel_sdvo, SDVO_ENCODE_DVI);
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/i
[Intel-gfx] [PATCH v2 10/10] drm/i915: Include infoframes in the crtc state dump
From: Ville Syrjälä
Dump out the infoframes in the normal crtc state dump.
TODO: Try to better integrate the infoframe dumps with
drm state dumps
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8c05084e5308..36defc958ce3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11170,6 +11170,16 @@ intel_dump_m_n_config(struct intel_crtc_state
*pipe_config, char *id,
m_n->link_m, m_n->link_n, m_n->tu);
}
+static void
+intel_dump_infoframe(struct drm_i915_private *dev_priv,
+const union hdmi_infoframe *frame)
+{
+ if ((drm_debug & DRM_UT_KMS) == 0)
+ return;
+
+ hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, frame);
+}
+
#define OUTPUT_TYPE(x) [INTEL_OUTPUT_ ## x] = #x
static const char * const output_type_str[] = {
@@ -11273,6 +11283,22 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
DRM_DEBUG_KMS("audio: %i, infoframes: %i\n",
pipe_config->has_audio, pipe_config->has_infoframe);
+ DRM_DEBUG_KMS("infoframes enabled: 0x%x\n",
+ pipe_config->infoframes.enable);
+
+ if (pipe_config->infoframes.enable &
+ intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GENERAL_CONTROL))
+ DRM_DEBUG_KMS("GCP: 0x%x\n", pipe_config->infoframes.gcp);
+ if (pipe_config->infoframes.enable &
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI))
+ intel_dump_infoframe(dev_priv, &pipe_config->infoframes.avi);
+ if (pipe_config->infoframes.enable &
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_SPD))
+ intel_dump_infoframe(dev_priv, &pipe_config->infoframes.spd);
+ if (pipe_config->infoframes.enable &
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_VENDOR))
+ intel_dump_infoframe(dev_priv, &pipe_config->infoframes.hdmi);
+
DRM_DEBUG_KMS("requested mode:\n");
drm_mode_debug_printmodeline(&pipe_config->base.mode);
DRM_DEBUG_KMS("adjusted mode:\n");
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/10] drm/i915/sdvo: Read out HDMI infoframes
From: Ville Syrjälä
Read the HDMI infoframes from the hbuf and unpack them into
the crtc state.
Well, actually just AVI infoframe for now but let's write the
infoframe readout code in a more generic fashion in case we
expand this later.
Note that Daniel was sceptical about the benefit if this and
also concerned about the potential for crappy sdvo encoders not
implementing the hbuf read commands. My (admittedly limited)
experience is that such encoders don't implement even the
get/set hdmi encoding commands and thus would always be treated
as dvi only. Hence I believe this is safe, and also IMO preferable
having quirks to deal with missing readout support. The readout
support is neatly isolated in the sdvo code whereas the quirk
would leak to other parts of the driver (state checker, fastboot,
etc.) thus complicating the lives of other people.
Signed-off-by: Ville Syrjälä
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c | 94 ++-
1 file changed, 91 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 31d0c56cfcfc..fd618b73cfc0 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -978,6 +978,58 @@ static bool intel_sdvo_write_infoframe(struct intel_sdvo
*intel_sdvo,
&tx_rate, 1);
}
+static ssize_t intel_sdvo_read_infoframe(struct intel_sdvo *intel_sdvo,
+unsigned int if_index,
+u8 *data, unsigned int length)
+{
+ u8 set_buf_index[2] = { if_index, 0 };
+ u8 hbuf_size, tx_rate, av_split;
+ int i;
+
+ if (!intel_sdvo_get_value(intel_sdvo,
+ SDVO_CMD_GET_HBUF_AV_SPLIT,
+ &av_split, 1))
+ return -ENXIO;
+
+ if (av_split < if_index)
+ return 0;
+
+ if (!intel_sdvo_get_value(intel_sdvo,
+ SDVO_CMD_GET_HBUF_TXRATE,
+ &tx_rate, 1))
+ return -ENXIO;
+
+ if (tx_rate == SDVO_HBUF_TX_DISABLED)
+ return 0;
+
+ if (!intel_sdvo_set_value(intel_sdvo,
+ SDVO_CMD_SET_HBUF_INDEX,
+ set_buf_index, 2))
+ return -ENXIO;
+
+ if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HBUF_INFO,
+ &hbuf_size, 1))
+ return -ENXIO;
+
+ /* Buffer size is 0 based, hooray! */
+ hbuf_size++;
+
+ DRM_DEBUG_KMS("reading sdvo hbuf: %i, hbuf_size %i, hbuf_size: %i\n",
+ if_index, length, hbuf_size);
+
+ hbuf_size = min_t(unsigned int, length, hbuf_size);
+
+ for (i = 0; i < hbuf_size; i += 8) {
+ if (!intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HBUF_DATA,
NULL, 0))
+ return -ENXIO;
+ if (!intel_sdvo_read_response(intel_sdvo, &data[i],
+ min_t(unsigned int, 8, hbuf_size
- i)))
+ return -ENXIO;
+ }
+
+ return hbuf_size;
+}
+
static bool intel_sdvo_compute_avi_infoframe(struct intel_sdvo *intel_sdvo,
struct intel_crtc_state
*crtc_state,
struct drm_connector_state
*conn_state)
@@ -1036,6 +1088,40 @@ static bool intel_sdvo_set_avi_infoframe(struct
intel_sdvo *intel_sdvo,
sdvo_data, sizeof(sdvo_data));
}
+static void intel_sdvo_get_avi_infoframe(struct intel_sdvo *intel_sdvo,
+struct intel_crtc_state *crtc_state)
+{
+ u8 sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
+ union hdmi_infoframe *frame = &crtc_state->infoframes.avi;
+ ssize_t len;
+ int ret;
+
+ if (!crtc_state->has_hdmi_sink)
+ return;
+
+ len = intel_sdvo_read_infoframe(intel_sdvo, SDVO_HBUF_INDEX_AVI_IF,
+ sdvo_data, sizeof(sdvo_data));
+ if (len < 0) {
+ DRM_DEBUG_KMS("failed to read AVI infoframe\n");
+ return;
+ } else if (len == 0) {
+ return;
+ }
+
+ crtc_state->infoframes.enable |=
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI);
+
+ ret = hdmi_infoframe_unpack(frame, sdvo_data, sizeof(sdvo_data));
+ if (ret) {
+ DRM_DEBUG_KMS("Failed to unpack AVI infoframe\n");
+ return;
+ }
+
+ if (frame->any.type != HDMI_INFOFRAME_TYPE_AVI)
+ DRM_DEBUG_KMS("Found the wrong infoframe type 0x%x (expected
0x%02x)\n",
+ frame->any.type, HDMI_INFOFRAME_TYPE_AVI);
+}
+
static bool intel_sdvo_set_tv_format(struct intel_sdvo *intel_sdvo,
[Intel-gfx] [PATCH v2 05/10] drm/i915: Precompute HDMI infoframes
From: Ville Syrjälä
Store the infoframes in the crtc state and precompute them in
.compute_config(). While precomputing we'll also fill out the
inforames.enable bitmask appropriately.
v2: Drop the null packet stuff (Daniel)
Add a FIXME for lspcon
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_drv.h| 5 +
drivers/gpu/drm/i915/intel_hdmi.c | 247
drivers/gpu/drm/i915/intel_lspcon.c | 2 +
3 files changed, 185 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a381b78f6722..fb7cf55865ea 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -936,6 +936,10 @@ struct intel_crtc_state {
struct {
u32 enable;
+ u32 gcp;
+ union hdmi_infoframe avi;
+ union hdmi_infoframe spd;
+ union hdmi_infoframe hdmi;
} infoframes;
/* HDMI scrambling status */
@@ -1990,6 +1994,7 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi
*hdmi, bool enable);
void intel_infoframe_init(struct intel_digital_port *intel_dig_port);
u32 intel_hdmi_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state);
+u32 intel_hdmi_infoframe_enable(unsigned int type);
/* intel_lvds.c */
bool intel_lvds_port_enabled(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index a7d5bb43b835..ab0ba24b9546 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -457,6 +457,18 @@ static const u8 infoframe_type_to_idx[] = {
HDMI_INFOFRAME_TYPE_VENDOR,
};
+u32 intel_hdmi_infoframe_enable(unsigned int type)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(infoframe_type_to_idx); i++) {
+ if (infoframe_type_to_idx[i] == type)
+ return BIT(i);
+ }
+
+ return 0;
+}
+
u32 intel_hdmi_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state)
{
@@ -502,15 +514,23 @@ u32 intel_hdmi_infoframes_enabled(struct intel_encoder
*encoder,
*/
static void intel_write_infoframe(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
- union hdmi_infoframe *frame)
+ enum hdmi_infoframe_type type,
+ const union hdmi_infoframe *frame)
{
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(&encoder->base);
u8 buffer[VIDEO_DIP_DATA_SIZE];
ssize_t len;
+ if ((crtc_state->infoframes.enable &
+intel_hdmi_infoframe_enable(type)) == 0)
+ return;
+
+ if (WARN_ON(frame->any.type != type))
+ return;
+
/* see comment above for the reason for this offset */
- len = hdmi_infoframe_pack(frame, buffer + 1, sizeof(buffer) - 1);
- if (len < 0)
+ len = hdmi_infoframe_pack_only(frame, buffer + 1, sizeof(buffer) - 1);
+ if (WARN_ON(len < 0))
return;
/* Insert the 'hole' (see big comment above) at position 3 */
@@ -518,84 +538,110 @@ static void intel_write_infoframe(struct intel_encoder
*encoder,
buffer[3] = 0;
len++;
- intel_dig_port->write_infoframe(encoder,
- crtc_state,
- frame->any.type, buffer, len);
+ intel_dig_port->write_infoframe(encoder, crtc_state, type, buffer, len);
}
-static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder,
-const struct intel_crtc_state
*crtc_state,
-const struct drm_connector_state
*conn_state)
+static bool
+intel_hdmi_compute_avi_infoframe(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
{
+ struct hdmi_avi_infoframe *frame = &crtc_state->infoframes.avi.avi;
const struct drm_display_mode *adjusted_mode =
&crtc_state->base.adjusted_mode;
- union hdmi_infoframe frame;
+ struct drm_connector *connector = conn_state->connector;
int ret;
- ret = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
- conn_state->connector,
+ if (!crtc_state->has_infoframe)
+ return true;
+
+ crtc_state->infoframes.enable |=
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI);
+
+ ret = drm_hdmi_avi_infoframe_from_display_mode(frame, connector,
adjusted_mode);
-
[Intel-gfx] [PATCH v2 03/10] drm/i915: Return the mask of enabled infoframes from ->inforame_enabled()
From: Ville Syrjälä
We want to start tracking which infoframes are enabled, so let's replace
the boolean flag with a bitmask.
We'll abstract the bitmask so that it's not platform dependent. That
will allow us to examine the bitmask later in platform independent code.
v2: Don't map VIDEO_DIP_ENABLE to the null packet (Daniel)
Put a FIXME in the lspcon function
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c| 2 +-
drivers/gpu/drm/i915/intel_drv.h| 6 ++-
drivers/gpu/drm/i915/intel_hdmi.c | 83 -
drivers/gpu/drm/i915/intel_lspcon.c | 3 +-
4 files changed, 65 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2d6ed990a232..b816ad11cb58 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3745,7 +3745,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
pipe_config->has_hdmi_sink = true;
intel_dig_port = enc_to_dig_port(&encoder->base);
- if (intel_dig_port->infoframe_enabled(encoder, pipe_config))
+ if (intel_hdmi_infoframes_enabled(encoder, pipe_config))
pipe_config->has_infoframe = true;
if (temp & TRANS_DDI_HDMI_SCRAMBLING)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3b051fdd0fce..7b3612007f50 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1250,7 +1250,7 @@ struct intel_digital_port {
bool enable,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state);
- bool (*infoframe_enabled)(struct intel_encoder *encoder,
+ u32 (*infoframes_enabled)(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config);
};
@@ -1984,6 +1984,8 @@ bool intel_hdmi_handle_sink_scrambling(struct
intel_encoder *encoder,
bool scrambling);
void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable);
void intel_infoframe_init(struct intel_digital_port *intel_dig_port);
+u32 intel_hdmi_infoframes_enabled(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state);
/* intel_lvds.c */
bool intel_lvds_port_enabled(struct drm_i915_private *dev_priv,
@@ -2352,7 +2354,7 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state);
-bool lspcon_infoframe_enabled(struct intel_encoder *encoder,
+u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config);
void lspcon_ycbcr420_config(struct drm_connector *connector,
struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 74b246fef08d..fe6cf487e12e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -103,6 +103,8 @@ static u32 g4x_infoframe_enable(unsigned int type)
return VIDEO_DIP_ENABLE_GCP;
case HDMI_PACKET_TYPE_GAMUT_METADATA:
return VIDEO_DIP_ENABLE_GAMUT;
+ case DP_SDP_VSC:
+ return 0;
case HDMI_INFOFRAME_TYPE_AVI:
return VIDEO_DIP_ENABLE_AVI;
case HDMI_INFOFRAME_TYPE_SPD:
@@ -212,17 +214,17 @@ static void g4x_write_infoframe(struct intel_encoder
*encoder,
POSTING_READ(VIDEO_DIP_CTL);
}
-static bool g4x_infoframe_enabled(struct intel_encoder *encoder,
+static u32 g4x_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 val = I915_READ(VIDEO_DIP_CTL);
if ((val & VIDEO_DIP_ENABLE) == 0)
- return false;
+ return 0;
if ((val & VIDEO_DIP_PORT_MASK) != VIDEO_DIP_PORT(encoder->port))
- return false;
+ return 0;
return val & (VIDEO_DIP_ENABLE_AVI |
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_SPD);
@@ -267,7 +269,7 @@ static void ibx_write_infoframe(struct intel_encoder
*encoder,
POSTING_READ(reg);
}
-static bool ibx_infoframe_enabled(struct intel_encoder *encoder,
+static u32 ibx_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
@@ -276,10 +278,10 @@ static bool ibx_infoframe_enabled(struct int
[Intel-gfx] [PATCH v2 01/10] video/hdmi: Add an enum for HDMI packet types
From: Ville Syrjälä
We'll be wanting to send more than just infoframes over HDMI. So add an
enum for other packet types.
TODO: Maybe just include the infoframe types in the packet type enum
and get rid of the infoframe type enum?
v2: s/AUDIO_CP/ACP/ (Shashank)
Cc: Thierry Reding
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Reviewed-by: Shashank Sharma
Signed-off-by: Ville Syrjälä
---
include/linux/hdmi.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index d2bacf502429..927ad6451105 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -27,6 +27,21 @@
#include
#include
+enum hdmi_packet_type {
+ HDMI_PACKET_TYPE_NULL = 0x00,
+ HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
+ HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
+ HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
+ HDMI_PACKET_TYPE_ACP = 0x04,
+ HDMI_PACKET_TYPE_ISRC1 = 0x05,
+ HDMI_PACKET_TYPE_ISRC2 = 0x06,
+ HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
+ HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
+ HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
+ HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
+ /* + enum hdmi_infoframe_type */
+};
+
enum hdmi_infoframe_type {
HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
HDMI_INFOFRAME_TYPE_AVI = 0x82,
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/10] drm/i915: Infoframe precompute/check
From: Ville Syrjälä Remainder of the infoframe precompute/readout stuff. Addressed the review comments (I hope) and massaged a few things that had changed. The main thing was lspcon appearing in the meantime. Note that I didn't implement precompute+readout for lspcon. That'll probably need to happen at some point, but I was too lazy to do it right now. Entire series available here: git://github.com/vsyrjala/linux.git infoframe_precompute_6 Ville Syrjälä (10): video/hdmi: Add an enum for HDMI packet types drm/i915: Add the missing HDMI gamut metadata packet stuff drm/i915: Return the mask of enabled infoframes from ->inforame_enabled() drm/i915: Store mask of enabled infoframes in the crtc state drm/i915: Precompute HDMI infoframes drm/i915: Read out HDMI infoframes drm/i915/sdvo: Precompute HDMI infoframes drm/i915/sdvo: Read out HDMI infoframes drm/i915: Check infoframe state in intel_pipe_config_compare() drm/i915: Include infoframes in the crtc state dump drivers/gpu/drm/i915/i915_reg.h | 8 +- drivers/gpu/drm/i915/intel_ddi.c | 17 +- drivers/gpu/drm/i915/intel_display.c | 75 +++- drivers/gpu/drm/i915/intel_drv.h | 29 +- drivers/gpu/drm/i915/intel_hdmi.c| 517 ++- drivers/gpu/drm/i915/intel_lspcon.c | 13 +- drivers/gpu/drm/i915/intel_sdvo.c| 154 ++-- include/linux/hdmi.h | 15 + 8 files changed, 706 insertions(+), 122 deletions(-) -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for MST refcounting/atomic helpers cleanup (rev6)
== Series Details == Series: MST refcounting/atomic helpers cleanup (rev6) URL : https://patchwork.freedesktop.org/series/54030/ State : success == Summary == CI Bug Log - changes from CI_DRM_5396 -> Patchwork_11275 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/54030/revisions/6/mbox/ Known issues Here are the changes found in Patchwork_11275 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@i915_selftest@live_execlists: - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: PASS -> FAIL [fdo#108767] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] Possible fixes * igt@i915_selftest@live_hangcheck: - fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS * igt@kms_flip@basic-flip-vs-dpms: - fi-apl-guc: DMESG-WARN -> PASS * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735 [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767 Participating hosts (45 -> 42) -- Additional (2): fi-whl-u fi-skl-iommu Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-pnv-d510 Build changes - * Linux: CI_DRM_5396 -> Patchwork_11275 CI_DRM_5396: 8aa43e01ae8e72537445ce6c00c625ad144eb153 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4758: f01796214bbde31e37b0593e547ad9436fdd02ba @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11275: eda808298487174cc9eac53857058ad855754aad @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == eda808298487 drm/nouveau: Use atomic VCPI helpers for MST c56bb94c3792 drm/dp_mst: Check payload count in drm_dp_mst_atomic_check() f9d81992c9e5 drm/dp_mst: Start tracking per-port VCPI allocations b82d3c430cb1 drm/dp_mst: Add some atomic state iterator macros afbb35c6e94b drm/nouveau: Grab payload lock in nv50_msto_payload() 64aa969674e9 drm/nouveau: Stop unsetting mstc->port, use malloc refs 141e44f950c7 drm/nouveau: Keep malloc references to MST ports 4f5695fc9072 drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup() defda10847fc drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector() 1ef9dfa3cc33 drm/amdgpu/display: Keep malloc ref to MST port 1171364b70bf drm/i915: Keep malloc references to MST ports 144f62fdfcaa drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs c47ff6b09ccd drm/dp_mst: Stop releasing VCPI when removing ports from topology 5d7e538f768f drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails 1f70bc12c76d drm/dp_mst: Introduce new refcounting scheme for mstbs and ports 0e76331779ed drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends ed2e6efe3038 drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi() a01f387a014f drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi() 2816687b107d drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg() bc4462c0913d drm/dp_mst: Fix some formatting in drm_dp_add_port() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11275/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for MST refcounting/atomic helpers cleanup (rev6)
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev6)
URL : https://patchwork.freedesktop.org/series/54030/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bc4462c0913d drm/dp_mst: Fix some formatting in drm_dp_add_port()
2816687b107d drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg()
a01f387a014f drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi()
ed2e6efe3038 drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi()
0e76331779ed drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and
friends
-:84: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#84: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:990:
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
-:102: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#102: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1006:
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
-:150: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#150: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1379:
+ mstb_child = drm_dp_mst_topology_get_mstb_validated(
total: 0 errors, 0 warnings, 3 checks, 401 lines checked
1f70bc12c76d drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
-:27: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#27:
commit 263efde31f97 ("drm/dp/mst: Get validated port ref in
drm_dp_update_payload_part1()")
-:51: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 9765635b3075 ("Revert
"drm/dp_mst: Skip validating ports during destruction, just ref"")'
#51:
commit 9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during
destruction, just ref"")
-:142: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#142:
new file mode 100644
-:848: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#848: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1330:
+ mport = drm_dp_mst_topology_get_port_validated_locked(
-:862: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#862: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1347:
+ rport = drm_dp_mst_topology_get_port_validated_locked(
total: 1 errors, 2 warnings, 2 checks, 916 lines checked
5d7e538f768f drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref
fails
c47ff6b09ccd drm/dp_mst: Stop releasing VCPI when removing ports from topology
144f62fdfcaa drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
-:97: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#97: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:2269:
+ port = drm_dp_mst_topology_get_port_validated(
total: 0 errors, 0 warnings, 1 checks, 124 lines checked
1171364b70bf drm/i915: Keep malloc references to MST ports
1ef9dfa3cc33 drm/amdgpu/display: Keep malloc ref to MST port
defda10847fc drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector()
4f5695fc9072 drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup()
141e44f950c7 drm/nouveau: Keep malloc references to MST ports
64aa969674e9 drm/nouveau: Stop unsetting mstc->port, use malloc refs
afbb35c6e94b drm/nouveau: Grab payload lock in nv50_msto_payload()
b82d3c430cb1 drm/dp_mst: Add some atomic state iterator macros
-:110: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__state' - possible
side-effects?
#110: FILE: include/drm/drm_dp_mst_helper.h:711:
+#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state,
__i) \
+ for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+ for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr),
&(old_state), &(new_state), (__i)))
-:110: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i' - possible
side-effects?
#110: FILE: include/drm/drm_dp_mst_helper.h:711:
+#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state,
__i) \
+ for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+ for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr),
&(old_state), &(new_state), (__i)))
-:112: WARNING:LONG_LINE: line over 100 characters
#112: FILE: include/drm/drm_dp_mst_helper.h:713:
+ for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr),
&(old_state), &(new_state), (__i)))
-:127: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__state' - possible
side-effects?
#127: FILE: include/drm/drm_dp_mst_helper.h:728:
+#define for_each_old_mst_mgr_in_state(__state, mgr, old_state, __i) \
+ for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+ for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr),
&(old_state), NULL, (__i)))
-:127: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i' - possible
side-effects?
#127: FILE: include/drm/drm_dp_mst_helper.h:728:
+#define for_each_old_mst_mgr_in_stat
[Intel-gfx] [PATCH v6 14/20] drm/nouveau: Keep malloc references to MST ports
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is allocated for
as long as we keep mstc around we can remove the connector registration
checks for codepaths which release payloads, allowing us to release
payloads on active topologies properly. These registration checks were
only required before in order to avoid situations where mstc->port could
technically be pointing at freed memory.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 28538ef19b71..15f378902fcb 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -963,7 +963,11 @@ static void
nv50_mstc_destroy(struct drm_connector *connector)
{
struct nv50_mstc *mstc = nv50_mstc(connector);
+
drm_connector_cleanup(&mstc->connector);
+ if (mstc->port)
+ drm_dp_mst_put_port_malloc(mstc->port);
+
kfree(mstc);
}
@@ -1011,6 +1015,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct
drm_dp_mst_port *port,
drm_object_attach_property(&mstc->connector.base,
dev->mode_config.path_property, 0);
drm_object_attach_property(&mstc->connector.base,
dev->mode_config.tile_property, 0);
drm_connector_set_path_property(&mstc->connector, path);
+ drm_dp_mst_get_port_malloc(port);
return 0;
}
@@ -1076,6 +1081,7 @@ nv50_mstm_destroy_connector(struct
drm_dp_mst_topology_mgr *mgr,
drm_fb_helper_remove_one_connector(&drm->fbcon->helper,
&mstc->connector);
drm_modeset_lock(&drm->dev->mode_config.connection_mutex, NULL);
+ drm_dp_mst_put_port_malloc(mstc->port);
mstc->port = NULL;
drm_modeset_unlock(&drm->dev->mode_config.connection_mutex);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 18/20] drm/dp_mst: Start tracking per-port VCPI allocations
There has been a TODO waiting for quite a long time in drm_dp_mst_topology.c: /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent * branch device was unplugged. This should be fixed by tracking * per-port slot allocation in drm_dp_mst_topology_state instead of * depending on the caller to tell us how many slots to release. */ That's not the only reason we should fix this: forcing the driver to track the VCPI allocations throughout a state's atomic check is error prone, because it means that extra care has to be taken with the order that drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release_vcpi_slots() are called in in order to ensure idempotency. Currently the only driver actually using these helpers, i915, doesn't even do this correctly: multiple ->best_encoder() checks with i915's current implementation would not be idempotent and would over-allocate VCPI slots, something I learned trying to implement fallback retraining in MST. So: simplify this whole mess, and teach drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release_vcpi_slots() to track the VCPI allocations for each port. This allows us to ensure idempotency without having to rely on the driver as much. Additionally: the driver doesn't need to do any kind of VCPI slot tracking anymore if it doesn't need it for it's own internal state. Additionally; this adds a new drm_dp_mst_atomic_check() helper which must be used by atomic drivers to perform validity checks for the new VCPI allocations incurred by a state. Also: update the documentation and make it more obvious that these /must/ be called by /all/ atomic drivers supporting MST. Changes since v9: * Add some missing changes that were requested by danvet that I forgot about after I redid all of the kref stuff: * Remove unnecessary state changes in intel_dp_mst_atomic_check * Cleanup atomic check logic for VCPI allocations - all we need to check in compute_config is whether or not this state disables a CRTC, then free VCPI based off that Changes since v8: * Fix compile errors, whoops! Changes since v7: - Don't check for mixed stale/valid VCPI allocations, just rely on connector registration to stop such erroneous modesets Changes since v6: - Keep a kref to all of the ports we have allocations on. This required a good bit of changing to when we call drm_dp_find_vcpi_slots(), mainly that we need to ensure that we only redo VCPI allocations on actual mode or CRTC changes, not crtc_state->active changes. Additionally, we no longer take the registration of the DRM connector for each port into account because so long as we have a kref to the port in the new or previous atomic state, the connector will stay registered. - Use the small changes to drm_dp_put_port() to add even more error checking to make misusage of the helpers more obvious. I added this after having to chase down various use-after-free conditions that started popping up from the new helpers so no one else has to troubleshoot that. - Move some accidental DRM_DEBUG_KMS() calls to DRM_DEBUG_ATOMIC() - Update documentation again, note that find/release() should both not be called on the same port in a single atomic check phase (but multiple calls to one or the other is OK) Changes since v4: - Don't skip the atomic checks for VCPI allocations if no new VCPI allocations happen in a state. This makes the next change I'm about to list here a lot easier to implement. - Don't ignore VCPI allocations on destroyed ports, instead ensure that when ports are destroyed and still have VCPI allocations in the topology state, the only state changes allowed are releasing said ports' VCPI. This prevents a state with a mix of VCPI allocations from destroyed ports, and allocations from valid ports. Changes since v3: - Don't release VCPI allocations in the topology state immediately in drm_dp_atomic_release_vcpi_slots(), instead mark them as 0 and skip over them in drm_dp_mst_duplicate_state(). This makes it so drm_dp_atomic_release_vcpi_slots() is still idempotent while also throwing warnings if the driver messes up it's book keeping and tries to release VCPI slots on a port that doesn't have any pre-existing VCPI allocation - danvet - Change mst_state/state in some debugging messages to "mst state" Changes since v2: - Use kmemdup() for duplicating MST state - danvet - Move port validation out of duplicate state callback - danvet - Handle looping through MST topology states in drm_dp_mst_atomic_check() so the driver doesn't have to do it - Fix documentation in drm_dp_atomic_find_vcpi_slots() - Move the atomic check for each individual topology state into it's own function, reduces indenting - Don't consider "stale" MST ports when calculating the bandwidth requirements. This is needed because originally we reli
[Intel-gfx] [PATCH v6 17/20] drm/dp_mst: Add some atomic state iterator macros
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 5 +-
include/drm/drm_dp_mst_helper.h | 96 +++
2 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index b5976f8c318c..e3497bc49494 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3521,10 +3521,11 @@ static void drm_dp_mst_destroy_state(struct
drm_private_obj *obj,
kfree(mst_state);
}
-static const struct drm_private_state_funcs mst_state_funcs = {
+const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs = {
.atomic_duplicate_state = drm_dp_mst_duplicate_state,
.atomic_destroy_state = drm_dp_mst_destroy_state,
};
+EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
/**
* drm_atomic_get_mst_topology_state: get MST topology state
@@ -3608,7 +3609,7 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
drm_atomic_private_obj_init(dev, &mgr->base,
&mst_state->base,
- &mst_state_funcs);
+ &drm_dp_mst_topology_state_funcs);
return 0;
}
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 70ec452f2a47..fa533571b16c 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -651,4 +651,100 @@ int drm_dp_send_power_updown_phy(struct
drm_dp_mst_topology_mgr *mgr,
void drm_dp_mst_get_port_malloc(struct drm_dp_mst_port *port);
void drm_dp_mst_put_port_malloc(struct drm_dp_mst_port *port);
+extern const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs;
+
+/**
+ * __drm_dp_mst_state_iter_get - private atomic state iterator function for
+ * macro-internal use
+ * @state: &struct drm_atomic_state pointer
+ * @mgr: pointer to the &struct drm_dp_mst_topology_mgr iteration cursor
+ * @old_state: optional pointer to the old &struct drm_dp_mst_topology_state
+ * iteration cursor
+ * @new_state: optional pointer to the new &struct drm_dp_mst_topology_state
+ * iteration cursor
+ * @i: int iteration cursor, for macro-internal use
+ *
+ * Used by for_each_oldnew_mst_mgr_in_state(),
+ * for_each_old_mst_mgr_in_state(), and for_each_new_mst_mgr_in_state(). Don't
+ * call this directly.
+ *
+ * Returns:
+ * True if the current &struct drm_private_obj is a &struct
+ * drm_dp_mst_topology_mgr, false otherwise.
+ */
+static inline bool
+__drm_dp_mst_state_iter_get(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr **mgr,
+ struct drm_dp_mst_topology_state **old_state,
+ struct drm_dp_mst_topology_state **new_state,
+ int i)
+{
+ struct __drm_private_objs_state *objs_state = &state->private_objs[i];
+
+ if (objs_state->ptr->funcs != &drm_dp_mst_topology_state_funcs)
+ return false;
+
+ *mgr = to_dp_mst_topology_mgr(objs_state->ptr);
+ if (old_state)
+ *old_state = to_dp_mst_topology_state(objs_state->old_state);
+ if (new_state)
+ *new_state = to_dp_mst_topology_state(objs_state->new_state);
+
+ return true;
+}
+
+/**
+ * for_each_oldnew_mst_mgr_in_state - iterate over all DP MST topology
+ * managers in an atomic update
+ * @__state: &struct drm_atomic_state pointer
+ * @mgr: &struct drm_dp_mst_topology_mgr iteration cursor
+ * @old_state: &struct drm_dp_mst_topology_state iteration cursor for the old
+ * state
+ * @new_state: &struct drm_dp_mst_topology_state iteration cursor for the new
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in an atomic update,
+ * tracking both old and new state. This is useful in places where the state
+ * delta needs to be considered, for example in atomic check functions.
+ */
+#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state,
__i) \
+ for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+ for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr),
&(old_state), &(new_state), (__i)))
+
+/**
+ * for_each_old_mst_mgr_in_state - iterate over all DP MST topology managers
+ * in an atomic update
+ * @__state: &struct drm_atomic_state pointer
+ * @mgr: &struct drm_dp_mst_topology_mgr iteration cursor
+ * @old_state: &struct drm_dp_mst_topology_state iteration cursor for the old
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in
[Intel-gfx] [PATCH v6 12/20] drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector()
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index bc06aa79363f..800213be76ea 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1098,11 +1098,8 @@ nv50_mstm_add_connector(struct drm_dp_mst_topology_mgr
*mgr,
int ret;
ret = nv50_mstc_new(mstm, port, path, &mstc);
- if (ret) {
- if (mstc)
- mstc->connector.funcs->destroy(&mstc->connector);
+ if (ret)
return NULL;
- }
return &mstc->connector;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 08/20] drm/dp_mst: Stop releasing VCPI when removing ports from topology
This has never actually worked, and isn't needed anyway: the driver's
always going to try to deallocate VCPI when it tears down the display
that the VCPI belongs to.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7a251905b3c4..bb9107852fed 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1177,8 +1177,6 @@ static void drm_dp_destroy_port(struct kref *kref)
struct drm_dp_mst_topology_mgr *mgr = port->mgr;
if (!port->input) {
- port->vcpi.num_slots = 0;
-
kfree(port->cached_edid);
/*
@@ -3487,12 +3485,6 @@ static void drm_dp_destroy_connector_work(struct
work_struct *work)
drm_dp_port_teardown_pdt(port, port->pdt);
port->pdt = DP_PEER_DEVICE_NONE;
- if (!port->input && port->vcpi.vcpi > 0) {
- drm_dp_mst_reset_vcpi_slots(mgr, port);
- drm_dp_update_payload_part1(mgr);
- drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
- }
-
drm_dp_mst_put_port_malloc(port);
send_hotplug = true;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 20/20] drm/nouveau: Use atomic VCPI helpers for MST
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actually check whether or not the topology still has
enough bandwidth to provide the VCPI tokens required.
So, drop usage of the old helpers and move entirely over to the atomic
helpers.
Changes since v6:
* Cleanup atomic check logic and remove a bunch of unneeded checks -
danvet
Changes since v5:
* Update nv50_msto_atomic_check() and nv50_mstc_atomic_check() to the
new requirements for drm_dp_atomic_find_vcpi_slots() and
drm_dp_atomic_release_vcpi_slots()
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 54 ++---
1 file changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 8044ebba56a4..67107f0b1299 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -761,16 +761,23 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
- struct nv50_mstc *mstc = nv50_mstc(conn_state->connector);
+ struct drm_atomic_state *state = crtc_state->state;
+ struct drm_connector *connector = conn_state->connector;
+ struct nv50_mstc *mstc = nv50_mstc(connector);
struct nv50_mstm *mstm = mstc->mstm;
- int bpp = conn_state->connector->display_info.bpc * 3;
+ int bpp = connector->display_info.bpc * 3;
int slots;
- mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock, bpp);
+ mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
+bpp);
- slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn);
- if (slots < 0)
- return slots;
+ if (drm_atomic_crtc_needs_modeset(crtc_state) &&
+ !drm_connector_is_unregistered(connector)) {
+ slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr,
+ mstc->port, mstc->pbn);
+ if (slots < 0)
+ return slots;
+ }
return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
mstc->native);
@@ -933,12 +940,43 @@ nv50_mstc_get_modes(struct drm_connector *connector)
return ret;
}
+static int
+nv50_mstc_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *new_conn_state)
+{
+ struct drm_atomic_state *state = new_conn_state->state;
+ struct nv50_mstc *mstc = nv50_mstc(connector);
+ struct drm_dp_mst_topology_mgr *mgr = &mstc->mstm->mgr;
+ struct drm_connector_state *old_conn_state =
+ drm_atomic_get_old_connector_state(state, connector);
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc *new_crtc = new_conn_state->crtc;
+
+ if (!old_conn_state->crtc)
+ return 0;
+
+ /* We only want to free VCPI if this state disables the CRTC on this
+* connector
+*/
+ if (new_crtc) {
+ crtc_state = drm_atomic_get_new_crtc_state(state, new_crtc);
+
+ if (!crtc_state ||
+ !drm_atomic_crtc_needs_modeset(crtc_state) ||
+ crtc_state->enable)
+ return 0;
+ }
+
+ return drm_dp_atomic_release_vcpi_slots(state, mgr, mstc->port);
+}
+
static const struct drm_connector_helper_funcs
nv50_mstc_help = {
.get_modes = nv50_mstc_get_modes,
.mode_valid = nv50_mstc_mode_valid,
.best_encoder = nv50_mstc_best_encoder,
.atomic_best_encoder = nv50_mstc_atomic_best_encoder,
+ .atomic_check = nv50_mstc_atomic_check,
};
static enum drm_connector_status
@@ -2120,6 +2158,10 @@ nv50_disp_atomic_check(struct drm_device *dev, struct
drm_atomic_state *state)
return ret;
}
+ ret = drm_dp_mst_atomic_check(state);
+ if (ret)
+ return ret;
+
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 v6 16/20] drm/nouveau: Grab payload lock in nv50_msto_payload()
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 6f8a54e81727..8044ebba56a4 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -679,6 +679,8 @@ nv50_msto_payload(struct nv50_msto *msto)
struct nv50_mstm *mstm = mstc->mstm;
int vcpi = mstc->port->vcpi.vcpi, i;
+ WARN_ON(!mutex_is_locked(&mstm->mgr.payload_lock));
+
NV_ATOMIC(drm, "%s: vcpi %d\n", msto->encoder.name, vcpi);
for (i = 0; i < mstm->mgr.max_payloads; i++) {
struct drm_dp_payload *payload = &mstm->mgr.payloads[i];
@@ -732,6 +734,8 @@ nv50_msto_prepare(struct nv50_msto *msto)
(0x0100 << msto->head->base.index),
};
+ mutex_lock(&mstm->mgr.payload_lock);
+
NV_ATOMIC(drm, "%s: msto prepare\n", msto->encoder.name);
if (mstc->port->vcpi.vcpi > 0) {
struct drm_dp_payload *payload = nv50_msto_payload(msto);
@@ -747,7 +751,9 @@ nv50_msto_prepare(struct nv50_msto *msto)
msto->encoder.name, msto->head->base.base.name,
args.vcpi.start_slot, args.vcpi.num_slots,
args.vcpi.pbn, args.vcpi.aligned_pbn);
+
nvif_mthd(&drm->display->disp.object, 0, &args, sizeof(args));
+ mutex_unlock(&mstm->mgr.payload_lock);
}
static int
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 19/20] drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 88db6d7e1a36..196ebba8af5f 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3641,7 +3641,7 @@ drm_dp_mst_atomic_check_topology_state(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state
*mst_state)
{
struct drm_dp_vcpi_allocation *vcpi;
- int avail_slots = 63;
+ int avail_slots = 63, payload_count = 0;
list_for_each_entry(vcpi, &mst_state->vcpis, next) {
/* Releasing VCPI is always OK-even if the port is gone */
@@ -3661,6 +3661,12 @@ drm_dp_mst_atomic_check_topology_state(struct
drm_dp_mst_topology_mgr *mgr,
avail_slots + vcpi->vcpi);
return -ENOSPC;
}
+
+ if (++payload_count > mgr->max_payloads) {
+ DRM_DEBUG_ATOMIC("[MST MGR:%p] state %p has too many
payloads (max=%d)\n",
+mgr, mst_state, mgr->max_payloads);
+ return -EINVAL;
+ }
}
DRM_DEBUG_ATOMIC("[MST MGR:%p] mst state %p VCPI avail=%d used=%d\n",
mgr, mst_state, avail_slots,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 13/20] drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup()
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks are meant to protect against.
More importantly though, we're about to stop clearing mstc->port in the
next commit, which means if we could potentially hit a use-after-free
error if we tried to check mstc->port->vcpi here. So to make life easier
for anyone who bisects this code in the future, use msto->disabled
instead to check whether or not we need to deallocate VCPI instead.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 800213be76ea..28538ef19b71 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -703,14 +703,17 @@ nv50_msto_cleanup(struct nv50_msto *msto)
struct nv50_mstc *mstc = msto->mstc;
struct nv50_mstm *mstm = mstc->mstm;
+ if (!msto->disabled)
+ return;
+
NV_ATOMIC(drm, "%s: msto cleanup\n", msto->encoder.name);
- if (mstc->port && mstc->port->vcpi.vcpi > 0 && !nv50_msto_payload(msto))
+
+ if (mstc->port)
drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
- if (msto->disabled) {
- msto->mstc = NULL;
- msto->head = NULL;
- msto->disabled = false;
- }
+
+ msto->mstc = NULL;
+ msto->head = NULL;
+ msto->disabled = false;
}
static void
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 15/20] drm/nouveau: Stop unsetting mstc->port, use malloc refs
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 15f378902fcb..6f8a54e81727 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -708,8 +708,7 @@ nv50_msto_cleanup(struct nv50_msto *msto)
NV_ATOMIC(drm, "%s: msto cleanup\n", msto->encoder.name);
- if (mstc->port)
- drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
+ drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
msto->mstc = NULL;
msto->head = NULL;
@@ -734,7 +733,7 @@ nv50_msto_prepare(struct nv50_msto *msto)
};
NV_ATOMIC(drm, "%s: msto prepare\n", msto->encoder.name);
- if (mstc->port && mstc->port->vcpi.vcpi > 0) {
+ if (mstc->port->vcpi.vcpi > 0) {
struct drm_dp_payload *payload = nv50_msto_payload(msto);
if (payload) {
args.vcpi.start_slot = payload->start_slot;
@@ -831,8 +830,7 @@ nv50_msto_disable(struct drm_encoder *encoder)
struct nv50_mstc *mstc = msto->mstc;
struct nv50_mstm *mstm = mstc->mstm;
- if (mstc->port)
- drm_dp_mst_reset_vcpi_slots(&mstm->mgr, mstc->port);
+ drm_dp_mst_reset_vcpi_slots(&mstm->mgr, mstc->port);
mstm->outp->update(mstm->outp, msto->head->base.index, NULL, 0, 0);
mstm->modified = true;
@@ -944,7 +942,7 @@ nv50_mstc_detect(struct drm_connector *connector, bool
force)
enum drm_connector_status conn_status;
int ret;
- if (!mstc->port)
+ if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
ret = pm_runtime_get_sync(connector->dev->dev);
@@ -965,8 +963,7 @@ nv50_mstc_destroy(struct drm_connector *connector)
struct nv50_mstc *mstc = nv50_mstc(connector);
drm_connector_cleanup(&mstc->connector);
- if (mstc->port)
- drm_dp_mst_put_port_malloc(mstc->port);
+ drm_dp_mst_put_port_malloc(mstc->port);
kfree(mstc);
}
@@ -1080,11 +1077,6 @@ nv50_mstm_destroy_connector(struct
drm_dp_mst_topology_mgr *mgr,
drm_fb_helper_remove_one_connector(&drm->fbcon->helper,
&mstc->connector);
- drm_modeset_lock(&drm->dev->mode_config.connection_mutex, NULL);
- drm_dp_mst_put_port_malloc(mstc->port);
- mstc->port = NULL;
- drm_modeset_unlock(&drm->dev->mode_config.connection_mutex);
-
drm_connector_put(&mstc->connector);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 07/20] drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails
While this isn't a complete fix, this will improve the reliability of
drm_dp_get_last_connected_port_and_mstb() pretty significantly during
hotplug events, since there's a chance that the in-memory topology tree
may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
is called and thus might end up causing our search to fail on an mstb
whose topology refcount has reached 0, but has not yet been removed from
it's parent.
Ideally, we should further fix this problem by ensuring that we deal
with the potential for racing with a hotplug event, which would look
like this:
* drm_dp_payload_send_msg() retrieves the last living relative of mstb
with drm_dp_get_last_connected_port_and_mstb()
* drm_dp_payload_send_msg() starts building payload message
At the same time, mstb gets unplugged from the topology and is no
longer the actual last living relative of the original mstb
* drm_dp_payload_send_msg() tries sending the payload message, hub times
out
* Hub timed out, we give up and run away-resulting in the payload being
leaked
This could be fixed by restarting the
drm_dp_get_last_connected_port_and_mstb() search whenever we get a
timeout, sending the payload to the new mstb, then repeating until
either the entire topology is removed from the system or
drm_dp_get_last_connected_port_and_mstb() fails. But since the above
race condition is not terribly likely, we'll address that in a later
patch series once we've improved the recovery handling for VCPI
allocations in the rest of the DP MST helpers.
Changes since v1:
* Convert kerneldoc for drm_dp_get_last_connected_port_and_mstb to
normal comment - danvet
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 44 +--
1 file changed, 34 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 796985609933..7a251905b3c4 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2048,24 +2048,40 @@ static struct drm_dp_mst_port
*drm_dp_get_last_connected_port_to_mstb(struct drm
return
drm_dp_get_last_connected_port_to_mstb(mstb->port_parent->parent);
}
-static struct drm_dp_mst_branch
*drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
-struct
drm_dp_mst_branch *mstb,
-int
*port_num)
+/*
+ * Searches upwards in the topology starting from mstb to try to find the
+ * closest available parent of mstb that's still connected to the rest of the
+ * topology. This can be used in order to perform operations like releasing
+ * payloads, where the branch device which owned the payload may no longer be
+ * around and thus would require that the payload on the last living relative
+ * be freed instead.
+ */
+static struct drm_dp_mst_branch *
+drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb,
+ int *port_num)
{
struct drm_dp_mst_branch *rmstb = NULL;
struct drm_dp_mst_port *found_port;
+
mutex_lock(&mgr->lock);
- if (mgr->mst_primary) {
+ if (!mgr->mst_primary)
+ goto out;
+
+ do {
found_port = drm_dp_get_last_connected_port_to_mstb(mstb);
+ if (!found_port)
+ break;
- if (found_port) {
+ if (drm_dp_mst_topology_try_get_mstb(found_port->parent)) {
rmstb = found_port->parent;
- if (drm_dp_mst_topology_try_get_mstb(rmstb))
- *port_num = found_port->port_num;
- else
- rmstb = NULL;
+ *port_num = found_port->port_num;
+ } else {
+ /* Search again, starting from this parent */
+ mstb = found_port->parent;
}
- }
+ } while (!rmstb);
+out:
mutex_unlock(&mgr->lock);
return rmstb;
}
@@ -2114,6 +2130,14 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
drm_dp_queue_down_tx(mgr, txmsg);
+ /*
+* FIXME: there is a small chance that between getting the last
+* connected mstb and sending the payload message, the last connected
+* mstb could also be removed from the topology. In the future, this
+* needs to be fixed by restarting the
+* drm_dp_get_last_connected_port_and_mstb() search in the event of a
+* timeout if the topology is still connected to the system.
+*/
ret = drm_dp_mst_wait_tx_reply(mstb, txmsg
[Intel-gfx] [PATCH v6 10/20] drm/i915: Keep malloc references to MST ports
So that the ports stay around until we've destroyed the connectors, in order to ensure that we don't pass an invalid pointer to any MST helpers once we introduce the new MST VCPI helpers. Changes since v1: * Move drm_dp_mst_get_port_malloc() to where we assign intel_connector->port - danvet Signed-off-by: Lyude Paul Reviewed-by: Daniel Vetter Cc: David Airlie Cc: Jerry Zuo Cc: Harry Wentland Cc: Juston Li --- drivers/gpu/drm/i915/intel_connector.c | 4 drivers/gpu/drm/i915/intel_dp_mst.c| 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_connector.c b/drivers/gpu/drm/i915/intel_connector.c index 4f4ffd1c8fd3..ee16758747c5 100644 --- a/drivers/gpu/drm/i915/intel_connector.c +++ b/drivers/gpu/drm/i915/intel_connector.c @@ -94,6 +94,10 @@ void intel_connector_destroy(struct drm_connector *connector) intel_panel_fini(&intel_connector->panel); drm_connector_cleanup(connector); + + if (intel_connector->port) + drm_dp_mst_put_port_malloc(intel_connector->port); + kfree(connector); } diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index 4eae81671b0e..cdce0c519f9a 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -456,6 +456,7 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo intel_connector->get_hw_state = intel_dp_mst_get_hw_state; intel_connector->mst_port = intel_dp; intel_connector->port = port; + drm_dp_mst_get_port_malloc(port); connector = &intel_connector->base; ret = drm_connector_init(dev, connector, &intel_dp_mst_connector_funcs, -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 06/20] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current scheme works like this:
drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When
this refcount hits 0 for either of the two, they're removed from the
topology state, but not immediately freed. Both ports and branch devices
will reinitialize their kref once it's hit 0 before actually destroying
themselves. The intended purpose behind this is so that we can avoid
problems like not being able to free a remote payload that might still
be active, due to us having removed all of the port/branch device
structures in memory, as per:
commit 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
Which may have worked, but then it caused use-after-free errors. Being
new to MST at the time, I tried fixing it;
commit 263efde31f97 ("drm/dp/mst: Get validated port ref in
drm_dp_update_payload_part1()")
But, that was broken: both drm_dp_mst_port and drm_dp_mst_branch structs
are validated in almost every DP MST helper function. Simply put, this
means we go through the topology and try to see if the given
drm_dp_mst_branch or drm_dp_mst_port is still attached to something
before trying to use it in order to avoid dereferencing freed memory
(something that has happened a LOT in the past with this library).
Because of this it doesn't actually matter whether or not we keep keep
the ports and branches around in memory as that's not enough, because
any function that validates the branches and ports passed to it will
still reject them anyway since they're no longer in the topology
structure. So, use-after-free errors were fixed but payload deallocation
was completely broken.
Two years later, AMD informed me about this issue and I attempted to
come up with a temporary fix, pending a long-overdue cleanup of this
library:
commit c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction,
just ref")
But then that introduced use-after-free errors, so I quickly reverted
it:
commit 9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during
destruction, just ref"")
And in the process, learned that there is just no simple fix for this:
the design is just broken. Unfortunately, the usage of these helpers are
quite broken as well. Some drivers like i915 have been smart enough to
avoid accessing any kind of information from MST port structures, but
others like nouveau have assumed, understandably so, that
drm_dp_mst_port structures are normal and can just be accessed at any
time without worrying about use-after-free errors.
After a lot of discussion, me and Daniel Vetter came up with a better
idea to replace all of this.
To summarize, since this is documented far more indepth in the
documentation this patch introduces, we make it so that drm_dp_mst_port
and drm_dp_mst_branch structures have two different classes of
refcounts: topology_kref, and malloc_kref. topology_kref corresponds to
the lifetime of the given drm_dp_mst_port or drm_dp_mst_branch in it's
given topology. Once it hits zero, any associated connectors are removed
and the branch or port can no longer be validated. malloc_kref
corresponds to the lifetime of the memory allocation for the actual
structure, and will always be non-zero so long as the topology_kref is
non-zero. This gives us a way to allow callers to hold onto port and
branch device structures past their topology lifetime, and dramatically
simplifies the lifetimes of both structures. This also finally fixes the
port deallocation problem, properly.
Additionally: since this now means that we can keep ports and branch
devices allocated in memory for however long we need, we no longer need
a significant amount of the port validation that we currently do.
Additionally, there is one last scenario that this fixes, which couldn't
have been fixed properly beforehand:
- CPU1 unrefs port from topology (refcount 1->0)
- CPU2 refs port in topology(refcount 0->1)
Since we now can guarantee memory safety for ports and branches
as-needed, we also can make our main reference counting functions fix
this problem by using kref_get_unless_zero() internally so that topology
refcounts can only ever reach 0 once.
Changes since v4:
* Change the kernel-figure summary for dp-mst/topology-figure-1.dot a
bit - danvet
* Remove figure numbers - danvet
Changes since v3:
* Remove rebase detritus - danvet
* Split out purely style changes into separate patches - hwentlan
Changes since v2:
* Fix commit message - checkpatch
* s/)-1/) - 1/g - checkpatch
Changes since v1:
* Remove forward declarations - danvet
* Move "Branch device and port refcounting" section from documentation
into kernel-doc comments - danvet
* Export internal topology lifetime functions into their own section in
the kernel
[Intel-gfx] [PATCH v6 11/20] drm/amdgpu/display: Keep malloc ref to MST port
Just like i915 and nouveau, it's a good idea for us to hold a malloc
reference to the port here so that we never pass a freed pointer to any
of the DP MST helper functions.
Also, we stop unsetting aconnector->port in
dm_dp_destroy_mst_connector(). There's literally no point to that
assignment that I can see anyway.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 5e7ca1f3a8d1..24632727e127 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -191,6 +191,7 @@ dm_dp_mst_connector_destroy(struct drm_connector *connector)
drm_encoder_cleanup(&amdgpu_encoder->base);
kfree(amdgpu_encoder);
drm_connector_cleanup(connector);
+ drm_dp_mst_put_port_malloc(amdgpu_dm_connector->port);
kfree(amdgpu_dm_connector);
}
@@ -363,7 +364,9 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
amdgpu_dm_connector_funcs_reset(connector);
DRM_INFO("DM_MST: added connector: %p [id: %d] [master: %p]\n",
- aconnector, connector->base.id, aconnector->mst_port);
+aconnector, connector->base.id, aconnector->mst_port);
+
+ drm_dp_mst_get_port_malloc(port);
DRM_DEBUG_KMS(":%d\n", connector->base.id);
@@ -379,12 +382,12 @@ static void dm_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
DRM_INFO("DM_MST: Disabling connector: %p [id: %d] [master: %p]\n",
- aconnector, connector->base.id,
aconnector->mst_port);
+aconnector, connector->base.id, aconnector->mst_port);
- aconnector->port = NULL;
if (aconnector->dc_sink) {
amdgpu_dm_update_freesync_caps(connector, NULL);
- dc_link_remove_remote_sink(aconnector->dc_link,
aconnector->dc_sink);
+ dc_link_remove_remote_sink(aconnector->dc_link,
+ aconnector->dc_sink);
dc_sink_release(aconnector->dc_sink);
aconnector->dc_sink = NULL;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 09/20] drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
Up until now, freeing payloads on remote MST hubs that just had ports
removed has almost never worked because we've been relying on port
validation in order to stop us from accessing ports that have already
been freed from memory, but ports which need their payloads released due
to being removed will never be a valid part of the topology after
they've been removed.
Since we've introduced malloc refs, we can replace all of the validation
logic in payload helpers which are used for deallocation with some
well-placed malloc krefs. This ensures that regardless of whether or not
the ports are still valid and in the topology, any port which has an
allocated payload will remain allocated in memory until it's payloads
have been removed - finally allowing us to actually release said
payloads correctly.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Reviewed-by: Harry Wentland
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 54 +++
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index bb9107852fed..b5976f8c318c 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2095,10 +2095,6 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
u8 sinks[DRM_DP_MAX_SDP_STREAMS];
int i;
- port = drm_dp_mst_topology_get_port_validated(mgr, port);
- if (!port)
- return -EINVAL;
-
port_num = port->port_num;
mstb = drm_dp_mst_topology_get_mstb_validated(mgr, port->parent);
if (!mstb) {
@@ -2106,10 +2102,8 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
port->parent,
&port_num);
- if (!mstb) {
- drm_dp_mst_topology_put_port(port);
+ if (!mstb)
return -EINVAL;
- }
}
txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
@@ -2146,7 +2140,6 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
kfree(txmsg);
fail_put:
drm_dp_mst_topology_put_mstb(mstb);
- drm_dp_mst_topology_put_port(port);
return ret;
}
@@ -2251,15 +2244,16 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
*/
int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
{
- int i, j;
- int cur_slots = 1;
struct drm_dp_payload req_payload;
struct drm_dp_mst_port *port;
+ int i, j;
+ int cur_slots = 1;
mutex_lock(&mgr->payload_lock);
for (i = 0; i < mgr->max_payloads; i++) {
struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
struct drm_dp_payload *payload = &mgr->payloads[i];
+ bool put_port = false;
/* solve the current payloads - compare to the hw ones
- update the hw view */
@@ -2267,12 +2261,20 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr)
if (vcpi) {
port = container_of(vcpi, struct drm_dp_mst_port,
vcpi);
- port = drm_dp_mst_topology_get_port_validated(mgr,
- port);
- if (!port) {
- mutex_unlock(&mgr->payload_lock);
- return -EINVAL;
+
+ /* Validated ports don't matter if we're releasing
+* VCPI
+*/
+ if (vcpi->num_slots) {
+ port = drm_dp_mst_topology_get_port_validated(
+ mgr, port);
+ if (!port) {
+ mutex_unlock(&mgr->payload_lock);
+ return -EINVAL;
+ }
+ put_port = true;
}
+
req_payload.num_slots = vcpi->num_slots;
req_payload.vcpi = vcpi->vcpi;
} else {
@@ -2304,7 +2306,7 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr)
}
cur_slots += req_payload.num_slots;
- if (port)
+ if (put_port)
drm_dp_mst_topology_put_port(port);
}
@@ -3120,6 +3122,8 @@ bool drm_dp_mst_allocate_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n",
pbn, port->vcpi.num_slots);
+ /* Keep port allocated until it's payload has been
[Intel-gfx] [PATCH v6 03/20] drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi()
Fix some indenting, split some stuff across multiple lines.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index fc93a71c42b0..a63a4d32962a 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2731,7 +2731,8 @@ bool drm_dp_mst_allocate_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
return false;
if (port->vcpi.vcpi > 0) {
- DRM_DEBUG_KMS("payload: vcpi %d already allocated for pbn %d -
requested pbn %d\n", port->vcpi.vcpi, port->vcpi.pbn, pbn);
+ DRM_DEBUG_KMS("payload: vcpi %d already allocated for pbn %d -
requested pbn %d\n",
+ port->vcpi.vcpi, port->vcpi.pbn, pbn);
if (pbn == port->vcpi.pbn) {
drm_dp_put_port(port);
return true;
@@ -2741,11 +2742,11 @@ bool drm_dp_mst_allocate_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
ret = drm_dp_init_vcpi(mgr, &port->vcpi, pbn, slots);
if (ret) {
DRM_DEBUG_KMS("failed to init vcpi slots=%d max=63 ret=%d\n",
- DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
+ DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
goto out;
}
DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n",
- pbn, port->vcpi.num_slots);
+ pbn, port->vcpi.num_slots);
drm_dp_put_port(port);
return true;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 04/20] drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi()
Split some stuff across multiple lines
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index a63a4d32962a..75cca6a843fb 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2790,7 +2790,8 @@ EXPORT_SYMBOL(drm_dp_mst_reset_vcpi_slots);
* @mgr: manager for this port
* @port: unverified port to deallocate vcpi for
*/
-void drm_dp_mst_deallocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct
drm_dp_mst_port *port)
+void drm_dp_mst_deallocate_vcpi(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port)
{
port = drm_dp_get_validated_port_ref(mgr, port);
if (!port)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 02/20] drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg()
Split some stuff across multiple lines, remove some unnecessary braces
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index c93bff5527fd..fc93a71c42b0 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1331,9 +1331,9 @@ static struct drm_dp_mst_branch
*get_mst_branch_device_by_guid_helper(
return NULL;
}
-static struct drm_dp_mst_branch *drm_dp_get_mst_branch_device_by_guid(
- struct drm_dp_mst_topology_mgr *mgr,
- uint8_t *guid)
+static struct drm_dp_mst_branch *
+drm_dp_get_mst_branch_device_by_guid(struct drm_dp_mst_topology_mgr *mgr,
+uint8_t *guid)
{
struct drm_dp_mst_branch *mstb;
@@ -1739,7 +1739,9 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
port_num = port->port_num;
mstb = drm_dp_get_validated_mstb_ref(mgr, port->parent);
if (!mstb) {
- mstb = drm_dp_get_last_connected_port_and_mstb(mgr,
port->parent, &port_num);
+ mstb = drm_dp_get_last_connected_port_and_mstb(mgr,
+ port->parent,
+ &port_num);
if (!mstb) {
drm_dp_put_port(port);
@@ -1765,9 +1767,9 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
ret = drm_dp_mst_wait_tx_reply(mstb, txmsg);
if (ret > 0) {
- if (txmsg->reply.reply_type == 1) {
+ if (txmsg->reply.reply_type == 1)
ret = -EINVAL;
- } else
+ else
ret = 0;
}
kfree(txmsg);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 05/20] drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends
s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/
s/drm_dp_put_port/drm_dp_mst_topology_put_port/
s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/
s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/
This is a much more consistent naming scheme, and will make even more
sense once we redesign how the current refcounting scheme here works.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Reviewed-by: Harry Wentland
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 114 ++
1 file changed, 62 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 75cca6a843fb..074e985093ca 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -46,7 +46,7 @@ static bool dump_dp_payload_table(struct
drm_dp_mst_topology_mgr *mgr,
char *buf);
static int test_calc_pbn_mode(void);
-static void drm_dp_put_port(struct drm_dp_mst_port *port);
+static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
int id,
@@ -888,7 +888,7 @@ static void drm_dp_destroy_mst_branch_device(struct kref
*kref)
*/
list_for_each_entry_safe(port, tmp, &mstb->ports, next) {
list_del(&port->next);
- drm_dp_put_port(port);
+ drm_dp_mst_topology_put_port(port);
}
/* drop any tx slots msg */
@@ -911,7 +911,7 @@ static void drm_dp_destroy_mst_branch_device(struct kref
*kref)
kref_put(kref, drm_dp_free_mst_branch_device);
}
-static void drm_dp_put_mst_branch_device(struct drm_dp_mst_branch *mstb)
+static void drm_dp_mst_topology_put_mstb(struct drm_dp_mst_branch *mstb)
{
kref_put(&mstb->kref, drm_dp_destroy_mst_branch_device);
}
@@ -930,7 +930,7 @@ static void drm_dp_port_teardown_pdt(struct drm_dp_mst_port
*port, int old_pdt)
case DP_PEER_DEVICE_MST_BRANCHING:
mstb = port->mstb;
port->mstb = NULL;
- drm_dp_put_mst_branch_device(mstb);
+ drm_dp_mst_topology_put_mstb(mstb);
break;
}
}
@@ -970,12 +970,14 @@ static void drm_dp_destroy_port(struct kref *kref)
kfree(port);
}
-static void drm_dp_put_port(struct drm_dp_mst_port *port)
+static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
{
kref_put(&port->kref, drm_dp_destroy_port);
}
-static struct drm_dp_mst_branch
*drm_dp_mst_get_validated_mstb_ref_locked(struct drm_dp_mst_branch *mstb,
struct drm_dp_mst_branch *to_find)
+static struct drm_dp_mst_branch *
+drm_dp_mst_topology_get_mstb_validated_locked(struct drm_dp_mst_branch *mstb,
+ struct drm_dp_mst_branch *to_find)
{
struct drm_dp_mst_port *port;
struct drm_dp_mst_branch *rmstb;
@@ -985,7 +987,8 @@ static struct drm_dp_mst_branch
*drm_dp_mst_get_validated_mstb_ref_locked(struct
}
list_for_each_entry(port, &mstb->ports, next) {
if (port->mstb) {
- rmstb =
drm_dp_mst_get_validated_mstb_ref_locked(port->mstb, to_find);
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
+ port->mstb, to_find);
if (rmstb)
return rmstb;
}
@@ -993,12 +996,15 @@ static struct drm_dp_mst_branch
*drm_dp_mst_get_validated_mstb_ref_locked(struct
return NULL;
}
-static struct drm_dp_mst_branch *drm_dp_get_validated_mstb_ref(struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_branch *mstb)
+static struct drm_dp_mst_branch *
+drm_dp_mst_topology_get_mstb_validated(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb)
{
struct drm_dp_mst_branch *rmstb = NULL;
mutex_lock(&mgr->lock);
if (mgr->mst_primary)
- rmstb =
drm_dp_mst_get_validated_mstb_ref_locked(mgr->mst_primary, mstb);
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
+ mgr->mst_primary, mstb);
mutex_unlock(&mgr->lock);
return rmstb;
}
@@ -1021,7 +1027,9 @@ static struct drm_dp_mst_port
*drm_dp_mst_get_port_ref_locked(struct drm_dp_mst_
return NULL;
}
-static struct drm_dp_mst_port *drm_dp_get_validated_port_ref(struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port)
+static struct drm_dp_mst_port *
+drm_dp_mst_topology_get_port_validated(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port)
{
struct drm_dp_mst_port *rport = NULL;
mutex_lock(&mgr->lock);
@@ -1215,7 +1223,7 @@ static void drm_dp_add_port(s
[Intel-gfx] [PATCH v6 01/20] drm/dp_mst: Fix some formatting in drm_dp_add_port()
Reindent some stuff, and split some stuff across multiple lines so we
aren't going over the text width limit.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 2ab16c9e6243..c93bff5527fd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1184,11 +1184,13 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
if (old_ddps != port->ddps) {
if (port->ddps) {
- if (!port->input)
- drm_dp_send_enum_path_resources(mstb->mgr,
mstb, port);
+ if (!port->input) {
+ drm_dp_send_enum_path_resources(mstb->mgr,
+ mstb, port);
+ }
} else {
port->available_pbn = 0;
- }
+ }
}
if (old_pdt != port->pdt && !port->input) {
@@ -1202,8 +1204,11 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
if (created && !port->input) {
char proppath[255];
- build_mst_prop_path(mstb, port->port_num, proppath,
sizeof(proppath));
- port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr,
port, proppath);
+ build_mst_prop_path(mstb, port->port_num, proppath,
+ sizeof(proppath));
+ port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr,
+ port,
+ proppath);
if (!port->connector) {
/* remove it from the port list */
mutex_lock(&mstb->mgr->lock);
@@ -1216,7 +1221,8 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
if ((port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV ||
port->pdt == DP_PEER_DEVICE_SST_SINK) &&
port->port_num >= DP_MST_LOGICAL_PORT_0) {
- port->cached_edid = drm_get_edid(port->connector,
&port->aux.ddc);
+ port->cached_edid = drm_get_edid(port->connector,
+&port->aux.ddc);
drm_connector_set_tile_property(port->connector);
}
(*mstb->mgr->cbs->register_connector)(port->connector);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 00/20] MST refcounting/atomic helpers cleanup
This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a ton of magic in the atomic helpers to work around properly and in many situations just plain doesn't work as intended. There's still more cleanup that can be done, but I think this is a good place to start off for now :). Also available on gitlab: https://gitlab.freedesktop.org/lyudess/linux/commits/wip/mst-dual-kref-start-v6 Lyude Paul (20): drm/dp_mst: Fix some formatting in drm_dp_add_port() drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg() drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi() drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi() drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends drm/dp_mst: Introduce new refcounting scheme for mstbs and ports drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails drm/dp_mst: Stop releasing VCPI when removing ports from topology drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs drm/i915: Keep malloc references to MST ports drm/amdgpu/display: Keep malloc ref to MST port drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector() drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup() drm/nouveau: Keep malloc references to MST ports drm/nouveau: Stop unsetting mstc->port, use malloc refs drm/nouveau: Grab payload lock in nv50_msto_payload() drm/dp_mst: Add some atomic state iterator macros drm/dp_mst: Start tracking per-port VCPI allocations drm/dp_mst: Check payload count in drm_dp_mst_atomic_check() drm/nouveau: Use atomic VCPI helpers for MST .../gpu/dp-mst/topology-figure-1.dot | 52 + .../gpu/dp-mst/topology-figure-2.dot | 56 ++ .../gpu/dp-mst/topology-figure-3.dot | 59 ++ Documentation/gpu/drm-kms-helpers.rst | 26 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 11 +- drivers/gpu/drm/drm_dp_mst_topology.c | 946 ++ drivers/gpu/drm/i915/intel_connector.c| 4 + drivers/gpu/drm/i915/intel_display.c | 4 + drivers/gpu/drm/i915/intel_dp_mst.c | 55 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 96 +- include/drm/drm_dp_mst_helper.h | 151 ++- 11 files changed, 1204 insertions(+), 256 deletions(-) create mode 100644 Documentation/gpu/dp-mst/topology-figure-1.dot create mode 100644 Documentation/gpu/dp-mst/topology-figure-2.dot create mode 100644 Documentation/gpu/dp-mst/topology-figure-3.dot -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen
Hi Ville,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-i915-Try-to-sanitize-bogus-DPLL-state-left-over-by-broken-SNB-BIOSen/20190109-222838
base: git://anongit.freedesktop.org/drm-intel for-linux-next
New smatch warnings:
drivers/gpu/drm/i915/intel_display.c:15452 has_bogus_dpll_config() warn:
variable dereferenced before check 'crtc_state' (see line 15439)
drivers/gpu/drm/i915/intel_display.c:15472 intel_sanitize_encoder() error: we
previously assumed 'crtc_state' could be null (see line 15469)
drivers/gpu/drm/i915/intel_display.c:15487 intel_sanitize_encoder() warn:
variable dereferenced before check 'crtc_state' (see line 15472)
#
https://github.com/0day-ci/linux/commit/5a0056f774727561e522ccde5fe7fe78d343d25f
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 5a0056f774727561e522ccde5fe7fe78d343d25f
vim +/crtc_state +15452 drivers/gpu/drm/i915/intel_display.c
249293524 Daniel Vetter 2012-07-02 15436
5a0056f77 Ville Syrjälä 2019-01-09 15437 static bool
has_bogus_dpll_config(struct intel_crtc_state *crtc_state)
5a0056f77 Ville Syrjälä 2019-01-09 15438 {
5a0056f77 Ville Syrjälä 2019-01-09 @15439 struct drm_i915_private
*dev_priv = to_i915(crtc_state->base.crtc->dev);
5a0056f77 Ville Syrjälä 2019-01-09 15440
5a0056f77 Ville Syrjälä 2019-01-09 15441 /*
5a0056f77 Ville Syrjälä 2019-01-09 15442* Some SNB BIOSen (eg. ASUS
K53SV) are known to misprogram
5a0056f77 Ville Syrjälä 2019-01-09 15443* the hardware when a high res
displays plugged in. DPLL P
5a0056f77 Ville Syrjälä 2019-01-09 15444* divider is zero, and the
pipe timings are bonkers. We'll
5a0056f77 Ville Syrjälä 2019-01-09 15445* try to disable everything in
that case.
5a0056f77 Ville Syrjälä 2019-01-09 15446*
5a0056f77 Ville Syrjälä 2019-01-09 15447* FIXME would be nice to be
able to sanitize this state
5a0056f77 Ville Syrjälä 2019-01-09 15448* without several WARNs, but
for now let's take the easy
5a0056f77 Ville Syrjälä 2019-01-09 15449* road.
5a0056f77 Ville Syrjälä 2019-01-09 15450*/
5a0056f77 Ville Syrjälä 2019-01-09 15451 return IS_GEN(dev_priv, 6) &&
5a0056f77 Ville Syrjälä 2019-01-09 @15452 crtc_state &&
5a0056f77 Ville Syrjälä 2019-01-09 15453 crtc_state->base.active
&&
5a0056f77 Ville Syrjälä 2019-01-09 15454 crtc_state->shared_dpll
&&
5a0056f77 Ville Syrjälä 2019-01-09 15455 crtc_state->port_clock
== 0;
5a0056f77 Ville Syrjälä 2019-01-09 15456 }
5a0056f77 Ville Syrjälä 2019-01-09 15457
249293524 Daniel Vetter 2012-07-02 15458 static void
intel_sanitize_encoder(struct intel_encoder *encoder)
249293524 Daniel Vetter 2012-07-02 15459 {
70332ac53 Imre Deak 2018-11-01 15460 struct drm_i915_private
*dev_priv = to_i915(encoder->base.dev);
249293524 Daniel Vetter 2012-07-02 15461 struct intel_connector
*connector;
5a0056f77 Ville Syrjälä 2019-01-09 15462 struct intel_crtc *crtc =
to_intel_crtc(encoder->base.crtc);
5a0056f77 Ville Syrjälä 2019-01-09 15463 struct intel_crtc_state
*crtc_state = crtc ?
5a0056f77 Ville Syrjälä 2019-01-09 15464
to_intel_crtc_state(crtc->base.state) : NULL;
249293524 Daniel Vetter 2012-07-02 15465
249293524 Daniel Vetter 2012-07-02 15466 /* We need to check both for a
crtc link (meaning that the
249293524 Daniel Vetter 2012-07-02 15467* encoder is active and trying
to read from a pipe) and the
249293524 Daniel Vetter 2012-07-02 15468* pipe itself being active. */
5a0056f77 Ville Syrjälä 2019-01-09 @15469 bool has_active_crtc =
crtc_state &&
5a0056f77 Ville Syrjälä 2019-01-09 15470 crtc_state->base.active;
5a0056f77 Ville Syrjälä 2019-01-09 15471
5a0056f77 Ville Syrjälä 2019-01-09 @15472 if
(has_bogus_dpll_config(crtc_state)) {
5a0056f77 Ville Syrjälä 2019-01-09 15473 DRM_DEBUG_KMS("BIOS has
misprogrammed the hardware. Disabling pipe %c\n",
5a0056f77 Ville Syrjälä 2019-01-09 15474
pipe_name(crtc->pipe));
5a0056f77 Ville Syrjälä 2019-01-09 15475 has_active_crtc = false;
5a0056f77 Ville Syrjälä 2019-01-09 15476 }
249293524 Daniel Vetter 2012-07-02 15477
496b0fc37 Maarten Lankhorst 2016-08-23 15478 connector =
intel_encoder_find_connector(encoder);
496b0fc37 Maarten Lankhorst 2016-08-23 15479 if (connector &&
!has_active_crtc) {
249293524 Daniel Vetter 2012-07-02 15480
DRM_DEBUG_KMS("[ENCODER:%d:%s] has active connectors but no active pipe!\n",
249293524 Daniel Vetter 2012-07-02 15481
encoder->base.base.id,
8e329a039 Jani Nikula 2014-06-03 15482
encoder->base.name);
249293524 Daniel Vetter
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Guard error capture against unpinned vma
== Series Details ==
Series: drm/i915: Guard error capture against unpinned vma
URL : https://patchwork.freedesktop.org/series/54994/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5392_full -> Patchwork_11274_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11274_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11274_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_11274_full:
### IGT changes ###
Warnings
* igt@pm_rc6_residency@rc6-accuracy:
- shard-snb: PASS -> {SKIP}
Known issues
Here are the changes found in Patchwork_11274_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_whisper@normal:
- shard-skl: PASS -> TIMEOUT [fdo#108592]
* igt@i915_suspend@fence-restore-untiled:
- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
* igt@i915_suspend@shrink:
- shard-snb: NOTRUN -> DMESG-WARN [fdo#109244]
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-kbl: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-a-ctm-max:
- shard-kbl: NOTRUN -> FAIL [fdo#108147]
* igt@kms_color@pipe-c-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-skl: NOTRUN -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-256x85-random:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu:
- shard-kbl: NOTRUN -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
- shard-glk: PASS -> FAIL [fdo#103167] +3
* igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
- shard-skl: NOTRUN -> FAIL [fdo#105683]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-onoff:
- shard-skl: NOTRUN -> FAIL [fdo#103167] +1
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1
* igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590] +1
* igt@kms_plane_multiple@atomic-pipe-a-tiling-none:
- shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@pm_backlight@fade_with_suspend:
- shard-skl: NOTRUN -> FAIL [fdo#107847]
Possible fixes
* igt@drm_read@invalid-buffer:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@gem_workarounds@suspend-resume-fd:
- shard-apl: DMESG-WARN [fdo#108566] -> PASS
* igt@i915_suspend@fence-restore-untiled:
- shard-snb: FAIL [fdo#103375] -> PASS
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl: FAIL [fdo#106510] / [fdo#108145] -> PASS
* igt@kms_chv_cursor_fail@pipe-b-128x128-top-edge:
- shard-skl: FAIL [fdo#104671] -> PASS +1
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-skl: INCOMPLETE [fdo#104108] -> PASS
* igt@kms_cursor_crc@cursor-256x256-onscreen:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-64x64-dpms:
- shard-skl: FAIL [fdo#103232] -> PASS +2
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-skl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw: FAIL [fdo#105767] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-skl: FAIL [fdo#105363] -> PASS
* igt@kms_flip_tiling@flip-changes-tiling:
- shard-skl: FAIL [fdo#108303] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-apl: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-cpu:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-pwrite:
- shard-skl: FAIL [fdo#103167] / [fdo#105682] -> PASS
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-wc:
- shard-skl: FAIL [fdo#105682] ->
Re: [Intel-gfx] [PATCH 16/21] drm/i915: Markup paired operations on display power domains
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-01-10 15:51:33)
>> Chris Wilson writes:
>> > @@ -680,6 +682,8 @@ static int i915_interrupt_info(struct seq_file *m,
>> > void *data)
>> > wakeref = intel_runtime_pm_get(dev_priv);
>> >
>> > if (IS_CHERRYVIEW(dev_priv)) {
>> > + intel_wakeref_t pref;
>> > +
>>
>> In here you are introducing a new, descriptive, power reference for display.
>> But then you drop it after using it twice. And can't seem to find
>> reason for inconsistency.
>
> pref, pref, pref...
>
>> > seq_printf(m, "Master Interrupt Control:\t%08x\n",
>> > I915_READ(GEN8_MASTER_IRQ));
>> >
>> > @@ -695,8 +699,9 @@ static int i915_interrupt_info(struct seq_file *m,
>> > void *data)
>> > enum intel_display_power_domain power_domain;
>> >
>> > power_domain = POWER_DOMAIN_PIPE(pipe);
>> > - if (!intel_display_power_get_if_enabled(dev_priv,
>> > -
>> > power_domain)) {
>> > + pref = intel_display_power_get_if_enabled(dev_priv,
>> > +
>> > power_domain);
>> > + if (!pref) {
>
> ah, it would have been chosen to fit 80cols.
You should have adopted it then fully! :)
>
>> > seq_printf(m, "Pipe %c power disabled\n",
>> > pipe_name(pipe));
>> > continue;
>> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> > b/drivers/gpu/drm/i915/i915_drv.h
>> > index f0a405604b75..44c1b21febba 100644
>> > --- a/drivers/gpu/drm/i915/i915_drv.h
>> > +++ b/drivers/gpu/drm/i915/i915_drv.h
>> > @@ -344,6 +344,7 @@ struct intel_csr {
>> > uint32_t mmiodata[8];
>> > uint32_t dc_state;
>> > uint32_t allowed_dc_mask;
>> > + intel_wakeref_t wakeref;
>> > };
>> >
>> > enum i915_cache_level {
>> > @@ -1982,6 +1983,7 @@ struct drm_i915_private {
>> >* is a slight delay before we do so.
>> >*/
>> > intel_wakeref_t awake;
>> > + intel_wakeref_t power;
>>
>> This prolly explains the prefs above :)
>
> Possibly.
>
>> > - intel_display_power_put(dev_priv, POWER_DOMAIN_PORT_DDI_A_IO);
>> > -
>> > - if (intel_dsi->dual_link)
>> > - intel_display_power_put(dev_priv,
>> > POWER_DOMAIN_PORT_DDI_B_IO);
>> > + for_each_dsi_port(port, intel_dsi->ports) {
>> > + intel_wakeref_t wakeref;
>> > +
>> > + wakeref = fetch_and_zero(&intel_dsi->io_wakeref[port]);
>> > + if (wakeref) {
>> > + intel_display_power_put(dev_priv,
>> > + port == PORT_A ?
>> > + POWER_DOMAIN_PORT_DDI_A_IO :
>> > + POWER_DOMAIN_PORT_DDI_B_IO,
>> > + wakeref);
>> > + }
>> > + }
>>
>> Ok, well. I have been trying to figure out what really is going on here.
>>
>> First it seems that you fix a bug. We take refs for each dsi port but
>> only release once special casing 'dual_link' without this patch.
>>
>> Second, all the hw access is before getting the refs, looking
>> suspicious.
>
> There's always been two, just this moves into a for(;;). I don't think
> it was buggy, but I do think the for(;;) has the advantage of being
> clearer that it operates over all the ports and wakerefs.
Agreed that your patch makes it more clear.
I am still suspicious about the ordering, hopefully there is
upper lever pdomain to cover access. But that is not
problem for this patch.
Reviewed-by: Mika Kuoppala
>
>> > @@ -15808,12 +15827,13 @@ intel_modeset_setup_hw_state(struct drm_device
>> > *dev,
>> >struct drm_modeset_acquire_ctx *ctx)
>> > {
>> > struct drm_i915_private *dev_priv = to_i915(dev);
>> > - struct intel_crtc *crtc;
>> > struct intel_crtc_state *crtc_state;
>> > struct intel_encoder *encoder;
>> > + struct intel_crtc *crtc;
>>
>> Not that I mind but I don't understand the reasoning
>> behind the change of order on this and on few other places in this
>> patch.
>
> Just quietly moving everyone over to a tidy set of variable definitions
> (we are not meant to grow Christmas trees as part of the kernel coding
> style).
>
>> > -/**
>> > - * intel_display_power_put - release a power domain reference
>> > - * @dev_priv: i915 device instance
>> > - * @domain: power domain to reference
>> > - *
>> > - * This function drops the power domain reference obtained by
>> > - * intel_display_power_get() and might power down the corresponding
>> > hardware
>> > - * block right away if this is the last reference.
>> > - */
>> > -void intel_display_power_put(struct drm_i915_private *dev_priv,
>>
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)
Quoting Ville Syrjälä (2019-01-10 16:03:21)
> On Thu, Jan 10, 2019 at 10:38:07AM +, Chris Wilson wrote:
> > Broadwater and the rest of gen4 do support being able to saving and
> > reloading context specific registers between contexts, providing isolation
> > of the basic GPU state (as programmable by userspace). This allows
> > userspace to assume that the GPU retains their state from one batch to the
> > next, minimising the amount of state it needs to reload and manually save
> > across batches.
> >
> > v2: CONSTANT_BUFFER woes
> >
> > Running through piglit turned up an interesting issue, a GPU hang inside
> > the context load. The context image includes the CONSTANT_BUFFER command
> > that loads an address into a on-gpu buffer, and the context load was
> > executing that immediately. However, since it was reading from the GTT
> > there is no guarantee that the GTT retains the same configuration as
> > when the context was saved, resulting in stray reads and a GPU hang.
> >
> > Having tried issuing a CONSTANT_BUFFER (to disable the command) from the
> > ring before saving the context to no avail, we resort to patching out
> > the instruction inside the context image before loading.
> >
> > This does impose that gen4 always reissues CONSTANT_BUFFER commands on
> > each batch, but due to the use of a shared GTT that was and will remain
> > a requirement.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Ville Syrjälä
> > Cc: Kenneth Graunke
> > Reviewed-by: Ville Syrjälä #v1
> > ---
> > drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
> > drivers/gpu/drm/i915/intel_gpu_commands.h | 3 +++
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 17 +
> > 3 files changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index f89b8f199e3f..88109e0de051 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -219,6 +219,7 @@ __intel_engine_context_size(struct drm_i915_private
> > *dev_priv, u8 class)
> > return round_up(GEN6_CXT_TOTAL_SIZE(cxt_size) * 64,
> > PAGE_SIZE);
> > case 5:
> > + case 4:
> > /*
> >* There is a discrepancy here between the size
> > reported
> >* by the register and the size of the context layout
> > @@ -235,7 +236,6 @@ __intel_engine_context_size(struct drm_i915_private
> > *dev_priv, u8 class)
> >cxt_size * 64,
> >cxt_size - 1);
> > return round_up(cxt_size * 64, PAGE_SIZE);
> > - case 4:
> > case 3:
> > case 2:
> > /* For the special day when i810 gets merged. */
> > diff --git a/drivers/gpu/drm/i915/intel_gpu_commands.h
> > b/drivers/gpu/drm/i915/intel_gpu_commands.h
> > index 105e2a9e874a..00c0175c37ed 100644
> > --- a/drivers/gpu/drm/i915/intel_gpu_commands.h
> > +++ b/drivers/gpu/drm/i915/intel_gpu_commands.h
> > @@ -266,6 +266,9 @@
> > #define GFX_OP_3DSTATE_BINDING_TABLE_EDIT_PS \
> > ((0x3<<29)|(0x3<<27)|(0x0<<24)|(0x47<<16))
> >
> > +#define GFX_OP_CONSTANT_BUFFER \
> > + (0x3 << 29 | 0x0 << 27 | 0x0 << 24 | 0x2 << 16)
> > +
> > #define MFX_WAIT ((0x3<<29)|(0x1<<27)|(0x0<<16))
> >
> > #define COLOR_BLT ((0x2<<29)|(0x40<<22))
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 889f3de79dd0..21bd71cf2e94 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1632,6 +1632,8 @@ static inline int mi_set_context(struct i915_request
> > *rq, u32 flags)
> > len += 2 + (num_rings ? 4*num_rings + 6 : 0);
> > else if (IS_GEN(i915, 5))
> > len += 2;
> > + else if (IS_GEN(i915, 4))
> > + len += 4;
> > if (flags & MI_FORCE_RESTORE) {
> > GEM_BUG_ON(flags & MI_RESTORE_INHIBIT);
> > flags &= ~MI_FORCE_RESTORE;
> > @@ -1668,6 +1670,21 @@ static inline int mi_set_context(struct i915_request
> > *rq, u32 flags)
> >* this should never take effect and so be a no-op!
> >*/
> > *cs++ = MI_SUSPEND_FLUSH | MI_SUSPEND_FLUSH_EN;
> > + } else if (IS_GEN(i915, 4)) {
> > + /*
> > + * Disable CONSTANT_BUFFER before it is loaded from the
> > context
> > + * image. For as it is loaded, it is executed and the stored
> > + * address may no longer be valid, leading to a GPU hang.
> > + *
> > + * This imposes the requirement that userspace reload their
> > + * CONSTANT_BUFFER on every batch, fortunately a requirement
> > + * they are already accustomed to f
Re: [Intel-gfx] [PATCH 16/21] drm/i915: Markup paired operations on display power domains
Quoting Mika Kuoppala (2019-01-10 15:51:33)
> Chris Wilson writes:
> > @@ -680,6 +682,8 @@ static int i915_interrupt_info(struct seq_file *m, void
> > *data)
> > wakeref = intel_runtime_pm_get(dev_priv);
> >
> > if (IS_CHERRYVIEW(dev_priv)) {
> > + intel_wakeref_t pref;
> > +
>
> In here you are introducing a new, descriptive, power reference for display.
> But then you drop it after using it twice. And can't seem to find
> reason for inconsistency.
pref, pref, pref...
> > seq_printf(m, "Master Interrupt Control:\t%08x\n",
> > I915_READ(GEN8_MASTER_IRQ));
> >
> > @@ -695,8 +699,9 @@ static int i915_interrupt_info(struct seq_file *m, void
> > *data)
> > enum intel_display_power_domain power_domain;
> >
> > power_domain = POWER_DOMAIN_PIPE(pipe);
> > - if (!intel_display_power_get_if_enabled(dev_priv,
> > -
> > power_domain)) {
> > + pref = intel_display_power_get_if_enabled(dev_priv,
> > +
> > power_domain);
> > + if (!pref) {
ah, it would have been chosen to fit 80cols.
> > seq_printf(m, "Pipe %c power disabled\n",
> > pipe_name(pipe));
> > continue;
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index f0a405604b75..44c1b21febba 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -344,6 +344,7 @@ struct intel_csr {
> > uint32_t mmiodata[8];
> > uint32_t dc_state;
> > uint32_t allowed_dc_mask;
> > + intel_wakeref_t wakeref;
> > };
> >
> > enum i915_cache_level {
> > @@ -1982,6 +1983,7 @@ struct drm_i915_private {
> >* is a slight delay before we do so.
> >*/
> > intel_wakeref_t awake;
> > + intel_wakeref_t power;
>
> This prolly explains the prefs above :)
Possibly.
> > - intel_display_power_put(dev_priv, POWER_DOMAIN_PORT_DDI_A_IO);
> > -
> > - if (intel_dsi->dual_link)
> > - intel_display_power_put(dev_priv, POWER_DOMAIN_PORT_DDI_B_IO);
> > + for_each_dsi_port(port, intel_dsi->ports) {
> > + intel_wakeref_t wakeref;
> > +
> > + wakeref = fetch_and_zero(&intel_dsi->io_wakeref[port]);
> > + if (wakeref) {
> > + intel_display_power_put(dev_priv,
> > + port == PORT_A ?
> > + POWER_DOMAIN_PORT_DDI_A_IO :
> > + POWER_DOMAIN_PORT_DDI_B_IO,
> > + wakeref);
> > + }
> > + }
>
> Ok, well. I have been trying to figure out what really is going on here.
>
> First it seems that you fix a bug. We take refs for each dsi port but
> only release once special casing 'dual_link' without this patch.
>
> Second, all the hw access is before getting the refs, looking
> suspicious.
There's always been two, just this moves into a for(;;). I don't think
it was buggy, but I do think the for(;;) has the advantage of being
clearer that it operates over all the ports and wakerefs.
> > @@ -15808,12 +15827,13 @@ intel_modeset_setup_hw_state(struct drm_device
> > *dev,
> >struct drm_modeset_acquire_ctx *ctx)
> > {
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > - struct intel_crtc *crtc;
> > struct intel_crtc_state *crtc_state;
> > struct intel_encoder *encoder;
> > + struct intel_crtc *crtc;
>
> Not that I mind but I don't understand the reasoning
> behind the change of order on this and on few other places in this
> patch.
Just quietly moving everyone over to a tidy set of variable definitions
(we are not meant to grow Christmas trees as part of the kernel coding
style).
> > -/**
> > - * intel_display_power_put - release a power domain reference
> > - * @dev_priv: i915 device instance
> > - * @domain: power domain to reference
> > - *
> > - * This function drops the power domain reference obtained by
> > - * intel_display_power_get() and might power down the corresponding
> > hardware
> > - * block right away if this is the last reference.
> > - */
> > -void intel_display_power_put(struct drm_i915_private *dev_priv,
> > - enum intel_display_power_domain domain)
> > +static void __intel_display_power_put(struct drm_i915_private *dev_priv,
> > + enum intel_display_power_domain domain)
> > {
> > struct i915_power_domains *power_domains;
> > struct i915_power_well *power_well;
> > @@ -1947,10 +1944,34 @@ void intel_display_power_put(struct
> > drm_i915_priv
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)
On Thu, Jan 10, 2019 at 10:38:07AM +, Chris Wilson wrote:
> Broadwater and the rest of gen4 do support being able to saving and
> reloading context specific registers between contexts, providing isolation
> of the basic GPU state (as programmable by userspace). This allows
> userspace to assume that the GPU retains their state from one batch to the
> next, minimising the amount of state it needs to reload and manually save
> across batches.
>
> v2: CONSTANT_BUFFER woes
>
> Running through piglit turned up an interesting issue, a GPU hang inside
> the context load. The context image includes the CONSTANT_BUFFER command
> that loads an address into a on-gpu buffer, and the context load was
> executing that immediately. However, since it was reading from the GTT
> there is no guarantee that the GTT retains the same configuration as
> when the context was saved, resulting in stray reads and a GPU hang.
>
> Having tried issuing a CONSTANT_BUFFER (to disable the command) from the
> ring before saving the context to no avail, we resort to patching out
> the instruction inside the context image before loading.
>
> This does impose that gen4 always reissues CONSTANT_BUFFER commands on
> each batch, but due to the use of a shared GTT that was and will remain
> a requirement.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> Cc: Kenneth Graunke
> Reviewed-by: Ville Syrjälä #v1
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
> drivers/gpu/drm/i915/intel_gpu_commands.h | 3 +++
> drivers/gpu/drm/i915/intel_ringbuffer.c | 17 +
> 3 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index f89b8f199e3f..88109e0de051 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -219,6 +219,7 @@ __intel_engine_context_size(struct drm_i915_private
> *dev_priv, u8 class)
> return round_up(GEN6_CXT_TOTAL_SIZE(cxt_size) * 64,
> PAGE_SIZE);
> case 5:
> + case 4:
> /*
>* There is a discrepancy here between the size reported
>* by the register and the size of the context layout
> @@ -235,7 +236,6 @@ __intel_engine_context_size(struct drm_i915_private
> *dev_priv, u8 class)
>cxt_size * 64,
>cxt_size - 1);
> return round_up(cxt_size * 64, PAGE_SIZE);
> - case 4:
> case 3:
> case 2:
> /* For the special day when i810 gets merged. */
> diff --git a/drivers/gpu/drm/i915/intel_gpu_commands.h
> b/drivers/gpu/drm/i915/intel_gpu_commands.h
> index 105e2a9e874a..00c0175c37ed 100644
> --- a/drivers/gpu/drm/i915/intel_gpu_commands.h
> +++ b/drivers/gpu/drm/i915/intel_gpu_commands.h
> @@ -266,6 +266,9 @@
> #define GFX_OP_3DSTATE_BINDING_TABLE_EDIT_PS \
> ((0x3<<29)|(0x3<<27)|(0x0<<24)|(0x47<<16))
>
> +#define GFX_OP_CONSTANT_BUFFER \
> + (0x3 << 29 | 0x0 << 27 | 0x0 << 24 | 0x2 << 16)
> +
> #define MFX_WAIT ((0x3<<29)|(0x1<<27)|(0x0<<16))
>
> #define COLOR_BLT ((0x2<<29)|(0x40<<22))
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 889f3de79dd0..21bd71cf2e94 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1632,6 +1632,8 @@ static inline int mi_set_context(struct i915_request
> *rq, u32 flags)
> len += 2 + (num_rings ? 4*num_rings + 6 : 0);
> else if (IS_GEN(i915, 5))
> len += 2;
> + else if (IS_GEN(i915, 4))
> + len += 4;
> if (flags & MI_FORCE_RESTORE) {
> GEM_BUG_ON(flags & MI_RESTORE_INHIBIT);
> flags &= ~MI_FORCE_RESTORE;
> @@ -1668,6 +1670,21 @@ static inline int mi_set_context(struct i915_request
> *rq, u32 flags)
>* this should never take effect and so be a no-op!
>*/
> *cs++ = MI_SUSPEND_FLUSH | MI_SUSPEND_FLUSH_EN;
> + } else if (IS_GEN(i915, 4)) {
> + /*
> + * Disable CONSTANT_BUFFER before it is loaded from the context
> + * image. For as it is loaded, it is executed and the stored
> + * address may no longer be valid, leading to a GPU hang.
> + *
> + * This imposes the requirement that userspace reload their
> + * CONSTANT_BUFFER on every batch, fortunately a requirement
> + * they are already accustomed to from before contexts were
> + * enabled.
> + */
> + *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
> + *cs++ = 0;
> + *cs++ = i915_ggtt_offset(rq->hw_context->state) + 0x1d4;
Is that offset correc
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/ringbuffer: EMIT_INVALIDATE *before* switch context
== Series Details ==
Series: series starting with [1/3] drm/i915/ringbuffer: EMIT_INVALIDATE
*before* switch context
URL : https://patchwork.freedesktop.org/series/54991/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5391_full -> Patchwork_11273_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11273_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11273_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_11273_full:
### IGT changes ###
Warnings
* igt@pm_rc6_residency@rc6-accuracy:
- shard-snb: {SKIP} -> PASS
* igt@tools_test@tools_test:
- shard-glk: PASS -> {SKIP}
Known issues
Here are the changes found in Patchwork_11273_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_schedule@pi-ringfull-bsd:
- shard-skl: NOTRUN -> FAIL [fdo#103158]
* igt@gem_exec_whisper@normal:
- shard-skl: PASS -> TIMEOUT [fdo#108592]
* igt@gem_softpin@noreloc-s3:
- shard-snb: PASS -> DMESG-WARN [fdo#102365]
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-dpms:
- shard-skl: NOTRUN -> FAIL [fdo#103232] +1
* igt@kms_draw_crc@fill-fb:
- shard-skl: NOTRUN -> FAIL [fdo#103184] +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-wc:
- shard-skl: NOTRUN -> FAIL [fdo#105682]
* igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-skl: NOTRUN -> FAIL [fdo#105683]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-pwrite:
- shard-skl: NOTRUN -> FAIL [fdo#103167] +2
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- shard-skl: NOTRUN -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: PASS -> FAIL [fdo#103166] +1
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815]
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-glk: PASS -> DMESG-WARN [fdo#105763] / [fdo#106538]
* igt@kms_setmode@basic:
- shard-apl: PASS -> FAIL [fdo#99912]
- shard-hsw: PASS -> FAIL [fdo#99912]
* igt@pm_rpm@gem-execbuf:
- shard-skl: PASS -> INCOMPLETE [fdo#107803] / [fdo#107807]
* igt@pm_rpm@system-suspend-devices:
- shard-skl: PASS -> INCOMPLETE [fdo#107807] +1
Possible fixes
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl: FAIL [fdo#106510] / [fdo#108145] -> PASS
* igt@kms_chv_cursor_fail@pipe-b-128x128-top-edge:
- shard-skl: FAIL [fdo#104671] -> PASS
* igt@kms_cursor_crc@cursor-64x21-onscreen:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc:
- shard-apl: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
- shard-glk: FAIL [fdo#103167] -> PASS +4
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-indfb-draw-render:
- shard-apl: INCOMPLETE [fdo#103927] -> {SKIP}
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_setmode@basic:
- shard-kbl: FAIL [fdo#99912] -> PASS
[fdo#102365]: https://bugs.freedesktop.org/show_bug.cgi?id=102365
[fdo#103158]: https://bugs.freedesktop.org/show_bug.cgi?id=103158
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103184]: https://bugs.freedesktop.org/show_bug.c
