[Intel-gfx] ✓ Fi.CI.IGT: success for Extend BT2020 support in iCSC and fixes (rev2)
== Series Details == Series: Extend BT2020 support in iCSC and fixes (rev2) URL : https://patchwork.freedesktop.org/series/60480/ State : success == Summary == CI Bug Log - changes from CI_DRM_6072_full -> Patchwork_12997_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12997_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#104108]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-skl9/igt@kms_cursor_...@cursor-128x128-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/shard-skl10/igt@kms_cursor_...@cursor-128x128-suspend.html * igt@kms_flip_tiling@flip-x-tiled: - shard-skl: [PASS][3] -> [FAIL][4] ([fdo#108145] / [fdo#108303]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-skl5/igt@kms_flip_til...@flip-x-tiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/shard-skl10/igt@kms_flip_til...@flip-x-tiled.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-apl5/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/shard-apl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#108145] / [fdo#110403]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#108341]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-iclb6/igt@kms_psr@no_drrs.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/shard-iclb3/igt@kms_psr@psr2_cursor_plane_onoff.html Possible fixes * igt@i915_suspend@debugfs-reader: - shard-apl: [DMESG-WARN][13] ([fdo#108566]) -> [PASS][14] +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-apl6/igt@i915_susp...@debugfs-reader.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/shard-apl1/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_edge_walk@pipe-b-64x64-bottom-edge: - shard-snb: [SKIP][15] ([fdo#109271] / [fdo#109278]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-snb7/igt@kms_cursor_edge_w...@pipe-b-64x64-bottom-edge.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/shard-snb7/igt@kms_cursor_edge_w...@pipe-b-64x64-bottom-edge.html * igt@kms_flip@flip-vs-suspend: - shard-kbl: [DMESG-WARN][17] ([fdo#108566]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-kbl1/igt@kms_f...@flip-vs-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/shard-kbl5/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: [FAIL][19] ([fdo#100368]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-skl2/igt@kms_f...@plain-flip-fb-recreate-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/shard-skl8/igt@kms_f...@plain-flip-fb-recreate-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [FAIL][21] ([fdo#103167]) -> [PASS][22] +5 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [FAIL][23] ([fdo#108145]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [24]:
Re: [Intel-gfx] IOMMU RMRR for Intel graphic device
Forward to i915 mailing list and post the question again so people knows what are the key concerns. The background is that Linux community is going to collect and report the reserved memory ranges of an assigned device to VFIO driver, and any mapped address will be checked against the reserved ranges. If there's any conflict, vifo will refuse the map request. Unfortunately, when it comes Intel graphic device, the conflict happens. That means address range mapped through vfio conflicts with the rmrr for graphic device. https://lkml.org/lkml/2018/6/5/760 The questions are 1) will the rmrr for graphic device still needs to be reserved for BIOS or firmware use, when a device is going to be assigned to user level? 2) if no, what's the check point, after which the rmrr is unnecessary anymore? Best regards, Lu Baolu On 5/9/19 5:14 PM, Zhang, Tina wrote: Hi Baolu, +Xiong I think the root cause is that guest i915 needs to access RMRR. Xiong cooked a patch to disable the RMRR use in i915 guest, however that patch didn't get landed into the i915 upstream repo due to some concerns from i915 maintainers. Xiong can give us more backgrounds. So agreed, need to ask the i915 folk for this. BR, Tina -Original Message- From: Yuan, Hang Sent: Thursday, May 9, 2019 4:07 PM To: Lu Baolu ; Tian, Kevin ; Zhenyu Wang ; Zhang, Tina ; Lu, Baolu ; Liu, Yi L Subject: RE: IOMMU RMRR for Intel graphic device Hi Baolu, as Kevin suggested, would you like to ask i915 people in their mailing list intel-gfx@lists.freedesktop.org? Regards, Henry -Original Message- From: Lu Baolu [mailto:baolu...@linux.intel.com] Sent: Thursday, May 9, 2019 2:42 PM To: Tian, Kevin ; Zhenyu Wang ; Zhang, Tina ; Yuan, Hang ; Lu, Baolu ; Liu, Yi L Cc: baolu...@linux.intel.com Subject: Re: IOMMU RMRR for Intel graphic device Hi, +Tina and Henry and cc more people The background is that Linux community is going to collect and report the reserved memory ranges of an assigned device to VFIO driver, and any mapped address will be checked against the reserved ranges. If there's any conflict, vifo will refuse the map request. Unfortunately, when it comes Intel graphic device, the conflict happens. That means address range mapped through vfio conflicts with the rmrr for graphic device. https://lkml.org/lkml/2018/6/5/760 The questions are 1) will the rmrr for graphic device still needs to be reserved for BIOS or firmware use, when a device is going to be assigned to user level? 2) if no, what's the check point, after which the rmrr is unnecessary anymore? Best regards, Lu Baolu On 5/6/19 2:16 PM, Tian, Kevin wrote: this should better be asked to i915 guys, since it's not virtualization related. :-) One caveat, iirc, i915 driver tries to reuse stolen memory (covered by RMRR) even after boot time. take it as if another type of memory resource. If true I'm afraid this might be a gap to your proposal. Since nothing confidential, possibly you can directly discuss in community. From: Lu Baolu [mailto:baolu...@linux.intel.com] Sent: Thursday, May 2, 2019 2:45 PM Ping... Any comments? This has been postponed in the community for a long time. We need to response this as soon as possible. Best regards, Lu Baolu On 4/29/19 1:19 PM, Lu Baolu wrote: Hi Zhenyu, As we discussed, BIOS always exports IOMMU reserved memory regions for (a.k.a. RMRR in vt-d spec) Intel integrated graphic device. This caused some problems when we pass-through such graphic devices to user level. I am about to propose something to the community so that a RMRR for graphic devices could be explicitly canceled as long as the driver (i915 or vfio) knows that the RMRR will never be used by BIOS anymore. The same story happens for USB host controller devices. And since we know that BIOS will stop using that memory region as soon as the driver clears the SMI bits. So the question is, can graphic driver know when the RMRR for graphic could be canceled? Best regards, Lu Baolu ___ 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/dp: Support for DP YCbCr4:2:0 outputs (rev2)
== Series Details == Series: drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev2) URL : https://patchwork.freedesktop.org/series/60404/ State : success == Summary == CI Bug Log - changes from CI_DRM_6072 -> Patchwork_13000 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13000/ Known issues Here are the changes found in Patchwork_13000 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-kbl-7500u: [DMESG-WARN][1] ([fdo#105128] / [fdo#107139]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13000/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [INCOMPLETE][3] ([fdo#103927] / [fdo#110624]) -> [DMESG-FAIL][4] ([fdo#110620]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13000/fi-apl-guc/igt@i915_selftest@live_hangcheck.html * igt@runner@aborted: - fi-apl-guc: [FAIL][5] ([fdo#110624]) -> [FAIL][6] ([fdo#110622]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13000/fi-apl-guc/igt@run...@aborted.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128 [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139 [fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620 [fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622 [fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624 Participating hosts (49 -> 43) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * Linux: CI_DRM_6072 -> Patchwork_13000 CI_DRM_6072: 645586708589c3d2ac81114595e875cdfbbff385 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4976: b1d91d0228db999145405e529952ca49bab7f706 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13000: 3558bfdc8c88152adf8ec4f35aef9c6145b90707 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3558bfdc8c88 drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11 433d0be3d892 drm/i915/dp: Change a link bandwidth computation for DP a4d0868f89c4 drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA f7948706a27d drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format fc873b937b6c drm: Rename struct edp_vsc_psr to struct dp_sdp c66c72a1f70d drm/i915/dp: Add a config function for YCBCR420 outputs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13000/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add support for asynchronous display power disabling (rev4)
== Series Details == Series: drm/i915: Add support for asynchronous display power disabling (rev4) URL : https://patchwork.freedesktop.org/series/60242/ State : success == Summary == CI Bug Log - changes from CI_DRM_6072_full -> Patchwork_12995_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12995_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@fifo-blt: - shard-hsw: [PASS][1] -> [INCOMPLETE][2] ([fdo#103540]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-hsw6/igt@gem_exec_sched...@fifo-blt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/shard-hsw6/igt@gem_exec_sched...@fifo-blt.html * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +6 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-apl6/igt@gem_workarou...@suspend-resume.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/shard-apl4/igt@gem_workarou...@suspend-resume.html * igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: - shard-glk: [PASS][5] -> [FAIL][6] ([fdo#106509] / [fdo#107409]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-glk6/igt@kms_cursor_leg...@2x-nonblocking-modeset-vs-cursor-atomic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/shard-glk1/igt@kms_cursor_leg...@2x-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_flip@2x-modeset-vs-vblank-race-interruptible: - shard-glk: [PASS][7] -> [FAIL][8] ([fdo#103060]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-glk3/igt@kms_f...@2x-modeset-vs-vblank-race-interruptible.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/shard-glk5/igt@kms_f...@2x-modeset-vs-vblank-race-interruptible.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#105363]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/shard-skl4/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#104108]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-skl10/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/shard-skl5/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/shard-iclb6/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_setmode@basic: - shard-apl: [PASS][19] -> [FAIL][20] ([fdo#99912]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-apl1/igt@kms_setm...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/shard-apl3/igt@kms_setm...@basic.html Possible fixes * igt@i915_suspend@debugfs-reader: - shard-apl: [DMESG-WARN][21] ([fdo#108566]) -> [PASS][22] +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-apl6/igt@i915_susp...@debugfs-reader.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/shard-apl2/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-apl: [FAIL][23] ([fdo#103375]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-apl5/igt@kms_cursor_...@cursor-256x256-suspend.html [24]:
[Intel-gfx] [PATCH v7 2/6] drm: Rename struct edp_vsc_psr to struct dp_sdp
VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
Packet). In order to generalize SDP packet structure name, it renames
struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have
different usages, each SDP type has different reserved data blocks and
Video_Stream_Configuration Extension VESA SDP might use all of Data Blocks
as Extended INFORFRAME Data Byte. so it makes Data Block variables as
array type. And it adds comments of details of DB of VSC SDP Payload
for Pixel Encoding/Colorimetry Format. This comments follows DP 1.4a spec,
section 2.2.5.7.5, chapter "VSC SDP Payload for Pixel Encoding/Colorimetry
Format".
v7: Addressed review comments from Ville.
Cc: Ville Syrjälä
Signed-off-by: Gwan-gyeong Mun
---
.../drm/bridge/analogix/analogix_dp_core.c| 12 +++
.../drm/bridge/analogix/analogix_dp_core.h| 2 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 +++---
drivers/gpu/drm/i915/intel_psr.c | 2 +-
include/drm/drm_dp_helper.h | 33 +--
5 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 225f5e5dd69b..d1c2659d0cce 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -115,7 +115,7 @@ EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
int analogix_dp_enable_psr(struct analogix_dp_device *dp)
{
- struct edp_vsc_psr psr_vsc;
+ struct dp_sdp psr_vsc;
if (!dp->psr_enable)
return 0;
@@ -127,8 +127,8 @@ int analogix_dp_enable_psr(struct analogix_dp_device *dp)
psr_vsc.sdp_header.HB2 = 0x2;
psr_vsc.sdp_header.HB3 = 0x8;
- psr_vsc.DB0 = 0;
- psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
+ psr_vsc.DB[0] = 0;
+ psr_vsc.DB[1] = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
return analogix_dp_send_psr_spd(dp, _vsc, true);
}
@@ -136,7 +136,7 @@ EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
int analogix_dp_disable_psr(struct analogix_dp_device *dp)
{
- struct edp_vsc_psr psr_vsc;
+ struct dp_sdp psr_vsc;
int ret;
if (!dp->psr_enable)
@@ -149,8 +149,8 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
psr_vsc.sdp_header.HB2 = 0x2;
psr_vsc.sdp_header.HB3 = 0x8;
- psr_vsc.DB0 = 0;
- psr_vsc.DB1 = 0;
+ psr_vsc.DB[0] = 0;
+ psr_vsc.DB[1] = 0;
ret = drm_dp_dpcd_writeb(>aux, DP_SET_POWER, DP_SET_POWER_D0);
if (ret != 1) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 769255dc6e99..3e5fe90edf71 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -254,7 +254,7 @@ void analogix_dp_enable_scrambling(struct
analogix_dp_device *dp);
void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc, bool blocking);
+struct dp_sdp *vsc, bool blocking);
ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
struct drm_dp_aux_msg *msg);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index a5f2763d72e4..f591810ef1be 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1041,7 +1041,7 @@ static ssize_t analogix_dp_get_psr_status(struct
analogix_dp_device *dp)
}
int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc, bool blocking)
+struct dp_sdp *vsc, bool blocking)
{
unsigned int val;
int ret;
@@ -1069,8 +1069,8 @@ int analogix_dp_send_psr_spd(struct analogix_dp_device
*dp,
writel(0x5D, dp->reg_base + ANALOGIX_DP_SPD_PB3);
/* configure DB0 / DB1 values */
- writel(vsc->DB0, dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB0);
- writel(vsc->DB1, dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB1);
+ writel(vsc->DB[0], dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB0);
+ writel(vsc->DB[1], dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB1);
/* set reuse spd inforframe */
val = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_3);
@@ -1092,8 +1092,8 @@ int analogix_dp_send_psr_spd(struct analogix_dp_device
*dp,
ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
psr_status >= 0 &&
- ((vsc->DB1 && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
- (!vsc->DB1 && psr_status == DP_PSR_SINK_INACTIVE)), 1500,
+
[Intel-gfx] [PATCH v7 4/6] drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for the Pixel
Encoding/Colorimetry Format.
v2: Block comment style fix.
v6:
Fix an wrong setting of MSA MISC1 fields for Pixel Encoding/Colorimetry
Format indication. As per DP 1.4a spec Table 2-96 [MSA MISC1 and MISC0
Fields for Pixel Encoding/Colorimetry Format Indication]
When MISC1, bit 6, is Set to 1, a Source device uses a VSC SDP to
indicate the Pixel Encoding/Colorimetry Format. On the wrong version
it set a bit 5 of MISC1, now it set a bit 6 of MISC1.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 8
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e97c47fca645..2ad98e62034f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9524,6 +9524,7 @@ enum skl_power_gate {
#define TRANS_MSA_12_BPC (3 << 5)
#define TRANS_MSA_16_BPC (4 << 5)
#define TRANS_MSA_CEA_RANGE (1 << 3)
+#define TRANS_MSA_USE_VSC_SDP (1 << 14)
/* LCPLL Control */
#define LCPLL_CTL _MMIO(0x130040)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2f1688ea5a2c..4441c5ba71fb 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1717,6 +1717,14 @@ void intel_ddi_set_pipe_settings(const struct
intel_crtc_state *crtc_state)
*/
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444)
temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR;
+ /*
+* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
+* of Color Encoding Format and Content Color Gamut] while sending
+* YCBCR 420 signals we should program MSA MISC1 fields which
+* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ temp |= TRANS_MSA_USE_VSC_SDP;
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 6/6] drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and HDMI ports. v2: Minor style fix. Signed-off-by: Gwan-gyeong Mun Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 86dc5e23ea73..6583c656612b 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -7385,6 +7385,9 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port, connector->interlace_allowed = true; connector->doublescan_allowed = 0; + if (INTEL_GEN(dev_priv) >= 11) + connector->ycbcr_420_allowed = true; + intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port); intel_dp_aux_init(intel_dp); -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 0/6] drm/i915/dp: Support for DP YCbCr4:2:0 outputs
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
And Link M/N values are calculated and applied based on the Full Clock
forYCbCr420.
The Bit per Pixel needs to be adjusted for YUV420 mode as it requires only
half of the RGB case.
- Link M/N values are calculated and applied based on the Full Clock
- Data M/N values needs to be calculated considering the data is half
due to subsampling
These patches add a VSC structure for handling Pixel Encoding/Colorimetry
Formats and program YCBCR 4:2:0 to MSA and VSC SDP. And it changes a link
bandwidth computation for DP.
These patches tested on below test environment.
Test Environment:
- Tested System: Gen11 platform
- Monitor: Wasabi Mango UHD430 REAL4K HDMI 2.0 Slim HDR DUAL DP i20
(This monitor supports HDMI YCbCr 4:2:0)
- DP to HDMI Adaptor (Dongle) : Club3D CAC-1080 (This dongle supports
DP YCbCr 4:2:0 pass through feature.)
- To enable DP YCbCr 4:2:0 forcely, test enviromnent uses work arounds
patches. You can find these on
https://gitlab.freedesktop.org/elongbug/drm-tip/tree/dp_ycbcr420_work
The idea of a scaling (RGB -> YCbCr4:4:4 -> YCbCr 4:2:0) is to follow the
same approach used in YCbCr 4:2:0 on HDMI.
v2: Addressed Maarten's review comments, fixed minor coding and block comment
style. And reordered a first patch ("drm/i915/dp: Support DP ports
YUV 4:2:0 output to GEN11") as a last patch.
v3: Addressed Ville's review comments.
Style fixed with few naming.
If lscon is active, it makes not to call intel_dp_ycbcr420_config() to avoid
to clobber of lspcon_ycbcr420_config() routine.
And it move the 420_only check into the intel_dp_ycbcr420_config().
Remove a changing of pipe_bpp on intel_ddi_set_pipe_settings().
Because the pipe is running at the full bpp, keep pipe_bpp as RGB even though
YCbCr 4:2:0 output format is used.
Add a link bandwidth computation for YCbCr4:2:0 output format.
v4: Fix uninitialized return value which is reported by Dan Carpenter.
v5: Addressed reivew comments from Ville.
In order to make codes simple, it adds and uses intel_dp_output_bpp() function.
In order to avoid the extra indentation, it inverts if-clause on
intel_dp_ycbcr420_config().
Remove the error print where no errors print are allowed.
v6:
Link M/N values are calculated and applied based on the Full Clock for
YCbCr420. The Bit per Pixel needs to be adjusted for YUV420 mode as it
requires only half of the RGB case.
- Link M/N values are calculated and applied based on the Full Clock
- Data M/N values needs to be calculated considering the data is half due
to subsampling
Remove a doubling of pixel clock on a dot clock calculator for DP YCbCr 4:2:0.
Rebase and remove a duplicate setting of vsc_sdp.DB17.
Add a setting of dynamic range bit to vsc_sdp.DB17.
Change Content Type bit to "Graphics" from "Not defined".
Change a dividing of pipe_bpp to muliplying to constant values on a switch-case
statement.
Fix an wrong setting of MSA MISC1 fields for Pixel Encoding/Colorimetry
Format indication. As per DP 1.4a spec Table 2-96 [MSA MISC1 and MISC0
Fields for Pixel Encoding/Colorimetry Format Indication] When MISC1, bit 6,
is Set to 1, a Source device uses a VSC SDP to indicate the Pixel
Encoding/Colorimetry Format. On the wrong version it set a bit 5 of MISC1,
now it set a bit 6 of MISC1.
v7:
Addressed review comments from Ville.
Move intel_dp_get_colorimetry_status() to intel_dp from intel_psr.
Move a setting of dynamic range bit and a setting of bpc which is based
on pipe_bpp to a "drm/i915/dp: Program VSC Header and DB for Pixel
Encoding/Colorimetry Format" commit.
Change Content Type bit to "Not defined" from "Graphics".
Fix non-standard comment format.
Remove a referring to specific commit.
Remove duplicated checking of connector's ycbcr_420_allowed from
intel_pixel_encoding_setup_vsc().
References: https://patchwork.freedesktop.org/series/56059/
Gwan-gyeong Mun (6):
drm/i915/dp: Add a config function for YCBCR420 outputs
drm: Rename struct edp_vsc_psr to struct dp_sdp
drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry
Format
drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA
drm/i915/dp: Change a link bandwidth computation for DP
drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11
.../drm/bridge/analogix/analogix_dp_core.c| 12 +-
.../drm/bridge/analogix/analogix_dp_core.h| 2 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 +-
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 12 +-
drivers/gpu/drm/i915/intel_dp.c | 156 +-
drivers/gpu/drm/i915/intel_dp.h | 1 +
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_psr.c | 12 +-
[Intel-gfx] [PATCH v7 5/6] drm/i915/dp: Change a link bandwidth computation for DP
Data M/N calculations were assumed a bpp as RGB format. But when we are
using YCbCr 4:2:0 output format on DP, we should change bpp calculations
as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier
value to 1.5.
Therefore we need to divide pipe_bpp to 2 while DP output uses YCbCr4:2:0
format.
- RGB format bpp = bpc x 3
- YCbCr 4:2:0 format bpp = bpc x 1.5
But Link M/N values are calculated and applied based on the Full Clock for
YCbCr 4:2:0. And DP YCbCr 4:2:0 does not need to pixel clock double for
a dotclock caluation. Only for HDMI YCbCr 4:2:0 needs to pixel clock double
for a dot clock calculation.
It only affects dp and edp port which use YCbCr 4:2:0 output format.
And for now, it does not consider a use case of DSC + YCbCr 4:2:0.
v2:
Addressed review comments from Ville.
Remove a changing of pipe_bpp on intel_ddi_set_pipe_settings().
Because the pipe is running at the full bpp, keep pipe_bpp as RGB
even though YCbCr 4:2:0 output format is used.
Add a link bandwidth computation for YCbCr4:2:0 output format.
v3:
Addressed reivew comments from Ville.
In order to make codes simple, it adds and uses intel_dp_output_bpp()
function.
v6:
Link M/N values are calculated and applied based on the Full Clock for
YCbCr420. The Bit per Pixel needs to be adjusted for YUV420 mode as it
requires only half of the RGB case.
- Link M/N values are calculated and applied based on the Full Clock
- Data M/N values needs to be calculated considering the data is half
due to subsampling
Remove a doubling of pixel clock on a dot clock calculator for
DP YCbCr 4:2:0.
Rebase and remove a duplicate setting of vsc_sdp.DB17.
Add a setting of dynamic range bit to vsc_sdp.DB17.
Change Content Type bit to "Graphics" from "Not defined".
Change a dividing of pipe_bpp to muliplying to constant values on a
switch-case statement.
v7:
Addressed review comments from Ville.
Move a setting of dynamic range bit and a setting of bpc which is based
on pipe_bpp to a "drm/i915/dp: Program VSC Header and DB for Pixel
Encoding/Colorimetry Format" commit.
Change Content Type bit to "Not defined" from "Graphics".
Cc: Ville Syrjälä
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/intel_ddi.c | 3 ++-
drivers/gpu/drm/i915/intel_dp.c | 15 ++-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 4441c5ba71fb..e22a0898b957 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1457,7 +1457,8 @@ static void ddi_dotclock_get(struct intel_crtc_state
*pipe_config)
else
dotclock = pipe_config->port_clock;
- if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 &&
+ !intel_crtc_has_dp_encoder(pipe_config))
dotclock *= 2;
if (pipe_config->pixel_multiplier)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a3fd279a5c52..86dc5e23ea73 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1842,6 +1842,19 @@ intel_dp_adjust_compliance_config(struct intel_dp
*intel_dp,
}
}
+static int intel_dp_output_bpp(const struct intel_crtc_state *crtc_state, int
bpp)
+{
+ /*
+* bpp value was assumed to RGB format. And YCbCr 4:2:0 output
+* format of the number of bytes per pixel will be half the number
+* of bytes of RGB pixel.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ bpp /= 2;
+
+ return bpp;
+}
+
/* Optimize link config in order: max bpp, min clock, min lanes */
static int
intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
@@ -2215,7 +2228,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (pipe_config->dsc_params.compression_enable)
output_bpp = pipe_config->dsc_params.compressed_bpp;
else
- output_bpp = pipe_config->pipe_bpp;
+ output_bpp = intel_dp_output_bpp(pipe_config,
pipe_config->pipe_bpp);
intel_link_compute_m_n(output_bpp,
pipe_config->lane_count,
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 1/6] drm/i915/dp: Add a config function for YCBCR420 outputs
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
v2:
Addressed review comments from Ville.
Style fixed with few naming.
%s/config/crtc_state/
%s/intel_crtc/crtc/
If lscon is active, it makes not to call intel_dp_ycbcr420_config()
to avoid to clobber of lspcon_ycbcr420_config() routine.
And it move the 420_only check into the intel_dp_ycbcr420_config().
v3: Fix uninitialized return value and it is reported by Dan Carpenter.
v4:
Addressed review comments from Ville.
In order to avoid the extra indentation, it inverts if-clause on
intel_dp_ycbcr420_config().
Remove the error print where no errors print are allowed.
v6: Rebase
v7:
Move intel_dp_get_colorimetry_status() to intel_dp from intel_psr.
intel_dp_get_colorimetry_status() checks
VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the
DPRX_FEATURE_ENUMERATION_LIST register.
And intel_dp_ycbcr420_config() uses intel_dp_get_colorimetry_status().
Cc: Ville Syrjälä
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 48 +++-
drivers/gpu/drm/i915/intel_dp.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 10 ---
3 files changed, 48 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 53cc4afea256..9f219f8f0c71 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2085,6 +2085,36 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
return 0;
}
+static int
+intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
+struct drm_connector *connector,
+struct intel_crtc_state *crtc_state)
+{
+ const struct drm_display_info *info = >display_info;
+ const struct drm_display_mode *adjusted_mode =
+ _state->base.adjusted_mode;
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ int ret;
+
+ if (!drm_mode_is_420_only(info, adjusted_mode) ||
+ !intel_dp_get_colorimetry_status(intel_dp) ||
+ !connector->ycbcr_420_allowed)
+ return 0;
+
+ crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+
+ /* YCBCR 420 output conversion needs a scaler */
+ ret = skl_update_scaler_crtc(crtc_state);
+ if (ret) {
+ DRM_DEBUG_KMS("Scaler allocation for output failed\n");
+ return ret;
+ }
+
+ intel_pch_panel_fitting(crtc, crtc_state, DRM_MODE_SCALE_FULLSCREEN);
+
+ return 0;
+}
+
bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
@@ -2124,7 +2154,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
to_intel_digital_connector_state(conn_state);
bool constant_n = drm_dp_has_quirk(_dp->desc,
DP_DPCD_QUIRK_CONSTANT_N);
- int ret, output_bpp;
+ int ret = 0, output_bpp;
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)
pipe_config->has_pch_encoder = true;
@@ -2132,6 +2162,12 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
if (lspcon->active)
lspcon_ycbcr420_config(_connector->base, pipe_config);
+ else
+ ret = intel_dp_ycbcr420_config(intel_dp, _connector->base,
+ pipe_config);
+
+ if (ret)
+ return ret;
pipe_config->has_drrs = false;
if (IS_G4X(dev_priv) || port == PORT_A)
@@ -4051,6 +4087,16 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
return intel_dp->dpcd[DP_DPCD_REV] != 0;
}
+bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
+{
+ u8 dprx = 0;
+
+ if (drm_dp_dpcd_readb(_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
+ ) != 1)
+ return false;
+ return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
+}
+
static void intel_dp_get_dsc_sink_cap(struct intel_dp *intel_dp)
{
/*
diff --git a/drivers/gpu/drm/i915/intel_dp.h b/drivers/gpu/drm/i915/intel_dp.h
index 5e9e8d13de6e..da70b1a41c83 100644
--- a/drivers/gpu/drm/i915/intel_dp.h
+++ b/drivers/gpu/drm/i915/intel_dp.h
@@ -108,6 +108,7 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
int mode_clock,
int mode_hdisplay);
bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
+bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp);
int intel_dp_link_required(int pixel_clock, int
[Intel-gfx] [PATCH v7 3/6] drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
table 2-120:VSC SDP Payload for DB16 through DB18.
v2:
Minor style fix. [Maarten]
Refer to commit ids instead of patchwork. [Maarten]
v6: Rebase
v7:
Rebase and addressed review comments from Ville.
Use a structure initializer instead of memset().
Fix non-standard comment format.
Remove a referring to specific commit.
Add a setting of dynamic range bit to vsc_sdp.DB17.
Add a setting of bpc which is based on pipe_bpp.
Remove duplicated checking of connector's ycbcr_420_allowed from
intel_pixel_encoding_setup_vsc(). It is already checked from
intel_dp_ycbcr420_config().
Remove comments for VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED. It is
already implemented on intel_dp_get_colorimetry_status().
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/intel_ddi.c | 1 +
drivers/gpu/drm/i915/intel_dp.c | 90
drivers/gpu/drm/i915/intel_drv.h | 2 +
3 files changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cd5277d98b03..2f1688ea5a2c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3391,6 +3391,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
+ intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9f219f8f0c71..a3fd279a5c52 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4407,6 +4407,96 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp
*intel_dp,
return 0;
}
+static void
+intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct dp_sdp vsc_sdp = {};
+
+ /* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119 */
+ vsc_sdp.sdp_header.HB0 = 0;
+ vsc_sdp.sdp_header.HB1 = 0x7;
+
+ /*
+* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
+* Colorimetry Format indication.
+*/
+ vsc_sdp.sdp_header.HB2 = 0x5;
+
+ /*
+* VSC SDP supporting 3D stereo, + PSR2, + Pixel Encoding/
+* Colorimetry Format indication (HB2 = 05h).
+*/
+ vsc_sdp.sdp_header.HB3 = 0x13;
+
+ /*
+* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
+* DB16[3:0] DP 1.4a spec, Table 2-120
+*/
+ vsc_sdp.DB[16] = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
+ /* RGB->YCBCR color conversion uses the BT.709 color space. */
+ vsc_sdp.DB[16] |= 0x1; /* 0x1, ITU-R BT.709 */
+
+ /*
+* For pixel encoding formats YCbCr444, YCbCr422, YCbCr420, and Y Only,
+* the following Component Bit Depth values are defined:
+* 001b = 8bpc.
+* 010b = 10bpc.
+* 011b = 12bpc.
+* 100b = 16bpc.
+*/
+ switch (crtc_state->pipe_bpp) {
+ case 24: /* 8bpc */
+ vsc_sdp.DB[17] = 0x1;
+ break;
+ case 30: /* 10bpc */
+ vsc_sdp.DB[17] = 0x2;
+ break;
+ case 36: /* 12bpc */
+ vsc_sdp.DB[17] = 0x3;
+ break;
+ case 48: /* 16bpc */
+ vsc_sdp.DB[17] = 0x4;
+ break;
+ default:
+ DRM_DEBUG_KMS("Invalid bpp value '%d'\n", crtc_state->pipe_bpp);
+ break;
+ }
+
+ /*
+* Dynamic Range (Bit 7)
+* 0 = VESA range, 1 = CTA range.
+* all YCbCr are always limited range
+*/
+ vsc_sdp.DB[17] |= 0x80;
+
+ /*
+* Content Type (Bits 2:0)
+* 000b = Not defined.
+* 001b = Graphics.
+* 010b = Photo.
+* 011b = Video.
+* 100b = Game
+* All other values are RESERVED.
+* Note: See CTA-861-G for the definition and expected
+* processing by a stream sink for the above contect types.
+*/
+ vsc_sdp.DB[18] = 0;
+
+ intel_dig_port->write_infoframe(_dig_port->base,
+ crtc_state, DP_SDP_VSC, _sdp, sizeof(vsc_sdp));
+}
+
+void intel_dp_ycbcr_420_enable(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
+
Re: [Intel-gfx] [PATCH v6 5/6] drm/i915/dp: Change a link bandwidth computation for DP
On Wed, 2019-05-08 at 20:58 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:56AM +0300, Gwan-gyeong Mun wrote:
> > Data M/N calculations were assumed a bpp as RGB format. But when we
> > are
> > using YCbCr 4:2:0 output format on DP, we should change bpp
> > calculations
> > as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
> > therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a
> > multiplier
> > value to 1.5.
> > Therefore we need to divide pipe_bpp to 2 while DP output uses
> > YCbCr4:2:0
> > format.
> > - RGB format bpp = bpc x 3
> > - YCbCr 4:2:0 format bpp = bpc x 1.5
> >
> > But Link M/N values are calculated and applied based on the Full
> > Clock for
> > YCbCr 4:2:0. And DP YCbCr 4:2:0 does not need to pixel clock double
> > for
> > a dotclock caluation. Only for HDMI YCbCr 4:2:0 needs to pixel
> > clock double
> > for a dot clock calculation.
> >
> > And it adds missed bpc values for a programming of VSC Header.
> > It only affects dp and edp port which use YCbCr 4:2:0 output
> > format.
> > And for now, it does not consider a use case of DSC + YCbCr 4:2:0.
> >
> > v2:
> > Addressed review comments from Ville.
> > Remove a changing of pipe_bpp on intel_ddi_set_pipe_settings().
> > Because the pipe is running at the full bpp, keep pipe_bpp as RGB
> > even though YCbCr 4:2:0 output format is used.
> > Add a link bandwidth computation for YCbCr4:2:0 output format.
> >
> > v3:
> > Addressed reivew comments from Ville.
> > In order to make codes simple, it adds and uses
> > intel_dp_output_bpp()
> > function.
> >
> > v6:
> > Link M/N values are calculated and applied based on the Full
> > Clock for
> > YCbCr420. The Bit per Pixel needs to be adjusted for YUV420 mode
> > as it
> > requires only half of the RGB case.
> > - Link M/N values are calculated and applied based on the Full
> > Clock
> > - Data M/N values needs to be calculated considering the data
> > is half
> > due to subsampling
> > Remove a doubling of pixel clock on a dot clock calculator for
> > DP YCbCr 4:2:0.
> > Rebase and remove a duplicate setting of vsc_sdp.DB17.
> > Add a setting of dynamic range bit to vsc_sdp.DB17.
> > Change Content Type bit to "Graphics" from "Not defined".
> > Change a dividing of pipe_bpp to muliplying to constant values on
> > a
> > switch-case statement.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Gwan-gyeong Mun
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 3 ++-
> > drivers/gpu/drm/i915/intel_dp.c | 42
> > +---
> > 2 files changed, 41 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 4441c5ba71fb..e22a0898b957 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1457,7 +1457,8 @@ static void ddi_dotclock_get(struct
> > intel_crtc_state *pipe_config)
> > else
> > dotclock = pipe_config->port_clock;
> >
> > - if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> > + if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420
> > &&
> > + !intel_crtc_has_dp_encoder(pipe_config))
> > dotclock *= 2;
> >
> > if (pipe_config->pixel_multiplier)
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 74aad8830a80..c75e2bbe612a 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1842,6 +1842,19 @@ intel_dp_adjust_compliance_config(struct
> > intel_dp *intel_dp,
> > }
> > }
> >
> > +static int intel_dp_output_bpp(const struct intel_crtc_state
> > *crtc_state, int bpp)
> > +{
> > + /*
> > +* bpp value was assumed to RGB format. And YCbCr 4:2:0 output
> > +* format of the number of bytes per pixel will be half the
> > number
> > +* of bytes of RGB pixel.
> > +*/
> > + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> > + bpp /= 2;
> > +
> > + return bpp;
> > +}
> > +
> > /* Optimize link config in order: max bpp, min clock, min lanes */
> > static int
> > intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
> > @@ -2212,7 +2225,7 @@ intel_dp_compute_config(struct intel_encoder
> > *encoder,
> > if (pipe_config->dsc_params.compression_enable)
> > output_bpp = pipe_config->dsc_params.compressed_bpp;
> > else
> > - output_bpp = pipe_config->pipe_bpp;
> > + output_bpp = intel_dp_output_bpp(pipe_config,
> > pipe_config->pipe_bpp);
> >
> > intel_link_compute_m_n(output_bpp,
> >pipe_config->lane_count,
> > @@ -4439,7 +4452,30 @@ intel_pixel_encoding_setup_vsc(struct
> > intel_dp *intel_dp,
> > * 011b = 12bpc.
> > * 100b = 16bpc.
> > */
> > - vsc_sdp.DB17 = 0x1;
> > + switch (crtc_state->pipe_bpp) {
> > + case 24: /* 8bpc */
> > + vsc_sdp.DB17 =
Re: [Intel-gfx] [PATCH v6 3/6] drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format
On Wed, 2019-05-08 at 20:56 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:54AM +0300, Gwan-gyeong Mun wrote:
> > Function intel_pixel_encoding_setup_vsc handles vsc header and data
> > block
> > setup for pixel encoding / colorimetry format.
> >
> > Setup VSC header and data block in function
> > intel_pixel_encoding_setup_vsc
> > for pixel encoding / colorimetry format as per dp 1.4a spec,
> > section 2.2.5.7.1, table 2-119: VSC SDP Header Bytes, section
> > 2.2.5.7.5,
> > table 2-120:VSC SDP Payload for DB16 through DB18.
> >
> > v2:
> > Minor style fix. [Maarten]
> > Refer to commit ids instead of patchwork. [Maarten]
> >
> > v6: Rebase
> >
> > Cc: Maarten Lankhorst
> > Signed-off-by: Gwan-gyeong Mun
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 1 +
> > drivers/gpu/drm/i915/intel_dp.c | 73
> >
> > drivers/gpu/drm/i915/intel_drv.h | 2 +
> > 3 files changed, 76 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index cd5277d98b03..2f1688ea5a2c 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -3391,6 +3391,7 @@ static void intel_enable_ddi_dp(struct
> > intel_encoder *encoder,
> >
> > intel_edp_backlight_on(crtc_state, conn_state);
> > intel_psr_enable(intel_dp, crtc_state);
> > + intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
>
> I wonder if this is a bit too late. But we do it for PSR here, so I
> guess we should think about this for both cases. We should actually
> add full readout + state checker for the VSC SDP for both cases as
> well. But that can be done later.
>
I'll check it again.
> > intel_edp_drrs_enable(intel_dp, crtc_state);
> >
> > if (crtc_state->has_audio)
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 06a3417a88d1..74aad8830a80 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4394,6 +4394,79 @@ u8 intel_dp_dsc_get_slice_count(struct
> > intel_dp *intel_dp,
> > return 0;
> > }
> >
> > +static void
> > +intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
> > + const struct intel_crtc_state
> > *crtc_state)
> > +{
> > + struct intel_digital_port *intel_dig_port =
> > dp_to_dig_port(intel_dp);
> > + struct dp_vsc_sdp vsc_sdp;
> > +
> > + if (!intel_dp->attached_connector->base.ycbcr_420_allowed)
> > + return;
> > +
> > + /* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
> > */
> > + memset(_sdp, 0, sizeof(vsc_sdp));
>
> Can be replaced with '= {}' in the declaration.
>
Yes, I'll use a structure initializer instead of memset().
> > + vsc_sdp.sdp_header.HB0 = 0;
> > + vsc_sdp.sdp_header.HB1 = 0x7;
> > +
> > + /* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> > +* Colorimetry Format indication. A DP Source device is allowed
> > +* to indicate the pixel encoding/colorimetry format to the DP
> > Sink
> > +* device with VSC SDP only when the DP Sink device supports it
> > +* (i.e., VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in
> > the register
> > +* DPRX_FEATURE_ENUMERATION_LIST (DPCD Address 02210h, bit 3)
> > is set to 1)
> > +*/
>
> Are we checking that bit somewhere? I suppose the sink might a bit
> nuts
> if it declares 420_only modes without that set, but maybe it should
> be
> checked anyway.
>
> Also non-standard comment format all over. Should be
> /*
> * blah
> */
>
I'll add a checking of VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit
with intel_dp_get_colorimetry_status() on intel_dp_ycbcr420_config().
And I will fix non-standard comment format.
> > + vsc_sdp.sdp_header.HB2 = 0x5;
> > +
> > + /* VSC SDP supporting 3D stereo, + PSR2, + Pixel Encoding/
> > +* Colorimetry Format indication (HB2 = 05h).
> > +*/
> > + vsc_sdp.sdp_header.HB3 = 0x13;
> > + /* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 =
> > 1h
> > +* DB16[3:0] DP 1.4a spec, Table 2-120
> > +*/
> > +
> > + /* Commit id (25edf91501b8 "drm/i915: prepare csc unit for
> > YCBCR420 output")
> > +* uses the BT.709 color space to perform RGB->YCBCR
> > conversion.
> > +*/
>
> I don't think referring to specific commit here is particularly
> helpful.
> The situation will change anyway at some point.
>
Yes, I'll remove a referring to specific commit.
> > + vsc_sdp.DB16 = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
> > + vsc_sdp.DB16 |= 0x1; /* 0x1, ITU-R BT.709 */
> > +
> > + /* For pixel encoding formats YCbCr444, YCbCr422, YCbCr420, and
> > Y Only,
> > +* the following Component Bit Depth values are defined:
> > +* 001b = 8bpc.
> > +* 010b = 10bpc.
> > +* 011b = 12bpc.
> > +* 100b = 16bpc.
> > +*/
> > + vsc_sdp.DB17 = 0x1;
>
> Don't we need to base this on pipe_bpp?
>
> And I'm thinking we want the CEA bit set here as well.
>
I'll move a
Re: [Intel-gfx] [PATCH v6 2/6] drm: Add a VSC structure for handling Pixel Encoding/Colorimetry Formats
On Wed, 2019-05-08 at 20:32 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:53AM +0300, Gwan-gyeong Mun wrote:
> > SDP VSC Header and Data Block follow DP 1.4a spec, section
> > 2.2.5.7.5,
> > chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
> >
> > Signed-off-by: Gwan-gyeong Mun
> > Reviewed-by: Maarten Lankhorst
> > ---
> > include/drm/drm_dp_helper.h | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
> > index 97ce790a5b5a..3793bea7b7fe 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1096,6 +1096,23 @@ struct edp_vsc_psr {
> > u8 DB8_31[24]; /* Reserved */
> > } __packed;
> >
> > +struct dp_vsc_sdp {
> > + struct dp_sdp_header sdp_header;
> > + u8 DB0; /* Stereo Interface */
> > + u8 DB1; /* 0 - PSR State; 1 - Update RFB; 2 - CRC Valid */
> > + u8 DB2; /* CRC value bits 7:0 of the R or Cr component */
> > + u8 DB3; /* CRC value bits 15:8 of the R or Cr component */
> > + u8 DB4; /* CRC value bits 7:0 of the G or Y component */
> > + u8 DB5; /* CRC value bits 15:8 of the G or Y component */
> > + u8 DB6; /* CRC value bits 7:0 of the B or Cb component */
> > + u8 DB7; /* CRC value bits 15:8 of the B or Cb component */
> > + u8 DB8_15[8]; /* Reserved */
> > + u8 DB16; /* Pixel Encoding and Colorimetry Formats */
> > + u8 DB17; /* Dynamic Range and Component Bit Depth */
> > + u8 DB18; /* Content Type */
> > + u8 DB19_31[13]; /* Reserved */
> > +} __packed;
>
> Isn't this the same thing we have for edp already? Just rename the
> edp
> struct and add the missing stuff?
>
Okay, I'll rename struct edp_vsc_psr to general name of dp_sdp and will
add missing stuff.
> > +
> > #define EDP_VSC_PSR_STATE_ACTIVE (1<<0)
> > #define EDP_VSC_PSR_UPDATE_RFB (1<<1)
> > #define EDP_VSC_PSR_CRC_VALUES_VALID (1<<2)
> > --
> > 2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case (rev2)
== Series Details == Series: drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case (rev2) URL : https://patchwork.freedesktop.org/series/60473/ State : success == Summary == CI Bug Log - changes from CI_DRM_6072_full -> Patchwork_12994_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12994_full that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries_display_off: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#104108]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-skl1/igt@debugfs_test@read_all_entries_display_off.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/shard-skl4/igt@debugfs_test@read_all_entries_display_off.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][3] -> [FAIL][4] ([fdo#105767]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions: - shard-hsw: [PASS][5] -> [FAIL][6] ([fdo#103355]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-hsw2/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: - shard-iclb: [PASS][7] -> [FAIL][8] ([fdo#103167]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109441]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/shard-iclb1/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-apl5/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/shard-apl8/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html * igt@kms_vblank@pipe-c-wait-forked-busy: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([fdo#103540]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-hsw6/igt@kms_vbl...@pipe-c-wait-forked-busy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/shard-hsw1/igt@kms_vbl...@pipe-c-wait-forked-busy.html Possible fixes * igt@gem_workarounds@suspend-resume-context: - shard-apl: [DMESG-WARN][15] ([fdo#108566]) -> [PASS][16] +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/shard-apl8/igt@gem_workarou...@suspend-resume-context.html * igt@kms_cursor_edge_walk@pipe-b-64x64-bottom-edge: - shard-snb: [SKIP][17] ([fdo#109271] / [fdo#109278]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-snb7/igt@kms_cursor_edge_w...@pipe-b-64x64-bottom-edge.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/shard-snb7/igt@kms_cursor_edge_w...@pipe-b-64x64-bottom-edge.html * igt@kms_flip@flip-vs-suspend: - shard-kbl: [DMESG-WARN][19] ([fdo#108566]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-kbl1/igt@kms_f...@flip-vs-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/shard-kbl1/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: [FAIL][21] ([fdo#100368]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/shard-skl2/igt@kms_f...@plain-flip-fb-recreate-interruptible.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/shard-skl7/igt@kms_f...@plain-flip-fb-recreate-interruptible.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-gtt: - shard-skl: [FAIL][23] ([fdo#103167] / [fdo#110379]) -> [PASS][24] [23]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: GTT remapping for display
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/60469/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072_full -> Patchwork_12991_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12991_full:
### IGT changes ###
Possible regressions
* {igt@kms_big_fb@x-tiled-32bpp-rotate-90} (NEW):
- shard-iclb: NOTRUN -> [SKIP][1] +33 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12991/shard-iclb7/igt@kms_big...@x-tiled-32bpp-rotate-90.html
New tests
-
New tests have been introduced between CI_DRM_6072_full and
Patchwork_12991_full:
### New IGT tests (75) ###
* igt@i915_selftest@live_vma:
- Statuses : 7 pass(s)
- Exec time: [0.33, 1.78] s
* igt@kms_big_fb@linear-16bpp-rotate-0:
- Statuses : 7 pass(s)
- Exec time: [1.57, 5.64] s
* igt@kms_big_fb@linear-16bpp-rotate-180:
- Statuses : 7 pass(s)
- Exec time: [1.55, 5.53] s
* igt@kms_big_fb@linear-16bpp-rotate-270:
- Statuses : 6 skip(s)
- Exec time: [0.29, 1.81] s
* igt@kms_big_fb@linear-16bpp-rotate-90:
- Statuses : 7 skip(s)
- Exec time: [0.49, 4.00] s
* igt@kms_big_fb@linear-32bpp-rotate-0:
- Statuses : 6 pass(s)
- Exec time: [1.76, 8.58] s
* igt@kms_big_fb@linear-32bpp-rotate-180:
- Statuses : 7 pass(s)
- Exec time: [1.67, 8.21] s
* igt@kms_big_fb@linear-32bpp-rotate-270:
- Statuses : 7 skip(s)
- Exec time: [0.36, 7.11] s
* igt@kms_big_fb@linear-32bpp-rotate-90:
- Statuses : 7 skip(s)
- Exec time: [0.33, 6.00] s
* igt@kms_big_fb@linear-64bpp-rotate-0:
- Statuses : 1 pass(s) 6 skip(s)
- Exec time: [0.0, 3.44] s
* igt@kms_big_fb@linear-64bpp-rotate-180:
- Statuses : 1 pass(s) 6 skip(s)
- Exec time: [0.0, 3.30] s
* igt@kms_big_fb@linear-64bpp-rotate-270:
- Statuses : 7 skip(s)
- Exec time: [0.0, 1.69] s
* igt@kms_big_fb@linear-64bpp-rotate-90:
- Statuses : 7 skip(s)
- Exec time: [0.0, 3.96] s
* igt@kms_big_fb@linear-8bpp-rotate-0:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_big_fb@linear-8bpp-rotate-180:
- Statuses : 6 skip(s)
- Exec time: [0.0] s
* igt@kms_big_fb@linear-8bpp-rotate-270:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_big_fb@linear-8bpp-rotate-90:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_big_fb@linear-addfb:
- Statuses : 7 pass(s)
- Exec time: [0.0, 0.00] s
* igt@kms_big_fb@x-tiled-16bpp-rotate-0:
- Statuses : 6 pass(s)
- Exec time: [1.49, 2.49] s
* igt@kms_big_fb@x-tiled-16bpp-rotate-180:
- Statuses : 7 pass(s)
- Exec time: [1.64, 6.71] s
* igt@kms_big_fb@x-tiled-16bpp-rotate-270:
- Statuses : 7 skip(s)
- Exec time: [0.20, 3.33] s
* igt@kms_big_fb@x-tiled-16bpp-rotate-90:
- Statuses : 7 skip(s)
- Exec time: [0.45, 3.75] s
* igt@kms_big_fb@x-tiled-32bpp-rotate-0:
- Statuses : 7 pass(s)
- Exec time: [1.70, 8.23] s
* igt@kms_big_fb@x-tiled-32bpp-rotate-180:
- Statuses : 7 pass(s)
- Exec time: [1.69, 8.33] s
* igt@kms_big_fb@x-tiled-32bpp-rotate-270:
- Statuses : 7 skip(s)
- Exec time: [0.30, 5.85] s
* igt@kms_big_fb@x-tiled-32bpp-rotate-90:
- Statuses : 7 skip(s)
- Exec time: [0.41, 6.08] s
* igt@kms_big_fb@x-tiled-64bpp-rotate-0:
- Statuses : 1 pass(s) 6 skip(s)
- Exec time: [0.0, 3.13] s
* igt@kms_big_fb@x-tiled-64bpp-rotate-180:
- Statuses : 1 pass(s) 6 skip(s)
- Exec time: [0.0, 3.15] s
* igt@kms_big_fb@x-tiled-64bpp-rotate-270:
- Statuses : 7 skip(s)
- Exec time: [0.0, 1.76] s
* igt@kms_big_fb@x-tiled-64bpp-rotate-90:
- Statuses : 7 skip(s)
- Exec time: [0.0, 1.63] s
* igt@kms_big_fb@x-tiled-8bpp-rotate-0:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_big_fb@x-tiled-8bpp-rotate-180:
- Statuses : 6 skip(s)
- Exec time: [0.0] s
* igt@kms_big_fb@x-tiled-8bpp-rotate-270:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_big_fb@x-tiled-8bpp-rotate-90:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_big_fb@x-tiled-addfb:
- Statuses : 7 pass(s)
- Exec time: [0.0, 0.00] s
* igt@kms_big_fb@x-tiled-addfb-size-offset-overflow:
- Statuses : 3 pass(s) 3 skip(s)
- Exec time: [0.0] s
* igt@kms_big_fb@x-tiled-addfb-size-overflow:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 0.00] s
* igt@kms_big_fb@y-tiled-16bpp-rotate-0:
- Statuses : 5 pass(s) 2 skip(s)
- Exec time: [0.0, 5.20] s
* igt@kms_big_fb@y-tiled-16bpp-rotate-180:
- Statuses : 5 pass(s) 2 skip(s)
- Exec time: [0.0, 5.18] s
* igt@kms_big_fb@y-tiled-16bpp-rotate-270:
- Statuses : 1 pass(s) 5
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Truly bump ready tasks ahead of busywaits
== Series Details == Series: drm/i915: Truly bump ready tasks ahead of busywaits URL : https://patchwork.freedesktop.org/series/60486/ State : success == Summary == CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12999 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12999/ Known issues Here are the changes found in Patchwork_12999 that come from known issues: ### IGT changes ### Issues hit * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [PASS][1] -> [DMESG-WARN][2] ([fdo#102614]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12999/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-kbl-7500u: [DMESG-WARN][3] ([fdo#105128] / [fdo#107139]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12999/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [INCOMPLETE][5] ([fdo#103927] / [fdo#110624]) -> [DMESG-FAIL][6] ([fdo#110620]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12999/fi-apl-guc/igt@i915_selftest@live_hangcheck.html * igt@runner@aborted: - fi-apl-guc: [FAIL][7] ([fdo#110624]) -> [FAIL][8] ([fdo#110622]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12999/fi-apl-guc/igt@run...@aborted.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128 [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139 [fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620 [fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622 [fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624 Participating hosts (49 -> 42) -- Additional (1): fi-blb-e6850 Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-byt-clapper Build changes - * Linux: CI_DRM_6072 -> Patchwork_12999 CI_DRM_6072: 645586708589c3d2ac81114595e875cdfbbff385 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4976: b1d91d0228db999145405e529952ca49bab7f706 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12999: 89d3cc2d23fab7f8c2e8506199705efbd66ea032 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 89d3cc2d23fa drm/i915: Truly bump ready tasks ahead of busywaits == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12999/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Truly bump ready tasks ahead of busywaits
In commit b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of
busywaits"), I tried cutting a corner in order to not install a signal
for each of our dependencies, and only listened to requests on which we
were intending to busywait. The compromise that was made was that
instead of then being able to promite the request with a full
NOSEMAPHORE like its non-busywaiting brethren, as we had not ensured we
had cleared the semaphore chain, we settled for only using the NEWCLIENT
boost. With an over saturated system with multiple NEWCLIENTS in flight
at any time, this was found to be an inadequate promotion and left us
with a much poorer scheduling order than prior to using semaphores.
The outcome of this patch, is that all requests have NOSEMAPHORE
priority when they have no dependencies and are ready to run and not
busywait, restoring the pre-semaphore ordering on saturated systems.
Fixes: b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of busywaits")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Dmitry Rogozhkin
Cc: Dmitry Ermilov
---
drivers/gpu/drm/i915/i915_request.c | 31 +++--
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index bed213148cbb..5569dff3887b 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -569,18 +569,7 @@ semaphore_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
switch (state) {
case FENCE_COMPLETE:
- /*
-* We only check a small portion of our dependencies
-* and so cannot guarantee that there remains no
-* semaphore chain across all. Instead of opting
-* for the full NOSEMAPHORE boost, we go for the
-* smaller (but still preempting) boost of
-* NEWCLIENT. This will be enough to boost over
-* a busywaiting request (as that cannot be
-* NEWCLIENT) without accidentally boosting
-* a busywait over real work elsewhere.
-*/
- i915_schedule_bump_priority(request, I915_PRIORITY_NEWCLIENT);
+ i915_schedule_bump_priority(request, I915_PRIORITY_NOSEMAPHORE);
break;
case FENCE_FREE:
@@ -846,12 +835,6 @@ emit_semaphore_wait(struct i915_request *to,
if (err < 0)
return err;
- err = i915_sw_fence_await_dma_fence(>semaphore,
- >fence, 0,
- I915_FENCE_GFP);
- if (err < 0)
- return err;
-
/* Only submit our spinner after the signaler is running! */
err = i915_request_await_execution(to, from, gfp);
if (err)
@@ -917,8 +900,18 @@ i915_request_await_request(struct i915_request *to, struct
i915_request *from)
>fence, 0,
I915_FENCE_GFP);
}
+ if (ret < 0)
+ return ret;
+
+ if (to->sched.flags & I915_SCHED_HAS_SEMAPHORE_CHAIN) {
+ ret = i915_sw_fence_await_dma_fence(>semaphore,
+ >fence, 0,
+ I915_FENCE_GFP);
+ if (ret < 0)
+ return ret;
+ }
- return ret < 0 ? ret : 0;
+ return 0;
}
int
--
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 RFC: console: hack up console_lock more v3 (rev3)
== Series Details == Series: RFC: console: hack up console_lock more v3 (rev3) URL : https://patchwork.freedesktop.org/series/60467/ State : success == Summary == CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12998 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12998/ Known issues Here are the changes found in Patchwork_12998 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [PASS][1] -> [INCOMPLETE][2] ([fdo#108602] / [fdo#108744]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12998/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size: - fi-bsw-n3050: [PASS][3] -> [FAIL][4] ([fdo#106081]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-bsw-n3050/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12998/fi-bsw-n3050/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-kbl-7500u: [DMESG-WARN][5] ([fdo#105128] / [fdo#107139]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12998/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [INCOMPLETE][7] ([fdo#103927] / [fdo#110624]) -> [INCOMPLETE][8] ([fdo#103927]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12998/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128 [fdo#106081]: https://bugs.freedesktop.org/show_bug.cgi?id=106081 [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624 Participating hosts (49 -> 44) -- Additional (1): fi-blb-e6850 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * Linux: CI_DRM_6072 -> Patchwork_12998 CI_DRM_6072: 645586708589c3d2ac81114595e875cdfbbff385 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4976: b1d91d0228db999145405e529952ca49bab7f706 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12998: b17a5bb889228f9e9db3679cf90a820c3a4bd3d7 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b17a5bb88922 kernel/locking/semaphore: use wake_q in up() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12998/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Extend BT2020 support in iCSC and fixes (rev2)
== Series Details == Series: Extend BT2020 support in iCSC and fixes (rev2) URL : https://patchwork.freedesktop.org/series/60480/ State : success == Summary == CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12997 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/ Known issues Here are the changes found in Patchwork_12997 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [PASS][1] -> [DMESG-FAIL][2] ([fdo#110235]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [PASS][3] -> [INCOMPLETE][4] ([fdo#108602] / [fdo#108744]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-kbl-7500u: [DMESG-WARN][5] ([fdo#105128] / [fdo#107139]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html [fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128 [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (49 -> 43) -- Additional (1): fi-blb-e6850 Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-apl-guc fi-ctg-p8600 fi-byt-clapper Build changes - * Linux: CI_DRM_6072 -> Patchwork_12997 CI_DRM_6072: 645586708589c3d2ac81114595e875cdfbbff385 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4976: b1d91d0228db999145405e529952ca49bab7f706 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12997: 52ef243e7805e0894631ede9c11484611c035879 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 52ef243e7805 drm/i915/icl: Fixed Input CSC Co-efficients for BT601/709 e16ab39821c8 drm/i915/icl: Fix Y pre-offset for Full Range YCbCr 5554288b7184 drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12997/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] kernel/locking/semaphore: use wake_q in up()
console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring the real backtrace we're really interested in.
One case I've seen (slightly simplified backtrace):
Call Trace:
console_trylock+0xe/0x60
vprintk_emit+0xf1/0x320
printk+0x4d/0x69
__warn_printk+0x46/0x90
native_smp_send_reschedule+0x2f/0x40
check_preempt_curr+0x81/0xa0
ttwu_do_wakeup+0x14/0x220
try_to_wake_up+0x218/0x5f0
pollwake+0x6f/0x90
credit_entropy_bits+0x204/0x310
add_interrupt_randomness+0x18f/0x210
handle_irq+0x67/0x160
do_IRQ+0x5e/0x130
common_interrupt+0xf/0xf
This alone isn't a problem, but the spinlock in the semaphore is also
still held while waking up waiters (up() -> __up() -> try_to_wake_up()
callchain), which then closes the runqueue vs. semaphore.lock loop,
and upsets lockdep, which issues a circular locking splat to dmesg.
Worse it upsets developers, since we don't want to spam dmesg with
clutter when the machine is dying already.
Fix this specific locking recursion by moving the wake_up_process out
from under the semaphore.lock spinlock, using wake_q as recommended by
Peter Zijlstra.
As Petr Mladek points out this doesn't fix all the locking recursions
in this area. If we actually recursive in the above callchain:
+ try_to_wake_up()# takes p->pi_lock
+ ttwu_remote() # takes rq lock
+ ttwu_do_wakeup()
+ check_preempt_curr()
+ native_smp_send_reschedule()
+ __warn_printk()
+ printk()
+ vprintk_emit()
+ console_trylock() # success
+ console_unlock()
+ up_console_sem()
+ up() # wait list in not empty
+ __up()
+ wake_up_process()
+ try_to_wake_up()
Then there's any number of scheduler related locks will deadlock.
Given that the kernel is dying already (the printk() in
native_smp_send_reschedule() happens because we run on an offlined
CPU) I think there's limited value in trying to fix this:
- We haven't seen the actual deadlock in our CI, only lockdep
complaining about the possibility.
- The real issue is that the lockdep splat hides useful dmesg
information we capture in e.g. pstore or on screen about the real
cause of why the kernel is dying.
- The console_unlock in the above callchain should have managed to get
all the dmesg up to that point out already. Dying later on is
somewhat ok - I've only seen this lockdep splat in pstore when the
machine died anyway.
Also cc'ing John Ogness since perhaps his printk rework fixes this all
properly.
v2: Ditch attempt to fix console_trylock.
v3: Add a comment explaining why the taks we're waking won't
disappear (Chris), and improve commit message to address review
questions.
v4: Use wake_q (Peter Z).
Signed-off-by: Daniel Vetter
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: Daniel Vetter
Cc: John Ogness
Cc: Chris Wilson
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
kernel/locking/semaphore.c | 42 +++---
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index 561acdd39960..7a6f33715688 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -33,12 +33,12 @@
#include
#include
#include
+#include
static noinline void __down(struct semaphore *sem);
static noinline int __down_interruptible(struct semaphore *sem);
static noinline int __down_killable(struct semaphore *sem);
static noinline int __down_timeout(struct semaphore *sem, long timeout);
-static noinline void __up(struct semaphore *sem);
/**
* down - acquire the semaphore
@@ -169,6 +169,14 @@ int down_timeout(struct semaphore *sem, long timeout)
}
EXPORT_SYMBOL(down_timeout);
+/* Functions for the contended case */
+
+struct semaphore_waiter {
+ struct list_head list;
+ struct task_struct *task;
+ bool up;
+};
+
/**
* up - release the semaphore
* @sem: the semaphore to release
@@ -179,24 +187,25 @@ EXPORT_SYMBOL(down_timeout);
void up(struct semaphore *sem)
{
unsigned long flags;
+ struct semaphore_waiter *waiter;
+ DEFINE_WAKE_Q(wake_q);
raw_spin_lock_irqsave(>lock, flags);
- if (likely(list_empty(>wait_list)))
+ if (likely(list_empty(>wait_list))) {
sem->count++;
- else
- __up(sem);
+ } else {
+ waiter = list_first_entry(>wait_list,
+ struct
[Intel-gfx] [v2] drm/i915/icl: Fixed Input CSC Co-efficients for BT601/709
Input CSC Co-efficients for BT601 and BT709 YCbCR to RGB
conversion were slightly off. Fixed the same.
v2: Fixed the co-eficients as there was issue with reference
matrix, spotted by Ville.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_sprite.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index c9c970f..ca15799 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -430,7 +430,7 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
*/
[DRM_COLOR_YCBCR_BT709] = {
0x7C98, 0x7800, 0x0,
- 0x9EF8, 0x7800, 0xABF8,
+ 0x9EF8, 0x7800, 0xAC00,
0x0, 0x7800, 0x7ED8,
},
/*
@@ -452,26 +452,26 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
/*
* BT.601 Limted range YCbCr -> full range RGB
* The matrix required is :
-* [1.164384, 0.000, 1.596370,
-* 1.138393, -0.382500, -0.794598,
-* 1.138393, 1.971696, 0.]
+* [1.164384, 0.000, 1.596027,
+* 1.164384, -0.39175, -0.812813,
+* 1.164384, 2.017232, 0.]
*/
[DRM_COLOR_YCBCR_BT601] = {
0x7CC8, 0x7950, 0x0,
- 0x8CB8, 0x7918, 0x9C40,
- 0x0, 0x7918, 0x7FC8,
+ 0x8D00, 0x7950, 0x9C88,
+ 0x0, 0x7950, 0x6810,
},
/*
* BT.709 Limited range YCbCr -> full range RGB
* The matrix required is :
-* [1.164, 0.000, 1.833671,
-* 1.138393, -0.213249, -0.532909,
-* 1.138393, 2.112402, 0.]
+* [1.164384, 0.000, 1.792741,
+* 1.164384, -0.213249, -0.532909,
+* 1.164384, 2.112402, 0.]
*/
[DRM_COLOR_YCBCR_BT709] = {
- 0x7EA8, 0x7950, 0x0,
- 0x, 0x7918, 0xADA8,
- 0x0, 0x7918, 0x6870,
+ 0x7E58, 0x7950, 0x0,
+ 0x, 0x7950, 0xADA8,
+ 0x0, 0x7950, 0x6870,
},
/*
* BT.2020 Limited range YCbCr -> full range RGB
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: Fixed Input CSC Co-efficients for BT601/709
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Friday, May 10, 2019 12:54 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; maarten.lankho...@linux.intel.com; Sharma,
>Shashank
>Subject: Re: [PATCH 3/3] drm/i915/icl: Fixed Input CSC Co-efficients for
>BT601/709
>
>On Fri, May 10, 2019 at 12:41:48AM +0530, Uma Shankar wrote:
>> Input CSC Co-efficients for BT601 and BT709 YCbCR to RGB conversion
>> were slightly off. Fixed the same.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/intel_sprite.c | 24
>> 1 file changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
>> b/drivers/gpu/drm/i915/intel_sprite.c
>> index c9c970f..1239457 100644
>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> @@ -430,7 +430,7 @@ int intel_plane_check_src_coordinates(struct
>intel_plane_state *plane_state)
>> */
>> [DRM_COLOR_YCBCR_BT709] = {
>> 0x7C98, 0x7800, 0x0,
>> -0x9EF8, 0x7800, 0xABF8,
>> +0x9EF8, 0x7800, 0xAC00,
>> 0x0, 0x7800, 0x7ED8,
>> },
>> /*
>> @@ -453,25 +453,25 @@ int intel_plane_check_src_coordinates(struct
>intel_plane_state *plane_state)
>> * BT.601 Limted range YCbCr -> full range RGB
>> * The matrix required is :
>> * [1.164384, 0.000, 1.596370,
>> - * 1.138393, -0.382500, -0.794598,
>> - * 1.138393, 1.971696, 0.]
>> + * 1.164384, -0.382500, -0.794598,
>> + * 1.164384, 1.971696, 0.]
>
>Still not quite what I'm getting here:
>1.164384 0.00 1.596027
>1.164384 -0.391762 -0.812968
>1.164384 2.017232 0.00
Hmm yeah, the reference matrix I used earlier is not accurate it seems. With
igt_color_encoding I am getting what you get here. Will update and resend.
>> */
>> [DRM_COLOR_YCBCR_BT601] = {
>> -0x7CC8, 0x7950, 0x0,
>> -0x8CB8, 0x7918, 0x9C40,
>> -0x0, 0x7918, 0x7FC8,
>> +0x7C80, 0x7950, 0x0,
>> +0x8CB8, 0x7950, 0x9C40,
>> +0x0, 0x7950, 0x7FC8,
>> },
>> /*
>> * BT.709 Limited range YCbCr -> full range RGB
>> * The matrix required is :
>> - * [1.164, 0.000, 1.833671,
>> - * 1.138393, -0.213249, -0.532909,
>> - * 1.138393, 2.112402, 0.]
>> + * [1.164384, 0.000, 1.792741,
>> + * 1.164384, -0.213249, -0.532909,
>> + * 1.164384, 2.112402, 0.]
>> */
>
>This one matches what I'm getting.
>
>> [DRM_COLOR_YCBCR_BT709] = {
>> -0x7EA8, 0x7950, 0x0,
>> -0x, 0x7918, 0xADA8,
>> -0x0, 0x7918, 0x6870,
>> +0x7E58, 0x7950, 0x0,
>> +0x, 0x7950, 0xADA8,
>> +0x0, 0x7950, 0x6870,
>> },
>> /*
>> * BT.2020 Limited range YCbCr -> full range RGB
>> --
>> 1.9.1
>
>--
>Ville Syrjälä
>Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Extend BT2020 support in iCSC and fixes
== Series Details == Series: Extend BT2020 support in iCSC and fixes URL : https://patchwork.freedesktop.org/series/60480/ State : success == Summary == CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12996 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12996/ Known issues Here are the changes found in Patchwork_12996 that come from known issues: ### IGT changes ### Issues hit * igt@gem_cpu_reloc@basic: - fi-icl-u3: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / [fdo#110246]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-icl-u3/igt@gem_cpu_re...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12996/fi-icl-u3/igt@gem_cpu_re...@basic.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-kbl-7500u: [DMESG-WARN][3] ([fdo#105128] / [fdo#107139]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12996/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [INCOMPLETE][5] ([fdo#103927] / [fdo#110624]) -> [DMESG-FAIL][6] ([fdo#110620]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12996/fi-apl-guc/igt@i915_selftest@live_hangcheck.html * igt@runner@aborted: - fi-apl-guc: [FAIL][7] ([fdo#110624]) -> [FAIL][8] ([fdo#110622]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12996/fi-apl-guc/igt@run...@aborted.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128 [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#110246]: https://bugs.freedesktop.org/show_bug.cgi?id=110246 [fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620 [fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622 [fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624 Participating hosts (49 -> 43) -- Additional (1): fi-blb-e6850 Missing(7): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * Linux: CI_DRM_6072 -> Patchwork_12996 CI_DRM_6072: 645586708589c3d2ac81114595e875cdfbbff385 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4976: b1d91d0228db999145405e529952ca49bab7f706 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12996: cdd5ea3566e2ed1bc6fa7e7e9aaf03a846ea1210 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == cdd5ea3566e2 drm/i915/icl: Fixed Input CSC Co-efficients for BT601/709 a6e420d39645 drm/i915/icl: Fix Y pre-offset for Full Range YCbCr 5b4fbc4e2925 drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12996/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: Fixed Input CSC Co-efficients for BT601/709
On Fri, May 10, 2019 at 12:41:48AM +0530, Uma Shankar wrote:
> Input CSC Co-efficients for BT601 and BT709 YCbCR to RGB
> conversion were slightly off. Fixed the same.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index c9c970f..1239457 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -430,7 +430,7 @@ int intel_plane_check_src_coordinates(struct
> intel_plane_state *plane_state)
>*/
> [DRM_COLOR_YCBCR_BT709] = {
> 0x7C98, 0x7800, 0x0,
> - 0x9EF8, 0x7800, 0xABF8,
> + 0x9EF8, 0x7800, 0xAC00,
> 0x0, 0x7800, 0x7ED8,
> },
> /*
> @@ -453,25 +453,25 @@ int intel_plane_check_src_coordinates(struct
> intel_plane_state *plane_state)
>* BT.601 Limted range YCbCr -> full range RGB
>* The matrix required is :
>* [1.164384, 0.000, 1.596370,
> - * 1.138393, -0.382500, -0.794598,
> - * 1.138393, 1.971696, 0.]
> + * 1.164384, -0.382500, -0.794598,
> + * 1.164384, 1.971696, 0.]
Still not quite what I'm getting here:
1.164384 0.00 1.596027
1.164384 -0.391762 -0.812968
1.164384 2.017232 0.00
>*/
> [DRM_COLOR_YCBCR_BT601] = {
> - 0x7CC8, 0x7950, 0x0,
> - 0x8CB8, 0x7918, 0x9C40,
> - 0x0, 0x7918, 0x7FC8,
> + 0x7C80, 0x7950, 0x0,
> + 0x8CB8, 0x7950, 0x9C40,
> + 0x0, 0x7950, 0x7FC8,
> },
> /*
>* BT.709 Limited range YCbCr -> full range RGB
>* The matrix required is :
> - * [1.164, 0.000, 1.833671,
> - * 1.138393, -0.213249, -0.532909,
> - * 1.138393, 2.112402, 0.]
> + * [1.164384, 0.000, 1.792741,
> + * 1.164384, -0.213249, -0.532909,
> + * 1.164384, 2.112402, 0.]
>*/
This one matches what I'm getting.
> [DRM_COLOR_YCBCR_BT709] = {
> - 0x7EA8, 0x7950, 0x0,
> - 0x, 0x7918, 0xADA8,
> - 0x0, 0x7918, 0x6870,
> + 0x7E58, 0x7950, 0x0,
> + 0x, 0x7950, 0xADA8,
> + 0x0, 0x7950, 0x6870,
> },
> /*
>* BT.2020 Limited range YCbCr -> full range RGB
> --
> 1.9.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
Currently input csc for YCbCR to RGB conversion handles only
BT601 and Bt709. Extending it to support BT2020 as well.
v2: Fixed the co-efficients for LR to FR conversion,
as suggested by Ville.
v3: Fixed Y Pre-offset in case of Full Range YCbCr as suggested
by Ville.
v4: Split the v2 and v3 changes.
Reviewed-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_sprite.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 2913e89..4f513600 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -433,6 +433,18 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
0x9EF8, 0x7800, 0xABF8,
0x0, 0x7800, 0x7ED8,
},
+ /*
+* BT.2020 full range YCbCr -> full range RGB
+* The matrix required is :
+* [1.000, 0.000, 1.474,
+* 1.000, -0.1645, -0.5713,
+* 1.000, 1.8814, 0.]
+*/
+ [DRM_COLOR_YCBCR_BT2020] = {
+ 0x7BC8, 0x7800, 0x0,
+ 0x8928, 0x7800, 0xAA88,
+ 0x0, 0x7800, 0x7F10,
+ },
};
/* Matrix for Limited Range to Full Range Conversion */
@@ -461,6 +473,18 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
0x, 0x7918, 0xADA8,
0x0, 0x7918, 0x6870,
},
+ /*
+* BT.2020 Limited range YCbCr -> full range RGB
+* The matrix required is :
+* [1.164, 0.000, 1.678,
+* 1.164, -0.1873, -0.6504,
+* 1.164, 2.1417, 0.]
+*/
+ [DRM_COLOR_YCBCR_BT2020] = {
+ 0x7D70, 0x7950, 0x0,
+ 0x8A68, 0x7950, 0xAC00,
+ 0x0, 0x7950, 0x6890,
+ },
};
const u16 *csc;
--
1.9.1
___
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: Fixed Input CSC Co-efficients for BT601/709
Input CSC Co-efficients for BT601 and BT709 YCbCR to RGB
conversion were slightly off. Fixed the same.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_sprite.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index c9c970f..1239457 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -430,7 +430,7 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
*/
[DRM_COLOR_YCBCR_BT709] = {
0x7C98, 0x7800, 0x0,
- 0x9EF8, 0x7800, 0xABF8,
+ 0x9EF8, 0x7800, 0xAC00,
0x0, 0x7800, 0x7ED8,
},
/*
@@ -453,25 +453,25 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
* BT.601 Limted range YCbCr -> full range RGB
* The matrix required is :
* [1.164384, 0.000, 1.596370,
-* 1.138393, -0.382500, -0.794598,
-* 1.138393, 1.971696, 0.]
+* 1.164384, -0.382500, -0.794598,
+* 1.164384, 1.971696, 0.]
*/
[DRM_COLOR_YCBCR_BT601] = {
- 0x7CC8, 0x7950, 0x0,
- 0x8CB8, 0x7918, 0x9C40,
- 0x0, 0x7918, 0x7FC8,
+ 0x7C80, 0x7950, 0x0,
+ 0x8CB8, 0x7950, 0x9C40,
+ 0x0, 0x7950, 0x7FC8,
},
/*
* BT.709 Limited range YCbCr -> full range RGB
* The matrix required is :
-* [1.164, 0.000, 1.833671,
-* 1.138393, -0.213249, -0.532909,
-* 1.138393, 2.112402, 0.]
+* [1.164384, 0.000, 1.792741,
+* 1.164384, -0.213249, -0.532909,
+* 1.164384, 2.112402, 0.]
*/
[DRM_COLOR_YCBCR_BT709] = {
- 0x7EA8, 0x7950, 0x0,
- 0x, 0x7918, 0xADA8,
- 0x0, 0x7918, 0x6870,
+ 0x7E58, 0x7950, 0x0,
+ 0x, 0x7950, 0xADA8,
+ 0x0, 0x7950, 0x6870,
},
/*
* BT.2020 Limited range YCbCr -> full range RGB
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/icl: Fix Y pre-offset for Full Range YCbCr
Fixed Y Pre-offset in case of Full Range YCbCr. Reviewed-by: Ville Syrjälä Suggested-by: Ville Syrjälä Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_sprite.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 4f513600..c9c970f 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -505,8 +505,11 @@ int intel_plane_check_src_coordinates(struct intel_plane_state *plane_state) I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 0), PREOFF_YUV_TO_RGB_HI); - I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), - PREOFF_YUV_TO_RGB_ME); + if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE) + I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), 0); + else + I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), + PREOFF_YUV_TO_RGB_ME); I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 2), PREOFF_YUV_TO_RGB_LO); I915_WRITE_FW(PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 0), 0x0); -- 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] Extend BT2020 support in iCSC and fixes
This series adds support for BT2020 YCbCr to RGB conversion using input CSC. This also fixes issues with BT601 and BT709 coefficients. Uma Shankar (3): drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case drm/i915/icl: Fix Y pre-offset for Full Range YCbCr drm/i915/icl: Fixed Input CSC Co-efficients for BT601/709 drivers/gpu/drm/i915/intel_sprite.c | 55 +++-- 1 file changed, 41 insertions(+), 14 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.BAT: success for drm/i915: Add support for asynchronous display power disabling (rev4)
== Series Details == Series: drm/i915: Add support for asynchronous display power disabling (rev4) URL : https://patchwork.freedesktop.org/series/60242/ State : success == Summary == CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12995 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/ Known issues Here are the changes found in Patchwork_12995 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: [PASS][1] -> [DMESG-WARN][2] ([fdo#108965]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [PASS][3] -> [DMESG-WARN][4] ([fdo#102614]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-kbl-7500u: [DMESG-WARN][5] ([fdo#105128] / [fdo#107139]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [INCOMPLETE][7] ([fdo#103927] / [fdo#110624]) -> [DMESG-FAIL][8] ([fdo#110620]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/fi-apl-guc/igt@i915_selftest@live_hangcheck.html * igt@runner@aborted: - fi-apl-guc: [FAIL][9] ([fdo#110624]) -> [FAIL][10] ([fdo#110622]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/fi-apl-guc/igt@run...@aborted.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128 [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 [fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620 [fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622 [fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624 Participating hosts (49 -> 44) -- Additional (1): fi-blb-e6850 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * Linux: CI_DRM_6072 -> Patchwork_12995 CI_DRM_6072: 645586708589c3d2ac81114595e875cdfbbff385 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4976: b1d91d0228db999145405e529952ca49bab7f706 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12995: 00c05bcbe97667ffa80702b2772dfd90962616a6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 00c05bcbe976 drm/i915: Assert that TypeC ports are not used for eDP 8be8c1a2a3ec drm/i915: Avoid taking the PPS lock for non-eDP/VLV/CHV 5ed418d5c21c drm/i915: Replace use of PLLS power domain with DISPLAY_CORE domain c7f8f0661059 drm/i915: Remove the unneeded AUX power ref from intel_dp_hpd_pulse() 5acca0e6cc51 drm/i915: Remove the unneeded AUX power ref from intel_dp_detect() e050454a5a0a drm/i915: WARN for eDP encoders in intel_dp_detect_dpcd() b782fd807447 drm/i915: Disable power asynchronously during DP AUX transfers ee3d9b40ce98 drm/i915: Add support for asynchronous display power disabling 8fddd30bab27 drm/i915: Verify power domains state during suspend in all cases 79f1a80345ce drm/i915: Force printing wakeref tacking during pm_cleanup cf4ea8e124c3 drm/i915: Add support for tracking wakerefs w/o power-on guarantee == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12995/ ___ 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: Add support for asynchronous display power disabling (rev4)
== Series Details == Series: drm/i915: Add support for asynchronous display power disabling (rev4) URL : https://patchwork.freedesktop.org/series/60242/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Add support for tracking wakerefs w/o power-on guarantee -drivers/gpu/drm/i915/selftests/../i915_utils.h:184:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_utils.h:186:16: warning: expression using sizeof(void) Commit: drm/i915: Force printing wakeref tacking during pm_cleanup Okay! Commit: drm/i915: Verify power domains state during suspend in all cases Okay! Commit: drm/i915: Add support for asynchronous display power disabling Okay! Commit: drm/i915: Disable power asynchronously during DP AUX transfers Okay! Commit: drm/i915: WARN for eDP encoders in intel_dp_detect_dpcd() Okay! Commit: drm/i915: Remove the unneeded AUX power ref from intel_dp_detect() Okay! Commit: drm/i915: Remove the unneeded AUX power ref from intel_dp_hpd_pulse() Okay! Commit: drm/i915: Replace use of PLLS power domain with DISPLAY_CORE domain Okay! Commit: drm/i915: Avoid taking the PPS lock for non-eDP/VLV/CHV Okay! Commit: drm/i915: Assert that TypeC ports are not used for eDP 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: Add support for asynchronous display power disabling (rev4)
== Series Details ==
Series: drm/i915: Add support for asynchronous display power disabling (rev4)
URL : https://patchwork.freedesktop.org/series/60242/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cf4ea8e124c3 drm/i915: Add support for tracking wakerefs w/o power-on guarantee
-:45: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'T' may be better as '(T)' to
avoid precedence issues
#45: FILE: drivers/gpu/drm/i915/i915_utils.h:105:
+#define struct_member(T, member) (((T *)0)->member)
-:45: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'member' may be better as
'(member)' to avoid precedence issues
#45: FILE: drivers/gpu/drm/i915/i915_utils.h:105:
+#define struct_member(T, member) (((T *)0)->member)
total: 0 errors, 0 warnings, 2 checks, 341 lines checked
79f1a80345ce drm/i915: Force printing wakeref tacking during pm_cleanup
8fddd30bab27 drm/i915: Verify power domains state during suspend in all cases
ee3d9b40ce98 drm/i915: Add support for asynchronous display power disabling
b782fd807447 drm/i915: Disable power asynchronously during DP AUX transfers
e050454a5a0a drm/i915: WARN for eDP encoders in intel_dp_detect_dpcd()
5acca0e6cc51 drm/i915: Remove the unneeded AUX power ref from intel_dp_detect()
-:176: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible
side-effects?
#176: FILE: drivers/gpu/drm/i915/intel_runtime_pm.h:79:
+#define with_intel_display_power(i915, domain, wf) \
+ for ((wf) = intel_display_power_get((i915), (domain)); (wf); \
+intel_display_power_put_async((i915), (domain), (wf)), (wf) = 0)
-:176: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'domain' - possible
side-effects?
#176: FILE: drivers/gpu/drm/i915/intel_runtime_pm.h:79:
+#define with_intel_display_power(i915, domain, wf) \
+ for ((wf) = intel_display_power_get((i915), (domain)); (wf); \
+intel_display_power_put_async((i915), (domain), (wf)), (wf) = 0)
-:176: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects?
#176: FILE: drivers/gpu/drm/i915/intel_runtime_pm.h:79:
+#define with_intel_display_power(i915, domain, wf) \
+ for ((wf) = intel_display_power_get((i915), (domain)); (wf); \
+intel_display_power_put_async((i915), (domain), (wf)), (wf) = 0)
total: 0 errors, 0 warnings, 3 checks, 119 lines checked
c7f8f0661059 drm/i915: Remove the unneeded AUX power ref from
intel_dp_hpd_pulse()
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#12:
commit 1c767b339b39 ("drm/i915: take display port power domain in DP HPD
handler")
total: 0 errors, 1 warnings, 0 checks, 46 lines checked
5ed418d5c21c drm/i915: Replace use of PLLS power domain with DISPLAY_CORE domain
8be8c1a2a3ec drm/i915: Avoid taking the PPS lock for non-eDP/VLV/CHV
00c05bcbe976 drm/i915: Assert that TypeC ports are not used for eDP
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Thursday, May 9, 2019 10:02 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst,
>Maarten
>Subject: Re: [Intel-gfx] [v3] drm/i915/icl: Handle YCbCr to RGB conversion for
>BT2020
>case
>
>On Thu, May 09, 2019 at 09:57:19PM +0530, Uma Shankar wrote:
>> Currently input csc for YCbCR to RGB conversion handles only
>> BT601 and Bt709. Extending it to support BT2020 as well.
>>
>> v2: Fixed the co-efficients for LR to FR conversion, as suggested by
>> Ville.
>>
>> v3: Fixed Y Pre-offset in case of Full Range YCbCr as suggested by
>> Ville.
>>
>> Signed-off-by: Uma Shankar
>> Signed-off-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/i915/intel_sprite.c | 31
>> +--
>> 1 file changed, 29 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
>> b/drivers/gpu/drm/i915/intel_sprite.c
>> index 2913e89..c9c970f 100644
>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> @@ -433,6 +433,18 @@ int intel_plane_check_src_coordinates(struct
>intel_plane_state *plane_state)
>> 0x9EF8, 0x7800, 0xABF8,
>> 0x0, 0x7800, 0x7ED8,
>> },
>> +/*
>> + * BT.2020 full range YCbCr -> full range RGB
>> + * The matrix required is :
>> + * [1.000, 0.000, 1.474,
>> + * 1.000, -0.1645, -0.5713,
>> + * 1.000, 1.8814, 0.]
>> + */
>> +[DRM_COLOR_YCBCR_BT2020] = {
>> +0x7BC8, 0x7800, 0x0,
>> +0x8928, 0x7800, 0xAA88,
>> +0x0, 0x7800, 0x7F10,
>> +},
>> };
>>
>> /* Matrix for Limited Range to Full Range Conversion */ @@ -461,6
>> +473,18 @@ int intel_plane_check_src_coordinates(struct intel_plane_state
>*plane_state)
>> 0x, 0x7918, 0xADA8,
>> 0x0, 0x7918, 0x6870,
>> },
>> +/*
>> + * BT.2020 Limited range YCbCr -> full range RGB
>> + * The matrix required is :
>> + * [1.164, 0.000, 1.678,
>> + * 1.164, -0.1873, -0.6504,
>> + * 1.164, 2.1417, 0.]
>> + */
>> +[DRM_COLOR_YCBCR_BT2020] = {
>> +0x7D70, 0x7950, 0x0,
>> +0x8A68, 0x7950, 0xAC00,
>> +0x0, 0x7950, 0x6890,
>> +},
>> };
>> const u16 *csc;
>>
>> @@ -481,8 +505,11 @@ int intel_plane_check_src_coordinates(struct
>> intel_plane_state *plane_state)
>>
>> I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 0),
>>PREOFF_YUV_TO_RGB_HI);
>> -I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1),
>> - PREOFF_YUV_TO_RGB_ME);
>> +if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
>> +I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), 0);
>> +else
>> +I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1),
>> + PREOFF_YUV_TO_RGB_ME);
>
>I think this could probably be a separate patch since it affects
>BT.601/BT.709 as well. Oh, and the matrix coefficients for 601/709 seem
>similarly off
>as what you had in this patch originally. So I think we want yet another patch
>to fix
>those up. Just a bit surprised that even the current igts pass with those
>coefficients.
Sure, will split the same and resend. I agree BT601/709 has similar issue and
was planning to
send a fixup patch for the same. I will investigate what is going on with IGT
and how its
working fine.
>Anyways,
>Reviewed-by: Ville Syrjälä (you can keep this
>on both
>patch if you split).
Thanks Ville.
>PS. pls. cc me @linux.intel.com rather than @intel.com. I generally ignore
>patches
>going to the @intel.com address. Not that I really care one way or the other
>whether
>a patch was cc:d to me anyway.
Sure, will add your linux.intel.com while cc'ing you :)
Regards,
Uma Shankar
>
>> I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 2),
>>PREOFF_YUV_TO_RGB_LO);
>> I915_WRITE_FW(PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 0), 0x0);
>> --
>> 1.9.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>--
>Ville Syrjälä
>Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 08/11] drm/i915: Remove the unneeded AUX power ref from intel_dp_hpd_pulse()
On Thu, May 09, 2019 at 08:43:25PM +0300, Souza, Jose wrote:
> On Thu, 2019-05-09 at 20:34 +0300, Imre Deak wrote:
> > The power get/put was added in
> >
> > commit 1c767b339b39 ("drm/i915: take display port power domain in DP
> > HPD handler")
> > Author: Imre Deak
> > Date: Mon Aug 18 14:42:42 2014 +0300
> >
> > to account for the HW access in ibx_digital_port_connected(). This
> > latter call was in turn removed in
> >
> > commit 7d23e3c37bb3 ("drm/i915: Cleaning up intel_dp_hpd_pulse")
> > Author: Shubhangi Shrivastava
> > Date: Wed Mar 30 18:05:23 2016 +0530
> >
> > after which we didn't actually need the power reference.
> >
> > One way we are accessing the HW during HPD pulse handling is via DP
> > AUX
> > transfers, but the transfer function takes its own reference, so
> > doesn't
> > need the reference in intel_dp_hpd_pulse().
>
>
>
> The problem of removing that reference is that every aux transfer will
> take a little bit more of time because it will need to wait the aux
> power well to be enabled/disabled, taking one reference before hand
> save us that.
That is solved by disabling the power with a delay. But we could only
claim that there would be any problem (even in the lack of the delayed
disabling) with actual numbers for the enabling/disabling delay. Please
check the discussion on patch 4 for more details.
>
> >
> > The other spot is in
> >
> > intel_psr_short_pulse()->intel_psr_disable_locked()
> >
> > but that can only happen when the panel is enabled with the
> > corresponding modeset already holding the required power reference.
> >
> > v2:
> > - Remove the unneeded power get/put from intel_psr_disable_locked().
> > (Ville)
> > - Checkpatch commit quoting format fix in the commit log.
> >
> > Cc: Ville Syrjala
> > Cc: Rodrigo Vivi
> > Cc: José Roberto de Souza
> > Signed-off-by: Imre Deak
> > Reviewed-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 20
> > 1 file changed, 4 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 553071812f69..8a91b453b2e9 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -6302,9 +6302,6 @@ enum irqreturn
> > intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool
> > long_hpd)
> > {
> > struct intel_dp *intel_dp = _dig_port->dp;
> > - struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > - enum irqreturn ret = IRQ_NONE;
> > - intel_wakeref_t wakeref;
> >
> > if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP)
> > {
> > /*
> > @@ -6327,9 +6324,6 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> > return IRQ_NONE;
> > }
> >
> > - wakeref = intel_display_power_get(dev_priv,
> > - intel_aux_power_domain(intel_
> > dig_port));
> > -
> > if (intel_dp->is_mst) {
> > if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
> > /*
> > @@ -6341,7 +6335,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> > intel_dp->is_mst = false;
> > drm_dp_mst_topology_mgr_set_mst(_dp-
> > >mst_mgr,
> > intel_dp-
> > >is_mst);
> > - goto put_power;
> > +
> > + return IRQ_NONE;
> > }
> > }
> >
> > @@ -6351,17 +6346,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> > handled = intel_dp_short_pulse(intel_dp);
> >
> > if (!handled)
> > - goto put_power;
> > + return IRQ_NONE;
> > }
> >
> > - ret = IRQ_HANDLED;
> > -
> > -put_power:
> > - intel_display_power_put(dev_priv,
> > - intel_aux_power_domain(intel_dig_port),
> > - wakeref);
> > -
> > - return ret;
> > + return IRQ_HANDLED;
> > }
> >
> > /* check the VBT to see whether the eDP is on another port */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 08/11] drm/i915: Remove the unneeded AUX power ref from intel_dp_hpd_pulse()
On Thu, 2019-05-09 at 20:34 +0300, Imre Deak wrote:
> The power get/put was added in
>
> commit 1c767b339b39 ("drm/i915: take display port power domain in DP
> HPD handler")
> Author: Imre Deak
> Date: Mon Aug 18 14:42:42 2014 +0300
>
> to account for the HW access in ibx_digital_port_connected(). This
> latter call was in turn removed in
>
> commit 7d23e3c37bb3 ("drm/i915: Cleaning up intel_dp_hpd_pulse")
> Author: Shubhangi Shrivastava
> Date: Wed Mar 30 18:05:23 2016 +0530
>
> after which we didn't actually need the power reference.
>
> One way we are accessing the HW during HPD pulse handling is via DP
> AUX
> transfers, but the transfer function takes its own reference, so
> doesn't
> need the reference in intel_dp_hpd_pulse().
The problem of removing that reference is that every aux transfer will
take a little bit more of time because it will need to wait the aux
power well to be enabled/disabled, taking one reference before hand
save us that.
>
> The other spot is in
>
> intel_psr_short_pulse()->intel_psr_disable_locked()
>
> but that can only happen when the panel is enabled with the
> corresponding modeset already holding the required power reference.
>
> v2:
> - Remove the unneeded power get/put from intel_psr_disable_locked().
> (Ville)
> - Checkpatch commit quoting format fix in the commit log.
>
> Cc: Ville Syrjala
> Cc: Rodrigo Vivi
> Cc: José Roberto de Souza
> Signed-off-by: Imre Deak
> Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 20
> 1 file changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 553071812f69..8a91b453b2e9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6302,9 +6302,6 @@ enum irqreturn
> intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool
> long_hpd)
> {
> struct intel_dp *intel_dp = _dig_port->dp;
> - struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - enum irqreturn ret = IRQ_NONE;
> - intel_wakeref_t wakeref;
>
> if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP)
> {
> /*
> @@ -6327,9 +6324,6 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> return IRQ_NONE;
> }
>
> - wakeref = intel_display_power_get(dev_priv,
> - intel_aux_power_domain(intel_
> dig_port));
> -
> if (intel_dp->is_mst) {
> if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
> /*
> @@ -6341,7 +6335,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> intel_dp->is_mst = false;
> drm_dp_mst_topology_mgr_set_mst(_dp-
> >mst_mgr,
> intel_dp-
> >is_mst);
> - goto put_power;
> +
> + return IRQ_NONE;
> }
> }
>
> @@ -6351,17 +6346,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> handled = intel_dp_short_pulse(intel_dp);
>
> if (!handled)
> - goto put_power;
> + return IRQ_NONE;
> }
>
> - ret = IRQ_HANDLED;
> -
> -put_power:
> - intel_display_power_put(dev_priv,
> - intel_aux_power_domain(intel_dig_port),
> - wakeref);
> -
> - return ret;
> + return IRQ_HANDLED;
> }
>
> /* check the VBT to see whether the eDP is on another port */
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
[Intel-gfx] [PATCH v3 04/11] drm/i915: Add support for asynchronous display power disabling
By disabling a power domain asynchronously we can restrict holding a
reference on that power domain to the actual code sequence that
requires the power to be on for the HW access it's doing, by also
avoiding unneeded on-off-on togglings of the power domain (since the
disabling happens with a delay).
One benefit is potential power saving due to the following two reasons:
1. The fact that we will now be holding the reference only for the
necessary duration by the end of the patchset. While simply not
delaying the disabling has the same benefit, it has the problem that
frequent on-off-on power switching has its own power cost (see the 2.
point below) and the debug trace for power well on/off events will
cause a lot of dmesg spam (see details about this further below).
2. Avoiding the power cost of freuqent on-off-on power switching. This
requires us to find the optimal disabling delay based on the measured
power cost of on->off and off->on switching of each power well vs.
the power of keeping the given power well on.
In this patchset I'm not providing this optimal delay for two
reasons:
a) I don't have the means yet to perform the measurement (with high
enough signal-to-noise ratio, or with the help of an energy
counter that takes switching into account). I'm currently looking
for a way to measure this.
b) Before reducing the disabling delay we need an alternative way for
debug tracing powerwell on/off events. Simply avoiding/throttling
the debug messages is not a solution, see further below.
Note that even in the case where we can't measure any considerable
power cost of frequent on-off switching of powerwells, it still would
make sense to do the disabling asynchronously (with 0 delay) to avoid
blocking on the disabling. On VLV I measured this disabling time
overhead to be 1ms on average with a worst case of 4ms.
In the case of the AUX power domains on ICL we would also need to keep
the sequence where we hold the power reference short, the way it would
be by the end of this patchset where we hold it only for the actual AUX
transfer. Anything else would make the locking we need for ICL TypeC
ports (whenever we hold a reference on any AUX power domain) rather
problematic, adding for instance unnecessary lockdep dependencies to
the required TypeC port lock.
I chose the disabling delay to be 100msec for now to avoid the unneeded
toggling (and so not to introduce dmesg spamming) in the DP MST sideband
signaling code. We could optimize this delay later, once we have the
means to measure the switching power cost (see above).
Note that simply removing/throttling the debug tracing for power well
on/off events is not a solution. We need to know the exact spots of
these events and cannot rely only on incorrect register accesses caught
(due to not holding a wakeref at the time of access). Incorrect
powerwell enabling/disabling could lead to other problems, for instance
we need to keep certain powerwells enabled for the duration of modesets
and AUX transfers.
v2:
- Clarify the commit log parts about power cost measurement and the
problem of simply removing/throttling debug tracing. (Chris)
- Optimize out local wakeref vars at intel_runtime_pm_put_raw() and
intel_display_power_put_async() call sites if
CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n. (Chris)
- Rebased on v2 of the wakeref w/o power-on guarantee patch.
- Add missing docbook headers.
v3:
- Checkpatch spelling/missing-empty-line fix.
Cc: Chris Wilson
Cc: Ville Syrjala
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 363 +++-
drivers/gpu/drm/i915/intel_runtime_pm.h | 8 +
3 files changed, 369 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d0257808734c..5801f5407589 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -834,6 +834,11 @@ struct i915_power_domains {
struct mutex lock;
int domain_use_count[POWER_DOMAIN_NUM];
+
+ struct delayed_work async_put_work;
+ intel_wakeref_t async_put_wakeref;
+ u64 async_put_domains[2];
+
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 2cf4943df2e7..2ed6fb33856a 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -60,6 +60,19 @@
* present for a given platform.
*/
+static intel_wakeref_t intel_runtime_pm_get_raw(struct drm_i915_private *i915);
+static void
+__intel_runtime_pm_put(struct drm_i915_private *i915, intel_wakeref_t wref,
+ bool wakelock);
+
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
+static void
+intel_runtime_pm_put_raw(struct drm_i915_private *i915, intel_wakeref_t wref);
+#else
[Intel-gfx] [PATCH v3 00/11] drm/i915: Add support for asynchronous display power disabling
This is v3 of [1] addressing the comments from Chris and Ville and fixing some checkpatch errors. [1] https://patchwork.freedesktop.org/series/60242/ Cc: Ville Syrjala Cc: Chris Wilson Cc: Rodrigo Vivi Cc: José Roberto de Souza Imre Deak (11): drm/i915: Add support for tracking wakerefs w/o power-on guarantee drm/i915: Force printing wakeref tacking during pm_cleanup drm/i915: Verify power domains state during suspend in all cases drm/i915: Add support for asynchronous display power disabling drm/i915: Disable power asynchronously during DP AUX transfers drm/i915: WARN for eDP encoders in intel_dp_detect_dpcd() drm/i915: Remove the unneeded AUX power ref from intel_dp_detect() drm/i915: Remove the unneeded AUX power ref from intel_dp_hpd_pulse() drm/i915: Replace use of PLLS power domain with DISPLAY_CORE domain drm/i915: Avoid taking the PPS lock for non-eDP/VLV/CHV drm/i915: Assert that TypeC ports are not used for eDP drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_utils.h | 4 +- drivers/gpu/drm/i915/intel_display.c| 2 +- drivers/gpu/drm/i915/intel_display.h| 2 +- drivers/gpu/drm/i915/intel_dp.c | 83 ++-- drivers/gpu/drm/i915/intel_dpll_mgr.c | 36 +- drivers/gpu/drm/i915/intel_drv.h| 52 ++- drivers/gpu/drm/i915/intel_runtime_pm.c | 598 +--- drivers/gpu/drm/i915/intel_runtime_pm.h | 13 + 9 files changed, 663 insertions(+), 132 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 02/11] drm/i915: Force printing wakeref tacking during pm_cleanup
Make sure we print and drop the wakeref tracking info during pm_cleanup
even if there are wakeref holders (either raw-wakeref or wakelock
holders). Dropping the wakeref tracking means that a late put on the ref
will WARN since the wakeref will be unknown, but that is rightly so,
since the put is late and we want to catch that case.
Cc: Chris Wilson
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 75 ++---
1 file changed, 54 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 53a172094c6a..18152978375a 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -233,31 +233,60 @@ __print_intel_runtime_pm_wakeref(struct drm_printer *p,
}
static noinline void
-__intel_wakeref_dec_and_check_tracking(struct drm_i915_private *i915)
+__untrack_all_wakerefs(struct intel_runtime_pm_debug *debug,
+ struct intel_runtime_pm_debug *saved)
+{
+ *saved = *debug;
+
+ debug->owners = NULL;
+ debug->count = 0;
+ debug->last_release = __save_depot_stack();
+}
+
+static void
+dump_and_free_wakeref_tracking(struct intel_runtime_pm_debug *debug)
{
- struct i915_runtime_pm *rpm = >runtime_pm;
- struct intel_runtime_pm_debug dbg = {};
struct drm_printer p;
- unsigned long flags;
- if (atomic_dec_and_lock_irqsave(>wakeref_count,
- >debug.lock,
- flags)) {
- dbg = rpm->debug;
-
- rpm->debug.owners = NULL;
- rpm->debug.count = 0;
- rpm->debug.last_release = __save_depot_stack();
-
- spin_unlock_irqrestore(>debug.lock, flags);
- }
- if (!dbg.count)
+ if (!debug->count)
return;
p = drm_debug_printer("i915");
- __print_intel_runtime_pm_wakeref(, );
+ __print_intel_runtime_pm_wakeref(, debug);
- kfree(dbg.owners);
+ kfree(debug->owners);
+}
+
+static noinline void
+__intel_wakeref_dec_and_check_tracking(struct drm_i915_private *i915)
+{
+ struct i915_runtime_pm *rpm = >runtime_pm;
+ struct intel_runtime_pm_debug dbg = {};
+ unsigned long flags;
+
+ if (!atomic_dec_and_lock_irqsave(>wakeref_count,
+>debug.lock,
+flags))
+ return;
+
+ __untrack_all_wakerefs(>debug, );
+ spin_unlock_irqrestore(>debug.lock, flags);
+
+ dump_and_free_wakeref_tracking();
+}
+
+static noinline void
+untrack_all_intel_runtime_pm_wakerefs(struct drm_i915_private *i915)
+{
+ struct i915_runtime_pm *rpm = >runtime_pm;
+ struct intel_runtime_pm_debug dbg = {};
+ unsigned long flags;
+
+ spin_lock_irqsave(>debug.lock, flags);
+ __untrack_all_wakerefs(>debug, );
+ spin_unlock_irqrestore(>debug.lock, flags);
+
+ dump_and_free_wakeref_tracking();
}
void print_intel_runtime_pm_wakeref(struct drm_i915_private *i915,
@@ -321,6 +350,11 @@ __intel_wakeref_dec_and_check_tracking(struct
drm_i915_private *i915)
atomic_dec(>runtime_pm.wakeref_count);
}
+static void
+untrack_all_intel_runtime_pm_wakerefs(struct drm_i915_private *i915)
+{
+}
+
#endif
static void
@@ -4838,15 +4872,14 @@ void intel_runtime_pm_disable(struct drm_i915_private
*i915)
void intel_runtime_pm_cleanup(struct drm_i915_private *i915)
{
struct i915_runtime_pm *rpm = >runtime_pm;
- int count;
+ int count = atomic_read(>wakeref_count);
- count = atomic_fetch_inc(>wakeref_count); /* balance untrack */
WARN(count,
"i915 raw-wakerefs=%d wakelocks=%d on cleanup\n",
intel_rpm_raw_wakeref_count(count),
intel_rpm_wakelock_count(count));
- intel_runtime_pm_release(i915, false);
+ untrack_all_intel_runtime_pm_wakerefs(i915);
}
void intel_runtime_pm_init_early(struct drm_i915_private *i915)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 10/11] drm/i915: Avoid taking the PPS lock for non-eDP/VLV/CHV
On ICL we have to make sure that we enable the AUX power domain in a
controlled way (corresponding to the port's actual TypeC mode). Since
the PPS lock - which takes an AUX power ref - is only needed on
eDP on all platforms and eDP/DP on VLV/CHV avoid taking it in all
other cases.
v2:
- Clarify commit log about the condition for taking the PPS lock.
(Ville)
Cc: Ville Syrjala
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a91b453b2e9..52452155250f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6259,6 +6259,10 @@ void intel_dp_encoder_reset(struct drm_encoder *encoder)
intel_dp->reset_link_params = true;
+ if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
+ !intel_dp_is_edp(intel_dp))
+ return;
+
with_pps_lock(intel_dp, wakeref) {
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
intel_dp->active_pipe = vlv_active_pipe(intel_dp);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 09/11] drm/i915: Replace use of PLLS power domain with DISPLAY_CORE domain
There isn't a separate power domain specific to PLLs. When programming
them we require the same power domain to be enabled which is needed when
accessing other display core parts (not specific to any
pipe/port/transcoder). This corresponds to the DISPLAY_CORE domain added
previously in this patchset, so use that instead to save bits in the
power domain mask.
Cc: Ville Syrjala
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c| 2 +-
drivers/gpu/drm/i915/intel_display.h| 1 -
drivers/gpu/drm/i915/intel_dpll_mgr.c | 36 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 --
4 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 05177f37181b..5ecab1666704 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6363,7 +6363,7 @@ static u64 get_crtc_power_domains(struct drm_crtc *crtc,
mask |= BIT_ULL(POWER_DOMAIN_AUDIO);
if (crtc_state->shared_dpll)
- mask |= BIT_ULL(POWER_DOMAIN_PLLS);
+ mask |= BIT_ULL(POWER_DOMAIN_DISPLAY_CORE);
return mask;
}
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 7f3fafdfbd5f..41f2aa966abc 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -251,7 +251,6 @@ enum intel_display_power_domain {
POWER_DOMAIN_PORT_OTHER,
POWER_DOMAIN_VGA,
POWER_DOMAIN_AUDIO,
- POWER_DOMAIN_PLLS,
POWER_DOMAIN_AUX_A,
POWER_DOMAIN_AUX_B,
POWER_DOMAIN_AUX_C,
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index bf5e2541c35e..897d93537414 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -351,7 +351,7 @@ static bool ibx_pch_dpll_get_hw_state(struct
drm_i915_private *dev_priv,
u32 val;
wakeref = intel_display_power_get_if_enabled(dev_priv,
-POWER_DOMAIN_PLLS);
+POWER_DOMAIN_DISPLAY_CORE);
if (!wakeref)
return false;
@@ -360,7 +360,7 @@ static bool ibx_pch_dpll_get_hw_state(struct
drm_i915_private *dev_priv,
hw_state->fp0 = I915_READ(PCH_FP0(id));
hw_state->fp1 = I915_READ(PCH_FP1(id));
- intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS, wakeref);
+ intel_display_power_put(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref);
return val & DPLL_VCO_ENABLE;
}
@@ -519,14 +519,14 @@ static bool hsw_ddi_wrpll_get_hw_state(struct
drm_i915_private *dev_priv,
u32 val;
wakeref = intel_display_power_get_if_enabled(dev_priv,
-POWER_DOMAIN_PLLS);
+POWER_DOMAIN_DISPLAY_CORE);
if (!wakeref)
return false;
val = I915_READ(WRPLL_CTL(id));
hw_state->wrpll = val;
- intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS, wakeref);
+ intel_display_power_put(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref);
return val & WRPLL_PLL_ENABLE;
}
@@ -539,14 +539,14 @@ static bool hsw_ddi_spll_get_hw_state(struct
drm_i915_private *dev_priv,
u32 val;
wakeref = intel_display_power_get_if_enabled(dev_priv,
-POWER_DOMAIN_PLLS);
+POWER_DOMAIN_DISPLAY_CORE);
if (!wakeref)
return false;
val = I915_READ(SPLL_CTL);
hw_state->spll = val;
- intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS, wakeref);
+ intel_display_power_put(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref);
return val & SPLL_PLL_ENABLE;
}
@@ -1004,7 +1004,7 @@ static bool skl_ddi_pll_get_hw_state(struct
drm_i915_private *dev_priv,
bool ret;
wakeref = intel_display_power_get_if_enabled(dev_priv,
-POWER_DOMAIN_PLLS);
+POWER_DOMAIN_DISPLAY_CORE);
if (!wakeref)
return false;
@@ -1025,7 +1025,7 @@ static bool skl_ddi_pll_get_hw_state(struct
drm_i915_private *dev_priv,
ret = true;
out:
- intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS, wakeref);
+ intel_display_power_put(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref);
return ret;
}
@@ -1041,7 +1041,7 @@ static bool skl_ddi_dpll0_get_hw_state(struct
drm_i915_private *dev_priv,
bool ret;
wakeref = intel_display_power_get_if_enabled(dev_priv,
-POWER_DOMAIN_PLLS);
+
[Intel-gfx] [PATCH v3 06/11] drm/i915: WARN for eDP encoders in intel_dp_detect_dpcd()
We are not calling this function for eDP, so add an early assert about this for clarity. Cc: Ville Syrjälä Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 700ceacb82e6..1e011998e9d5 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4844,15 +4844,15 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp) u8 *dpcd = intel_dp->dpcd; u8 type; + if (WARN_ON(intel_dp_is_edp(intel_dp))) + return connector_status_connected; + if (lspcon->active) lspcon_resume(lspcon); if (!intel_dp_get_dpcd(intel_dp)) return connector_status_disconnected; - if (intel_dp_is_edp(intel_dp)) - return connector_status_connected; - /* if there's no downstream port, we're done */ if (!drm_dp_is_branch(dpcd)) return connector_status_connected; -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 05/11] drm/i915: Disable power asynchronously during DP AUX transfers
In a follow-up patch we will restrict holding the reference on the AUX power domain to the AUX transfer function. To avoid the unnecessary on-off-on power togglings drop the reference asynchronously. There is no reason we couldn't do this in general and also put the reference asynchronously in pps_unlock(); but that's a separate change that can be done as a follow-up. Cc: Ville Syrjala Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 53cc4afea256..700ceacb82e6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1221,7 +1221,10 @@ 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]; u32 aux_clock_divider; - intel_wakeref_t wakeref; + enum intel_display_power_domain aux_domain = + intel_aux_power_domain(intel_dig_port); + intel_wakeref_t aux_wakeref; + intel_wakeref_t pps_wakeref; int i, ret, recv_bytes; int try, clock = 0; u32 status; @@ -1231,7 +1234,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp, for (i = 0; i < ARRAY_SIZE(ch_data); i++) ch_data[i] = intel_dp->aux_ch_data_reg(intel_dp, i); - wakeref = pps_lock(intel_dp); + aux_wakeref = intel_display_power_get(dev_priv, aux_domain); + pps_wakeref = pps_lock(intel_dp); /* * We will be called with VDD already enabled for dpcd/edid/oui reads. @@ -1377,7 +1381,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp, if (vdd) edp_panel_vdd_off(intel_dp, false); - pps_unlock(intel_dp, wakeref); + pps_unlock(intel_dp, pps_wakeref); + intel_display_power_put_async(dev_priv, aux_domain, aux_wakeref); return ret; } -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 01/11] drm/i915: Add support for tracking wakerefs w/o power-on guarantee
It's useful to track runtime PM refs that don't guarantee a device
power-on state to the rest of the driver. One such case is holding a
reference that will be put asynchronously, during which normal users
without their own reference shouldn't access the HW. A follow-up patch
will add support for disabling display power domains asynchronously
which needs this.
For this we can split wakeref_count into a low half-word tracking
all references (raw-wakerefs) and a high half-word tracking
references guaranteeing a power-on state (wakelocks).
Follow-up patches will make use of the API added here.
While at it add the missing docbook header for the unchecked
display-power and runtime_pm put functions.
No functional changes, except for printing leaked raw-wakerefs
and wakelocks separately in intel_runtime_pm_cleanup().
v2:
- Track raw wakerefs/wakelocks in the low/high half-word of
wakeref_count, instead of adding a new counter. (Chris)
v3:
- Add a struct_member(T, m) helper instead of open-coding it. (Chris)
- Checkpatch indentation formatting fix.
Cc: Chris Wilson
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_utils.h | 4 +-
drivers/gpu/drm/i915/intel_drv.h| 52 +++-
drivers/gpu/drm/i915/intel_runtime_pm.c | 152 ++--
3 files changed, 164 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index c849cfa7cb28..5c94c7ab4607 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -102,6 +102,8 @@
#define page_pack_bits(ptr, bits) ptr_pack_bits(ptr, bits, PAGE_SHIFT)
#define page_unpack_bits(ptr, bits) ptr_unpack_bits(ptr, bits, PAGE_SHIFT)
+#define struct_member(T, member) (((T *)0)->member)
+
#define ptr_offset(ptr, member) offsetof(typeof(*(ptr)), member)
#define fetch_and_zero(ptr) ({ \
@@ -118,7 +120,7 @@
*/
#define container_of_user(ptr, type, member) ({
\
void __user *__mptr = (void __user *)(ptr); \
- BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
+ BUILD_BUG_ON_MSG(!__same_type(*(ptr), struct_member(type, member)) && \
!__same_type(*(ptr), void),\
"pointer type mismatch in container_of()");\
((type __user *)(__mptr - offsetof(type, member))); })
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 247893ed1543..5ad1256b2065 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1619,6 +1619,24 @@ unsigned int i9xx_plane_max_stride(struct intel_plane
*plane,
unsigned int rotation);
/* intel_runtime_pm.c */
+#define BITS_PER_WAKEREF \
+ BITS_PER_TYPE(struct_member(struct i915_runtime_pm, wakeref_count))
+#define INTEL_RPM_WAKELOCK_SHIFT (BITS_PER_WAKEREF / 2)
+#define INTEL_RPM_WAKELOCK_BIAS(1 << INTEL_RPM_WAKELOCK_SHIFT)
+#define INTEL_RPM_RAW_WAKEREF_MASK (INTEL_RPM_WAKELOCK_BIAS - 1)
+
+static inline int
+intel_rpm_raw_wakeref_count(int wakeref_count)
+{
+ return wakeref_count & INTEL_RPM_RAW_WAKEREF_MASK;
+}
+
+static inline int
+intel_rpm_wakelock_count(int wakeref_count)
+{
+ return wakeref_count >> INTEL_RPM_WAKELOCK_SHIFT;
+}
+
static inline void
assert_rpm_device_not_suspended(struct i915_runtime_pm *rpm)
{
@@ -1627,11 +1645,33 @@ assert_rpm_device_not_suspended(struct i915_runtime_pm
*rpm)
}
static inline void
-__assert_rpm_wakelock_held(struct i915_runtime_pm *rpm)
+assert_rpm_raw_wakeref_held(struct i915_runtime_pm *rpm, int wakeref_count)
{
assert_rpm_device_not_suspended(rpm);
- WARN_ONCE(!atomic_read(>wakeref_count),
- "RPM wakelock ref not held during HW access");
+ WARN_ONCE(!intel_rpm_raw_wakeref_count(wakeref_count),
+ "RPM raw-wakeref not held\n");
+}
+
+static inline void
+assert_rpm_wakelock_held(struct i915_runtime_pm *rpm, int wakeref_count)
+{
+ assert_rpm_raw_wakeref_held(rpm, wakeref_count);
+ WARN_ONCE(!intel_rpm_wakelock_count(wakeref_count),
+ "RPM wakelock ref not held during HW access\n");
+}
+
+static inline void
+assert_rpm_raw_wakeref_held(struct drm_i915_private *i915)
+{
+ struct i915_runtime_pm *rpm = >runtime_pm;
+
+ assert_rpm_raw_wakeref_held(rpm, atomic_read(>wakeref_count));
+}
+
+static inline void
+__assert_rpm_wakelock_held(struct i915_runtime_pm *rpm)
+{
+ assert_rpm_wakelock_held(rpm, atomic_read(>wakeref_count));
}
static inline void
@@ -1661,7 +1701,8 @@ assert_rpm_wakelock_held(struct drm_i915_private *i915)
static inline void
disable_rpm_wakeref_asserts(struct drm_i915_private *i915)
{
- atomic_inc(>runtime_pm.wakeref_count);
+
[Intel-gfx] [PATCH v3 03/11] drm/i915: Verify power domains state during suspend in all cases
There is no reason why we couldn't verify the power domains state during
suspend in all cases, so do that. I overlooked this when originally
adding the check.
Cc: Chris Wilson
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 18152978375a..2cf4943df2e7 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -4528,10 +4528,10 @@ void intel_power_domains_suspend(struct
drm_i915_private *i915,
* Even if power well support was disabled we still want to disable
* power wells if power domains must be deinitialized for suspend.
*/
- if (!i915_modparams.disable_power_well) {
+ if (!i915_modparams.disable_power_well)
intel_display_power_put_unchecked(i915, POWER_DOMAIN_INIT);
- intel_power_domains_verify_state(i915);
- }
+
+ intel_power_domains_verify_state(i915);
if (INTEL_GEN(i915) >= 11)
icl_display_core_uninit(i915);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 11/11] drm/i915: Assert that TypeC ports are not used for eDP
Add an assert that we don't use TypeC ports for eDP. That may in theory
be possible on TypeC legacy ports, but I'm not sure if that's a
practical scenario, so let's deal with that only if there's a use case.
Adding support for that wouldn't be too difficult, since TypeC mode
switching is not possible on TypeC legacy ports.
Cc: Ville Syrjala
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 52452155250f..e3e719c04440 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -7206,10 +7206,16 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
intel_dp->DP = I915_READ(intel_dp->output_reg);
intel_dp->attached_connector = intel_connector;
- if (intel_dp_is_port_edp(dev_priv, port))
+ if (intel_dp_is_port_edp(dev_priv, port)) {
+ /*
+* Currently we don't support eDP on TypeC ports, although in
+* theory it could work on TypeC legacy ports.
+*/
+ WARN_ON(intel_port_is_tc(dev_priv, port));
type = DRM_MODE_CONNECTOR_eDP;
- else
+ } else {
type = DRM_MODE_CONNECTOR_DisplayPort;
+ }
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
intel_dp->active_pipe = vlv_active_pipe(intel_dp);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 07/11] drm/i915: Remove the unneeded AUX power ref from intel_dp_detect()
We don't need the AUX power for the whole duration of the detect, only
when we're doing AUX transfers. The AUX transfer function takes its own
reference on the AUX power domain already. The two places during detect
which access display core registers (not specific to a
pipe/port/transcoder) only need the power domain that is required for
that access. That power domain is equivalent to the device global power
domain on most platforms (enabled whenever we hold a runtime PM
reference) except on CHV/VLV where it's equivalent to the display power
well.
Add a new power domain that reflects the above, and use this at the two
spots accessing registers. With that we can avoid taking the AUX
reference for the whole duration of the detect function.
Put the domains asynchronously to avoid the unneeded on-off-on toggling.
Also adapt the idea from with_intel_runtime_pm et al. for making it easy
to write short sequences where a display power ref is needed.
v2: (Ville)
- Add with_intel_display_power() helper to simplify things.
- s/bool res/bool is_connected/
Cc: Ville Syrjala
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.h| 1 +
drivers/gpu/drm/i915/intel_dp.c | 32 +++--
drivers/gpu/drm/i915/intel_runtime_pm.c | 4
drivers/gpu/drm/i915/intel_runtime_pm.h | 5
4 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 1b6f5a71184d..7f3fafdfbd5f 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -220,6 +220,7 @@ enum aux_ch {
#define aux_ch_name(a) ((a) + 'A')
enum intel_display_power_domain {
+ POWER_DOMAIN_DISPLAY_CORE,
POWER_DOMAIN_PIPE_A,
POWER_DOMAIN_PIPE_B,
POWER_DOMAIN_PIPE_C,
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1e011998e9d5..553071812f69 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -216,14 +216,16 @@ static int intel_dp_get_fia_supported_lane_count(struct
intel_dp *intel_dp)
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
+ intel_wakeref_t wakeref;
u32 lane_info;
if (tc_port == PORT_TC_NONE || dig_port->tc_type != TC_PORT_TYPEC)
return 4;
- lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
-DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
- DP_LANE_ASSIGNMENT_SHIFT(tc_port);
+ with_intel_display_power(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref)
+ lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
+DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
+ DP_LANE_ASSIGNMENT_SHIFT(tc_port);
switch (lane_info) {
default:
@@ -5294,7 +5296,7 @@ static bool icl_digital_port_connected(struct
intel_encoder *encoder)
*
* Return %true if port is connected, %false otherwise.
*/
-bool intel_digital_port_connected(struct intel_encoder *encoder)
+static bool __intel_digital_port_connected(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
@@ -5324,6 +5326,18 @@ bool intel_digital_port_connected(struct intel_encoder
*encoder)
return false;
}
+bool intel_digital_port_connected(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ intel_wakeref_t wakeref;
+ bool is_connected;
+
+ with_intel_display_power(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref)
+ is_connected = __intel_digital_port_connected(encoder);
+
+ return is_connected;
+}
+
static struct edid *
intel_dp_get_edid(struct intel_dp *intel_dp)
{
@@ -5377,16 +5391,11 @@ intel_dp_detect(struct drm_connector *connector,
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = _port->base;
enum drm_connector_status status;
- enum intel_display_power_domain aux_domain =
- intel_aux_power_domain(dig_port);
- intel_wakeref_t wakeref;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
WARN_ON(!drm_modeset_is_locked(_priv->drm.mode_config.connection_mutex));
- wakeref = intel_display_power_get(dev_priv, aux_domain);
-
/* Can't disconnect eDP */
if (intel_dp_is_edp(intel_dp))
status = edp_detect(intel_dp);
@@ -5450,10 +5459,8 @@ intel_dp_detect(struct drm_connector *connector,
int ret;
ret = intel_dp_retrain_link(encoder, ctx);
- if (ret) {
- intel_display_power_put(dev_priv, aux_domain,
[Intel-gfx] [PATCH v3 08/11] drm/i915: Remove the unneeded AUX power ref from intel_dp_hpd_pulse()
The power get/put was added in
commit 1c767b339b39 ("drm/i915: take display port power domain in DP HPD
handler")
Author: Imre Deak
Date: Mon Aug 18 14:42:42 2014 +0300
to account for the HW access in ibx_digital_port_connected(). This
latter call was in turn removed in
commit 7d23e3c37bb3 ("drm/i915: Cleaning up intel_dp_hpd_pulse")
Author: Shubhangi Shrivastava
Date: Wed Mar 30 18:05:23 2016 +0530
after which we didn't actually need the power reference.
One way we are accessing the HW during HPD pulse handling is via DP AUX
transfers, but the transfer function takes its own reference, so doesn't
need the reference in intel_dp_hpd_pulse().
The other spot is in
intel_psr_short_pulse()->intel_psr_disable_locked()
but that can only happen when the panel is enabled with the
corresponding modeset already holding the required power reference.
v2:
- Remove the unneeded power get/put from intel_psr_disable_locked().
(Ville)
- Checkpatch commit quoting format fix in the commit log.
Cc: Ville Syrjala
Cc: Rodrigo Vivi
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 553071812f69..8a91b453b2e9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6302,9 +6302,6 @@ enum irqreturn
intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
{
struct intel_dp *intel_dp = _dig_port->dp;
- struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- enum irqreturn ret = IRQ_NONE;
- intel_wakeref_t wakeref;
if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
/*
@@ -6327,9 +6324,6 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
return IRQ_NONE;
}
- wakeref = intel_display_power_get(dev_priv,
-
intel_aux_power_domain(intel_dig_port));
-
if (intel_dp->is_mst) {
if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
/*
@@ -6341,7 +6335,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
intel_dp->is_mst = false;
drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
intel_dp->is_mst);
- goto put_power;
+
+ return IRQ_NONE;
}
}
@@ -6351,17 +6346,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
handled = intel_dp_short_pulse(intel_dp);
if (!handled)
- goto put_power;
+ return IRQ_NONE;
}
- ret = IRQ_HANDLED;
-
-put_power:
- intel_display_power_put(dev_priv,
- intel_aux_power_domain(intel_dig_port),
- wakeref);
-
- return ret;
+ return IRQ_HANDLED;
}
/* check the VBT to see whether the eDP is on another port */
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 0/5] cgroup support for GPU devices
Hello, On Tue, May 07, 2019 at 12:50:50PM -0700, Welty, Brian wrote: > There might still be merit in having a 'device mem' cgroup controller. > The resource model at least is then no longer mixed up with host memory. > RDMA community seemed to have some interest in a common controller at > least for device memory aspects. > Thoughts on this? I believe could still reuse the 'struct mem_cgroup' data > structure. There should be some opportunity to reuse charging APIs and > have some nice integration with HMM for charging to device memory, depending > on backing store. Library-ish sharing is fine but in terms of interface, I think it'd be better to keep them separate at least for now. Down the line maybe these resources will interact with each other in a more integrated way but I don't think it's a good idea to try to design and implement resource models for something like that preemptively. Thanks. -- tejun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v3
On Thu, May 9, 2019 at 4:56 PM Petr Mladek wrote:
>
> On Thu 2019-05-09 14:09:03, Daniel Vetter wrote:
> > console_trylock, called from within printk, can be called from pretty
> > much anywhere. Including try_to_wake_up. Note that this isn't common,
> > usually the box is in pretty bad shape at that point already. But it
> > really doesn't help when then lockdep jumps in and spams the logs,
> > potentially obscuring the real backtrace we're really interested in.
> > One case I've seen (slightly simplified backtrace):
> >
> > Call Trace:
> >
> > console_trylock+0xe/0x60
> > vprintk_emit+0xf1/0x320
> > printk+0x4d/0x69
> > __warn_printk+0x46/0x90
> > native_smp_send_reschedule+0x2f/0x40
> > check_preempt_curr+0x81/0xa0
> > ttwu_do_wakeup+0x14/0x220
> > try_to_wake_up+0x218/0x5f0
> > pollwake+0x6f/0x90
> > credit_entropy_bits+0x204/0x310
> > add_interrupt_randomness+0x18f/0x210
> > handle_irq+0x67/0x160
> > do_IRQ+0x5e/0x130
> > common_interrupt+0xf/0xf
> >
> >
> > This alone isn't a problem, but the spinlock in the semaphore is also
> > still held while waking up waiters (up() -> __up() -> try_to_wake_up()
> > callchain), which then closes the runqueue vs. semaphore.lock loop,
> > and upsets lockdep, which issues a circular locking splat to dmesg.
> > Worse it upsets developers, since we don't want to spam dmesg with
> > clutter when the machine is dying already.
> >
> > Fix this by creating a prinkt_safe_up() which calls wake_up_process
> > outside of the spinlock. This isn't correct in full generality, but
> > good enough for console_lock:
> >
> > - console_lock doesn't use interruptible or killable or timeout down()
> > calls, hence an up() is the only thing that can wake up a process.
> > Hence the process can't get woken and killed and reaped while we try
> > to wake it up too.
> >
> > - semaphore.c always updates the waiter list while under the spinlock,
> > so there's no other races. Specifically another process that races
> > with a quick console_lock/unlock while we've dropped the spinlock
> > already won't see our own waiter.
> >
> > Note that we only have to break the recursion for the semaphore.lock
> > spinlock of the console_lock. Recursion within various scheduler
> > related locks is already prevented by the printk_safe_enter/exit pair
> > in __up_console_sem().
>
> This is not fully true. printk_safe() helps only when
> the first try_to_wake_up() is called from printk_safe() context.
>
> > --- a/kernel/locking/semaphore.c
> > +++ b/kernel/locking/semaphore.c
> > @@ -197,6 +197,37 @@ struct semaphore_waiter {
> > bool up;
> > };
> >
> > +/**
> > + * printk_safe_up - release the semaphore in console_unlock
> > + * @sem: the semaphore to release
> > + *
> > + * Release the semaphore. Unlike mutexes, up() may be called from any
> > + * context and even by tasks which have never called down().
> > + *
> > + * NOTE: This is a special version of up() for console_unlock only. It is
> > only
> > + * safe if there are no killable, interruptible or timing out down() calls.
> > + */
> > +void printk_safe_up(struct semaphore *sem)
> > +{
> > + unsigned long flags;
> > + struct semaphore_waiter *waiter = NULL;
> > +
> > + raw_spin_lock_irqsave(>lock, flags);
> > + if (likely(list_empty(>wait_list))) {
> > + sem->count++;
> > + } else {
> > + waiter = list_first_entry(>wait_list,
> > + struct semaphore_waiter, list);
> > + list_del(>list);
> > + waiter->up = true;
> > + }
> > + raw_spin_unlock_irqrestore(>lock, flags);
> > +
> > + if (waiter) /* protected by being sole wake source */
> > + wake_up_process(waiter->task);
>
> I still do not see how this could help. Let's take the above
> backtrace as example:
>
>
>console_trylock+0xe/0x60
>vprintk_emit+0xf1/0x320
>printk+0x4d/0x69
>__warn_printk+0x46/0x90
>native_smp_send_reschedule +0x2f/0x40
>check_preempt_curr+0x81/0xa0
>ttwu_do_wakeup+0x14/0x220
>try_to_wake_up+0x218/0x5f0
>pollwake+0x6f/0x90
>credit_entropy_bits+0x204/0x310
>add_interrupt_randomness+0x18f/0x210
>handle_irq+0x67/0x160
>do_IRQ+0x5e/0x130
>common_interrupt+0xf/0xf
>
>
> We have the following chain of calls:
>
> + do_IRQ()
> ...
> + try_to_wake_up()# takes p->pi_lock
> + ttwu_remote() # takes rq lock
> + ttwu_do_wakeup()
> + check_preempt_curr()
> + native_smp_send_reschedule()
> + __warn_printk()
> + printk()
> + vprintk_emit()
> + console_trylock() # success
> + console_unlock()
> + up_console_sem()
> + up() # wait list in not empty
> + __up()
> + wake_up_process()
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case (rev2)
== Series Details == Series: drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case (rev2) URL : https://patchwork.freedesktop.org/series/60473/ State : success == Summary == CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12994 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/ Known issues Here are the changes found in Patchwork_12994 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-kbl-7500u: [DMESG-WARN][1] ([fdo#105128] / [fdo#107139]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html [fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128 [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139 Participating hosts (49 -> 44) -- Additional (1): fi-blb-e6850 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * Linux: CI_DRM_6072 -> Patchwork_12994 CI_DRM_6072: 645586708589c3d2ac81114595e875cdfbbff385 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4976: b1d91d0228db999145405e529952ca49bab7f706 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12994: 051e3d86d174b71f01404b2afb895e4ad89d7668 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 051e3d86d174 drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12994/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
On Thu, May 09, 2019 at 09:57:19PM +0530, Uma Shankar wrote:
> Currently input csc for YCbCR to RGB conversion handles only
> BT601 and Bt709. Extending it to support BT2020 as well.
>
> v2: Fixed the co-efficients for LR to FR conversion,
> as suggested by Ville.
>
> v3: Fixed Y Pre-offset in case of Full Range YCbCr as suggested
> by Ville.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 31 +--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 2913e89..c9c970f 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -433,6 +433,18 @@ int intel_plane_check_src_coordinates(struct
> intel_plane_state *plane_state)
> 0x9EF8, 0x7800, 0xABF8,
> 0x0, 0x7800, 0x7ED8,
> },
> + /*
> + * BT.2020 full range YCbCr -> full range RGB
> + * The matrix required is :
> + * [1.000, 0.000, 1.474,
> + * 1.000, -0.1645, -0.5713,
> + * 1.000, 1.8814, 0.]
> + */
> + [DRM_COLOR_YCBCR_BT2020] = {
> + 0x7BC8, 0x7800, 0x0,
> + 0x8928, 0x7800, 0xAA88,
> + 0x0, 0x7800, 0x7F10,
> + },
> };
>
> /* Matrix for Limited Range to Full Range Conversion */
> @@ -461,6 +473,18 @@ int intel_plane_check_src_coordinates(struct
> intel_plane_state *plane_state)
> 0x, 0x7918, 0xADA8,
> 0x0, 0x7918, 0x6870,
> },
> + /*
> + * BT.2020 Limited range YCbCr -> full range RGB
> + * The matrix required is :
> + * [1.164, 0.000, 1.678,
> + * 1.164, -0.1873, -0.6504,
> + * 1.164, 2.1417, 0.]
> + */
> + [DRM_COLOR_YCBCR_BT2020] = {
> + 0x7D70, 0x7950, 0x0,
> + 0x8A68, 0x7950, 0xAC00,
> + 0x0, 0x7950, 0x6890,
> + },
> };
> const u16 *csc;
>
> @@ -481,8 +505,11 @@ int intel_plane_check_src_coordinates(struct
> intel_plane_state *plane_state)
>
> I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 0),
> PREOFF_YUV_TO_RGB_HI);
> - I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1),
> - PREOFF_YUV_TO_RGB_ME);
> + if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
> + I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), 0);
> + else
> + I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1),
> + PREOFF_YUV_TO_RGB_ME);
I think this could probably be a separate patch since it affects
BT.601/BT.709 as well. Oh, and the matrix coefficients for 601/709 seem
similarly off as what you had in this patch originally. So I think we
want yet another patch to fix those up. Just a bit surprised that even
the current igts pass with those coefficients.
Anyways,
Reviewed-by: Ville Syrjälä
(you can keep this on both patch if you split).
PS. pls. cc me @linux.intel.com rather than @intel.com. I generally
ignore patches going to the @intel.com address. Not that I really
care one way or the other whether a patch was cc:d to me anyway.
> I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 2),
> PREOFF_YUV_TO_RGB_LO);
> I915_WRITE_FW(PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 0), 0x0);
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/11] drm/i915: Add support for asynchronous display power disabling
On Thu, May 09, 2019 at 09:19:43AM +0300, Imre Deak wrote: > This patchset is v2 of [1]. The main change is the rework of patch 1 > based on Chris' feedback. > > Cc: Ville Syrjala > Cc: Chris Wilson > Cc: Rodrigo Vivi > Cc: José Roberto de Souza > > [1] https://patchwork.freedesktop.org/series/60242/ > > Imre Deak (11): > drm/i915: Add support for tracking wakerefs w/o power-on guarantee > drm/i915: Force printing wakeref tacking during pm_cleanup > drm/i915: Verify power domains state during suspend in all cases > drm/i915: Add support for asynchronous display power disabling > drm/i915: Disable power asynchronously during DP AUX transfers > drm/i915: WARN for eDP encoders in intel_dp_detect_dpcd() > drm/i915: Remove the unneeded AUX power ref from intel_dp_detect() > drm/i915: Remove the unneeded AUX power ref from intel_dp_hpd_pulse() > drm/i915: Replace use of PLLS power domain with DISPLAY_CORE domain > drm/i915: Avoid taking the PPS lock for non-eDP/VLV/CHV > drm/i915: Assert that TypeC ports are not used for eDP I trust Chris scrutinized the wakeref stuff sufficiently so I didn't pay all that much attention to those patches. Patches 5-11 lgtm. Reviewed-by: Ville Syrjälä > > drivers/gpu/drm/i915/i915_drv.h | 5 + > drivers/gpu/drm/i915/intel_display.c| 2 +- > drivers/gpu/drm/i915/intel_display.h| 2 +- > drivers/gpu/drm/i915/intel_dp.c | 83 ++-- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 36 +- > drivers/gpu/drm/i915/intel_drv.h| 52 ++- > drivers/gpu/drm/i915/intel_psr.c| 6 + > drivers/gpu/drm/i915/intel_runtime_pm.c | 595 +--- > drivers/gpu/drm/i915/intel_runtime_pm.h | 8 + > 9 files changed, 662 insertions(+), 127 deletions(-) > > -- > 2.17.1 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
== Series Details == Series: drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case URL : https://patchwork.freedesktop.org/series/60473/ State : success == Summary == CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12993 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12993/ Known issues Here are the changes found in Patchwork_12993 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [PASS][1] -> [DMESG-FAIL][2] ([fdo#110235]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12993/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html * igt@prime_vgem@basic-fence-flip: - fi-ilk-650: [PASS][3] -> [DMESG-WARN][4] ([fdo#106387]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-ilk-650/igt@prime_v...@basic-fence-flip.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12993/fi-ilk-650/igt@prime_v...@basic-fence-flip.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-kbl-7500u: [DMESG-WARN][5] ([fdo#105128] / [fdo#107139]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12993/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [INCOMPLETE][7] ([fdo#103927] / [fdo#110624]) -> [DMESG-FAIL][8] ([fdo#110620]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12993/fi-apl-guc/igt@i915_selftest@live_hangcheck.html * igt@runner@aborted: - fi-apl-guc: [FAIL][9] ([fdo#110624]) -> [FAIL][10] ([fdo#110622]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12993/fi-apl-guc/igt@run...@aborted.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128 [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387 [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620 [fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622 [fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624 Participating hosts (49 -> 44) -- Additional (1): fi-blb-e6850 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * Linux: CI_DRM_6072 -> Patchwork_12993 CI_DRM_6072: 645586708589c3d2ac81114595e875cdfbbff385 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4976: b1d91d0228db999145405e529952ca49bab7f706 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12993: 10622f507eda4601908351b1359ed96e90bc63b3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 10622f507eda drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12993/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/11] drm/i915: Remove the unneeded AUX power ref from intel_dp_detect()
On Thu, May 09, 2019 at 06:57:56PM +0300, Ville Syrjälä wrote:
> On Thu, May 09, 2019 at 09:19:50AM +0300, Imre Deak wrote:
> > We don't need the AUX power for the whole duration of the detect, only
> > when we're doing AUX transfers. The AUX transfer function takes its own
> > reference on the AUX power domain already. The two places during detect
> > which access display core registers (not specific to a
> > pipe/port/transcoder) only need the power domain that is required for
> > that access. That power domain is equivalent to the device global power
> > domain on most platforms (enabled whenever we hold a runtime PM
> > reference) except on CHV/VLV where it's equivalent to the display power
> > well.
> >
> > Add a new power domain that reflects the above, and use this at the two
> > spots accessing registers. With that we can avoid taking the AUX
> > reference for the whole duration of the detect function.
> >
> > Put the domains asynchronously to avoid the unneeded on-off-on toggling.
> >
> > Cc: Ville Syrjala
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_display.h| 1 +
> > drivers/gpu/drm/i915/intel_dp.c | 32 +
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 4
> > 3 files changed, 27 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index 1b6f5a71184d..7f3fafdfbd5f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -220,6 +220,7 @@ enum aux_ch {
> > #define aux_ch_name(a) ((a) + 'A')
> >
> > enum intel_display_power_domain {
> > + POWER_DOMAIN_DISPLAY_CORE,
> > POWER_DOMAIN_PIPE_A,
> > POWER_DOMAIN_PIPE_B,
> > POWER_DOMAIN_PIPE_C,
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 1e011998e9d5..24cca12a9a3e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -216,15 +216,21 @@ static int
> > intel_dp_get_fia_supported_lane_count(struct intel_dp *intel_dp)
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> > enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
> > + intel_wakeref_t wakeref;
> > u32 lane_info;
> >
> > if (tc_port == PORT_TC_NONE || dig_port->tc_type != TC_PORT_TYPEC)
> > return 4;
> >
> > + wakeref = intel_display_power_get(dev_priv, POWER_DOMAIN_DISPLAY_CORE);
> > +
> > lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
> > DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
> > DP_LANE_ASSIGNMENT_SHIFT(tc_port);
> >
> > + intel_display_power_put_async(dev_priv, POWER_DOMAIN_DISPLAY_CORE,
> > + wakeref);
> > +
>
> Future idea: maybe we want a with_something() {} for this sort of thing?
Yep, good idea, can add that in this patch.
>
> > switch (lane_info) {
> > default:
> > MISSING_CASE(lane_info);
>
> Unrelated but this thing here looks like a hand rolled hweight(). And
> for some reason it's using decimal for bitmasks.
Yep, that's strange. I can follow up fixing that if noone is
interested.
>
> > @@ -5294,7 +5300,7 @@ static bool icl_digital_port_connected(struct
> > intel_encoder *encoder)
> > *
> > * Return %true if port is connected, %false otherwise.
> > */
> > -bool intel_digital_port_connected(struct intel_encoder *encoder)
> > +static bool __intel_digital_port_connected(struct intel_encoder *encoder)
> > {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> >
> > @@ -5324,6 +5330,20 @@ bool intel_digital_port_connected(struct
> > intel_encoder *encoder)
> > return false;
> > }
> >
> > +bool intel_digital_port_connected(struct intel_encoder *encoder)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > + intel_wakeref_t wakeref;
> > + bool res;
>
> bool is_connected perhaps?
Ok.
>
> > +
> > + wakeref = intel_display_power_get(dev_priv, POWER_DOMAIN_DISPLAY_CORE);
> > + res = __intel_digital_port_connected(encoder);
> > + intel_display_power_put_async(dev_priv, POWER_DOMAIN_DISPLAY_CORE,
> > + wakeref);
> > +
> > + return res;
> > +}
> > +
> > static struct edid *
> > intel_dp_get_edid(struct intel_dp *intel_dp)
> > {
> > @@ -5377,16 +5397,11 @@ intel_dp_detect(struct drm_connector *connector,
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > struct intel_encoder *encoder = _port->base;
> > enum drm_connector_status status;
> > - enum intel_display_power_domain aux_domain =
> > - intel_aux_power_domain(dig_port);
> > - intel_wakeref_t wakeref;
> >
> > DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> > connector->base.id, connector->name);
> >
>
Re: [Intel-gfx] [PATCH v2 08/11] drm/i915: Remove the unneeded AUX power ref from intel_dp_hpd_pulse()
On Thu, May 09, 2019 at 06:50:42PM +0300, Ville Syrjälä wrote:
> On Thu, May 09, 2019 at 09:19:51AM +0300, Imre Deak wrote:
> > The power get/put was added in
> >
> > commit 1c767b339b3938b19076ffdc9d70aa1e4235a45b
> > Author: Imre Deak
> > Date: Mon Aug 18 14:42:42 2014 +0300
> >
> > drm/i915: take display port power domain in DP HPD handle
> >
> > to account for the HW access in ibx_digital_port_connected(). This
> > latter call was in turn removed in
> >
> > commit 7d23e3c37bb3fc6952dc84007ee60cb533fd2d5c
> > Author: Shubhangi Shrivastava
> > Date: Wed Mar 30 18:05:23 2016 +0530
> >
> > drm/i915: Cleaning up intel_dp_hpd_pulse
> >
> > after which we didn't actually need the power reference.
> >
> > One way we are accessing the HW during HPD pulse handling is via DP AUX
> > transfers, but the transfer function takes its own reference, so doesn't
> > need the reference in intel_dp_hpd_pulse().
> >
> > The other spot is in the PSR code doing register access, for that we can
> > use the DISPLAY_CORE power domain in a similar way done in the previous
> > patch.
>
> I don't think the PSR code should touch the hardware unless the crtc is
> active. So not sure it really needs anything.
Ah, right, thanks for spotting it. I noticed the access in
intel_psr_short_pulse()->intel_psr_disable_locked()
only by code inspection, didn't think of checking the state in which it
can be called (even though the fn name should've been indicative). So
yes PSR is enabled at that point and the modeset should have already all
the power references needed for that access. I will remove the get/put
from intel_psr_short_pulse().
>
> >
> > Cc: Ville Syrjala
> > Cc: Rodrigo Vivi
> > Cc: José Roberto de Souza
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 20
> > drivers/gpu/drm/i915/intel_psr.c | 6 ++
> > 2 files changed, 10 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 24cca12a9a3e..de881bfea011 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -6308,9 +6308,6 @@ enum irqreturn
> > intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool
> > long_hpd)
> > {
> > struct intel_dp *intel_dp = _dig_port->dp;
> > - struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > - enum irqreturn ret = IRQ_NONE;
> > - intel_wakeref_t wakeref;
> >
> > if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
> > /*
> > @@ -6333,9 +6330,6 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> > return IRQ_NONE;
> > }
> >
> > - wakeref = intel_display_power_get(dev_priv,
> > -
> > intel_aux_power_domain(intel_dig_port));
> > -
> > if (intel_dp->is_mst) {
> > if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
> > /*
> > @@ -6347,7 +6341,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> > intel_dp->is_mst = false;
> > drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> > intel_dp->is_mst);
> > - goto put_power;
> > +
> > + return IRQ_NONE;
> > }
> > }
> >
> > @@ -6357,17 +6352,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> > handled = intel_dp_short_pulse(intel_dp);
> >
> > if (!handled)
> > - goto put_power;
> > + return IRQ_NONE;
> > }
> >
> > - ret = IRQ_HANDLED;
> > -
> > -put_power:
> > - intel_display_power_put(dev_priv,
> > - intel_aux_power_domain(intel_dig_port),
> > - wakeref);
> > -
> > - return ret;
> > + return IRQ_HANDLED;
> > }
> >
> > /* check the VBT to see whether the eDP is on another port */
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 963663ba0edf..856a39c7ee77 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -1251,10 +1251,13 @@ void intel_psr_short_pulse(struct intel_dp
> > *intel_dp)
> > const u8 errors = DP_PSR_RFB_STORAGE_ERROR |
> > DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR |
> > DP_PSR_LINK_CRC_ERROR;
> > + intel_wakeref_t wakeref;
> >
> > if (!CAN_PSR(dev_priv) || !intel_dp_is_edp(intel_dp))
> > return;
> >
> > + wakeref = intel_display_power_get(dev_priv, POWER_DOMAIN_DISPLAY_CORE);
> > +
> > mutex_lock(>lock);
> >
> > if (!psr->enabled || psr->dp != intel_dp)
> > @@ -1294,6 +1297,9 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
> > drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS,
[Intel-gfx] [v3] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
Currently input csc for YCbCR to RGB conversion handles only
BT601 and Bt709. Extending it to support BT2020 as well.
v2: Fixed the co-efficients for LR to FR conversion,
as suggested by Ville.
v3: Fixed Y Pre-offset in case of Full Range YCbCr as suggested
by Ville.
Signed-off-by: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_sprite.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 2913e89..c9c970f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -433,6 +433,18 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
0x9EF8, 0x7800, 0xABF8,
0x0, 0x7800, 0x7ED8,
},
+ /*
+* BT.2020 full range YCbCr -> full range RGB
+* The matrix required is :
+* [1.000, 0.000, 1.474,
+* 1.000, -0.1645, -0.5713,
+* 1.000, 1.8814, 0.]
+*/
+ [DRM_COLOR_YCBCR_BT2020] = {
+ 0x7BC8, 0x7800, 0x0,
+ 0x8928, 0x7800, 0xAA88,
+ 0x0, 0x7800, 0x7F10,
+ },
};
/* Matrix for Limited Range to Full Range Conversion */
@@ -461,6 +473,18 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
0x, 0x7918, 0xADA8,
0x0, 0x7918, 0x6870,
},
+ /*
+* BT.2020 Limited range YCbCr -> full range RGB
+* The matrix required is :
+* [1.164, 0.000, 1.678,
+* 1.164, -0.1873, -0.6504,
+* 1.164, 2.1417, 0.]
+*/
+ [DRM_COLOR_YCBCR_BT2020] = {
+ 0x7D70, 0x7950, 0x0,
+ 0x8A68, 0x7950, 0xAC00,
+ 0x0, 0x7950, 0x6890,
+ },
};
const u16 *csc;
@@ -481,8 +505,11 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 0),
PREOFF_YUV_TO_RGB_HI);
- I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1),
- PREOFF_YUV_TO_RGB_ME);
+ if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
+ I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), 0);
+ else
+ I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1),
+ PREOFF_YUV_TO_RGB_ME);
I915_WRITE_FW(PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 2),
PREOFF_YUV_TO_RGB_LO);
I915_WRITE_FW(PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 0), 0x0);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/11] drm/i915: Remove the unneeded AUX power ref from intel_dp_detect()
On Thu, May 09, 2019 at 09:19:50AM +0300, Imre Deak wrote:
> We don't need the AUX power for the whole duration of the detect, only
> when we're doing AUX transfers. The AUX transfer function takes its own
> reference on the AUX power domain already. The two places during detect
> which access display core registers (not specific to a
> pipe/port/transcoder) only need the power domain that is required for
> that access. That power domain is equivalent to the device global power
> domain on most platforms (enabled whenever we hold a runtime PM
> reference) except on CHV/VLV where it's equivalent to the display power
> well.
>
> Add a new power domain that reflects the above, and use this at the two
> spots accessing registers. With that we can avoid taking the AUX
> reference for the whole duration of the detect function.
>
> Put the domains asynchronously to avoid the unneeded on-off-on toggling.
>
> Cc: Ville Syrjala
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.h| 1 +
> drivers/gpu/drm/i915/intel_dp.c | 32 +
> drivers/gpu/drm/i915/intel_runtime_pm.c | 4
> 3 files changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 1b6f5a71184d..7f3fafdfbd5f 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -220,6 +220,7 @@ enum aux_ch {
> #define aux_ch_name(a) ((a) + 'A')
>
> enum intel_display_power_domain {
> + POWER_DOMAIN_DISPLAY_CORE,
> POWER_DOMAIN_PIPE_A,
> POWER_DOMAIN_PIPE_B,
> POWER_DOMAIN_PIPE_C,
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1e011998e9d5..24cca12a9a3e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -216,15 +216,21 @@ static int intel_dp_get_fia_supported_lane_count(struct
> intel_dp *intel_dp)
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
> + intel_wakeref_t wakeref;
> u32 lane_info;
>
> if (tc_port == PORT_TC_NONE || dig_port->tc_type != TC_PORT_TYPEC)
> return 4;
>
> + wakeref = intel_display_power_get(dev_priv, POWER_DOMAIN_DISPLAY_CORE);
> +
> lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
>DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
> DP_LANE_ASSIGNMENT_SHIFT(tc_port);
>
> + intel_display_power_put_async(dev_priv, POWER_DOMAIN_DISPLAY_CORE,
> + wakeref);
> +
Future idea: maybe we want a with_something() {} for this sort of thing?
> switch (lane_info) {
> default:
> MISSING_CASE(lane_info);
Unrelated but this thing here looks like a hand rolled hweight(). And
for some reason it's using decimal for bitmasks.
> @@ -5294,7 +5300,7 @@ static bool icl_digital_port_connected(struct
> intel_encoder *encoder)
> *
> * Return %true if port is connected, %false otherwise.
> */
> -bool intel_digital_port_connected(struct intel_encoder *encoder)
> +static bool __intel_digital_port_connected(struct intel_encoder *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>
> @@ -5324,6 +5330,20 @@ bool intel_digital_port_connected(struct intel_encoder
> *encoder)
> return false;
> }
>
> +bool intel_digital_port_connected(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + intel_wakeref_t wakeref;
> + bool res;
bool is_connected perhaps?
> +
> + wakeref = intel_display_power_get(dev_priv, POWER_DOMAIN_DISPLAY_CORE);
> + res = __intel_digital_port_connected(encoder);
> + intel_display_power_put_async(dev_priv, POWER_DOMAIN_DISPLAY_CORE,
> + wakeref);
> +
> + return res;
> +}
> +
> static struct edid *
> intel_dp_get_edid(struct intel_dp *intel_dp)
> {
> @@ -5377,16 +5397,11 @@ intel_dp_detect(struct drm_connector *connector,
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct intel_encoder *encoder = _port->base;
> enum drm_connector_status status;
> - enum intel_display_power_domain aux_domain =
> - intel_aux_power_domain(dig_port);
> - intel_wakeref_t wakeref;
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
>
> WARN_ON(!drm_modeset_is_locked(_priv->drm.mode_config.connection_mutex));
>
> - wakeref = intel_display_power_get(dev_priv, aux_domain);
> -
> /* Can't disconnect eDP */
> if (intel_dp_is_edp(intel_dp))
> status = edp_detect(intel_dp);
> @@ -5450,10 +5465,8 @@ intel_dp_detect(struct drm_connector *connector,
>
Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Thursday, May 9, 2019 9:00 PM
>To: Shankar, Uma
>Cc: Sharma, Shashank ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion
>for
>BT2020 case
>
>On Thu, May 09, 2019 at 03:08:40PM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> >Sent: Thursday, May 9, 2019 8:28 PM
>> >To: Shankar, Uma
>> >Cc: Sharma, Shashank ; intel-
>> >g...@lists.freedesktop.org
>> >Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB
>> >conversion for
>> >BT2020 case
>> >
>> >On Thu, May 09, 2019 at 02:54:19PM +, Shankar, Uma wrote:
>> >>
>> >>
>> >> >-Original Message-
>> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> >> >Sent: Tuesday, May 7, 2019 9:08 PM
>> >> >To: Shankar, Uma
>> >> >Cc: Sharma, Shashank ; intel-
>> >> >g...@lists.freedesktop.org
>> >> >Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB
>> >> >conversion for
>> >> >BT2020 case
>> >> >
>> >> >On Tue, May 07, 2019 at 02:35:15PM +, Shankar, Uma wrote:
>> >> >>
>> >> >>
>> >> >> >-Original Message-
>> >> >> >From: Intel-gfx
>> >> >> >[mailto:intel-gfx-boun...@lists.freedesktop.org]
>> >> >> >On Behalf Of Ville Syrjälä
>> >> >> >Sent: Tuesday, May 7, 2019 7:37 PM
>> >> >> >To: Sharma, Shashank
>> >> >> >Cc: intel-gfx@lists.freedesktop.org
>> >> >> >Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to
>> >> >> >RGB conversion for
>> >> >> >BT2020 case
>> >> >> >
>> >> >> >On Tue, May 07, 2019 at 06:32:57PM +0530, Shashank Sharma wrote:
>> >> >> >> From: Uma Shankar
>> >> >> >>
>> >> >> >> Currently input csc for YCbCR to RGB conversion handles only
>> >> >> >> BT601 and Bt709. Extending it to support BT2020 as well.
>> >> >> >>
>> >> >> >> Signed-off-by: Uma Shankar
>> >> >> >> Signed-off-by: Shashank Sharma
>> >> >> >> ---
>> >> >> >> drivers/gpu/drm/i915/intel_sprite.c | 24
>> >> >> >>
>> >> >> >> 1 file changed, 24 insertions(+)
>> >> >> >>
>> >> >> >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
>> >> >> >> b/drivers/gpu/drm/i915/intel_sprite.c
>> >> >> >> index 44aaeac1b2ed..2536e757bec2 100644
>> >> >> >> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> >> >> >> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> >> >> >> @@ -433,6 +433,18 @@ icl_program_input_csc(struct intel_plane
>> >> >> >> *plane,
>> >> >> >> 0x9EF8, 0x7800, 0xABF8,
>> >> >> >> 0x0, 0x7800, 0x7ED8,
>> >> >> >> },
>> >> >> >> + /*
>> >> >> >> +* BT.2020 full range YCbCr -> full range RGB
>> >> >> >> +* The matrix required is :
>> >> >> >> +* [1.000, 0.000, 1.474,
>> >> >> >> +* 1.000, -0.1645, -0.5713,
>> >> >> >> +* 1.000, 1.8814, 0.]
>> >> >> >> +*/
>> >> >> >> + [DRM_COLOR_YCBCR_BT2020] = {
>> >> >> >> + 0x7BC8, 0x7800, 0x0,
>> >> >> >> + 0x8928, 0x7800, 0xAA88,
>> >> >> >> + 0x0, 0x7800, 0x7F10,
>> >> >> >> + },
>> >> >> >> };
>> >> >> >>
>> >> >> >> /* Matrix for Limited Range to Full Range Conversion */ @@
>> >> >> >> -461,6
>> >> >> >> +473,18 @@ icl_program_input_csc(struct intel_plane *plane,
>> >> >> >> 0x, 0x7918, 0xADA8,
>> >> >> >> 0x0, 0x7918, 0x6870,
>> >> >> >> },
>> >> >> >> + /*
>> >> >> >> +* BT.2020 Limited range YCbCr -> full range RGB
>> >> >> >> +* The matrix required is :
>> >> >> >> +* [1.164, 0.000, 1.717,
>> >> >> >> +* 1.138, -0.1873, -0.6504,
>> >> >> >> +* 1.1380, 2.1417, 0.]
>> >> >> >
>> >> >> >Where are those 1.138 coming from?
>> >> >>
>> >> >> Hi Ville,
>> >> >> This is the original YCBCR to RGB BT2020 matrix:
>> >> >> {
>> >> >> 1.000, 0.000, 1.4746000,
>> >> >> 1.000, -0.16455312684, -0.57135312684,
>> >> >> 1.000, 1.8814000, 0.000 };
>> >> >>
>> >> >> We have to convert Limited Range YCbCr to Full Range RGB. Hence
>> >> >> we need to
>> >> >apply a scale factor:
>> >> >> yscalefactor = 219.0 * normalizingfactor; cbcrscalefactor =
>> >> >> 224.0
>> >> >> * normalizingfactor;
>> >> >>
>> >> >> /* Scale factors are inverted for LR to FR conversion */
>> >> >> yscalefactor = 1.0 / yscalefactor; cbcrscalefactor = 1.0 /
>> >> >> cbcrscalefactor;
>> >> >>
>> >> >> This yields the above results.
>> >> >
>> >> >Those are the coefficients for Y, so they should still be the same
>> >> >for all three output channels.
>> >> >
>> >> >igt_color_encoding gives me:
>> >> >|1.1644, 0., 1.6787,|
>> >> >|1.1644,-0.1873,-0.6504,|
>> >> >|1.1644, 2.1418, 0.,|
>> >>
>> >> Ok, I used the
Re: [Intel-gfx] [PATCH v2 08/11] drm/i915: Remove the unneeded AUX power ref from intel_dp_hpd_pulse()
On Thu, May 09, 2019 at 09:19:51AM +0300, Imre Deak wrote:
> The power get/put was added in
>
> commit 1c767b339b3938b19076ffdc9d70aa1e4235a45b
> Author: Imre Deak
> Date: Mon Aug 18 14:42:42 2014 +0300
>
> drm/i915: take display port power domain in DP HPD handle
>
> to account for the HW access in ibx_digital_port_connected(). This
> latter call was in turn removed in
>
> commit 7d23e3c37bb3fc6952dc84007ee60cb533fd2d5c
> Author: Shubhangi Shrivastava
> Date: Wed Mar 30 18:05:23 2016 +0530
>
> drm/i915: Cleaning up intel_dp_hpd_pulse
>
> after which we didn't actually need the power reference.
>
> One way we are accessing the HW during HPD pulse handling is via DP AUX
> transfers, but the transfer function takes its own reference, so doesn't
> need the reference in intel_dp_hpd_pulse().
>
> The other spot is in the PSR code doing register access, for that we can
> use the DISPLAY_CORE power domain in a similar way done in the previous
> patch.
I don't think the PSR code should touch the hardware unless the crtc is
active. So not sure it really needs anything.
>
> Cc: Ville Syrjala
> Cc: Rodrigo Vivi
> Cc: José Roberto de Souza
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_dp.c | 20
> drivers/gpu/drm/i915/intel_psr.c | 6 ++
> 2 files changed, 10 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 24cca12a9a3e..de881bfea011 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6308,9 +6308,6 @@ enum irqreturn
> intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
> {
> struct intel_dp *intel_dp = _dig_port->dp;
> - struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - enum irqreturn ret = IRQ_NONE;
> - intel_wakeref_t wakeref;
>
> if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
> /*
> @@ -6333,9 +6330,6 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> return IRQ_NONE;
> }
>
> - wakeref = intel_display_power_get(dev_priv,
> -
> intel_aux_power_domain(intel_dig_port));
> -
> if (intel_dp->is_mst) {
> if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
> /*
> @@ -6347,7 +6341,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> intel_dp->is_mst = false;
> drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> intel_dp->is_mst);
> - goto put_power;
> +
> + return IRQ_NONE;
> }
> }
>
> @@ -6357,17 +6352,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> handled = intel_dp_short_pulse(intel_dp);
>
> if (!handled)
> - goto put_power;
> + return IRQ_NONE;
> }
>
> - ret = IRQ_HANDLED;
> -
> -put_power:
> - intel_display_power_put(dev_priv,
> - intel_aux_power_domain(intel_dig_port),
> - wakeref);
> -
> - return ret;
> + return IRQ_HANDLED;
> }
>
> /* check the VBT to see whether the eDP is on another port */
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 963663ba0edf..856a39c7ee77 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -1251,10 +1251,13 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
> const u8 errors = DP_PSR_RFB_STORAGE_ERROR |
> DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR |
> DP_PSR_LINK_CRC_ERROR;
> + intel_wakeref_t wakeref;
>
> if (!CAN_PSR(dev_priv) || !intel_dp_is_edp(intel_dp))
> return;
>
> + wakeref = intel_display_power_get(dev_priv, POWER_DOMAIN_DISPLAY_CORE);
> +
> mutex_lock(>lock);
>
> if (!psr->enabled || psr->dp != intel_dp)
> @@ -1294,6 +1297,9 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
> drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, val);
> exit:
> mutex_unlock(>lock);
> +
> + intel_display_power_put_async(dev_priv, POWER_DOMAIN_DISPLAY_CORE,
> + wakeref);
> }
>
> bool intel_psr_enabled(struct intel_dp *intel_dp)
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
On Thu, May 09, 2019 at 03:08:40PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Thursday, May 9, 2019 8:28 PM
> >To: Shankar, Uma
> >Cc: Sharma, Shashank ; intel-
> >g...@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB
> >conversion for
> >BT2020 case
> >
> >On Thu, May 09, 2019 at 02:54:19PM +, Shankar, Uma wrote:
> >>
> >>
> >> >-Original Message-
> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >> >Sent: Tuesday, May 7, 2019 9:08 PM
> >> >To: Shankar, Uma
> >> >Cc: Sharma, Shashank ; intel-
> >> >g...@lists.freedesktop.org
> >> >Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB
> >> >conversion for
> >> >BT2020 case
> >> >
> >> >On Tue, May 07, 2019 at 02:35:15PM +, Shankar, Uma wrote:
> >> >>
> >> >>
> >> >> >-Original Message-
> >> >> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org]
> >> >> >On Behalf Of Ville Syrjälä
> >> >> >Sent: Tuesday, May 7, 2019 7:37 PM
> >> >> >To: Sharma, Shashank
> >> >> >Cc: intel-gfx@lists.freedesktop.org
> >> >> >Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB
> >> >> >conversion for
> >> >> >BT2020 case
> >> >> >
> >> >> >On Tue, May 07, 2019 at 06:32:57PM +0530, Shashank Sharma wrote:
> >> >> >> From: Uma Shankar
> >> >> >>
> >> >> >> Currently input csc for YCbCR to RGB conversion handles only
> >> >> >> BT601 and Bt709. Extending it to support BT2020 as well.
> >> >> >>
> >> >> >> Signed-off-by: Uma Shankar
> >> >> >> Signed-off-by: Shashank Sharma
> >> >> >> ---
> >> >> >> drivers/gpu/drm/i915/intel_sprite.c | 24
> >> >> >>
> >> >> >> 1 file changed, 24 insertions(+)
> >> >> >>
> >> >> >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> >> >> >> b/drivers/gpu/drm/i915/intel_sprite.c
> >> >> >> index 44aaeac1b2ed..2536e757bec2 100644
> >> >> >> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >> >> >> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >> >> >> @@ -433,6 +433,18 @@ icl_program_input_csc(struct intel_plane *plane,
> >> >> >> 0x9EF8, 0x7800, 0xABF8,
> >> >> >> 0x0, 0x7800, 0x7ED8,
> >> >> >> },
> >> >> >> +/*
> >> >> >> + * BT.2020 full range YCbCr -> full range RGB
> >> >> >> + * The matrix required is :
> >> >> >> + * [1.000, 0.000, 1.474,
> >> >> >> + * 1.000, -0.1645, -0.5713,
> >> >> >> + * 1.000, 1.8814, 0.]
> >> >> >> + */
> >> >> >> +[DRM_COLOR_YCBCR_BT2020] = {
> >> >> >> +0x7BC8, 0x7800, 0x0,
> >> >> >> +0x8928, 0x7800, 0xAA88,
> >> >> >> +0x0, 0x7800, 0x7F10,
> >> >> >> +},
> >> >> >> };
> >> >> >>
> >> >> >> /* Matrix for Limited Range to Full Range Conversion */ @@
> >> >> >> -461,6
> >> >> >> +473,18 @@ icl_program_input_csc(struct intel_plane *plane,
> >> >> >> 0x, 0x7918, 0xADA8,
> >> >> >> 0x0, 0x7918, 0x6870,
> >> >> >> },
> >> >> >> +/*
> >> >> >> + * BT.2020 Limited range YCbCr -> full range RGB
> >> >> >> + * The matrix required is :
> >> >> >> + * [1.164, 0.000, 1.717,
> >> >> >> + * 1.138, -0.1873, -0.6504,
> >> >> >> + * 1.1380, 2.1417, 0.]
> >> >> >
> >> >> >Where are those 1.138 coming from?
> >> >>
> >> >> Hi Ville,
> >> >> This is the original YCBCR to RGB BT2020 matrix:
> >> >> {
> >> >> 1.000, 0.000, 1.4746000,
> >> >> 1.000, -0.16455312684, -0.57135312684,
> >> >> 1.000, 1.8814000, 0.000 };
> >> >>
> >> >> We have to convert Limited Range YCbCr to Full Range RGB. Hence we
> >> >> need to
> >> >apply a scale factor:
> >> >> yscalefactor = 219.0 * normalizingfactor; cbcrscalefactor = 224.0
> >> >> * normalizingfactor;
> >> >>
> >> >> /* Scale factors are inverted for LR to FR conversion */
> >> >> yscalefactor = 1.0 / yscalefactor; cbcrscalefactor = 1.0 /
> >> >> cbcrscalefactor;
> >> >>
> >> >> This yields the above results.
> >> >
> >> >Those are the coefficients for Y, so they should still be the same
> >> >for all three output channels.
> >> >
> >> >igt_color_encoding gives me:
> >> >|1.1644, 0., 1.6787,|
> >> >|1.1644,-0.1873,-0.6504,|
> >> >|1.1644, 2.1418, 0.,|
> >>
> >> Ok, I used the igt_color_encoding method and able to get values what you
> >> got.
> >> Will update the matrix. Thanks Ville.
> >>
> >> >Looks like we're also misprogramming the Y pre-offset for the full range
> >> >YCbCr
> >case.
> >> For full range, I am getting same values as programmed above. Looks ok,
> >> can you
> >double check.
> >
> >The matrix itself looks OK (some minor rounding differences perhaps, but
> >nothing
> >major). But
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: GTT remapping for display
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/60469/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12991
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12991/
New tests
-
New tests have been introduced between CI_DRM_6072 and Patchwork_12991:
### New IGT tests (1) ###
* igt@i915_selftest@live_vma:
- Statuses : 41 pass(s)
- Exec time: [0.33, 1.23] s
Known issues
Here are the changes found in Patchwork_12991 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [PASS][1] -> [DMESG-FAIL][2] ([fdo#110235])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12991/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@prime_vgem@basic-fence-flip:
- fi-glk-dsi: [PASS][3] -> [SKIP][4] ([fdo#109271])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-glk-dsi/igt@prime_v...@basic-fence-flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12991/fi-glk-dsi/igt@prime_v...@basic-fence-flip.html
- fi-bxt-dsi: [PASS][5] -> [SKIP][6] ([fdo#109271])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-bxt-dsi/igt@prime_v...@basic-fence-flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12991/fi-bxt-dsi/igt@prime_v...@basic-fence-flip.html
- fi-kbl-r: [PASS][7] -> [SKIP][8] ([fdo#109271])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-kbl-r/igt@prime_v...@basic-fence-flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12991/fi-kbl-r/igt@prime_v...@basic-fence-flip.html
- fi-skl-6600u: [PASS][9] -> [SKIP][10] ([fdo#109271])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-skl-6600u/igt@prime_v...@basic-fence-flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12991/fi-skl-6600u/igt@prime_v...@basic-fence-flip.html
- fi-whl-u: [PASS][11] -> [SKIP][12] ([fdo#109271])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-whl-u/igt@prime_v...@basic-fence-flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12991/fi-whl-u/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-7500u: [DMESG-WARN][13] ([fdo#105128] / [fdo#107139]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12991/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
Warnings
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [INCOMPLETE][15] ([fdo#103927] / [fdo#110624]) ->
[DMESG-FAIL][16] ([fdo#110620])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12991/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
* igt@runner@aborted:
- fi-apl-guc: [FAIL][17] ([fdo#110624]) -> [FAIL][18] ([fdo#110622])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6072/fi-apl-guc/igt@run...@aborted.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12991/fi-apl-guc/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128
[fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110531]: https://bugs.freedesktop.org/show_bug.cgi?id=110531
[fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620
[fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622
[fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624
Participating hosts (49 -> 42)
--
Additional (1): fi-blb-e6850
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 fi-byt-clapper
Build changes
-
* IGT: IGT_4976 -> IGTPW_2953
* Linux: CI_DRM_6072 -> Patchwork_12991
CI_DRM_6072: 645586708589c3d2ac81114595e875cdfbbff385 @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_2953: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2953/
IGT_4976:
[Intel-gfx] ✗ Fi.CI.BAT: failure for RFC: console: hack up console_lock more v3 (rev2)
== Series Details == Series: RFC: console: hack up console_lock more v3 (rev2) URL : https://patchwork.freedesktop.org/series/60467/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC kernel/locking/semaphore.o kernel/locking/semaphore.c: In function ‘up’: kernel/locking/semaphore.c:181:2: error: implicit declaration of function ‘DEFINE_WAKE_Q’; did you mean ‘DEFINE_WAIT’? [-Werror=implicit-function-declaration] DEFINE_WAKE_Q(wake_q); ^ DEFINE_WAIT kernel/locking/semaphore.c:181:16: error: ‘wake_q’ undeclared (first use in this function); did you mean ‘wake_up’? DEFINE_WAKE_Q(wake_q); ^~ wake_up kernel/locking/semaphore.c:181:16: note: each undeclared identifier is reported only once for each function it appears in kernel/locking/semaphore.c:182:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] unsigned long flags; ^~~~ In file included from kernel/locking/semaphore.c:28:0: ./include/linux/kernel.h:979:51: error: dereferencing pointer to incomplete type ‘struct semaphore_waiter’ BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^ ./include/linux/compiler.h:324:9: note: in definition of macro ‘__compiletime_assert’ if (!(condition)) \ ^ ./include/linux/compiler.h:344:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/kernel.h:979:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~ ./include/linux/kernel.h:979:20: note: in expansion of macro ‘__same_type’ BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~ ./include/linux/list.h:430:2: note: in expansion of macro ‘container_of’ container_of(ptr, type, member) ^~~~ ./include/linux/list.h:441:2: note: in expansion of macro ‘list_entry’ list_entry((ptr)->next, type, member) ^~ kernel/locking/semaphore.c:190:11: note: in expansion of macro ‘list_first_entry’ waiter = list_first_entry(>wait_list, struct semaphore_waiter, list); ^~~~ In file included from :0:0: ././include/linux/compiler_types.h:127:35: error: invalid use of undefined type ‘struct semaphore_waiter’ #define __compiler_offsetof(a, b) __builtin_offsetof(a, b) ^ ./include/linux/stddef.h:17:32: note: in expansion of macro ‘__compiler_offsetof’ #define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER) ^~~ ./include/linux/kernel.h:982:21: note: in expansion of macro ‘offsetof’ ((type *)(__mptr - offsetof(type, member))); }) ^~~~ ./include/linux/list.h:430:2: note: in expansion of macro ‘container_of’ container_of(ptr, type, member) ^~~~ ./include/linux/list.h:441:2: note: in expansion of macro ‘list_entry’ list_entry((ptr)->next, type, member) ^~ kernel/locking/semaphore.c:190:11: note: in expansion of macro ‘list_first_entry’ waiter = list_first_entry(>wait_list, struct semaphore_waiter, list); ^~~~ kernel/locking/semaphore.c:193:2: error: implicit declaration of function ‘wake_q_add’; did you mean ‘wake_up_all’? [-Werror=implicit-function-declaration] wake_q_add(_q, waiter->task); ^~ wake_up_all kernel/locking/semaphore.c:197:2: error: implicit declaration of function ‘wake_up_q’; did you mean ‘wake_up_nr’? [-Werror=implicit-function-declaration] wake_up_q(_q); ^ wake_up_nr cc1: some warnings being treated as errors scripts/Makefile.build:275: recipe for target 'kernel/locking/semaphore.o' failed make[2]: *** [kernel/locking/semaphore.o] Error 1 scripts/Makefile.build:486: recipe for target 'kernel/locking' failed make[1]: *** [kernel/locking] Error 2 Makefile:1051: recipe for target 'kernel' failed make: *** [kernel] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v2
On Wed 2019-05-08 10:17:12, Daniel Vetter wrote: > On Mon, May 06, 2019 at 01:24:48PM +0200, Petr Mladek wrote: > > On Mon 2019-05-06 11:38:13, Daniel Vetter wrote: > > > On Mon, May 06, 2019 at 10:26:28AM +0200, Petr Mladek wrote: > > > > On Mon 2019-05-06 10:16:14, Petr Mladek wrote: > > > > > On Mon 2019-05-06 09:45:53, Daniel Vetter wrote: > > > > > > console_trylock, called from within printk, can be called from > > > > > > pretty > > > > > > much anywhere. Including try_to_wake_up. Note that this isn't > > > > > > common, > > > > > > usually the box is in pretty bad shape at that point already. But it > > > > > > really doesn't help when then lockdep jumps in and spams the logs, > > > > > > potentially obscuring the real backtrace we're really interested in. > > > > > > One case I've seen (slightly simplified backtrace): > > > > > > > > > > > > Call Trace: > > > > > > > > > > > > console_trylock+0xe/0x60 > > > > > > vprintk_emit+0xf1/0x320 > > > > > > printk+0x4d/0x69 > > > > > > __warn_printk+0x46/0x90 > > > > > > native_smp_send_reschedule+0x2f/0x40 > > > > > > check_preempt_curr+0x81/0xa0 > > > > > > ttwu_do_wakeup+0x14/0x220 > > > > > > try_to_wake_up+0x218/0x5f0 > > > > > > > > > > try_to_wake_up() takes p->pi_lock. It could deadlock because it > > > > > can get called recursively from printk_safe_up(). > > > > > > > > > > And there are more locks taken from try_to_wake_up(), for example, > > > > > __task_rq_lock() taken from ttwu_remote(). > > > > > > > > > > IMHO, the most reliable solution would be do call the entire > > > > > up_console_sem() from printk deferred context. We could assign > > > > > few bytes for this context in the per-CPU printk_deferred > > > > > variable. > > > > > > > > Ah, I was too fast and did the same mistake. This won't help because > > > > it would still call try_to_wake_up() recursively. > > > > > > Uh :-/ > > > > > > > We need to call all printk's that can be called under locks > > > > taken in try_to_wake_up() path in printk deferred context. > > > > Unfortunately it is whack a mole approach. > > > > > > Hm since it's whack-a-mole anyway, what about converting the WARN_ON into > > > a prinkt_deferred, like all the other scheduler related code? Feels a > > > notch more consistent to me than leaking the printk_context into areas it > > > wasn't really meant built for. Scheduler code already fully subscribed to > > > the whack-a-mole approach after all. > > > > I am not sure how exactly you mean the conversion. > > > > Anyway, we do not want to use printk_deferred() treewide. It reduces > > the chance that the messages reach consoles. Scheduler is an > > exception because of the possible deadlocks. > > > > A solution would be to define WARN_ON_DEFERRED() that would > > call normal WARN_ON() in printk deferred context and > > use in scheduler. > > Sent it out, and then Sergey pointed out printk_safe_enter/exit (which I > guess is what you meant, and which I missed) No, I meant introducing a deferred printk context that would behave like printk_deferred(). printk safe context is more limiting. It prevents deadlock on logbuf_lock by temporary saving the messages into per-CPU buffers. In scheduler, we could store the messages directly into the main log buffer. We just need to deffer the console handling to avoid deadlock on the scheduler locks. > , but we're doing this already around the up() call > in __up_console_sem. > > So I think these further recursions you're pointed out are already handled > correctly, and all we need to do is to break the loop involving > semaphore.lock of the console_lock semaphore only. Which I think this > patch here achieves. printk safe context would help only when try_to_wake_up() and all other functions using the same locks _all over the system_ are called printk safe (or deferred) context. By other words, printk safe context solves only printk() recursion. It does not solve recursion of the scheduler operations. Best Regards, Petr ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Thursday, May 9, 2019 8:28 PM
>To: Shankar, Uma
>Cc: Sharma, Shashank ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion
>for
>BT2020 case
>
>On Thu, May 09, 2019 at 02:54:19PM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> >Sent: Tuesday, May 7, 2019 9:08 PM
>> >To: Shankar, Uma
>> >Cc: Sharma, Shashank ; intel-
>> >g...@lists.freedesktop.org
>> >Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB
>> >conversion for
>> >BT2020 case
>> >
>> >On Tue, May 07, 2019 at 02:35:15PM +, Shankar, Uma wrote:
>> >>
>> >>
>> >> >-Original Message-
>> >> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org]
>> >> >On Behalf Of Ville Syrjälä
>> >> >Sent: Tuesday, May 7, 2019 7:37 PM
>> >> >To: Sharma, Shashank
>> >> >Cc: intel-gfx@lists.freedesktop.org
>> >> >Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB
>> >> >conversion for
>> >> >BT2020 case
>> >> >
>> >> >On Tue, May 07, 2019 at 06:32:57PM +0530, Shashank Sharma wrote:
>> >> >> From: Uma Shankar
>> >> >>
>> >> >> Currently input csc for YCbCR to RGB conversion handles only
>> >> >> BT601 and Bt709. Extending it to support BT2020 as well.
>> >> >>
>> >> >> Signed-off-by: Uma Shankar
>> >> >> Signed-off-by: Shashank Sharma
>> >> >> ---
>> >> >> drivers/gpu/drm/i915/intel_sprite.c | 24
>> >> >>
>> >> >> 1 file changed, 24 insertions(+)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
>> >> >> b/drivers/gpu/drm/i915/intel_sprite.c
>> >> >> index 44aaeac1b2ed..2536e757bec2 100644
>> >> >> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> >> >> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> >> >> @@ -433,6 +433,18 @@ icl_program_input_csc(struct intel_plane *plane,
>> >> >>0x9EF8, 0x7800, 0xABF8,
>> >> >>0x0, 0x7800, 0x7ED8,
>> >> >>},
>> >> >> + /*
>> >> >> + * BT.2020 full range YCbCr -> full range RGB
>> >> >> + * The matrix required is :
>> >> >> + * [1.000, 0.000, 1.474,
>> >> >> + * 1.000, -0.1645, -0.5713,
>> >> >> + * 1.000, 1.8814, 0.]
>> >> >> + */
>> >> >> + [DRM_COLOR_YCBCR_BT2020] = {
>> >> >> + 0x7BC8, 0x7800, 0x0,
>> >> >> + 0x8928, 0x7800, 0xAA88,
>> >> >> + 0x0, 0x7800, 0x7F10,
>> >> >> + },
>> >> >>};
>> >> >>
>> >> >>/* Matrix for Limited Range to Full Range Conversion */ @@
>> >> >> -461,6
>> >> >> +473,18 @@ icl_program_input_csc(struct intel_plane *plane,
>> >> >>0x, 0x7918, 0xADA8,
>> >> >>0x0, 0x7918, 0x6870,
>> >> >>},
>> >> >> + /*
>> >> >> + * BT.2020 Limited range YCbCr -> full range RGB
>> >> >> + * The matrix required is :
>> >> >> + * [1.164, 0.000, 1.717,
>> >> >> + * 1.138, -0.1873, -0.6504,
>> >> >> + * 1.1380, 2.1417, 0.]
>> >> >
>> >> >Where are those 1.138 coming from?
>> >>
>> >> Hi Ville,
>> >> This is the original YCBCR to RGB BT2020 matrix:
>> >> {
>> >> 1.000, 0.000, 1.4746000,
>> >> 1.000, -0.16455312684, -0.57135312684,
>> >> 1.000, 1.8814000, 0.000 };
>> >>
>> >> We have to convert Limited Range YCbCr to Full Range RGB. Hence we
>> >> need to
>> >apply a scale factor:
>> >> yscalefactor = 219.0 * normalizingfactor; cbcrscalefactor = 224.0
>> >> * normalizingfactor;
>> >>
>> >> /* Scale factors are inverted for LR to FR conversion */
>> >> yscalefactor = 1.0 / yscalefactor; cbcrscalefactor = 1.0 /
>> >> cbcrscalefactor;
>> >>
>> >> This yields the above results.
>> >
>> >Those are the coefficients for Y, so they should still be the same
>> >for all three output channels.
>> >
>> >igt_color_encoding gives me:
>> >|1.1644, 0., 1.6787,|
>> >|1.1644,-0.1873,-0.6504,|
>> >|1.1644, 2.1418, 0.,|
>>
>> Ok, I used the igt_color_encoding method and able to get values what you got.
>> Will update the matrix. Thanks Ville.
>>
>> >Looks like we're also misprogramming the Y pre-offset for the full range
>> >YCbCr
>case.
>> For full range, I am getting same values as programmed above. Looks ok, can
>> you
>double check.
>
>The matrix itself looks OK (some minor rounding differences perhaps, but
>nothing
>major). But the Y preoffset should be zero for full range YCbCr.
Hi Ville,
This is what I got for Full Range from igt_color_encoding.
m4.d[m(row=0, col=0)] = 1.00
m4.d[m(row=1, col=0)] = 1.00
m4.d[m(row=2, col=0)] = 1.00
m4.d[m(row=3, col=0)] = 0.00
m4.d[m(row=0,
[Intel-gfx] [v2] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
Currently input csc for YCbCR to RGB conversion handles only
BT601 and Bt709. Extending it to support BT2020 as well.
v2: Fixed the co-efficients for LR to FR conversion,
as suggested by Ville.
Signed-off-by: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_sprite.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 2913e89..4f513600 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -433,6 +433,18 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
0x9EF8, 0x7800, 0xABF8,
0x0, 0x7800, 0x7ED8,
},
+ /*
+* BT.2020 full range YCbCr -> full range RGB
+* The matrix required is :
+* [1.000, 0.000, 1.474,
+* 1.000, -0.1645, -0.5713,
+* 1.000, 1.8814, 0.]
+*/
+ [DRM_COLOR_YCBCR_BT2020] = {
+ 0x7BC8, 0x7800, 0x0,
+ 0x8928, 0x7800, 0xAA88,
+ 0x0, 0x7800, 0x7F10,
+ },
};
/* Matrix for Limited Range to Full Range Conversion */
@@ -461,6 +473,18 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
0x, 0x7918, 0xADA8,
0x0, 0x7918, 0x6870,
},
+ /*
+* BT.2020 Limited range YCbCr -> full range RGB
+* The matrix required is :
+* [1.164, 0.000, 1.678,
+* 1.164, -0.1873, -0.6504,
+* 1.164, 2.1417, 0.]
+*/
+ [DRM_COLOR_YCBCR_BT2020] = {
+ 0x7D70, 0x7950, 0x0,
+ 0x8A68, 0x7950, 0xAC00,
+ 0x0, 0x7950, 0x6890,
+ },
};
const u16 *csc;
--
1.9.1
___
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: GTT remapping for display
== Series Details == Series: drm/i915: GTT remapping for display URL : https://patchwork.freedesktop.org/series/60469/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Add a new "remapped" gtt_view +drivers/gpu/drm/i915/i915_gem_gtt.c:3633:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:3633:34: warning: expression using sizeof(void) Commit: drm/i915/selftests: Add mock selftest for remapped vmas Okay! Commit: drm/i915/selftests: Add live vma selftest Okay! Commit: drm/i915: Shuffle stride checking code around Okay! Commit: drm/i915: Overcome display engine stride limits via GTT remapping Okay! Commit: drm/i915: Align dumb buffer stride to 4k to allow for gtt remapping Okay! Commit: drm/i915: Bump fb stride limit to 128KiB for gen4+ and 256KiB for gen7+ Okay! Commit: drm/i915: Bump gen7+ fb size limits to 16kx16k Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
On Thu, May 09, 2019 at 02:54:19PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, May 7, 2019 9:08 PM
> >To: Shankar, Uma
> >Cc: Sharma, Shashank ; intel-
> >g...@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB
> >conversion for
> >BT2020 case
> >
> >On Tue, May 07, 2019 at 02:35:15PM +, Shankar, Uma wrote:
> >>
> >>
> >> >-Original Message-
> >> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> >> >Behalf Of Ville Syrjälä
> >> >Sent: Tuesday, May 7, 2019 7:37 PM
> >> >To: Sharma, Shashank
> >> >Cc: intel-gfx@lists.freedesktop.org
> >> >Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB
> >> >conversion for
> >> >BT2020 case
> >> >
> >> >On Tue, May 07, 2019 at 06:32:57PM +0530, Shashank Sharma wrote:
> >> >> From: Uma Shankar
> >> >>
> >> >> Currently input csc for YCbCR to RGB conversion handles only
> >> >> BT601 and Bt709. Extending it to support BT2020 as well.
> >> >>
> >> >> Signed-off-by: Uma Shankar
> >> >> Signed-off-by: Shashank Sharma
> >> >> ---
> >> >> drivers/gpu/drm/i915/intel_sprite.c | 24
> >> >> 1 file changed, 24 insertions(+)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> >> >> b/drivers/gpu/drm/i915/intel_sprite.c
> >> >> index 44aaeac1b2ed..2536e757bec2 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >> >> @@ -433,6 +433,18 @@ icl_program_input_csc(struct intel_plane *plane,
> >> >> 0x9EF8, 0x7800, 0xABF8,
> >> >> 0x0, 0x7800, 0x7ED8,
> >> >> },
> >> >> + /*
> >> >> +* BT.2020 full range YCbCr -> full range RGB
> >> >> +* The matrix required is :
> >> >> +* [1.000, 0.000, 1.474,
> >> >> +* 1.000, -0.1645, -0.5713,
> >> >> +* 1.000, 1.8814, 0.]
> >> >> +*/
> >> >> + [DRM_COLOR_YCBCR_BT2020] = {
> >> >> + 0x7BC8, 0x7800, 0x0,
> >> >> + 0x8928, 0x7800, 0xAA88,
> >> >> + 0x0, 0x7800, 0x7F10,
> >> >> + },
> >> >> };
> >> >>
> >> >> /* Matrix for Limited Range to Full Range Conversion */ @@
> >> >> -461,6
> >> >> +473,18 @@ icl_program_input_csc(struct intel_plane *plane,
> >> >> 0x, 0x7918, 0xADA8,
> >> >> 0x0, 0x7918, 0x6870,
> >> >> },
> >> >> + /*
> >> >> +* BT.2020 Limited range YCbCr -> full range RGB
> >> >> +* The matrix required is :
> >> >> +* [1.164, 0.000, 1.717,
> >> >> +* 1.138, -0.1873, -0.6504,
> >> >> +* 1.1380, 2.1417, 0.]
> >> >
> >> >Where are those 1.138 coming from?
> >>
> >> Hi Ville,
> >> This is the original YCBCR to RGB BT2020 matrix:
> >> {
> >> 1.000, 0.000, 1.4746000,
> >> 1.000, -0.16455312684, -0.57135312684,
> >> 1.000, 1.8814000, 0.000 };
> >>
> >> We have to convert Limited Range YCbCr to Full Range RGB. Hence we need to
> >apply a scale factor:
> >> yscalefactor = 219.0 * normalizingfactor; cbcrscalefactor = 224.0 *
> >> normalizingfactor;
> >>
> >> /* Scale factors are inverted for LR to FR conversion */
> >> yscalefactor = 1.0 / yscalefactor; cbcrscalefactor = 1.0 /
> >> cbcrscalefactor;
> >>
> >> This yields the above results.
> >
> >Those are the coefficients for Y, so they should still be the same for all
> >three output
> >channels.
> >
> >igt_color_encoding gives me:
> >|1.1644, 0., 1.6787,|
> >|1.1644,-0.1873,-0.6504,|
> >|1.1644, 2.1418, 0.,|
>
> Ok, I used the igt_color_encoding method and able to get values what you got.
> Will update the matrix. Thanks Ville.
>
> >Looks like we're also misprogramming the Y pre-offset for the full range
> >YCbCr case.
> For full range, I am getting same values as programmed above. Looks ok, can
> you double check.
The matrix itself looks OK (some minor rounding differences perhaps, but
nothing major). But the Y preoffset should be zero for full range
YCbCr.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v3
On Thu 2019-05-09 14:09:03, Daniel Vetter wrote:
> console_trylock, called from within printk, can be called from pretty
> much anywhere. Including try_to_wake_up. Note that this isn't common,
> usually the box is in pretty bad shape at that point already. But it
> really doesn't help when then lockdep jumps in and spams the logs,
> potentially obscuring the real backtrace we're really interested in.
> One case I've seen (slightly simplified backtrace):
>
> Call Trace:
>
> console_trylock+0xe/0x60
> vprintk_emit+0xf1/0x320
> printk+0x4d/0x69
> __warn_printk+0x46/0x90
> native_smp_send_reschedule+0x2f/0x40
> check_preempt_curr+0x81/0xa0
> ttwu_do_wakeup+0x14/0x220
> try_to_wake_up+0x218/0x5f0
> pollwake+0x6f/0x90
> credit_entropy_bits+0x204/0x310
> add_interrupt_randomness+0x18f/0x210
> handle_irq+0x67/0x160
> do_IRQ+0x5e/0x130
> common_interrupt+0xf/0xf
>
>
> This alone isn't a problem, but the spinlock in the semaphore is also
> still held while waking up waiters (up() -> __up() -> try_to_wake_up()
> callchain), which then closes the runqueue vs. semaphore.lock loop,
> and upsets lockdep, which issues a circular locking splat to dmesg.
> Worse it upsets developers, since we don't want to spam dmesg with
> clutter when the machine is dying already.
>
> Fix this by creating a prinkt_safe_up() which calls wake_up_process
> outside of the spinlock. This isn't correct in full generality, but
> good enough for console_lock:
>
> - console_lock doesn't use interruptible or killable or timeout down()
> calls, hence an up() is the only thing that can wake up a process.
> Hence the process can't get woken and killed and reaped while we try
> to wake it up too.
>
> - semaphore.c always updates the waiter list while under the spinlock,
> so there's no other races. Specifically another process that races
> with a quick console_lock/unlock while we've dropped the spinlock
> already won't see our own waiter.
>
> Note that we only have to break the recursion for the semaphore.lock
> spinlock of the console_lock. Recursion within various scheduler
> related locks is already prevented by the printk_safe_enter/exit pair
> in __up_console_sem().
This is not fully true. printk_safe() helps only when
the first try_to_wake_up() is called from printk_safe() context.
> --- a/kernel/locking/semaphore.c
> +++ b/kernel/locking/semaphore.c
> @@ -197,6 +197,37 @@ struct semaphore_waiter {
> bool up;
> };
>
> +/**
> + * printk_safe_up - release the semaphore in console_unlock
> + * @sem: the semaphore to release
> + *
> + * Release the semaphore. Unlike mutexes, up() may be called from any
> + * context and even by tasks which have never called down().
> + *
> + * NOTE: This is a special version of up() for console_unlock only. It is
> only
> + * safe if there are no killable, interruptible or timing out down() calls.
> + */
> +void printk_safe_up(struct semaphore *sem)
> +{
> + unsigned long flags;
> + struct semaphore_waiter *waiter = NULL;
> +
> + raw_spin_lock_irqsave(>lock, flags);
> + if (likely(list_empty(>wait_list))) {
> + sem->count++;
> + } else {
> + waiter = list_first_entry(>wait_list,
> + struct semaphore_waiter, list);
> + list_del(>list);
> + waiter->up = true;
> + }
> + raw_spin_unlock_irqrestore(>lock, flags);
> +
> + if (waiter) /* protected by being sole wake source */
> + wake_up_process(waiter->task);
I still do not see how this could help. Let's take the above
backtrace as example:
console_trylock+0xe/0x60
vprintk_emit+0xf1/0x320
printk+0x4d/0x69
__warn_printk+0x46/0x90
native_smp_send_reschedule +0x2f/0x40
check_preempt_curr+0x81/0xa0
ttwu_do_wakeup+0x14/0x220
try_to_wake_up+0x218/0x5f0
pollwake+0x6f/0x90
credit_entropy_bits+0x204/0x310
add_interrupt_randomness+0x18f/0x210
handle_irq+0x67/0x160
do_IRQ+0x5e/0x130
common_interrupt+0xf/0xf
We have the following chain of calls:
+ do_IRQ()
...
+ try_to_wake_up()# takes p->pi_lock
+ ttwu_remote() # takes rq lock
+ ttwu_do_wakeup()
+ check_preempt_curr()
+ native_smp_send_reschedule()
+ __warn_printk()
+ printk()
+ vprintk_emit()
+ console_trylock() # success
+ console_unlock()
+ up_console_sem()
+ up() # wait list in not empty
+ __up()
+ wake_up_process()
+ try_to_wake_up()
!BANG! Deadlock on p->pi_lock.
It does not matter if the nested try_to_wake_up() was called
under sem->lock or outside.
By other words. The patch removed one lockdep warning. But it just
just delayed the deadlock. It will not happen on sem->lock but
Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, May 7, 2019 9:08 PM
>To: Shankar, Uma
>Cc: Sharma, Shashank ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion
>for
>BT2020 case
>
>On Tue, May 07, 2019 at 02:35:15PM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
>> >Behalf Of Ville Syrjälä
>> >Sent: Tuesday, May 7, 2019 7:37 PM
>> >To: Sharma, Shashank
>> >Cc: intel-gfx@lists.freedesktop.org
>> >Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB
>> >conversion for
>> >BT2020 case
>> >
>> >On Tue, May 07, 2019 at 06:32:57PM +0530, Shashank Sharma wrote:
>> >> From: Uma Shankar
>> >>
>> >> Currently input csc for YCbCR to RGB conversion handles only
>> >> BT601 and Bt709. Extending it to support BT2020 as well.
>> >>
>> >> Signed-off-by: Uma Shankar
>> >> Signed-off-by: Shashank Sharma
>> >> ---
>> >> drivers/gpu/drm/i915/intel_sprite.c | 24
>> >> 1 file changed, 24 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
>> >> b/drivers/gpu/drm/i915/intel_sprite.c
>> >> index 44aaeac1b2ed..2536e757bec2 100644
>> >> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> >> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> >> @@ -433,6 +433,18 @@ icl_program_input_csc(struct intel_plane *plane,
>> >> 0x9EF8, 0x7800, 0xABF8,
>> >> 0x0, 0x7800, 0x7ED8,
>> >> },
>> >> + /*
>> >> + * BT.2020 full range YCbCr -> full range RGB
>> >> + * The matrix required is :
>> >> + * [1.000, 0.000, 1.474,
>> >> + * 1.000, -0.1645, -0.5713,
>> >> + * 1.000, 1.8814, 0.]
>> >> + */
>> >> + [DRM_COLOR_YCBCR_BT2020] = {
>> >> + 0x7BC8, 0x7800, 0x0,
>> >> + 0x8928, 0x7800, 0xAA88,
>> >> + 0x0, 0x7800, 0x7F10,
>> >> + },
>> >> };
>> >>
>> >> /* Matrix for Limited Range to Full Range Conversion */ @@ -461,6
>> >> +473,18 @@ icl_program_input_csc(struct intel_plane *plane,
>> >> 0x, 0x7918, 0xADA8,
>> >> 0x0, 0x7918, 0x6870,
>> >> },
>> >> + /*
>> >> + * BT.2020 Limited range YCbCr -> full range RGB
>> >> + * The matrix required is :
>> >> + * [1.164, 0.000, 1.717,
>> >> + * 1.138, -0.1873, -0.6504,
>> >> + * 1.1380, 2.1417, 0.]
>> >
>> >Where are those 1.138 coming from?
>>
>> Hi Ville,
>> This is the original YCBCR to RGB BT2020 matrix:
>> {
>> 1.000, 0.000, 1.4746000,
>> 1.000, -0.16455312684, -0.57135312684,
>> 1.000, 1.8814000, 0.000 };
>>
>> We have to convert Limited Range YCbCr to Full Range RGB. Hence we need to
>apply a scale factor:
>> yscalefactor = 219.0 * normalizingfactor; cbcrscalefactor = 224.0 *
>> normalizingfactor;
>>
>> /* Scale factors are inverted for LR to FR conversion */
>> yscalefactor = 1.0 / yscalefactor; cbcrscalefactor = 1.0 /
>> cbcrscalefactor;
>>
>> This yields the above results.
>
>Those are the coefficients for Y, so they should still be the same for all
>three output
>channels.
>
>igt_color_encoding gives me:
>|1.1644, 0., 1.6787,|
>|1.1644,-0.1873,-0.6504,|
>|1.1644, 2.1418, 0.,|
Ok, I used the igt_color_encoding method and able to get values what you got.
Will update the matrix. Thanks Ville.
>Looks like we're also misprogramming the Y pre-offset for the full range YCbCr
>case.
For full range, I am getting same values as programmed above. Looks ok, can you
double check.
Regards,
Uma Shankar
>--
>Ville Syrjälä
>Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: GTT remapping for display
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/60469/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e1a44e3ca92e drm/i915: Add a new "remapped" gtt_view
-:98: CHECK:LINE_SPACING: Please don't use multiple blank lines
#98: FILE: drivers/gpu/drm/i915/i915_gem.c:5106:
+
+
-:246: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#246: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:196:
+ BUILD_BUG_ON(sizeof(struct intel_remapped_info) != 9*sizeof(unsigned
int));
^
total: 0 errors, 0 warnings, 2 checks, 286 lines checked
08493348be9d drm/i915/selftests: Add mock selftest for remapped vmas
-:76: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#76: FILE: drivers/gpu/drm/i915/selftests/i915_vma.c:436:
+ if (left < PAGE_SIZE || left & (PAGE_SIZE-1)) {
^
-:92: CHECK:LINE_SPACING: Please don't use multiple blank lines
#92: FILE: drivers/gpu/drm/i915/selftests/i915_vma.c:452:
+
+
-:128: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional
statements (8, 8)
#128: FILE: drivers/gpu/drm/i915/selftests/i915_vma.c:506:
+ for (t = types; *t; t++) {
for (a = planes; a->width; a++) {
-:172: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code
refactoring
#172: FILE: drivers/gpu/drm/i915/selftests/i915_vma.c:576:
+ if (view.type ==
I915_GGTT_VIEW_ROTATED)
-:173: WARNING:LONG_LINE: line over 100 characters
#173: FILE: drivers/gpu/drm/i915/selftests/i915_vma.c:577:
+ sg =
assert_rotated(obj, , n, sg);
-:174: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code
refactoring
#174: FILE: drivers/gpu/drm/i915/selftests/i915_vma.c:578:
+ else
-:175: WARNING:LONG_LINE: line over 100 characters
#175: FILE: drivers/gpu/drm/i915/selftests/i915_vma.c:579:
+ sg =
assert_remapped(obj, , n, sg);
total: 0 errors, 5 warnings, 2 checks, 165 lines checked
86cfa7fe1e0b drm/i915/selftests: Add live vma selftest
5f08f33bb992 drm/i915: Shuffle stride checking code around
f7bb2263cd69 drm/i915: Overcome display engine stride limits via GTT remapping
494ec5d13440 drm/i915: Align dumb buffer stride to 4k to allow for gtt remapping
5fc14462b19b drm/i915: Bump fb stride limit to 128KiB for gen4+ and 256KiB for
gen7+
-:44: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#44: FILE: drivers/gpu/drm/i915/intel_display.c:2530:
+ return 256*1024;
^
-:46: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#46: FILE: drivers/gpu/drm/i915/intel_display.c:2532:
+ return 128*1024;
^
total: 0 errors, 0 warnings, 2 checks, 19 lines checked
853938b87ba6 drm/i915: Bump gen7+ fb size limits to 16kx16k
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/4] drm/i915/icl: Add Multi-segmented gamma support
On Thu, May 09, 2019 at 01:05:26AM +0530, Shashank Sharma wrote:
> ICL introduces a new gamma correction mode in display engine, called
> multi-segmented-gamma mode. This mode allows users to program the
> darker region of the gamma curve with sueprfine precision. An
> example use case for this is HDR curves (like PQ ST-2084).
>
> If we plot a gamma correction curve from value range between 0.0 to 1.0,
> ICL's multi-segment has 3 different sections:
> - superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
> - fine segment: 257 values, ranges between 0 - 1/(128)
> - corase segment: 257 values, ranges between 0 - 1
>
> This patch:
> - Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
> so that userspace can program with highest precision supported.
> - Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
> - Adds functions to program/detect multi-segment gamma.
>
> V2: Addressed review comments from Ville
> - separate function for superfine and fine segments.
> - remove enum for segments.
> - reuse last entry of the LUT as gc_max value.
> - replace if() cond with switch...case in icl_load_luts.
> - add an entry variable, instead of 'word'
>
> V3: Addressed review comments from Ville
> - extra newline
> - s/entry/color/
> - remove LUT size checks
> - program ilk_lut_12p4_ldw value before ilk_lut_12p4_udw
> - Change the comments in description of fine and coarse segments,
> and try to make more sense.
> - use 8 * 128 instead of 1024
> - add 1 entry in LUT for GCMAX
>
> V4: Addressed review comments from Ville
> - Remove unused macro
> - missing shift entry in blue
> - pick correct entry for GCMAX
> - Added Ville's R-B
> Note: Tested and confirmed the programming sequence of odd/even
> registers in the HW. The correct sequence should be:
> ilk_lut_12p4_udw
> ilk_lut_12p4_ldw
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
>
> Reviewed-by: Ville Syrjälä
> Suggested-by: Ville Syrjälä
> Signed-off-by: Shashank Sharma
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/i915_pci.c| 2 +-
> drivers/gpu/drm/i915/intel_color.c | 126 -
> 2 files changed, 123 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index d7c07a947497..24305238b4ea 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -747,7 +747,7 @@ static const struct intel_device_info
> intel_cannonlake_info = {
> GEN(11), \
> .ddb_size = 2048, \
> .has_logical_ring_elsq = 1, \
> - .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
> + .color = { .degamma_lut_size = 33, .gamma_lut_size = 262145 }
>
> static const struct intel_device_info intel_icelake_11_info = {
> GEN11_FEATURES,
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 6c341bea514c..22ccbeacbee2 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -41,6 +41,7 @@
> #define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
>
> #define LEGACY_LUT_LENGTH256
> +
> /*
> * Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
> * format). This macro takes the coefficient we want transformed and the
> @@ -767,6 +768,116 @@ static void glk_load_luts(const struct intel_crtc_state
> *crtc_state)
> }
> }
>
> +/* ilk+ "12.4" interpolated format (high 10 bits) */
> +static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
> +{
> + return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
> + (color->blue >> 6);
> +}
> +
> +/* ilk+ "12.4" interpolated format (low 6 bits) */
> +static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
> +{
> + return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
> + (color->blue & 0x3f << 4);
Wrong placement of the closing paren.
> +}
> +
> +static void
> +icl_load_gcmax(const struct intel_crtc_state *crtc_state,
> +const struct drm_color_lut *color)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> +
> + /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
> + I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), color->red);
> + I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), color->green);
> + I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), color->blue);
> +}
> +
> +static void
> +icl_program_gamma_superfine_segment(const struct intel_crtc_state
> *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + const struct drm_property_blob *blob =
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v3
On Thu, May 09, 2019 at 03:06:09PM +0200, Daniel Vetter wrote:
> On Thu, May 9, 2019 at 2:31 PM Peter Zijlstra wrote:
> > On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> > > Fix this by creating a prinkt_safe_up() which calls wake_up_process
> > > outside of the spinlock. This isn't correct in full generality, but
> > > good enough for console_lock:
> > >
> > > - console_lock doesn't use interruptible or killable or timeout down()
> > > calls, hence an up() is the only thing that can wake up a process.
> >
> > Wrong :/ Any task can be woken at any random time. We must, at all
> > times, assume spurious wakeups will happen.
>
> Out of curiosity, where do these come from? I know about the races
> where you need to recheck on the waiter side to avoid getting stuck,
> but didn't know about this. Are these earlier (possibly spurious)
> wakeups that got held up and delayed for a while, then hit the task
> much later when it's already continued doing something else?
Yes, this. So they all more or less have the form:
CPU0CPU1
enqueue_waiter()
done = true;
if (waiters)
for (;;) {
if (done)
break;
...
}
dequeue_waiter()
do something else again
wake_up_task
The wake_q thing made the above much more common, but we've had it
forever.
> Or even
> more random, and even if I never put a task on a wait list or anything
> else, ever, it can get woken spuriously?
I had patches that did that on purpose, but no.
> > Something like the below might work.
>
> Yeah that looks like the proper fix. I guess semaphores are uncritical
> enough that we can roll this out for everyone. Thanks for the hint.
It's actually an optimization that we never did because semaphores are
so uncritical :-)
The thing is, by delaying the wakup until after we've released the
spinlock, the waiter will not contend on the spinlock the moment it
wakes.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:drm-intel-next-queued 4/6] drivers/gpu/drm/drm_hdcp.c:27:3: sparse: sparse: symbol 'srm_data' was not declared. Should it be static?
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: c16fd9be70faf3c49a61700efd16018dd910e390 commit: 6498bf5800a302ef69e7f4914e727893f278bb2f [4/6] drm: revocation check at drm subsystem reproduce: # apt-get install sparse git checkout 6498bf5800a302ef69e7f4914e727893f278bb2f make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/drm_hdcp.c:27:3: sparse: sparse: symbol 'srm_data' was not >> declared. Should it be static? >> drivers/gpu/drm/drm_hdcp.c:235:6: sparse: sparse: symbol >> 'drm_hdcp_request_srm' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH drm-intel] drm: drm_hdcp_request_srm() can be static
Fixes: 6498bf5800a3 ("drm: revocation check at drm subsystem")
Signed-off-by: kbuild test robot
---
drm_hdcp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 5e54095..dc0beb3 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -232,7 +232,7 @@ static void drm_hdcp_srm_update(const u8 *buf, size_t count)
drm_hdcp_parse_hdcp2_srm(buf, count);
}
-void drm_hdcp_request_srm(struct drm_device *drm_dev)
+static void drm_hdcp_request_srm(struct drm_device *drm_dev)
{
char fw_name[36] = "display_hdcp_srm.bin";
const struct firmware *fw;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v3
On Thu, May 9, 2019 at 2:31 PM Peter Zijlstra wrote:
> On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> > Fix this by creating a prinkt_safe_up() which calls wake_up_process
> > outside of the spinlock. This isn't correct in full generality, but
> > good enough for console_lock:
> >
> > - console_lock doesn't use interruptible or killable or timeout down()
> > calls, hence an up() is the only thing that can wake up a process.
>
> Wrong :/ Any task can be woken at any random time. We must, at all
> times, assume spurious wakeups will happen.
Out of curiosity, where do these come from? I know about the races
where you need to recheck on the waiter side to avoid getting stuck,
but didn't know about this. Are these earlier (possibly spurious)
wakeups that got held up and delayed for a while, then hit the task
much later when it's already continued doing something else? Or even
more random, and even if I never put a task on a wait list or anything
else, ever, it can get woken spuriously?
> > +void printk_safe_up(struct semaphore *sem)
> > +{
> > + unsigned long flags;
> > + struct semaphore_waiter *waiter = NULL;
> > +
> > + raw_spin_lock_irqsave(>lock, flags);
> > + if (likely(list_empty(>wait_list))) {
> > + sem->count++;
> > + } else {
> > + waiter = list_first_entry(>wait_list,
> > + struct semaphore_waiter, list);
> > + list_del(>list);
> > + waiter->up = true;
> > + }
> > + raw_spin_unlock_irqrestore(>lock, flags);
> > +
> > + if (waiter) /* protected by being sole wake source */
> > + wake_up_process(waiter->task);
> > +}
> > +EXPORT_SYMBOL(printk_safe_up);
>
> Since its only used from printk, that EXPORT really isn't needed.
>
> Something like the below might work.
Yeah that looks like the proper fix. I guess semaphores are uncritical
enough that we can roll this out for everyone. Thanks for the hint.
-Daniel
>
> ---
> kernel/locking/semaphore.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
> index 561acdd39960..ac0a67e95aac 100644
> --- a/kernel/locking/semaphore.c
> +++ b/kernel/locking/semaphore.c
> @@ -38,7 +38,6 @@ static noinline void __down(struct semaphore *sem);
> static noinline int __down_interruptible(struct semaphore *sem);
> static noinline int __down_killable(struct semaphore *sem);
> static noinline int __down_timeout(struct semaphore *sem, long timeout);
> -static noinline void __up(struct semaphore *sem);
>
> /**
> * down - acquire the semaphore
> @@ -178,14 +177,24 @@ EXPORT_SYMBOL(down_timeout);
> */
> void up(struct semaphore *sem)
> {
> + struct semaphore_waiter *waiter;
> + DEFINE_WAKE_Q(wake_q);
> unsigned long flags;
>
> raw_spin_lock_irqsave(>lock, flags);
> - if (likely(list_empty(>wait_list)))
> + if (likely(list_empty(>wait_list))) {
> sem->count++;
> - else
> - __up(sem);
> + goto unlock;
> + }
> +
> + waiter = list_first_entry(>wait_list, struct semaphore_waiter,
> list);
> + list_del(>list);
> + waiter->up = true;
> + wake_q_add(_q, waiter->task);
> +unlock:
> raw_spin_unlock_irqrestore(>lock, flags);
> +
> + wake_up_q(_q);
> }
> EXPORT_SYMBOL(up);
>
> @@ -252,12 +261,3 @@ static noinline int __sched __down_timeout(struct
> semaphore *sem, long timeout)
> {
> return __down_common(sem, TASK_UNINTERRUPTIBLE, timeout);
> }
> -
> -static noinline void __sched __up(struct semaphore *sem)
> -{
> - struct semaphore_waiter *waiter = list_first_entry(>wait_list,
> - struct semaphore_waiter,
> list);
> - list_del(>list);
> - waiter->up = true;
> - wake_up_process(waiter->task);
> -}
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v2
On Thu, May 09, 2019 at 11:32:57AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-05-06 08:45:53)
> > +/**
> > + * printk_safe_up - release the semaphore in console_unlock
> > + * @sem: the semaphore to release
> > + *
> > + * Release the semaphore. Unlike mutexes, up() may be called from any
> > + * context and even by tasks which have never called down().
> > + *
> > + * NOTE: This is a special version of up() for console_unlock only. It is
> > only
> > + * safe if there are no killable, interruptible or timing out down() calls.
> > + */
> > +void printk_safe_up(struct semaphore *sem)
> > +{
> > + unsigned long flags;
> > + struct semaphore_waiter *waiter = NULL;
> > +
> > + raw_spin_lock_irqsave(>lock, flags);
> > + if (likely(list_empty(>wait_list))) {
> > + sem->count++;
> > + } else {
> > + waiter = list_first_entry(>wait_list,
> > + struct semaphore_waiter, list);
> > + list_del(>list);
> > + waiter->up = true;
> > + }
> > + raw_spin_unlock_irqrestore(>lock, flags);
> > +
> > + if (waiter)
> > + wake_up_process(waiter->task);
>
> From comparing against __down_common() there's a risk here that as soon
> as waiter->up == true, the waiter may complete and make the onstack
> struct semaphore_waiter invalid. If you store waiter->task locally under
> the spinlock that problem is resolved.
>
> Then there is the issue of an unprotected dereference of the task in
> wake_up_process() -- I think you can wrap this function with
> rcu_read_lock() to keep that safe, and wake_up_process() should be a
> no-op if it races against process termination.
task_struct is not RCU protected, see task_rcu_dereference() for magic.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix fastset vs. pfit on/off on HSW EDP transcoder
On Wed, May 08, 2019 at 12:46:09PM +0200, Maarten Lankhorst wrote:
> Op 25-04-2019 om 18:29 schreef Ville Syrjala:
> > From: Ville Syrjälä
> >
> > On HSW the pipe A panel fitter lives inside the display power well,
> > and the input MUX for the EDP transcoder needs to be configured
> > appropriately to route the data through the power well as needed.
> > Changing the MUX setting is not allowed while the pipe is active,
> > so we need to force a full modeset whenever we need to change it.
> >
> > Currently we may end up doing a fastset which won't change the
> > MUX settings, but it will drop the power well reference, and that
> > kills the pipe.
> >
> > Cc: sta...@vger.kernel.org
> > Cc: Hans de Goede
> > Cc: Maarten Lankhorst
> > Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 9 +
> > drivers/gpu/drm/i915/intel_pipe_crc.c | 13 ++---
> > 2 files changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index c67f165b466c..691c9a929164 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12133,6 +12133,7 @@ intel_pipe_config_compare(struct drm_i915_private
> > *dev_priv,
> > struct intel_crtc_state *pipe_config,
> > bool adjust)
> > {
> > + struct intel_crtc *crtc = to_intel_crtc(current_config->base.crtc);
> > bool ret = true;
> > bool fixup_inherited = adjust &&
> > (current_config->base.mode.private_flags &
> > I915_MODE_FLAG_INHERITED) &&
> > @@ -12354,6 +12355,14 @@ intel_pipe_config_compare(struct drm_i915_private
> > *dev_priv,
> > PIPE_CONF_CHECK_X(gmch_pfit.pgm_ratios);
> > PIPE_CONF_CHECK_X(gmch_pfit.lvds_border_bits);
> >
> > + /*
> > +* Changing the EDP transcoder input mux
> > +* (A_ONOFF vs. A_ON) requires a full modeset.
> > +*/
> > + if (IS_HASWELL(dev_priv) && crtc->pipe == PIPE_A &&
> > + current_config->cpu_transcoder == TRANSCODER_EDP)
> > + PIPE_CONF_CHECK_BOOL(pch_pfit.enabled);
>
> I guess it depends if we want to make it a blocker or not..
>
> > +
> > if (!adjust) {
> > PIPE_CONF_CHECK_I(pipe_src_w);
> > PIPE_CONF_CHECK_I(pipe_src_h);
> > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > index e94b5b1bc1b7..e7c7be4911c1 100644
> > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > @@ -311,10 +311,17 @@ intel_crtc_crc_setup_workarounds(struct intel_crtc
> > *crtc, bool enable)
> > pipe_config->base.mode_changed = pipe_config->has_psr;
> > pipe_config->crc_enabled = enable;
> >
> > - if (IS_HASWELL(dev_priv) && crtc->pipe == PIPE_A) {
> > + if (IS_HASWELL(dev_priv) &&
> > + pipe_config->base.active && crtc->pipe == PIPE_A &&
> > + pipe_config->cpu_transcoder == TRANSCODER_EDP) {
> > + bool old_need_power_well = pipe_config->pch_pfit.enabled ||
> > + pipe_config->pch_pfit.force_thru;
> > + bool new_need_power_well = pipe_config->pch_pfit.enabled ||
> > + enable;
> > +
> > pipe_config->pch_pfit.force_thru = enable;
> > - if (pipe_config->cpu_transcoder == TRANSCODER_EDP &&
> > - pipe_config->pch_pfit.enabled != enable)
> > +
> > + if (old_need_power_well != new_need_power_well)
> > pipe_config->base.connectors_changed = true;
>
> Could we get rid of this logic and set mode_changed instead?
>
> Ah, I see that is done in 2/2, much less surprises then. :)
Yeah, wanted to keep the fix itself minimal for backporting.
>
> In that case, for both:
>
> Reviewed-by: Maarten Lankhorst
Thanks. Series pushed.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 7/8] drm/i915: Bump fb stride limit to 128KiB for gen4+ and 256KiB for gen7+
From: Ville Syrjälä
With gtt remapping plugged in we can simply raise the stride
limit on gen4+. Let's just pick the limit to match the render
engine max stride (256KiB on gen7+, 128KiB on gen4+).
No remapping CCS because the virtual address of each page actually
matters due to the new hash mode
(WaCompressedResourceDisplayNewHashMode:skl,kbl etc.), and no
remapping on gen2/3 due extra complications from fence alignment
and gen2 2KiB GTT tile size. Also no real benefit since the
display engine limits already match the other limits.
v2: Rebase due to is_ccs_modifier()
v3: Tweak the comment and commit msg
v4: Fix gen4+ stride limit to be 128KiB
Reviewed-by: Daniel Vetter #v3
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fa317c40d548..a2e4ef938d53 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2519,6 +2519,19 @@ static
u32 intel_fb_max_stride(struct drm_i915_private *dev_priv,
u32 pixel_format, u64 modifier)
{
+ /*
+* Arbitrary limit for gen4+ chosen to match the
+* render engine max stride.
+*
+* The new CCS hash mode makes remapping impossible
+*/
+ if (!is_ccs_modifier(modifier)) {
+ if (INTEL_GEN(dev_priv) >= 7)
+ return 256*1024;
+ else if (INTEL_GEN(dev_priv) >= 4)
+ return 128*1024;
+ }
+
return intel_plane_fb_max_stride(dev_priv, pixel_format, modifier);
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 6/8] drm/i915: Align dumb buffer stride to 4k to allow for gtt remapping
From: Ville Syrjälä
Align dumb buffer stride to 4k if the fb will be big enough to
require gtt remapping.
v2: Leave the stride alone for buffers that look to be for the cursor
v3: Make it not a hack (Daniel)
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem.c | 26 +-
drivers/gpu/drm/i915/intel_display.c | 1 -
drivers/gpu/drm/i915/intel_display.h | 2 ++
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4e474bcf4c22..7cafd5612f71 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -52,6 +52,7 @@
#include "i915_trace.h"
#include "i915_vgpu.h"
+#include "intel_display.h"
#include "intel_drv.h"
#include "intel_frontbuffer.h"
#include "intel_pm.h"
@@ -560,8 +561,31 @@ i915_gem_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
+ int cpp = DIV_ROUND_UP(args->bpp, 8);
+ u32 format;
+
+ switch (cpp) {
+ case 1:
+ format = DRM_FORMAT_C8;
+ break;
+ case 2:
+ format = DRM_FORMAT_RGB565;
+ break;
+ case 4:
+ format = DRM_FORMAT_XRGB;
+ break;
+ default:
+ return -EINVAL;
+ }
+
/* have to work out size/pitch and return them */
- args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 64);
+ args->pitch = ALIGN(args->width * cpp, 64);
+
+ /* align stride to page size so that we can remap */
+ if (args->pitch > intel_plane_fb_max_stride(to_i915(dev), format,
+ DRM_FORMAT_MOD_LINEAR))
+ args->pitch = ALIGN(args->pitch, 4096);
+
args->size = args->pitch * args->height;
return i915_gem_create(file, to_i915(dev),
>size, >handle);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 94faac9e3666..fa317c40d548 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2498,7 +2498,6 @@ bool is_ccs_modifier(u64 modifier)
modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
}
-static
u32 intel_plane_fb_max_stride(struct drm_i915_private *dev_priv,
u32 pixel_format, u64 modifier)
{
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 500eec90928d..1e6533fbd061 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -436,6 +436,8 @@ void intel_link_compute_m_n(u16 bpp, int nlanes,
bool constant_n);
bool is_ccs_modifier(u64 modifier);
void lpt_disable_clkout_dp(struct drm_i915_private *dev_priv);
+u32 intel_plane_fb_max_stride(struct drm_i915_private *dev_priv,
+ u32 pixel_format, u64 modifier);
bool intel_plane_can_remap(const struct intel_plane_state *plane_state);
#endif
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v3
Quoting Daniel Vetter (2019-05-09 13:09:03) > console_trylock, called from within printk, can be called from pretty > much anywhere. Including try_to_wake_up. Note that this isn't common, > usually the box is in pretty bad shape at that point already. But it > really doesn't help when then lockdep jumps in and spams the logs, > potentially obscuring the real backtrace we're really interested in. > One case I've seen (slightly simplified backtrace): > > Call Trace: > > console_trylock+0xe/0x60 > vprintk_emit+0xf1/0x320 > printk+0x4d/0x69 > __warn_printk+0x46/0x90 > native_smp_send_reschedule+0x2f/0x40 > check_preempt_curr+0x81/0xa0 > ttwu_do_wakeup+0x14/0x220 > try_to_wake_up+0x218/0x5f0 > pollwake+0x6f/0x90 > credit_entropy_bits+0x204/0x310 > add_interrupt_randomness+0x18f/0x210 > handle_irq+0x67/0x160 > do_IRQ+0x5e/0x130 > common_interrupt+0xf/0xf > > > This alone isn't a problem, but the spinlock in the semaphore is also > still held while waking up waiters (up() -> __up() -> try_to_wake_up() > callchain), which then closes the runqueue vs. semaphore.lock loop, > and upsets lockdep, which issues a circular locking splat to dmesg. > Worse it upsets developers, since we don't want to spam dmesg with > clutter when the machine is dying already. > > Fix this by creating a prinkt_safe_up() which calls wake_up_process > outside of the spinlock. This isn't correct in full generality, but > good enough for console_lock: > > - console_lock doesn't use interruptible or killable or timeout down() > calls, hence an up() is the only thing that can wake up a process. > Hence the process can't get woken and killed and reaped while we try > to wake it up too. > > - semaphore.c always updates the waiter list while under the spinlock, > so there's no other races. Specifically another process that races > with a quick console_lock/unlock while we've dropped the spinlock > already won't see our own waiter. > > Note that we only have to break the recursion for the semaphore.lock > spinlock of the console_lock. Recursion within various scheduler > related locks is already prevented by the printk_safe_enter/exit pair > in __up_console_sem(). > > Also cc'ing John Ogness since perhaps his printk rework fixes this all > properly. > > v2: Ditch attempt to fix console_trylock. > > v3: Add a comment explaining why the taks we're waking won't > disappear (Chris), and improve commit message to address review > questions. > > Signed-off-by: Daniel Vetter > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: Will Deacon > Cc: Petr Mladek > Cc: Sergey Senozhatsky > Cc: Steven Rostedt > Cc: Daniel Vetter > Cc: John Ogness > Cc: Chris Wilson > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Daniel Vetter I'm a bit nervous about that this is only safe for the precisely controlled conditions, but then again that it is called printk_safe should deter any other users. The logic checks out, and you convinced me that the dereference is protected, so Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915: disable framebuffer compression on GeminiLake
On Thu, 09 May 2019, Daniel Drake wrote:
> Hi,
>
>
> On Thu, Apr 25, 2019 at 4:27 AM Paulo Zanoni wrote:
>>
>> Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
>> > Quoting Jian-Hong Pan (2019-04-23 10:28:10)
>> > > From: Daniel Drake
>> > >
>> > > On many (all?) the Gemini Lake systems we work with, there is frequent
>> > > momentary graphical corruption at the top of the screen, and it seems
>> > > that disabling framebuffer compression can avoid this.
>> > >
>> > > The ticket was reported 6 months ago and has already affected a
>> > > multitude of users, without any real progress being made. So, lets
>> > > disable framebuffer compression on GeminiLake until a solution is found.
>> > >
>> > > Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=108085
>> > > Signed-off-by: Daniel Drake
>> > > Signed-off-by: Jian-Hong Pan
>> >
>> > Fixes: fd7d6c5c8f3e ("drm/i915: enable FBC on gen9+ too") ?
>> > Cc: Paulo Zanoni
>> > Cc: Daniel Vetter
>> > Cc: Jani Nikula
>> > Cc: # v4.11+
>> >
>> > glk landed 1 month before, so that seems the earliest broken point.
>> >
>>
>> The bug is well reported, the bug author is helpful and it even has a
>> description of "steps to reproduce" that looks very easy (although I
>> didn't try it). Everything suggests this is a bug the display team
>> could actually solve with not-so-many hours of debugging.
>>
>> In the meantime, unbreak the systems:
>> Reviewed-by: Paulo Zanoni
>
> Quick ping here. Any further comments on this patch? Can it be applied?
Pushed now, thanks. Needed to get a clean CI result, and I dropped the
ball a bit there, sorry.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 4/8] drm/i915: Shuffle stride checking code around
From: Ville Syrjälä
Reorganize some fb stride checking code a bit to prepare for
gtt remapping. And do a bit of s/pitch/stride/ renaming in the
process for a bit more uniformity (apart from the whole
fb->pitches[] thing).
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 64 ++--
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f4e6e9a8bbf9..321cb6d2bc76 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2509,6 +2509,33 @@ bool is_ccs_modifier(u64 modifier)
modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
}
+static
+u32 intel_fb_max_stride(struct drm_i915_private *dev_priv,
+ u32 pixel_format, u64 modifier)
+{
+ struct intel_crtc *crtc;
+ struct intel_plane *plane;
+
+ /*
+* We assume the primary plane for pipe A has
+* the highest stride limits of them all.
+*/
+ crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
+ plane = to_intel_plane(crtc->base.primary);
+
+ return plane->max_stride(plane, pixel_format, modifier,
+DRM_MODE_ROTATE_0);
+}
+
+static u32
+intel_fb_stride_alignment(const struct drm_framebuffer *fb, int color_plane)
+{
+ if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
+ return 64;
+ else
+ return intel_tile_width_bytes(fb, color_plane);
+}
+
static int
intel_fill_fb_info(struct drm_i915_private *dev_priv,
struct drm_framebuffer *fb)
@@ -3586,15 +3613,6 @@ static bool i9xx_plane_get_hw_state(struct intel_plane
*plane,
return ret;
}
-static u32
-intel_fb_stride_alignment(const struct drm_framebuffer *fb, int color_plane)
-{
- if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
- return 64;
- else
- return intel_tile_width_bytes(fb, color_plane);
-}
-
static void skl_detach_scaler(struct intel_crtc *intel_crtc, int id)
{
struct drm_device *dev = intel_crtc->base.dev;
@@ -14921,31 +14939,13 @@ static const struct drm_framebuffer_funcs
intel_fb_funcs = {
.dirty = intel_user_framebuffer_dirty,
};
-static
-u32 intel_fb_pitch_limit(struct drm_i915_private *dev_priv,
-u32 pixel_format, u64 fb_modifier)
-{
- struct intel_crtc *crtc;
- struct intel_plane *plane;
-
- /*
-* We assume the primary plane for pipe A has
-* the highest stride limits of them all.
-*/
- crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
- plane = to_intel_plane(crtc->base.primary);
-
- return plane->max_stride(plane, pixel_format, fb_modifier,
-DRM_MODE_ROTATE_0);
-}
-
static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
struct drm_i915_gem_object *obj,
struct drm_mode_fb_cmd2 *mode_cmd)
{
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct drm_framebuffer *fb = _fb->base;
- u32 pitch_limit;
+ u32 max_stride;
unsigned int tiling, stride;
int ret = -EINVAL;
int i;
@@ -14997,13 +14997,13 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
goto err;
}
- pitch_limit = intel_fb_pitch_limit(dev_priv, mode_cmd->pixel_format,
- mode_cmd->modifier[0]);
- if (mode_cmd->pitches[0] > pitch_limit) {
+ max_stride = intel_fb_max_stride(dev_priv, mode_cmd->pixel_format,
+mode_cmd->modifier[0]);
+ if (mode_cmd->pitches[0] > max_stride) {
DRM_DEBUG_KMS("%s pitch (%u) must be at most %d\n",
mode_cmd->modifier[0] != DRM_FORMAT_MOD_LINEAR ?
"tiled" : "linear",
- mode_cmd->pitches[0], pitch_limit);
+ mode_cmd->pitches[0], max_stride);
goto err;
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v3
On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> Fix this by creating a prinkt_safe_up() which calls wake_up_process
> outside of the spinlock. This isn't correct in full generality, but
> good enough for console_lock:
>
> - console_lock doesn't use interruptible or killable or timeout down()
> calls, hence an up() is the only thing that can wake up a process.
Wrong :/ Any task can be woken at any random time. We must, at all
times, assume spurious wakeups will happen.
> +void printk_safe_up(struct semaphore *sem)
> +{
> + unsigned long flags;
> + struct semaphore_waiter *waiter = NULL;
> +
> + raw_spin_lock_irqsave(>lock, flags);
> + if (likely(list_empty(>wait_list))) {
> + sem->count++;
> + } else {
> + waiter = list_first_entry(>wait_list,
> + struct semaphore_waiter, list);
> + list_del(>list);
> + waiter->up = true;
> + }
> + raw_spin_unlock_irqrestore(>lock, flags);
> +
> + if (waiter) /* protected by being sole wake source */
> + wake_up_process(waiter->task);
> +}
> +EXPORT_SYMBOL(printk_safe_up);
Since its only used from printk, that EXPORT really isn't needed.
Something like the below might work.
---
kernel/locking/semaphore.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index 561acdd39960..ac0a67e95aac 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -38,7 +38,6 @@ static noinline void __down(struct semaphore *sem);
static noinline int __down_interruptible(struct semaphore *sem);
static noinline int __down_killable(struct semaphore *sem);
static noinline int __down_timeout(struct semaphore *sem, long timeout);
-static noinline void __up(struct semaphore *sem);
/**
* down - acquire the semaphore
@@ -178,14 +177,24 @@ EXPORT_SYMBOL(down_timeout);
*/
void up(struct semaphore *sem)
{
+ struct semaphore_waiter *waiter;
+ DEFINE_WAKE_Q(wake_q);
unsigned long flags;
raw_spin_lock_irqsave(>lock, flags);
- if (likely(list_empty(>wait_list)))
+ if (likely(list_empty(>wait_list))) {
sem->count++;
- else
- __up(sem);
+ goto unlock;
+ }
+
+ waiter = list_first_entry(>wait_list, struct semaphore_waiter,
list);
+ list_del(>list);
+ waiter->up = true;
+ wake_q_add(_q, waiter->task);
+unlock:
raw_spin_unlock_irqrestore(>lock, flags);
+
+ wake_up_q(_q);
}
EXPORT_SYMBOL(up);
@@ -252,12 +261,3 @@ static noinline int __sched __down_timeout(struct
semaphore *sem, long timeout)
{
return __down_common(sem, TASK_UNINTERRUPTIBLE, timeout);
}
-
-static noinline void __sched __up(struct semaphore *sem)
-{
- struct semaphore_waiter *waiter = list_first_entry(>wait_list,
- struct semaphore_waiter, list);
- list_del(>list);
- waiter->up = true;
- wake_up_process(waiter->task);
-}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 8/8] drm/i915: Bump gen7+ fb size limits to 16kx16k
From: Ville Syrjälä
With gtt remapping in place we can use arbitrarily large
framebuffers. Let's bump the limits to 16kx16k on gen7+.
The limit was chosen to match the maximum 2D surface size
of the 3D engine.
With the remapping we could easily go higher than that for the
display engine. However the modesetting ddx will blindly assume
it can handle whatever is reported via kms. The oversized
buffer dimensions are not caught by glamor nor Mesa until
finally an assert will trip when genxml attempts to pack the
SURFACE_STATE. So we pick a safe limit to avoid the X server
from crashing (or potentially misbehaving if the genxml asserts
are compiled out).
Reviewed-by: Daniel Vetter
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110187
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a2e4ef938d53..a495fd2dcaa3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15783,16 +15783,22 @@ int intel_modeset_init(struct drm_device *dev)
}
}
- /* maximum framebuffer dimensions */
- if (IS_GEN(dev_priv, 2)) {
- dev->mode_config.max_width = 2048;
- dev->mode_config.max_height = 2048;
+ /*
+* Maximum framebuffer dimensions, chosen to match
+* the maximum render engine surface size on gen4+.
+*/
+ if (INTEL_GEN(dev_priv) >= 7) {
+ dev->mode_config.max_width = 16384;
+ dev->mode_config.max_height = 16384;
+ } else if (INTEL_GEN(dev_priv) >= 4) {
+ dev->mode_config.max_width = 8192;
+ dev->mode_config.max_height = 8192;
} else if (IS_GEN(dev_priv, 3)) {
dev->mode_config.max_width = 4096;
dev->mode_config.max_height = 4096;
} else {
- dev->mode_config.max_width = 8192;
- dev->mode_config.max_height = 8192;
+ dev->mode_config.max_width = 2048;
+ dev->mode_config.max_height = 2048;
}
if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/8] drm/i915: GTT remapping for display
From: Ville Syrjälä Here's a new version of the GTT remapping series. Changes since last time: - Split up some code shuffling from the main patch - Made the dumb stride alignment proper - Finished the test case - Fixed a few bugs found in testing The one thing I didn't do is make remapping always happen. The main reason is that it would break FBC, and I don't want to rewrite the FBC code right now. Test-with: 20190508162906.20808-1-ville.syrj...@linux.intel.com Ville Syrjälä (8): drm/i915: Add a new "remapped" gtt_view drm/i915/selftests: Add mock selftest for remapped vmas drm/i915/selftests: Add live vma selftest drm/i915: Shuffle stride checking code around drm/i915: Overcome display engine stride limits via GTT remapping drm/i915: Align dumb buffer stride to 4k to allow for gtt remapping drm/i915: Bump fb stride limit to 128KiB for gen4+ and 256KiB for gen7+ drm/i915: Bump gen7+ fb size limits to 16kx16k drivers/gpu/drm/i915/i915_debugfs.c | 12 + drivers/gpu/drm/i915/i915_drv.h | 4 + drivers/gpu/drm/i915/i915_gem.c | 43 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 88 drivers/gpu/drm/i915/i915_gem_gtt.h | 25 +- drivers/gpu/drm/i915/i915_vma.c | 10 +- drivers/gpu/drm/i915/i915_vma.h | 3 + drivers/gpu/drm/i915/intel_display.c | 453 ++ drivers/gpu/drm/i915/intel_display.h | 4 + drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_sprite.c | 34 +- .../drm/i915/selftests/i915_live_selftests.h | 1 + drivers/gpu/drm/i915/selftests/i915_vma.c | 246 +- 13 files changed, 798 insertions(+), 126 deletions(-) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/8] drm/i915: Add a new "remapped" gtt_view
From: Ville Syrjälä
To overcome display engine stride limits we'll want to remap the
pages in the GTT. To that end we need a new gtt_view type which
is just like the "rotated" type except not rotated.
v2: Use intel_remapped_plane_info base type
s/unused/unused_mbz/ (Chris)
Separate BUILD_BUG_ON()s (Chris)
Use I915_GTT_PAGE_SIZE (Chris)
v3: Use i915_gem_object_get_dma_address() (Chris)
Trim the sg (Tvrtko)
v4: Actually trim this time. Limit the max length
to one row of pages to keep things simple
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Daniel Vetter
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 12
drivers/gpu/drm/i915/i915_drv.h | 4 ++
drivers/gpu/drm/i915/i915_gem.c | 17 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 88 +++
drivers/gpu/drm/i915/i915_gem_gtt.h | 25 +--
drivers/gpu/drm/i915/i915_vma.c | 6 +-
drivers/gpu/drm/i915/i915_vma.h | 3 +
drivers/gpu/drm/i915/intel_display.c | 11 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/selftests/i915_vma.c | 6 +-
10 files changed, 163 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 072464a18050..633a08c0f907 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -212,6 +212,18 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
vma->ggtt_view.rotated.plane[1].offset);
break;
+ case I915_GGTT_VIEW_REMAPPED:
+ seq_printf(m, ", remapped [(%ux%u, stride=%u,
offset=%u), (%ux%u, stride=%u, offset=%u)]",
+
vma->ggtt_view.remapped.plane[0].width,
+
vma->ggtt_view.remapped.plane[0].height,
+
vma->ggtt_view.remapped.plane[0].stride,
+
vma->ggtt_view.remapped.plane[0].offset,
+
vma->ggtt_view.remapped.plane[1].width,
+
vma->ggtt_view.remapped.plane[1].height,
+
vma->ggtt_view.remapped.plane[1].stride,
+
vma->ggtt_view.remapped.plane[1].offset);
+ break;
+
default:
MISSING_CASE(vma->ggtt_view.type);
break;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d0257808734c..c6d519e67ed0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2859,6 +2859,10 @@ i915_gem_object_get_dirty_page(struct
drm_i915_gem_object *obj,
unsigned int n);
dma_addr_t
+i915_gem_object_get_dma_address_len(struct drm_i915_gem_object *obj,
+ unsigned long n,
+ unsigned int *len);
+dma_addr_t
i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj,
unsigned long n);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2fcec1bfb038..4e474bcf4c22 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5081,16 +5081,29 @@ i915_gem_object_get_dirty_page(struct
drm_i915_gem_object *obj,
}
dma_addr_t
-i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj,
- unsigned long n)
+i915_gem_object_get_dma_address_len(struct drm_i915_gem_object *obj,
+ unsigned long n,
+ unsigned int *len)
{
struct scatterlist *sg;
unsigned int offset;
sg = i915_gem_object_get_sg(obj, n, );
+
+ if (len)
+ *len = sg_dma_len(sg) - (offset << PAGE_SHIFT);
+
return sg_dma_address(sg) + (offset << PAGE_SHIFT);
}
+dma_addr_t
+i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj,
+ unsigned long n)
+{
+ return i915_gem_object_get_dma_address_len(obj, n, NULL);
+}
+
+
int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj, int align)
{
struct sg_table *pages;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8f5db787b7f2..9ed41aefb456 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3608,6 +3608,89 @@ intel_rotate_pages(struct intel_rotation_info *rot_info,
return ERR_PTR(ret);
}
+static struct scatterlist *
+remap_pages(struct drm_i915_gem_object *obj, unsigned int offset,
+ unsigned int width, unsigned
[Intel-gfx] [PATCH v4 5/8] drm/i915: Overcome display engine stride limits via GTT remapping
From: Ville Syrjälä
The display engine stride limits are getting in our way. On SKL+
we are limited to 8k pixels, which is easily exceeded with three
4k displays. To overcome this limitation we can remap the pages
in the GTT to provide the display engine with a view of memory
with a smaller stride.
The code is mostly already there as We already play tricks with
the plane surface address and x/y offsets.
A few caveats apply:
* linear buffers need the fb stride to be page aligned, as
otherwise the remapped lines wouldn't start at the same
spot
* compressed buffers can't be remapped due to the new
ccs hash mode causing the virtual address of the pages
to affect the interpretation of the compressed data. IIRC
the old hash was limited to the low 12 bits so if we were
using that mode we could remap. As it stands we just refuse
to remapp with compressed fbs.
* no remapping gen2/3 as we'd need a fence for the remapped
vma, which we currently don't have. Need to deal with the
fence POT requirements, and do something about the gen2
gtt page size vs tile size difference
v2: Rebase due to is_ccs_modifier()
Fix up the skl+ stride_mult mess
memset() the gtt_view because otherwise we could leave
junk in plane[1] when going from 2 plane to 1 plane format
v3: intel_check_plane_stride() was split out
v4: Drop the aligned viewport stuff, it was meant for ccs which
can't be remapped anyway
v5: Introduce intel_plane_can_remap()
Reorder the code so that plane_state->view gets filled
even for invisible planes, otherwise we'd keep using
stale values and could explode during remapping. The new
logic never remaps invisible planes since we don't have
a viewport, and instead pins the full fb instead
v6: Fix plane src coord checks after remapping by moving
plane_state->base.src to the final plane x/y offsets.
Allow intel_plane_check_stride() to fail even with
remapping (can happen at least with a linear 64bpp
fb with a 4k plane and a suitably inconvenient src
coordinates).
Improve aux plane FIXME (Daniel)
Move some code shuffling into a separate patch (Daniel)
Testcase: igt/kms_big_fb
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 354 ++-
drivers/gpu/drm/i915/intel_display.h | 2 +
drivers/gpu/drm/i915/intel_sprite.c | 34 ++-
3 files changed, 323 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 321cb6d2bc76..94faac9e3666 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1915,7 +1915,7 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
switch (fb->modifier) {
case DRM_FORMAT_MOD_LINEAR:
- return cpp;
+ return intel_tile_size(dev_priv);
case I915_FORMAT_MOD_X_TILED:
if (IS_GEN(dev_priv, 2))
return 128;
@@ -1958,11 +1958,8 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
static unsigned int
intel_tile_height(const struct drm_framebuffer *fb, int color_plane)
{
- if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
- return 1;
- else
- return intel_tile_size(to_i915(fb->dev)) /
- intel_tile_width_bytes(fb, color_plane);
+ return intel_tile_size(to_i915(fb->dev)) /
+ intel_tile_width_bytes(fb, color_plane);
}
/* Return the tile dimensions in pixel units */
@@ -2220,16 +2217,8 @@ void intel_add_fb_offsets(int *x, int *y,
int color_plane)
{
- const struct intel_framebuffer *intel_fb =
to_intel_framebuffer(state->base.fb);
- unsigned int rotation = state->base.rotation;
-
- if (drm_rotation_90_or_270(rotation)) {
- *x += intel_fb->rotated[color_plane].x;
- *y += intel_fb->rotated[color_plane].y;
- } else {
- *x += intel_fb->normal[color_plane].x;
- *y += intel_fb->normal[color_plane].y;
- }
+ *x += state->color_plane[color_plane].x;
+ *y += state->color_plane[color_plane].y;
}
static u32 intel_adjust_tile_offset(int *x, int *y,
@@ -2510,8 +2499,8 @@ bool is_ccs_modifier(u64 modifier)
}
static
-u32 intel_fb_max_stride(struct drm_i915_private *dev_priv,
- u32 pixel_format, u64 modifier)
+u32 intel_plane_fb_max_stride(struct drm_i915_private *dev_priv,
+ u32 pixel_format, u64 modifier)
{
struct intel_crtc *crtc;
struct intel_plane *plane;
@@ -2527,13 +2516,102 @@ u32 intel_fb_max_stride(struct drm_i915_private
*dev_priv,
DRM_MODE_ROTATE_0);
}
+static
+u32 intel_fb_max_stride(struct drm_i915_private *dev_priv,
+ u32 pixel_format, u64 modifier)
+{
+ return
[Intel-gfx] [PATCH v4 3/8] drm/i915/selftests: Add live vma selftest
From: Ville Syrjälä
Add a live selftest to excercise rotated/remapped vmas. We simply
write through the rotated/remapped vma, and confirm that the data
appears in the right page when read through the normal vma.
Not sure what the fallout of making all rotated/remapped vmas
mappable/fenceable would be, hence I just hacked it in the test.
v2: Grab rpm reference (Chris)
GEM_BUG_ON(view.type not as expected) (Chris)
Allow CAN_FENCE for rotated/remapped vmas (Chris)
Update intel_plane_uses_fence() to ask for a fence
only for normal vmas on gen4+
v3: Deal with intel_wakeref_t
v4: Rebase
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_vma.c | 8 -
drivers/gpu/drm/i915/intel_display.c | 4 +-
.../drm/i915/selftests/i915_live_selftests.h | 1 +
drivers/gpu/drm/i915/selftests/i915_vma.c | 142 ++
4 files changed, 146 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index c68b435d4064..343736b2d602 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -483,14 +483,6 @@ void __i915_vma_set_map_and_fenceable(struct i915_vma *vma)
GEM_BUG_ON(!i915_vma_is_ggtt(vma));
GEM_BUG_ON(!vma->fence_size);
- /*
-* Explicitly disable for rotated VMA since the display does not
-* need the fence and the VMA is not accessible to other users.
-*/
- if (vma->ggtt_view.type == I915_GGTT_VIEW_ROTATED ||
- vma->ggtt_view.type == I915_GGTT_VIEW_REMAPPED)
- return;
-
fenceable = (vma->node.size >= vma->fence_size &&
IS_ALIGNED(vma->node.start, vma->fence_alignment));
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0931fe621077..f4e6e9a8bbf9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2077,7 +2077,9 @@ static bool intel_plane_uses_fence(const struct
intel_plane_state *plane_state)
struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
- return INTEL_GEN(dev_priv) < 4 || plane->has_fbc;
+ return INTEL_GEN(dev_priv) < 4 ||
+ (plane->has_fbc &&
+plane_state->view.type == I915_GGTT_VIEW_NORMAL);
}
struct i915_vma *
diff --git a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
index 6d766925ad04..a54f590788a4 100644
--- a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
+++ b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
@@ -17,6 +17,7 @@ selftest(requests, i915_request_live_selftests)
selftest(active, i915_active_live_selftests)
selftest(objects, i915_gem_object_live_selftests)
selftest(dmabuf, i915_gem_dmabuf_live_selftests)
+selftest(vma, i915_vma_live_selftests)
selftest(coherency, i915_gem_coherency_live_selftests)
selftest(gtt, i915_gem_gtt_live_selftests)
selftest(gem, i915_gem_live_selftests)
diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c
b/drivers/gpu/drm/i915/selftests/i915_vma.c
index 89f6ef945c1b..0027c1fac336 100644
--- a/drivers/gpu/drm/i915/selftests/i915_vma.c
+++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
@@ -834,3 +834,145 @@ int i915_vma_mock_selftests(void)
drm_dev_put(>drm);
return err;
}
+
+static int igt_vma_remapped_gtt(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ const struct intel_remapped_plane_info planes[] = {
+ { .width = 1, .height = 1, .stride = 1 },
+ { .width = 2, .height = 2, .stride = 2 },
+ { .width = 4, .height = 4, .stride = 4 },
+ { .width = 8, .height = 8, .stride = 8 },
+
+ { .width = 3, .height = 5, .stride = 3 },
+ { .width = 3, .height = 5, .stride = 4 },
+ { .width = 3, .height = 5, .stride = 5 },
+
+ { .width = 5, .height = 3, .stride = 5 },
+ { .width = 5, .height = 3, .stride = 7 },
+ { .width = 5, .height = 3, .stride = 9 },
+
+ { .width = 4, .height = 6, .stride = 6 },
+ { .width = 6, .height = 4, .stride = 6 },
+ { }
+ }, *p;
+ enum i915_ggtt_view_type types[] = {
+ I915_GGTT_VIEW_ROTATED,
+ I915_GGTT_VIEW_REMAPPED,
+ 0,
+ }, *t;
+ struct drm_i915_gem_object *obj;
+ intel_wakeref_t wakeref;
+ int err = 0;
+
+ obj = i915_gem_object_create_internal(i915, 10 * 10 * PAGE_SIZE);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ mutex_lock(>drm.struct_mutex);
+
+ wakeref = intel_runtime_pm_get(i915);
+
+ for (t = types; *t; t++) {
+ for (p = planes; p->width; p++) {
+ struct
[Intel-gfx] [PATCH v4 2/8] drm/i915/selftests: Add mock selftest for remapped vmas
From: Ville Syrjälä
Extend the rotated vma mock selftest to cover remapped vmas as
well.
TODO: reindent the loops I guess? Left like this for now to
ease review
v2: Include the vma type in the error message (Chris)
v3: Deal with trimmed sg
v4: Drop leftover debugs
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/selftests/i915_vma.c | 98 +--
1 file changed, 90 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c
b/drivers/gpu/drm/i915/selftests/i915_vma.c
index 18dc221cb22b..89f6ef945c1b 100644
--- a/drivers/gpu/drm/i915/selftests/i915_vma.c
+++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
@@ -59,7 +59,7 @@ static bool assert_vma(struct i915_vma *vma,
static struct i915_vma *
checked_vma_instance(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
-struct i915_ggtt_view *view)
+const struct i915_ggtt_view *view)
{
struct i915_vma *vma;
bool ok = true;
@@ -397,13 +397,74 @@ assert_rotated(struct drm_i915_gem_object *obj,
return sg;
}
+static unsigned long remapped_index(const struct intel_remapped_info *r,
+ unsigned int n,
+ unsigned int x,
+ unsigned int y)
+{
+ return (r->plane[n].stride * y +
+ r->plane[n].offset + x);
+}
+
+static struct scatterlist *
+assert_remapped(struct drm_i915_gem_object *obj,
+ const struct intel_remapped_info *r, unsigned int n,
+ struct scatterlist *sg)
+{
+ unsigned int x, y;
+ unsigned int left = 0;
+ unsigned int offset;
+
+ for (y = 0; y < r->plane[n].height; y++) {
+ for (x = 0; x < r->plane[n].width; x++) {
+ unsigned long src_idx;
+ dma_addr_t src;
+
+ if (!sg) {
+ pr_err("Invalid sg table: too short at plane
%d, (%d, %d)!\n",
+ n, x, y);
+ return ERR_PTR(-EINVAL);
+ }
+ if (!left) {
+ offset = 0;
+ left = sg_dma_len(sg);
+ }
+
+ src_idx = remapped_index(r, n, x, y);
+ src = i915_gem_object_get_dma_address(obj, src_idx);
+
+ if (left < PAGE_SIZE || left & (PAGE_SIZE-1)) {
+ pr_err("Invalid sg.length, found %d, expected
%lu for remapped page (%d, %d) [src index %lu]\n",
+ sg_dma_len(sg), PAGE_SIZE,
+ x, y, src_idx);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (sg_dma_address(sg) + offset != src) {
+ pr_err("Invalid address for remapped page (%d,
%d) [src index %lu]\n",
+ x, y, src_idx);
+ return ERR_PTR(-EINVAL);
+ }
+
+ left -= PAGE_SIZE;
+ offset += PAGE_SIZE;
+
+
+ if (!left)
+ sg = sg_next(sg);
+ }
+ }
+
+ return sg;
+}
+
static unsigned int rotated_size(const struct intel_remapped_plane_info *a,
const struct intel_remapped_plane_info *b)
{
return a->width * a->height + b->width * b->height;
}
-static int igt_vma_rotate(void *arg)
+static int igt_vma_rotate_remap(void *arg)
{
struct i915_ggtt *ggtt = arg;
struct i915_address_space *vm = >vm;
@@ -426,6 +487,11 @@ static int igt_vma_rotate(void *arg)
{ .width = 6, .height = 4, .stride = 6 },
{ }
}, *a, *b;
+ enum i915_ggtt_view_type types[] = {
+ I915_GGTT_VIEW_ROTATED,
+ I915_GGTT_VIEW_REMAPPED,
+ 0,
+ }, *t;
const unsigned int max_pages = 64;
int err = -ENOMEM;
@@ -437,6 +503,7 @@ static int igt_vma_rotate(void *arg)
if (IS_ERR(obj))
goto out;
+ for (t = types; *t; t++) {
for (a = planes; a->width; a++) {
for (b = planes + ARRAY_SIZE(planes); b-- != planes; ) {
struct i915_ggtt_view view;
@@ -447,7 +514,7 @@ static int igt_vma_rotate(void *arg)
GEM_BUG_ON(max_offset > max_pages);
max_offset = max_pages - max_offset;
- view.type = I915_GGTT_VIEW_ROTATED;
+ view.type = *t;
view.rotated.plane[0] = *a;
view.rotated.plane[1] = *b;
@@ -468,14 +535,23 @@ static int
Re: [Intel-gfx] [RFT i-g-t] tests/prime_vgem/basic-fence-flip: Probe display resolution
On 09/05/2019 11:51, Kahola, Mika wrote:
On Wed, 2019-04-10 at 13:11 +0100, Tvrtko Ursulin wrote:
On 10/04/2019 12:48, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-04-10 12:43:22)
@@ -754,8 +768,8 @@ static void test_flip(int i915, int vgem,
unsigned hang)
uint32_t offsets[4] = {};
int fd;
- bo[i].width = 1024;
- bo[i].height = 768;
+ bo[i].width = mode->hdisplay;
+ bo[i].height = mode->vdisplay;
bo[i].bpp = 32;
vgem_create(vgem, [i]);
That may not result in a buffer that we are able to flip to. :|
width = ALIGN(hdisplay, 16); vdisplay should be ok.
Oh.. well I don't know. Maarten helpfully described in the BZ that
the
skip is due BO being too small for the FB. Aligning width would then
make it too large. Is that OK? Who assigned this display related IGT
bug
to me anyway? :))
I don't know about that. I have a task to improve the test in my
backlog too :)
This patch definitely improves the test. However, I wasn't able to
apply the patch cleanly on my tree. Maybe it needs a rebase? Anyway, CI
seems to be happy with the change.
Reviewed-by: Mika Kahola
Thanks, pushed!
One less thing on your todo list now. :)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] RFC: console: hack up console_lock more v3
console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring the real backtrace we're really interested in.
One case I've seen (slightly simplified backtrace):
Call Trace:
console_trylock+0xe/0x60
vprintk_emit+0xf1/0x320
printk+0x4d/0x69
__warn_printk+0x46/0x90
native_smp_send_reschedule+0x2f/0x40
check_preempt_curr+0x81/0xa0
ttwu_do_wakeup+0x14/0x220
try_to_wake_up+0x218/0x5f0
pollwake+0x6f/0x90
credit_entropy_bits+0x204/0x310
add_interrupt_randomness+0x18f/0x210
handle_irq+0x67/0x160
do_IRQ+0x5e/0x130
common_interrupt+0xf/0xf
This alone isn't a problem, but the spinlock in the semaphore is also
still held while waking up waiters (up() -> __up() -> try_to_wake_up()
callchain), which then closes the runqueue vs. semaphore.lock loop,
and upsets lockdep, which issues a circular locking splat to dmesg.
Worse it upsets developers, since we don't want to spam dmesg with
clutter when the machine is dying already.
Fix this by creating a prinkt_safe_up() which calls wake_up_process
outside of the spinlock. This isn't correct in full generality, but
good enough for console_lock:
- console_lock doesn't use interruptible or killable or timeout down()
calls, hence an up() is the only thing that can wake up a process.
Hence the process can't get woken and killed and reaped while we try
to wake it up too.
- semaphore.c always updates the waiter list while under the spinlock,
so there's no other races. Specifically another process that races
with a quick console_lock/unlock while we've dropped the spinlock
already won't see our own waiter.
Note that we only have to break the recursion for the semaphore.lock
spinlock of the console_lock. Recursion within various scheduler
related locks is already prevented by the printk_safe_enter/exit pair
in __up_console_sem().
Also cc'ing John Ogness since perhaps his printk rework fixes this all
properly.
v2: Ditch attempt to fix console_trylock.
v3: Add a comment explaining why the taks we're waking won't
disappear (Chris), and improve commit message to address review
questions.
Signed-off-by: Daniel Vetter
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: Daniel Vetter
Cc: John Ogness
Cc: Chris Wilson
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
include/linux/semaphore.h | 1 +
kernel/locking/semaphore.c | 31 +++
kernel/printk/printk.c | 2 +-
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/include/linux/semaphore.h b/include/linux/semaphore.h
index 11c86fbfeb98..7e839c72809d 100644
--- a/include/linux/semaphore.h
+++ b/include/linux/semaphore.h
@@ -41,6 +41,7 @@ extern int __must_check down_interruptible(struct semaphore
*sem);
extern int __must_check down_killable(struct semaphore *sem);
extern int __must_check down_trylock(struct semaphore *sem);
extern int __must_check down_timeout(struct semaphore *sem, long jiffies);
+extern void printk_safe_up(struct semaphore *sem);
extern void up(struct semaphore *sem);
#endif /* __LINUX_SEMAPHORE_H */
diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index 561acdd39960..55a896f18d91 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -197,6 +197,37 @@ struct semaphore_waiter {
bool up;
};
+/**
+ * printk_safe_up - release the semaphore in console_unlock
+ * @sem: the semaphore to release
+ *
+ * Release the semaphore. Unlike mutexes, up() may be called from any
+ * context and even by tasks which have never called down().
+ *
+ * NOTE: This is a special version of up() for console_unlock only. It is only
+ * safe if there are no killable, interruptible or timing out down() calls.
+ */
+void printk_safe_up(struct semaphore *sem)
+{
+ unsigned long flags;
+ struct semaphore_waiter *waiter = NULL;
+
+ raw_spin_lock_irqsave(>lock, flags);
+ if (likely(list_empty(>wait_list))) {
+ sem->count++;
+ } else {
+ waiter = list_first_entry(>wait_list,
+ struct semaphore_waiter, list);
+ list_del(>list);
+ waiter->up = true;
+ }
+ raw_spin_unlock_irqrestore(>lock, flags);
+
+ if (waiter) /* protected by being sole wake source */
+ wake_up_process(waiter->task);
+}
+EXPORT_SYMBOL(printk_safe_up);
+
/*
* Because this function is inlined, the 'state' parameter will be
* constant, and thus optimised away by the compiler. Likewise the
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 02ca827b8fac..62303929afda 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -234,7
Re: [Intel-gfx] [PATCH] i915: disable framebuffer compression on GeminiLake
Hi,
On Thu, Apr 25, 2019 at 4:27 AM Paulo Zanoni wrote:
>
> Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
> > Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> > > From: Daniel Drake
> > >
> > > On many (all?) the Gemini Lake systems we work with, there is frequent
> > > momentary graphical corruption at the top of the screen, and it seems
> > > that disabling framebuffer compression can avoid this.
> > >
> > > The ticket was reported 6 months ago and has already affected a
> > > multitude of users, without any real progress being made. So, lets
> > > disable framebuffer compression on GeminiLake until a solution is found.
> > >
> > > Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=108085
> > > Signed-off-by: Daniel Drake
> > > Signed-off-by: Jian-Hong Pan
> >
> > Fixes: fd7d6c5c8f3e ("drm/i915: enable FBC on gen9+ too") ?
> > Cc: Paulo Zanoni
> > Cc: Daniel Vetter
> > Cc: Jani Nikula
> > Cc: # v4.11+
> >
> > glk landed 1 month before, so that seems the earliest broken point.
> >
>
> The bug is well reported, the bug author is helpful and it even has a
> description of "steps to reproduce" that looks very easy (although I
> didn't try it). Everything suggests this is a bug the display team
> could actually solve with not-so-many hours of debugging.
>
> In the meantime, unbreak the systems:
> Reviewed-by: Paulo Zanoni
Quick ping here. Any further comments on this patch? Can it be applied?
Thanks
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFT i-g-t] tests/prime_vgem/basic-fence-flip: Probe display resolution
On Wed, 2019-04-10 at 13:11 +0100, Tvrtko Ursulin wrote:
> On 10/04/2019 12:48, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-04-10 12:43:22)
> > > @@ -754,8 +768,8 @@ static void test_flip(int i915, int vgem,
> > > unsigned hang)
> > > uint32_t offsets[4] = {};
> > > int fd;
> > >
> > > - bo[i].width = 1024;
> > > - bo[i].height = 768;
> > > + bo[i].width = mode->hdisplay;
> > > + bo[i].height = mode->vdisplay;
> > > bo[i].bpp = 32;
> > > vgem_create(vgem, [i]);
> >
> > That may not result in a buffer that we are able to flip to. :|
> > width = ALIGN(hdisplay, 16); vdisplay should be ok.
>
> Oh.. well I don't know. Maarten helpfully described in the BZ that
> the
> skip is due BO being too small for the FB. Aligning width would then
> make it too large. Is that OK? Who assigned this display related IGT
> bug
> to me anyway? :))
I don't know about that. I have a task to improve the test in my
backlog too :)
This patch definitely improves the test. However, I wasn't able to
apply the patch cleanly on my tree. Maybe it needs a rebase? Anyway, CI
seems to be happy with the change.
Reviewed-by: Mika Kahola
>
> > I would query what happened to the scalers though :)
>
> Are they supposed to automagicaly apply any fb to any output? Or an
> explicit step is required? Regardless - it may be better to involve
> less
> of the driver and hardware stack in a simple test.
>
> 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] [PATCH v2 04/11] drm/i915: Add support for asynchronous display power disabling
On Thu, May 09, 2019 at 09:17:54AM +0100, Chris Wilson wrote: > Quoting Imre Deak (2019-05-09 07:19:47) > > By disabling a power domain asynchronously we can restrict holding a > > reference on that power domain to the actual code sequence that > > requires the power to be on for the HW access it's doing, by also > > avoiding unneeded on-off-on togglings of the power domain (since the > > disabling happens with a delay). > > > > One benefit is potential power saving due to the following two reasons: > > 1. The fact that we will now be holding the reference only for the > >necessary duration by the end of the patchset. While simply not > >delaying the disabling has the same benefit, it has the problem that > >frequent on-off-on power switching has its own power cost (see the 2. > >point below) and the debug trace for power well on/off events will > >cause a lot of dmesg spam (see details about this further below). > > 2. Avoiding the power cost of freuqent on-off-on power switching. This > >requires us to find the optimal disabling delay based on the measured > >power cost of on->off and off->on switching of each power well vs. > >the power of keeping the given power well on. > > > >In this patchset I'm not providing this optimal delay for two > >reasons: > >a) I don't have the means yet to perform the measurement (with high > > enough signal-to-noise ratio, or with the help of an energy > > counter that takes switching into account). I'm currently looking > > for a way to measure this. > > > >b) Before reducing the disabling delay we need an alternative way for > > debug tracing powerwell on/off events. Simply avoiding/throttling > > the debug messages is not a solution, see further below. > > > >Note that even in the case where we can't measure any considerable > >power cost of frequent on-off switching of powerwells, it still would > >make sense to do the disabling asynchronously (with 0 delay) to avoid > >blocking on the disabling. On VLV I measured this disabling time > >overhead to be 1ms on average with a worst case of 4ms. > > Good point. Again, that would be nice to show in a microbenchmark -- the > latency will still impact the wakeup path (I expect), I thought intel_display_power_grab_async_put_ref() would alleviate that. > the challenge is > identifying userspace path impacted and relating that to workloads. The > further challenge is that since this is power centric, we need to > measure the power vs latency / throughput of such workloads. Ok. I can only promise to do these as a follow-up. We'd need most of all some way for the power measurement, I asked about it from Art et al, but ideas are welcome. The time measurement is easier, I will put together some report about it across all platforms. > > > In the case of the AUX power domains on ICL we would also need to keep > > the sequence where we hold the power reference short, the way it would > > be by the end of this patchset where we hold it only for the actual AUX > > transfer. Anything else would make the locking we need for ICL TypeC > > ports (whenever we hold a reference on any AUX power domain) rather > > problematic, adding for instance unnecessary lockdep dependencies to > > the required TypeC port lock. > > > > I chose the disabling delay to be 100msec for now to avoid the unneeded > > toggling (and so not to introduce dmesg spamming) in the DP MST sideband > > signaling code. We could optimize this delay later, once we have the > > means to measure the switching power cost (see above). > > > > Note that simply removing/throttling the debug tracing for power well > > on/off events is not a solution. We need to know the exact spots of > > these events and cannot rely only on incorrect register accesses caught > > (due to not holding a wakeref at the time of access). Incorrect > > powerwell enabling/disabling could lead to other problems, for instance > > we need to keep certain powerwells enabled for the duration of modesets > > and AUX transfers. > > > > v2: > > - Clarify the commit log parts about power cost measurement and the > > problem of simply removing/throttling debug tracing. (Chris) > > - Optimize out local wakeref vars at intel_runtime_pm_put_raw() and > > intel_display_power_put_async() call sites if > > CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n. (Chris) > > - Rebased on v2 of the wakeref w/o power-on guarantee patch. > > - Add missing docbook headers. > > > > Cc: Chris Wilson > > Cc: Ville Syrjala > > Signed-off-by: Imre Deak > > --- > > drivers/gpu/drm/i915/i915_drv.h | 5 + > > drivers/gpu/drm/i915/intel_runtime_pm.c | 362 +++- > > drivers/gpu/drm/i915/intel_runtime_pm.h | 8 + > > 3 files changed, 368 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > b/drivers/gpu/drm/i915/i915_drv.h > > index d0257808734c..5801f5407589 100644 > >
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v2
Quoting Daniel Vetter (2019-05-06 08:45:53)
> +/**
> + * printk_safe_up - release the semaphore in console_unlock
> + * @sem: the semaphore to release
> + *
> + * Release the semaphore. Unlike mutexes, up() may be called from any
> + * context and even by tasks which have never called down().
> + *
> + * NOTE: This is a special version of up() for console_unlock only. It is
> only
> + * safe if there are no killable, interruptible or timing out down() calls.
> + */
> +void printk_safe_up(struct semaphore *sem)
> +{
> + unsigned long flags;
> + struct semaphore_waiter *waiter = NULL;
> +
> + raw_spin_lock_irqsave(>lock, flags);
> + if (likely(list_empty(>wait_list))) {
> + sem->count++;
> + } else {
> + waiter = list_first_entry(>wait_list,
> + struct semaphore_waiter, list);
> + list_del(>list);
> + waiter->up = true;
> + }
> + raw_spin_unlock_irqrestore(>lock, flags);
> +
> + if (waiter)
> + wake_up_process(waiter->task);
From comparing against __down_common() there's a risk here that as soon
as waiter->up == true, the waiter may complete and make the onstack
struct semaphore_waiter invalid. If you store waiter->task locally under
the spinlock that problem is resolved.
Then there is the issue of an unprotected dereference of the task in
wake_up_process() -- I think you can wrap this function with
rcu_read_lock() to keep that safe, and wake_up_process() should be a
no-op if it races against process termination.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add support for asynchronous display power disabling (rev3)
== Series Details == Series: drm/i915: Add support for asynchronous display power disabling (rev3) URL : https://patchwork.freedesktop.org/series/60242/ State : success == Summary == CI Bug Log - changes from CI_DRM_6068_full -> Patchwork_12990_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12990_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#104108] / [fdo#107773]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-skl6/igt@gem_ctx_isolat...@bcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-skl2/igt@gem_ctx_isolat...@bcs0-s3.html * igt@i915_pm_rpm@sysfs-read: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#107807]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-skl4/igt@i915_pm_...@sysfs-read.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-skl6/igt@i915_pm_...@sysfs-read.html * igt@i915_pm_rpm@system-suspend: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#104108] / [fdo#107807]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-skl9/igt@i915_pm_...@system-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-skl4/igt@i915_pm_...@system-suspend.html * igt@i915_suspend@fence-restore-untiled: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +5 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-apl2/igt@i915_susp...@fence-restore-untiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-apl3/igt@i915_susp...@fence-restore-untiled.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-iclb3/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-iclb8/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-kbl5/igt@kms_frontbuffer_track...@fbc-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-kbl7/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109642]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-iclb2/igt@kms_psr2...@frontbuffer.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-iclb7/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#108341]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-iclb5/igt@kms_psr@no_drrs.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_dpms: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-iclb2/igt@kms_psr@psr2_dpms.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-iclb4/igt@kms_psr@psr2_dpms.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-apl1/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-apl5/igt@kms_setm...@basic.html - shard-hsw: [PASS][23] -> [FAIL][24] ([fdo#99912]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-hsw6/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-hsw2/igt@kms_setm...@basic.html Possible fixes * igt@kms_flip@2x-flip-vs-suspend: - shard-hsw: [INCOMPLETE][25] ([fdo#103540]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6068/shard-hsw2/igt@kms_f...@2x-flip-vs-suspend.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12990/shard-hsw5/igt@kms_f...@2x-flip-vs-suspend.html *
Re: [Intel-gfx] [PATCH 2/2] RFC: soft/hardlookup: taint kernel
On Thu, May 9, 2019 at 11:24 AM Sergey Senozhatsky
wrote:
>
> On (05/02/19 21:42), Daniel Vetter wrote:
> [..]
> > @@ -469,6 +469,8 @@ static enum hrtimer_restart watchdog_timer_fn(struct
> > hrtimer *hrtimer)
> > add_taint(TAINT_SOFTLOCKUP, LOCKDEP_STILL_OK);
> > if (softlockup_panic)
> > panic("softlockup: hung tasks");
> > + else
> > + add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
> > __this_cpu_write(soft_watchdog_warn, true);
>
> Soft lockup sets TAINT_SOFTLOCKUP bit. Would it be enough for your CI?
I'm blind :-/ Yes this is totally useful.
> [..]
> > @@ -154,6 +154,8 @@ static void watchdog_overflow_callback(struct
> > perf_event *event,
> >
> > if (hardlockup_panic)
> > nmi_panic(regs, "Hard LOCKUP");
> > + else
> > + add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
>
> Maybe you can mirror what soft lockup does. Add a HARDLOCKUP taint bit
We'd also want a taint for hung tasks (separate patch, same idea), not
sure it's a good idea to use a new taint bit for all of them? Atm we
don't check for all taint bits (some of them are set because of things
our testcases do, like module reload or setting unsafe kernel options
meant for testing only, so picking one of the bits we check already
was least resistance.
> +++ b/include/linux/kernel.h
> @@ -571,7 +571,8 @@ extern enum system_states {
> #define TAINT_LIVEPATCH15
> #define TAINT_AUX 16
> #define TAINT_RANDSTRUCT 17
> -#define TAINT_FLAGS_COUNT 18
> +#define TAINT_HARDLOCKUP 18
> +#define TAINT_FLAGS_COUNT 19
>
> and then set TAINT_HARDLOCKUP in watchdog_overflow_callback().
>
> Just a small idea, I'll leave this to more experienced people.
The hung_tasks taint wasn't all that positively received, I feels like
this will stay a hack private to our CI. Except if someone else pipes
up who wants this, then I'm happy to polish.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave & Daniel, Still rather quiet, most issues seem to have been fixed during CI testing. For i915, just two fixes to the request semaphore ordering code. For GVT a couple regression and static checker fixes. Best Regards, Joonas *** drm-intel-next-fixes-2019-05-09: - Two fixes for the freshly enabled semaphore ordering code - Includes gvt-next-fixes-2019-05-07 The following changes since commit 9628e15ca9d5f7595ba886173e98a139d0a56cd1: drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1 (2019-04-30 10:16:18 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-05-09 for you to fetch changes up to 23372cce8fe7ee98a6458fd3d035a55b87f0c6fe: Merge tag 'gvt-next-fixes-2019-05-07' of https://github.com/intel/gvt-linux into drm-intel-next-fixes (2019-05-07 15:29:15 +0300) - Two fixes for the freshly enabled semaphore ordering code - Includes gvt-next-fixes-2019-05-07 Aleksei Gimbitskii (4): drm/i915/gvt: Remove typedef and let the enumeration starts from zero drm/i915/gvt: Do not copy the uninitialized pointer from fb_info drm/i915/gvt: Use snprintf() to prevent possible buffer overflow. drm/i915/gvt: Check if get_next_pt_type() always returns a valid value Chris Wilson (2): drm/i915: Delay semaphore submission until the start of the signaler drm/i915: Disable semaphore busywaits on saturated systems Colin Xu (1): drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list Joonas Lahtinen (1): Merge tag 'gvt-next-fixes-2019-05-07' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Xiong Zhang (1): drm/i915/gvt: Change fb_info->size from pages to bytes Zhao Yakui (1): drm/i915/gvt: Revert "drm/i915/gvt: Refine the snapshort range of I915 MCHBAR to optimize gvt-g boot time" drivers/gpu/drm/i915/gvt/debugfs.c | 4 +- drivers/gpu/drm/i915/gvt/dmabuf.c | 19 -- drivers/gpu/drm/i915/gvt/gtt.c | 15 +--- drivers/gpu/drm/i915/gvt/gtt.h | 16 drivers/gpu/drm/i915/gvt/handlers.c| 4 +- drivers/gpu/drm/i915/gvt/mmio_context.c| 1 + drivers/gpu/drm/i915/gvt/reg.h | 3 -- drivers/gpu/drm/i915/gvt/scheduler.c | 2 +- drivers/gpu/drm/i915/i915_request.c| 59 +- drivers/gpu/drm/i915/intel_context.c | 1 + drivers/gpu/drm/i915/intel_context_types.h | 3 ++ 11 files changed, 93 insertions(+), 34 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Add support for tracking wakerefs w/o power-on guarantee
On Thu, May 09, 2019 at 09:03:04AM +0100, Chris Wilson wrote:
> Quoting Imre Deak (2019-05-09 07:19:44)
> > It's useful to track runtime PM refs that don't guarantee a device
> > power-on state to the rest of the driver. One such case is holding a
> > reference that will be put asynchronously, during which normal users
> > without their own reference shouldn't access the HW. A follow-up patch
> > will add support for disabling display power domains asynchronously
> > which needs this.
> >
> > For this we can split wakeref_count into a low half-word tracking
> > all references (raw-wakerefs) and a high half-word tracking
> > references guaranteeing a power-on state (wakelocks).
> >
> > Follow-up patches will make use of the API added here.
> >
> > While at it add the missing docbook header for the unchecked
> > display-power and runtime_pm put functions.
> >
> > No functional changes, except for printing leaked raw-wakerefs
> > and wakelocks separately in intel_runtime_pm_cleanup().
> >
> > v2:
> > - Track raw wakerefs/wakelocks in the low/high half-word of
> > wakeref_count, instead of adding a new counter. (Chris)
> >
> > Cc: Chris Wilson
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_drv.h| 52 +++-
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 150 ++--
> > 2 files changed, 160 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 247893ed1543..772ed0fedb39 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1619,6 +1619,24 @@ unsigned int i9xx_plane_max_stride(struct
> > intel_plane *plane,
> >unsigned int rotation);
> >
> > /* intel_runtime_pm.c */
>
> #define struct_member(T, member) (((T *)0)->member)
>
> and stick that in i915_utils.h.
Ok.
> There's a few repetitions in include/linux so maybe worth
> centralising.
For reference, the corresponding spatch, found a few tens of uses across
the tree (not sure if 'identifier I;' is the best way to denote a struct
member):
@nc@
type T;
identifier I;
@@
- ((T *)NULL)->I
+ struct_member(T, I)
>
> > +#define BITS_PER_WAKEREF \
> > + BITS_PER_TYPE(((struct i915_runtime_pm *)NULL)->wakeref_count)
> > +#define INTEL_RPM_WAKELOCK_SHIFT (BITS_PER_WAKEREF / 2)
> > +#define INTEL_RPM_WAKELOCK_BIAS(1 <<
> > INTEL_RPM_WAKELOCK_SHIFT)
> > +#define INTEL_RPM_RAW_WAKEREF_MASK (INTEL_RPM_WAKELOCK_BIAS - 1)
>
>
> > +static void
> > +intel_runtime_pm_acquire(struct drm_i915_private *i915, bool wakelock)
> > +{
> > + struct i915_runtime_pm *rpm = >runtime_pm;
> > +
> > + if (wakelock) {
> > + atomic_add(1 + INTEL_RPM_WAKELOCK_BIAS,
> > >wakeref_count);
> > + assert_rpm_wakelock_held(i915);
> > + } else {
> > + atomic_inc(>wakeref_count);
> > + assert_rpm_raw_wakeref_held(i915);
> > + }
> > +}
> > +
> > +static void
> > +intel_runtime_pm_release(struct drm_i915_private *i915, int wakelock)
> > +{
> > + struct i915_runtime_pm *rpm = >runtime_pm;
> > +
> > + if (wakelock) {
> > + assert_rpm_wakelock_held(i915);
> > + atomic_sub(INTEL_RPM_WAKELOCK_BIAS, >wakeref_count);
> > + } else {
> > + assert_rpm_raw_wakeref_held(i915);
> > + }
> > +
> > + __intel_wakeref_dec_and_check_tracking(i915);
>
> Creating a atomic_sub_and_lock_irqsave() would restore the onion?
Yep. One day I may go through the architecture maze/header magic I
suspect that involves, or if someone could add it I'd be happy to use
that instead.
>
> Reviewed-by: Chris Wilson
> -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 01/21] scripts/trace.pl: Fix after intel_engine_notify removal
On 08/05/2019 13:17, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-05-08 13:10:38) From: Tvrtko Ursulin After the removal of engine global seqnos and the corresponding intel_engine_notify tracepoints the script needs to be adjusted to cope with the new state of things. To keep working it switches over using the dma_fence:dma_fence_signaled: tracepoint and keeps one extra internal map to connect the ctx-seqno pairs with engines. Is the map suitable for the planned (by me) s/i915_request_wait_begin/dma_fence_wait_begin/ I guess it should be. I think it would be workable. One complication would be that engine is not guaranteed to be known ahead of the wait, like it is ahead of the signal. But since ctx.seqno is unique it can be tracked and added later I think. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
