Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On Wed, 19 Dec 2018, "Winkler, Tomas" wrote:
>>
>> On Wed, 19 Dec 2018, "C, Ramalingam" wrote:
>> > On 12/19/2018 8:05 PM, Daniel Vetter wrote:
>> >> On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
>> >>> struct intel_hdcp {
>> >>> @@ -414,6 +430,24 @@ struct intel_hdcp {
>> >>> */
>> >>> u8 content_type;
>> >>> struct hdcp_port_data port_data;
>> >>> +
>> >>> +u8 is_paired;
>> >>> +u8 is_repeater;
>> >> Make these two bool, will simplify the code a bunch.
>> >
>> > Seems there is a movement for not to use the bool in structures.
>>
>> No. Please use bools in structs when it makes sense. Avoid bools in structs
>> when you need to care about memory footprint or alignment or packing or
>> the like. This is not one of those cases.
>>
>> > Thats why I have changed these from bool to u8 from v8 onwards.
>> > Checkpatch also complains on this
>>
>> Sorry to say, checkpatch is not the authority although we do send out
>> automated checkpatch results.
>
> I believe it was Linus' call to not use bool in structs at all
> https://lkml.org/lkml/2017/11/21/384
I don't care. That's a valid judgement in the context referenced, but
the conclusion "no bools in structs at all" isn't. In this case, I think
bools are the better option, and anything else makes the code worse.
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
Re: [Intel-gfx] [PATCH] drm/amd: Compile fix for amdgpu_dm.c
Hi Mika,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20181219]
[cannot apply to v4.20-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Mika-Kuoppala/drm-amd-Compile-fix-for-amdgpu_dm-c/20181213-062039
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sparc64
All errors (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
'amdgpu_dm_mode_config_init':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1666:30: error:
>> passing argument 1 of 'drm_atomic_private_obj_init' from incompatible
>> pointer type [-Werror=incompatible-pointer-types]
drm_atomic_private_obj_init(adev->ddev,
^~~~
In file included from include/drm/drm_dp_mst_helper.h:27:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31:
include/drm/drm_atomic.h:403:6: note: expected 'struct drm_private_obj *'
but argument is of type 'struct drm_device *'
void drm_atomic_private_obj_init(struct drm_private_obj *obj,
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1667:9: error:
passing argument 2 of 'drm_atomic_private_obj_init' from incompatible pointer
type [-Werror=incompatible-pointer-types]
&adev->dm.atomic_obj,
^
In file included from include/drm/drm_dp_mst_helper.h:27:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31:
include/drm/drm_atomic.h:403:6: note: expected 'struct drm_private_state *'
but argument is of type 'struct drm_private_obj *'
void drm_atomic_private_obj_init(struct drm_private_obj *obj,
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1668:9: error:
passing argument 3 of 'drm_atomic_private_obj_init' from incompatible pointer
type [-Werror=incompatible-pointer-types]
&state->base,
^
In file included from include/drm/drm_dp_mst_helper.h:27:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31:
include/drm/drm_atomic.h:403:6: note: expected 'const struct
drm_private_state_funcs *' but argument is of type 'struct drm_private_state *'
void drm_atomic_private_obj_init(struct drm_private_obj *obj,
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1666:2: error:
too many arguments to function 'drm_atomic_private_obj_init'
drm_atomic_private_obj_init(adev->ddev,
^~~
In file included from include/drm/drm_dp_mst_helper.h:27:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31:
include/drm/drm_atomic.h:403:6: note: declared here
void drm_atomic_private_obj_init(struct drm_private_obj *obj,
^~~
cc1: some warnings being treated as errors
vim +/drm_atomic_private_obj_init +1666
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c
1631
1632 static int amdgpu_dm_mode_config_init(struct amdgpu_device *adev)
1633 {
1634 struct dm_atomic_state *state;
1635 int r;
1636
1637 adev->mode_info.mode_config_initialized = true;
1638
1639 adev->ddev->mode_config.funcs = (void *)&amdgpu_dm_mode_funcs;
1640 adev->ddev->mode_config.helper_private =
&amdgpu_dm_mode_config_helperfuncs;
1641
1642 adev->ddev->mode_config.max_width = 16384;
1643 adev->ddev->mode_config.max_height = 16384;
1644
1645 adev->ddev->mode_config.preferred_depth = 24;
1646 adev->ddev->mode_conf
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsc: Fix the deadlock in dsc debugfs node
== Series Details == Series: drm/i915/dsc: Fix the deadlock in dsc debugfs node URL : https://patchwork.freedesktop.org/series/54312/ State : success == Summary == CI Bug Log - changes from CI_DRM_5333_full -> Patchwork_11131_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11131_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11131_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11131_full: ### IGT changes ### Warnings * igt@kms_cursor_crc@cursor-128x42-offscreen: - shard-apl: SKIP -> PASS +91 * igt@perf_pmu@rc6: - shard-kbl: SKIP -> PASS * igt@pm_rc6_residency@rc6-accuracy: - shard-snb: PASS -> SKIP Known issues Here are the changes found in Patchwork_11131_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ppgtt@blt-vs-render-ctxn: - shard-skl: PASS -> TIMEOUT [fdo#108039] * igt@i915_suspend@shrink: - shard-skl: NOTRUN -> DMESG-WARN [fdo#108784] * igt@kms_available_modes_crc@available_mode_test_crc: - shard-snb: NOTRUN -> FAIL [fdo#106641] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-apl: SKIP -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-pageflip-hang-newfb-render-c: - shard-glk: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: - shard-iclb: PASS -> DMESG-WARN [fdo#107956] * igt@kms_color@pipe-b-ctm-negative: - shard-kbl: PASS -> DMESG-WARN [fdo#103313] / [fdo#103558] / [fdo#105602] +10 * igt@kms_color@pipe-b-degamma: - shard-apl: PASS -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_crc@cursor-128x42-onscreen: - shard-apl: PASS -> FAIL [fdo#103232] +5 * igt@kms_cursor_crc@cursor-256x256-sliding: - shard-glk: PASS -> FAIL [fdo#103232] +2 * igt@kms_cursor_crc@cursor-64x64-sliding: - shard-apl: SKIP -> FAIL [fdo#103232] +1 * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: PASS -> FAIL [fdo#104873] * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: - shard-glk: PASS -> FAIL [fdo#100368] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff: - shard-apl: SKIP -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render: - shard-apl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-kbl: PASS -> DMESG-WARN [fdo#103313] / [fdo#103558] - shard-apl: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-2p-pri-indfb-multidraw: - shard-glk: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbcpsr-1p-rte: - shard-iclb: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-glk: PASS -> FAIL [fdo#108948] * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-iclb: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_alpha_blend@pipe-a-alpha-basic: - shard-apl: SKIP -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@kms_rmfb@close-fd: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1 * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] +1 * igt@pm_backlight@fade_with_suspend: - shard-iclb: NOTRUN -> FAIL [fdo#107847] * igt@pm_rpm@system-suspend-execbuf: - shard-kbl: PASS -> INCOMPLETE [fdo#103665] / [fdo#107807] * igt@pm_rpm@universal-planes: - shard-skl: PASS -> INCOMPLETE [fdo#107807] +1 Possible fixes * igt@drm_read@short-buffer-block: - shard-iclb: DMESG-WARN [fdo#107724] -> PASS +13 * igt@gem_ctx_isolatio
[Intel-gfx] ✗ Fi.CI.BAT: failure for MST refcounting/atomic helpers cleanup (rev2)
== Series Details == Series: MST refcounting/atomic helpers cleanup (rev2) URL : https://patchwork.freedesktop.org/series/54030/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5333 -> Patchwork_11132 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11132 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11132, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/54030/revisions/2/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11132: ### IGT changes ### Possible regressions * igt@i915_selftest@live_contexts: - fi-bsw-kefka: PASS -> DMESG-FAIL Warnings * igt@kms_busy@basic-flip-c: - fi-kbl-7500u: PASS -> SKIP +2 Known issues Here are the changes found in Patchwork_11132 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@gem_mmap_gtt@basic: - fi-glk-dsi: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133] * igt@kms_chamelium@dp-hpd-fast: - fi-kbl-7500u: PASS -> DMESG-WARN [fdo#102505] / [fdo#103558] / [fdo#105602] * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: PASS -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: - fi-byt-clapper: PASS -> FAIL [fdo#107362] Possible fixes * igt@i915_selftest@live_hangcheck: - fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS - fi-apl-guc: DMESG-FAIL -> PASS - fi-kbl-7560u: INCOMPLETE [fdo#108044] -> PASS * igt@kms_flip@basic-flip-vs-dpms: - fi-skl-6700hq: DMESG-WARN [fdo#105998] -> PASS * igt@kms_frontbuffer_tracking@basic: - fi-byt-clapper: FAIL [fdo#103167] -> PASS * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS Warnings * igt@i915_selftest@live_contexts: - fi-icl-u2: INCOMPLETE [fdo#108315] -> DMESG-FAIL [fdo#108569] [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558 [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602 [fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044 [fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (49 -> 44) -- Additional (1): fi-pnv-d510 Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_5333 -> Patchwork_11132 CI_DRM_5333: c758693b615deff56e5e2098379b587486cfff8a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4750: f05c8c2739dce89185349703062784a7745cab14 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11132: b6b2a3fc307688511351dc937250867c56fd8f00 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b6b2a3fc3076 drm/nouveau: Use atomic VCPI helpers for MST 4d20dde05c36 drm/dp_mst: Check payload count in drm_dp_mst_atomic_check() 945779405902 drm/dp_mst: Start tracking per-port VCPI allocations 260fc11b1f9a drm/dp_mst: Add some atomic state iterator macros d242f9257a4b drm/nouveau: Grab payload lock in nv50_msto_payload() e4743c105b87 drm/nouveau: Stop unsetting mstc->port, use malloc refs f0d136a0f492 drm/nouveau: Keep malloc references to MST ports 371889f7b60e drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup() 6d9550106577 drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector() 3c24606c381a drm/amdgpu/display: Keep malloc ref to MST port 514f014c71f3 drm/i915: Keep malloc references to MST ports 859904901106 drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs 3b35c50d8406 drm/dp_mst: Stop releasing VCPI when removing ports from topology a4378c0bb6f7 drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails 5e53f025958a drm/dp_mst:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for MST refcounting/atomic helpers cleanup (rev2)
== Series Details == Series: MST refcounting/atomic helpers cleanup (rev2) URL : https://patchwork.freedesktop.org/series/54030/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends Okay! Commit: drm/dp_mst: Introduce new refcounting scheme for mstbs and ports Okay! Commit: drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails Okay! Commit: drm/dp_mst: Stop releasing VCPI when removing ports from topology Okay! Commit: drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs Okay! Commit: drm/i915: Keep malloc references to MST ports Okay! Commit: drm/amdgpu/display: Keep malloc ref to MST port Okay! Commit: drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector() Okay! Commit: drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup() Okay! Commit: drm/nouveau: Keep malloc references to MST ports Okay! Commit: drm/nouveau: Stop unsetting mstc->port, use malloc refs Okay! Commit: drm/nouveau: Grab payload lock in nv50_msto_payload() Okay! Commit: drm/dp_mst: Add some atomic state iterator macros Okay! Commit: drm/dp_mst: Start tracking per-port VCPI allocations + ^~ +^~ +drivers/gpu/drm/drm_dp_mst_topology.c:3064:16: error: ‘struct drm_dp_mst_topology_state’ has no member named ‘vcpi_allocated’ +drivers/gpu/drm/drm_dp_mst_topology.c:3064:23: error: no member 'vcpi_allocated' in struct drm_dp_mst_topology_state +drivers/gpu/drm/drm_dp_mst_topology.c:3064:23: warning: generating address of non-lvalue (8) +drivers/gpu/drm/drm_dp_mst_topology.c:3602:14: error: no member 'vcpi_allocated' in struct drm_dp_mst_topology_state +drivers/gpu/drm/drm_dp_mst_topology.c:3602:14: warning: generating address of non-lvalue (8) +drivers/gpu/drm/drm_dp_mst_topology.c:3602:7: error: ‘struct drm_dp_mst_topology_state’ has no member named ‘vcpi_allocated’ +drivers/gpu/drm/drm_dp_mst_topology.c: In function ‘drm_dp_atomic_find_vcpi_slots’: +drivers/gpu/drm/drm_dp_mst_topology.c: In function ‘drm_dp_mst_duplicate_state’: +make[1]: *** [drivers/gpu/drm/drm_dp_mst_topology.o] Error 1 +make[1]: *** Waiting for unfinished jobs +make: *** [drivers/gpu/drm/] Error 2 + state->vcpi_allocated = false; + topology_state->vcpi_allocated = true; Commit: drm/dp_mst: Check payload count in drm_dp_mst_atomic_check() - ^~ -^~ -O:drivers/gpu/drm/drm_dp_mst_topology.c:3064:16: error: ‘struct drm_dp_mst_topology_state’ has no member named ‘vcpi_allocated’ -O:drivers/gpu/drm/drm_dp_mst_topology.c:3064:23: error: no member 'vcpi_allocated' in struct drm_dp_mst_topology_state -O:drivers/gpu/drm/drm_dp_mst_topology.c:3064:23: warning: generating address of non-lvalue (8) -O:drivers/gpu/drm/drm_dp_mst_topology.c:3602:14: error: no member 'vcpi_allocated' in struct drm_dp_mst_topology_state -O:drivers/gpu/drm/drm_dp_mst_topology.c:3602:14: warning: generating address of non-lvalue (8) -O:drivers/gpu/drm/drm_dp_mst_topology.c:3602:7: error: ‘struct drm_dp_mst_topology_state’ has no member named ‘vcpi_allocated’ -drivers/gpu/drm/drm_dp_mst_topology.c: In function ‘drm_dp_atomic_find_vcpi_slots’: -drivers/gpu/drm/drm_dp_mst_topology.c: In function ‘drm_dp_mst_duplicate_state’: +./include/linux/slab.h:332:43: warning: dubious: x & !y -make[1]: *** [drivers/gpu/drm/drm_dp_mst_topology.o] Error 1 -make[1]: *** Waiting for unfinished jobs -make: *** [drivers/gpu/drm/] Error 2 - state->vcpi_allocated = false; - topology_state->vcpi_allocated = true; Commit: drm/nouveau: Use atomic VCPI helpers for MST 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 MST refcounting/atomic helpers cleanup (rev2)
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/54030/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f950c3fa3447 drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and
friends
-:84: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#84: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:990:
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
-:102: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#102: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1006:
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
-:150: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#150: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1373:
+ mstb_child = drm_dp_mst_topology_get_mstb_validated(
total: 0 errors, 0 warnings, 3 checks, 399 lines checked
5e53f025958a drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
-:22: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 91a25e463130 ("drm/dp/mst:
deallocate payload on port destruction")'
#22:
91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
-:27: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#27:
263efde31f97 ("drm/dp/mst: Get validated port ref in
drm_dp_update_payload_part1()")
-:27: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 263efde31f97 ("drm/dp/mst: Get
validated port ref in drm_dp_update_payload_part1()")'
#27:
263efde31f97 ("drm/dp/mst: Get validated port ref in
drm_dp_update_payload_part1()")
-:46: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit c54c7374ff44 ("drm/dp_mst: Skip
validating ports during destruction, just ref")'
#46:
c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, just ref")
-:51: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 9765635b3075 ("Revert
"drm/dp_mst: Skip validating ports during destruction, just ref"")'
#51:
9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during destruction,
just ref"")
-:129: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#129:
new file mode 100644
-:511: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#511: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:988:
+ DRM_DEBUG("mstb %p (%d)\n", mstb, kref_read(&mstb->malloc_kref)-1);
^
-:562: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#562: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1039:
+ DRM_DEBUG("port %p (%d)\n", port, kref_read(&port->malloc_kref)-1);
^
-:679: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#679: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1149:
+ DRM_DEBUG("mstb %p (%d)\n", mstb, kref_read(&mstb->topology_kref)-1);
^
-:779: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#779: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1273:
+ DRM_DEBUG("port %p (%d)\n", port, kref_read(&port->topology_kref)-1);
^
-:832: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#832: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1327:
+ mport = drm_dp_mst_topology_get_port_validated_locked(
-:846: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#846: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1344:
+ rport = drm_dp_mst_topology_get_port_validated_locked(
-:1012: WARNING:BRACES: braces {} are not necessary for any arm of this
statement
#1012: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:2058:
+ if (drm_dp_mst_topology_try_get_mstb(rmstb)) {
[...]
+ } else {
[...]
total: 4 errors, 3 warnings, 6 checks, 974 lines checked
a4378c0bb6f7 drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref
fails
3b35c50d8406 drm/dp_mst: Stop releasing VCPI when removing ports from topology
859904901106 drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
-:97: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#97: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:2274:
+ port = drm_dp_mst_topology_get_port_validated(
total: 0 errors, 0 warnings, 1 checks, 124 lines checked
514f014c71f3 drm/i915: Keep malloc references to MST ports
3c24606c381a drm/amdgpu/display: Keep malloc ref to MST port
6d9550106577 drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector()
371889f7b60e drm/nouveau: Remove
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsc: Fix the deadlock in dsc debugfs node
== Series Details ==
Series: drm/i915/dsc: Fix the deadlock in dsc debugfs node
URL : https://patchwork.freedesktop.org/series/54312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5333 -> Patchwork_11131
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11131 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11131, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54312/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11131:
### IGT changes ###
Warnings
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u: PASS -> SKIP +33
Known issues
Here are the changes found in Patchwork_11131 that come from known issues:
### IGT changes ###
Issues hit
* {igt@runner@aborted}:
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
- fi-apl-guc: DMESG-FAIL -> PASS
- fi-kbl-7560u: INCOMPLETE [fdo#108044] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: DMESG-WARN [fdo#105998] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- fi-icl-u3: DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108315]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
Participating hosts (49 -> 44)
--
Additional (1): fi-icl-y
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5333 -> Patchwork_11131
CI_DRM_5333: c758693b615deff56e5e2098379b587486cfff8a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4750: f05c8c2739dce89185349703062784a7745cab14 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11131: 3131b5be9d533bae25cbaced4d275760c578586c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3131b5be9d53 drm/i915/dsc: Fix the deadlock in dsc debugfs node
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11131/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 14/16] drm/dp_mst: Start tracking per-port VCPI allocations
There has been a TODO waiting for quite a long time in drm_dp_mst_topology.c: /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent * branch device was unplugged. This should be fixed by tracking * per-port slot allocation in drm_dp_mst_topology_state instead of * depending on the caller to tell us how many slots to release. */ That's not the only reason we should fix this: forcing the driver to track the VCPI allocations throughout a state's atomic check is error prone, because it means that extra care has to be taken with the order that drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release_vcpi_slots() are called in in order to ensure idempotency. Currently the only driver actually using these helpers, i915, doesn't even do this correctly: multiple ->best_encoder() checks with i915's current implementation would not be idempotent and would over-allocate VCPI slots, something I learned trying to implement fallback retraining in MST. So: simplify this whole mess, and teach drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release_vcpi_slots() to track the VCPI allocations for each port. This allows us to ensure idempotency without having to rely on the driver as much. Additionally: the driver doesn't need to do any kind of VCPI slot tracking anymore if it doesn't need it for it's own internal state. Additionally; this adds a new drm_dp_mst_atomic_check() helper which must be used by atomic drivers to perform validity checks for the new VCPI allocations incurred by a state. Also: update the documentation and make it more obvious that these /must/ be called by /all/ atomic drivers supporting MST. Changes since v7: - Don't check for mixed stale/valid VCPI allocations, just rely on connector registration to stop such erroneous modesets Changes since v6: - Keep a kref to all of the ports we have allocations on. This required a good bit of changing to when we call drm_dp_find_vcpi_slots(), mainly that we need to ensure that we only redo VCPI allocations on actual mode or CRTC changes, not crtc_state->active changes. Additionally, we no longer take the registration of the DRM connector for each port into account because so long as we have a kref to the port in the new or previous atomic state, the connector will stay registered. - Use the small changes to drm_dp_put_port() to add even more error checking to make misusage of the helpers more obvious. I added this after having to chase down various use-after-free conditions that started popping up from the new helpers so no one else has to troubleshoot that. - Move some accidental DRM_DEBUG_KMS() calls to DRM_DEBUG_ATOMIC() - Update documentation again, note that find/release() should both not be called on the same port in a single atomic check phase (but multiple calls to one or the other is OK) Changes since v4: - Don't skip the atomic checks for VCPI allocations if no new VCPI allocations happen in a state. This makes the next change I'm about to list here a lot easier to implement. - Don't ignore VCPI allocations on destroyed ports, instead ensure that when ports are destroyed and still have VCPI allocations in the topology state, the only state changes allowed are releasing said ports' VCPI. This prevents a state with a mix of VCPI allocations from destroyed ports, and allocations from valid ports. Changes since v3: - Don't release VCPI allocations in the topology state immediately in drm_dp_atomic_release_vcpi_slots(), instead mark them as 0 and skip over them in drm_dp_mst_duplicate_state(). This makes it so drm_dp_atomic_release_vcpi_slots() is still idempotent while also throwing warnings if the driver messes up it's book keeping and tries to release VCPI slots on a port that doesn't have any pre-existing VCPI allocation - danvet - Change mst_state/state in some debugging messages to "mst state" Changes since v2: - Use kmemdup() for duplicating MST state - danvet - Move port validation out of duplicate state callback - danvet - Handle looping through MST topology states in drm_dp_mst_atomic_check() so the driver doesn't have to do it - Fix documentation in drm_dp_atomic_find_vcpi_slots() - Move the atomic check for each individual topology state into it's own function, reduces indenting - Don't consider "stale" MST ports when calculating the bandwidth requirements. This is needed because originally we relied on the state duplication functions to prune any stale ports from the new state, which would prevent us from incorrectly considering their bandwidth requirements alongside legitimate new payloads. - Add function references in drm_dp_atomic_release_vcpi_slots() - danvet - Annotate atomic VCPI and atomic check functions with __must_check - danvet Changes since v1: - Don't use the now-removed ->atomic_check()
[Intel-gfx] [PATCH v2 15/16] drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index b55b58bf86ba..455fcf0a82df 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3061,8 +3061,6 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state
*state,
if (port == NULL)
return -EINVAL;
- topology_state->vcpi_allocated = true;
-
/* Find the current allocation for this port, if any */
list_for_each_entry(pos, &topology_state->vcpis, next) {
if (pos->port == port) {
@@ -3599,7 +3597,6 @@ drm_dp_mst_duplicate_state(struct drm_private_obj *obj)
__drm_atomic_helper_private_obj_duplicate_state(obj, &state->base);
INIT_LIST_HEAD(&state->vcpis);
- state->vcpi_allocated = false;
list_for_each_entry(pos, &old_state->vcpis, next) {
/* Prune leftover freed VCPI allocations */
@@ -3648,7 +3645,7 @@ drm_dp_mst_atomic_check_topology_state(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state
*mst_state)
{
struct drm_dp_vcpi_allocation *vcpi;
- int avail_slots = 63;
+ int avail_slots = 63, payload_count = 0;
list_for_each_entry(vcpi, &mst_state->vcpis, next) {
/* Releasing VCPI is always OK-even if the port is gone */
@@ -3669,6 +3666,12 @@ drm_dp_mst_atomic_check_topology_state(struct
drm_dp_mst_topology_mgr *mgr,
return -ENOSPC;
}
+ if (++payload_count > mgr->max_payloads) {
+ DRM_DEBUG_ATOMIC("[MST MGR:%p] state %p has too many
payloads (max=%d)\n",
+mgr, mst_state, mgr->max_payloads);
+ return -EINVAL;
+ }
+
}
DRM_DEBUG_ATOMIC("[MST MGR:%p] mst state %p VCPI avail=%d used=%d\n",
mgr, mst_state, avail_slots,
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/16] drm/amdgpu/display: Keep malloc ref to MST port
Just like i915 and nouveau, it's a good idea for us to hold a malloc
reference to the port here so that we never pass a freed pointer to any
of the DP MST helper functions.
Also, we stop unsetting aconnector->port in
dm_dp_destroy_mst_connector(). There's literally no point to that
assignment that I can see anyway.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 5e7ca1f3a8d1..24632727e127 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -191,6 +191,7 @@ dm_dp_mst_connector_destroy(struct drm_connector *connector)
drm_encoder_cleanup(&amdgpu_encoder->base);
kfree(amdgpu_encoder);
drm_connector_cleanup(connector);
+ drm_dp_mst_put_port_malloc(amdgpu_dm_connector->port);
kfree(amdgpu_dm_connector);
}
@@ -363,7 +364,9 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
amdgpu_dm_connector_funcs_reset(connector);
DRM_INFO("DM_MST: added connector: %p [id: %d] [master: %p]\n",
- aconnector, connector->base.id, aconnector->mst_port);
+aconnector, connector->base.id, aconnector->mst_port);
+
+ drm_dp_mst_get_port_malloc(port);
DRM_DEBUG_KMS(":%d\n", connector->base.id);
@@ -379,12 +382,12 @@ static void dm_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
DRM_INFO("DM_MST: Disabling connector: %p [id: %d] [master: %p]\n",
- aconnector, connector->base.id,
aconnector->mst_port);
+aconnector, connector->base.id, aconnector->mst_port);
- aconnector->port = NULL;
if (aconnector->dc_sink) {
amdgpu_dm_update_freesync_caps(connector, NULL);
- dc_link_remove_remote_sink(aconnector->dc_link,
aconnector->dc_sink);
+ dc_link_remove_remote_sink(aconnector->dc_link,
+ aconnector->dc_sink);
dc_sink_release(aconnector->dc_sink);
aconnector->dc_sink = NULL;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 11/16] drm/nouveau: Stop unsetting mstc->port, use malloc refs
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 982054bbcc8b..157d208d37b5 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -709,8 +709,7 @@ nv50_msto_cleanup(struct nv50_msto *msto)
NV_ATOMIC(drm, "%s: msto cleanup\n", msto->encoder.name);
- if (mstc->port)
- drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
+ drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
msto->mstc = NULL;
msto->head = NULL;
@@ -735,7 +734,7 @@ nv50_msto_prepare(struct nv50_msto *msto)
};
NV_ATOMIC(drm, "%s: msto prepare\n", msto->encoder.name);
- if (mstc->port && mstc->port->vcpi.vcpi > 0) {
+ if (mstc->port->vcpi.vcpi > 0) {
struct drm_dp_payload *payload = nv50_msto_payload(msto);
if (payload) {
args.vcpi.start_slot = payload->start_slot;
@@ -832,8 +831,7 @@ nv50_msto_disable(struct drm_encoder *encoder)
struct nv50_mstc *mstc = msto->mstc;
struct nv50_mstm *mstm = mstc->mstm;
- if (mstc->port)
- drm_dp_mst_reset_vcpi_slots(&mstm->mgr, mstc->port);
+ drm_dp_mst_reset_vcpi_slots(&mstm->mgr, mstc->port);
mstm->outp->update(mstm->outp, msto->head->base.index, NULL, 0, 0);
mstm->modified = true;
@@ -945,7 +943,7 @@ nv50_mstc_detect(struct drm_connector *connector, bool
force)
enum drm_connector_status conn_status;
int ret;
- if (!mstc->port)
+ if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
ret = pm_runtime_get_sync(connector->dev->dev);
@@ -966,8 +964,7 @@ nv50_mstc_destroy(struct drm_connector *connector)
struct nv50_mstc *mstc = nv50_mstc(connector);
drm_connector_cleanup(&mstc->connector);
- if (mstc->port)
- drm_dp_mst_put_port_malloc(mstc->port);
+ drm_dp_mst_put_port_malloc(mstc->port);
kfree(mstc);
}
@@ -1081,11 +1078,6 @@ nv50_mstm_destroy_connector(struct
drm_dp_mst_topology_mgr *mgr,
drm_fb_helper_remove_one_connector(&drm->fbcon->helper,
&mstc->connector);
- drm_modeset_lock(&drm->dev->mode_config.connection_mutex, NULL);
- drm_dp_mst_put_port_malloc(mstc->port);
- mstc->port = NULL;
- drm_modeset_unlock(&drm->dev->mode_config.connection_mutex);
-
drm_connector_put(&mstc->connector);
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 13/16] drm/dp_mst: Add some atomic state iterator macros
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 5 +-
include/drm/drm_dp_mst_helper.h | 96 +++
2 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 11dd3ede7b7d..22bc54d83b20 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3525,10 +3525,11 @@ static void drm_dp_mst_destroy_state(struct
drm_private_obj *obj,
kfree(mst_state);
}
-static const struct drm_private_state_funcs mst_state_funcs = {
+const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs = {
.atomic_duplicate_state = drm_dp_mst_duplicate_state,
.atomic_destroy_state = drm_dp_mst_destroy_state,
};
+EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
/**
* drm_atomic_get_mst_topology_state: get MST topology state
@@ -3612,7 +3613,7 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
drm_atomic_private_obj_init(dev, &mgr->base,
&mst_state->base,
- &mst_state_funcs);
+ &drm_dp_mst_topology_state_funcs);
return 0;
}
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 8eca5f29242c..581163c8d7d7 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -650,4 +650,100 @@ int drm_dp_send_power_updown_phy(struct
drm_dp_mst_topology_mgr *mgr,
void drm_dp_mst_get_port_malloc(struct drm_dp_mst_port *port);
void drm_dp_mst_put_port_malloc(struct drm_dp_mst_port *port);
+extern const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs;
+
+/**
+ * __drm_dp_mst_state_iter_get - private atomic state iterator function for
+ * macro-internal use
+ * @state: &struct drm_atomic_state pointer
+ * @mgr: pointer to the &struct drm_dp_mst_topology_mgr iteration cursor
+ * @old_state: optional pointer to the old &struct drm_dp_mst_topology_state
+ * iteration cursor
+ * @new_state: optional pointer to the new &struct drm_dp_mst_topology_state
+ * iteration cursor
+ * @i: int iteration cursor, for macro-internal use
+ *
+ * Used by for_each_oldnew_mst_mgr_in_state(),
+ * for_each_old_mst_mgr_in_state(), and for_each_new_mst_mgr_in_state(). Don't
+ * call this directly.
+ *
+ * Returns:
+ * True if the current &struct drm_private_obj is a &struct
+ * drm_dp_mst_topology_mgr, false otherwise.
+ */
+static inline bool
+__drm_dp_mst_state_iter_get(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr **mgr,
+ struct drm_dp_mst_topology_state **old_state,
+ struct drm_dp_mst_topology_state **new_state,
+ int i)
+{
+ struct __drm_private_objs_state *objs_state = &state->private_objs[i];
+
+ if (objs_state->ptr->funcs != &drm_dp_mst_topology_state_funcs)
+ return false;
+
+ *mgr = to_dp_mst_topology_mgr(objs_state->ptr);
+ if (old_state)
+ *old_state = to_dp_mst_topology_state(objs_state->old_state);
+ if (new_state)
+ *new_state = to_dp_mst_topology_state(objs_state->new_state);
+
+ return true;
+}
+
+/**
+ * for_each_oldnew_mst_mgr_in_state - iterate over all DP MST topology
+ * managers in an atomic update
+ * @__state: &struct drm_atomic_state pointer
+ * @mgr: &struct drm_dp_mst_topology_mgr iteration cursor
+ * @old_state: &struct drm_dp_mst_topology_state iteration cursor for the old
+ * state
+ * @new_state: &struct drm_dp_mst_topology_state iteration cursor for the new
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in an atomic update,
+ * tracking both old and new state. This is useful in places where the state
+ * delta needs to be considered, for example in atomic check functions.
+ */
+#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state,
__i) \
+ for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+ for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr),
&(old_state), &(new_state), (__i)))
+
+/**
+ * for_each_old_mst_mgr_in_state - iterate over all DP MST topology managers
+ * in an atomic update
+ * @__state: &struct drm_atomic_state pointer
+ * @mgr: &struct drm_dp_mst_topology_mgr iteration cursor
+ * @old_state: &struct drm_dp_mst_topology_state iteration cursor for the old
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in
[Intel-gfx] [PATCH v2 08/16] drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector()
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 26af45785939..641252208e67 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1099,11 +1099,8 @@ nv50_mstm_add_connector(struct drm_dp_mst_topology_mgr
*mgr,
int ret;
ret = nv50_mstc_new(mstm, port, path, &mstc);
- if (ret) {
- if (mstc)
- mstc->connector.funcs->destroy(&mstc->connector);
+ if (ret)
return NULL;
- }
return &mstc->connector;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 10/16] drm/nouveau: Keep malloc references to MST ports
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is allocated for
as long as we keep mstc around we can remove the connector registration
checks for codepaths which release payloads, allowing us to release
payloads on active topologies properly. These registration checks were
only required before in order to avoid situations where mstc->port could
technically be pointing at freed memory.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 0f7d72518604..982054bbcc8b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -964,7 +964,11 @@ static void
nv50_mstc_destroy(struct drm_connector *connector)
{
struct nv50_mstc *mstc = nv50_mstc(connector);
+
drm_connector_cleanup(&mstc->connector);
+ if (mstc->port)
+ drm_dp_mst_put_port_malloc(mstc->port);
+
kfree(mstc);
}
@@ -1012,6 +1016,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct
drm_dp_mst_port *port,
drm_object_attach_property(&mstc->connector.base,
dev->mode_config.path_property, 0);
drm_object_attach_property(&mstc->connector.base,
dev->mode_config.tile_property, 0);
drm_connector_set_path_property(&mstc->connector, path);
+ drm_dp_mst_get_port_malloc(port);
return 0;
}
@@ -1077,6 +1082,7 @@ nv50_mstm_destroy_connector(struct
drm_dp_mst_topology_mgr *mgr,
drm_fb_helper_remove_one_connector(&drm->fbcon->helper,
&mstc->connector);
drm_modeset_lock(&drm->dev->mode_config.connection_mutex, NULL);
+ drm_dp_mst_put_port_malloc(mstc->port);
mstc->port = NULL;
drm_modeset_unlock(&drm->dev->mode_config.connection_mutex);
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 09/16] drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup()
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks are meant to protect against.
More importantly though, we're about to stop clearing mstc->port in the
next commit, which means if we could potentially hit a use-after-free
error if we tried to check mstc->port->vcpi here. So to make life easier
for anyone who bisects this code in the future, use msto->disabled
instead to check whether or not we need to deallocate VCPI instead.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 641252208e67..0f7d72518604 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -704,14 +704,17 @@ nv50_msto_cleanup(struct nv50_msto *msto)
struct nv50_mstc *mstc = msto->mstc;
struct nv50_mstm *mstm = mstc->mstm;
+ if (!msto->disabled)
+ return;
+
NV_ATOMIC(drm, "%s: msto cleanup\n", msto->encoder.name);
- if (mstc->port && mstc->port->vcpi.vcpi > 0 && !nv50_msto_payload(msto))
+
+ if (mstc->port)
drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
- if (msto->disabled) {
- msto->mstc = NULL;
- msto->head = NULL;
- msto->disabled = false;
- }
+
+ msto->mstc = NULL;
+ msto->head = NULL;
+ msto->disabled = false;
}
static void
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 16/16] drm/nouveau: Use atomic VCPI helpers for MST
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actually check whether or not the topology still has
enough bandwidth to provide the VCPI tokens required.
So, drop usage of the old helpers and move entirely over to the atomic
helpers.
Changes since v5:
- Update nv50_msto_atomic_check() and nv50_mstc_atomic_check() to the
new requirements for drm_dp_atomic_find_vcpi_slots() and
drm_dp_atomic_release_vcpi_slots()
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 52 ++---
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 67f7bf97e5d9..df696008d205 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -762,16 +762,22 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
- struct nv50_mstc *mstc = nv50_mstc(conn_state->connector);
+ struct drm_atomic_state *state = crtc_state->state;
+ struct drm_connector *connector = conn_state->connector;
+ struct nv50_mstc *mstc = nv50_mstc(connector);
struct nv50_mstm *mstm = mstc->mstm;
- int bpp = conn_state->connector->display_info.bpc * 3;
+ int bpp = connector->display_info.bpc * 3;
int slots;
- mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock, bpp);
+ mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
+bpp);
- slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn);
- if (slots < 0)
- return slots;
+ if (crtc_state->connectors_changed || crtc_state->mode_changed) {
+ slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr,
+ mstc->port, mstc->pbn);
+ if (slots < 0)
+ return slots;
+ }
return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
mstc->native);
@@ -934,12 +940,42 @@ nv50_mstc_get_modes(struct drm_connector *connector)
return ret;
}
+static int
+nv50_mstc_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *new_conn_state)
+{
+ struct drm_atomic_state *state = new_conn_state->state;
+ struct nv50_mstc *mstc = nv50_mstc(connector);
+ struct drm_dp_mst_topology_mgr *mgr = &mstc->mstm->mgr;
+ struct drm_connector_state *old_conn_state =
+ drm_atomic_get_old_connector_state(state, connector);
+ struct drm_crtc_state *old_crtc_state;
+ struct drm_crtc *new_crtc = new_conn_state->crtc,
+ *old_crtc = old_conn_state->crtc;
+
+ if (!old_crtc)
+ return 0;
+
+ old_crtc_state = drm_atomic_get_old_crtc_state(state, old_crtc);
+ if (!old_crtc_state || !old_crtc_state->enable)
+ return 0;
+
+ if (new_crtc)
+ return 0;
+
+ /* This connector will be left without an enabled CRTC, so its VCPI
+* must be released here
+*/
+ return drm_dp_atomic_release_vcpi_slots(state, mgr, mstc->port);
+}
+
static const struct drm_connector_helper_funcs
nv50_mstc_help = {
.get_modes = nv50_mstc_get_modes,
.mode_valid = nv50_mstc_mode_valid,
.best_encoder = nv50_mstc_best_encoder,
.atomic_best_encoder = nv50_mstc_atomic_best_encoder,
+ .atomic_check = nv50_mstc_atomic_check,
};
static enum drm_connector_status
@@ -2121,6 +2157,10 @@ nv50_disp_atomic_check(struct drm_device *dev, struct
drm_atomic_state *state)
return ret;
}
+ ret = drm_dp_mst_atomic_check(state);
+ if (ret)
+ return ret;
+
return 0;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/16] drm/dp_mst: Stop releasing VCPI when removing ports from topology
This has never actually worked, and isn't needed anyway: the driver's
always going to try to deallocate VCPI when it tears down the display
that the VCPI belongs to.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 356a95aba2d8..ef8637f37564 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1175,8 +1175,6 @@ static void drm_dp_destroy_port(struct kref *kref)
struct drm_dp_mst_topology_mgr *mgr = port->mgr;
if (!port->input) {
- port->vcpi.num_slots = 0;
-
kfree(port->cached_edid);
/*
@@ -3491,12 +3489,6 @@ static void drm_dp_destroy_connector_work(struct
work_struct *work)
drm_dp_port_teardown_pdt(port, port->pdt);
port->pdt = DP_PEER_DEVICE_NONE;
- if (!port->input && port->vcpi.vcpi > 0) {
- drm_dp_mst_reset_vcpi_slots(mgr, port);
- drm_dp_update_payload_part1(mgr);
- drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
- }
-
drm_dp_mst_put_port_malloc(port);
send_hotplug = true;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 01/16] drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends
s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/
s/drm_dp_put_port/drm_dp_mst_topology_put_port/
s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/
s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/
This is a much more consistent naming scheme, and will make even more
sense once we redesign how the current refcounting scheme here works.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 114 ++
1 file changed, 62 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 2ab16c9e6243..6f9b211069a7 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -46,7 +46,7 @@ static bool dump_dp_payload_table(struct
drm_dp_mst_topology_mgr *mgr,
char *buf);
static int test_calc_pbn_mode(void);
-static void drm_dp_put_port(struct drm_dp_mst_port *port);
+static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
int id,
@@ -888,7 +888,7 @@ static void drm_dp_destroy_mst_branch_device(struct kref
*kref)
*/
list_for_each_entry_safe(port, tmp, &mstb->ports, next) {
list_del(&port->next);
- drm_dp_put_port(port);
+ drm_dp_mst_topology_put_port(port);
}
/* drop any tx slots msg */
@@ -911,7 +911,7 @@ static void drm_dp_destroy_mst_branch_device(struct kref
*kref)
kref_put(kref, drm_dp_free_mst_branch_device);
}
-static void drm_dp_put_mst_branch_device(struct drm_dp_mst_branch *mstb)
+static void drm_dp_mst_topology_put_mstb(struct drm_dp_mst_branch *mstb)
{
kref_put(&mstb->kref, drm_dp_destroy_mst_branch_device);
}
@@ -930,7 +930,7 @@ static void drm_dp_port_teardown_pdt(struct drm_dp_mst_port
*port, int old_pdt)
case DP_PEER_DEVICE_MST_BRANCHING:
mstb = port->mstb;
port->mstb = NULL;
- drm_dp_put_mst_branch_device(mstb);
+ drm_dp_mst_topology_put_mstb(mstb);
break;
}
}
@@ -970,12 +970,14 @@ static void drm_dp_destroy_port(struct kref *kref)
kfree(port);
}
-static void drm_dp_put_port(struct drm_dp_mst_port *port)
+static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
{
kref_put(&port->kref, drm_dp_destroy_port);
}
-static struct drm_dp_mst_branch
*drm_dp_mst_get_validated_mstb_ref_locked(struct drm_dp_mst_branch *mstb,
struct drm_dp_mst_branch *to_find)
+static struct drm_dp_mst_branch *
+drm_dp_mst_topology_get_mstb_validated_locked(struct drm_dp_mst_branch *mstb,
+ struct drm_dp_mst_branch *to_find)
{
struct drm_dp_mst_port *port;
struct drm_dp_mst_branch *rmstb;
@@ -985,7 +987,8 @@ static struct drm_dp_mst_branch
*drm_dp_mst_get_validated_mstb_ref_locked(struct
}
list_for_each_entry(port, &mstb->ports, next) {
if (port->mstb) {
- rmstb =
drm_dp_mst_get_validated_mstb_ref_locked(port->mstb, to_find);
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
+ port->mstb, to_find);
if (rmstb)
return rmstb;
}
@@ -993,12 +996,15 @@ static struct drm_dp_mst_branch
*drm_dp_mst_get_validated_mstb_ref_locked(struct
return NULL;
}
-static struct drm_dp_mst_branch *drm_dp_get_validated_mstb_ref(struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_branch *mstb)
+static struct drm_dp_mst_branch *
+drm_dp_mst_topology_get_mstb_validated(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb)
{
struct drm_dp_mst_branch *rmstb = NULL;
mutex_lock(&mgr->lock);
if (mgr->mst_primary)
- rmstb =
drm_dp_mst_get_validated_mstb_ref_locked(mgr->mst_primary, mstb);
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
+ mgr->mst_primary, mstb);
mutex_unlock(&mgr->lock);
return rmstb;
}
@@ -1021,7 +1027,9 @@ static struct drm_dp_mst_port
*drm_dp_mst_get_port_ref_locked(struct drm_dp_mst_
return NULL;
}
-static struct drm_dp_mst_port *drm_dp_get_validated_port_ref(struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port)
+static struct drm_dp_mst_port *
+drm_dp_mst_topology_get_port_validated(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port)
{
struct drm_dp_mst_port *rport = NULL;
mutex_lock(&mgr->lock);
@@ -1210,7 +1218,7 @@ static void drm_dp_add_port(struct drm_dp_mst_b
[Intel-gfx] [PATCH v2 03/16] drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails
While this isn't a complete fix, this will improve the reliability of
drm_dp_get_last_connected_port_and_mstb() pretty significantly during
hotplug events, since there's a chance that the in-memory topology tree
may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
is called and thus might end up causing our search to fail on an mstb
whose topology refcount has reached 0, but has not yet been removed from
it's parent.
Ideally, we should further fix this problem by ensuring that we deal
with the potential for racing with a hotplug event, which would look
like this:
* drm_dp_payload_send_msg() retrieves the last living relative of mstb
with drm_dp_get_last_connected_port_and_mstb()
* drm_dp_payload_send_msg() starts building payload message
At the same time, mstb gets unplugged from the topology and is no
longer the actual last living relative of the original mstb
* drm_dp_payload_send_msg() tries sending the payload message, hub times
out
* Hub timed out, we give up and run away-resulting in the payload being
leaked
This could be fixed by restarting the
drm_dp_get_last_connected_port_and_mstb() search whenever we get a
timeout, sending the payload to the new mstb, then repeating until
either the entire topology is removed from the system or
drm_dp_get_last_connected_port_and_mstb() fails. But since the above
race condition is not terribly likely, we'll address that in a later
patch series once we've improved the recovery handling for VCPI
allocations in the rest of the DP MST helpers.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 55 +--
1 file changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index b380ada09e90..356a95aba2d8 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2043,25 +2043,50 @@ static struct drm_dp_mst_port
*drm_dp_get_last_connected_port_to_mstb(struct drm
return
drm_dp_get_last_connected_port_to_mstb(mstb->port_parent->parent);
}
-static struct drm_dp_mst_branch
*drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
-struct
drm_dp_mst_branch *mstb,
-int
*port_num)
+/**
+ * drm_dp_get_last_connected_port_and_mstb() - Find the last living relatives
+ * in a topology of a given branch device
+ * @mgr: The topology manager to use
+ * @mstb: The disconnected branch device
+ * @port_num: Where to store the number of the last connected port
+ *
+ * Searches upwards in the topology starting from @mstb to try to find the
+ * closest available parent of @mstb that's still connected to the rest of the
+ * topology. This can be used in order to perform operations like releasing
+ * payloads, where the branch device which owned the payload may no longer be
+ * around and thus would require that the payload on the last living relative
+ * be freed instead.
+ *
+ * Returns:
+ * The last connected &drm_dp_mst_branch in the topology that was a parent of
+ * @mstb, if there is one.
+ */
+static struct drm_dp_mst_branch *
+drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb,
+ int *port_num)
{
struct drm_dp_mst_branch *rmstb = NULL;
struct drm_dp_mst_port *found_port;
+
mutex_lock(&mgr->lock);
- if (mgr->mst_primary) {
+ if (!mgr->mst_primary)
+ goto out;
+
+ do {
found_port = drm_dp_get_last_connected_port_to_mstb(mstb);
+ if (!found_port)
+ break;
- if (found_port) {
+ if (drm_dp_mst_topology_try_get_mstb(found_port->parent)) {
rmstb = found_port->parent;
- if (drm_dp_mst_topology_try_get_mstb(rmstb)) {
- *port_num = found_port->port_num;
- } else {
- rmstb = NULL;
- }
+ *port_num = found_port->port_num;
+ } else {
+ /* Search again, starting from this parent */
+ mstb = found_port->parent;
}
- }
+ } while (!rmstb);
+out:
mutex_unlock(&mgr->lock);
return rmstb;
}
@@ -2110,6 +2135,14 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
drm_dp_queue_down_tx(mgr, txmsg);
+ /*
+* FIXME: there is a small chance that between getting the last
+* connected mstb and sending the payload message, the last connected
+* mstb could also be
[Intel-gfx] [PATCH v2 05/16] drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
Up until now, freeing payloads on remote MST hubs that just had ports
removed has almost never worked because we've been relying on port
validation in order to stop us from accessing ports that have already
been freed from memory, but ports which need their payloads released due
to being removed will never be a valid part of the topology after
they've been removed.
Since we've introduced malloc refs, we can replace all of the validation
logic in payload helpers which are used for deallocation with some
well-placed malloc krefs. This ensures that regardless of whether or not
the ports are still valid and in the topology, any port which has an
allocated payload will remain allocated in memory until it's payloads
have been removed - finally allowing us to actually release said
payloads correctly.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 54 +++
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ef8637f37564..11dd3ede7b7d 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2100,10 +2100,6 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
u8 sinks[DRM_DP_MAX_SDP_STREAMS];
int i;
- port = drm_dp_mst_topology_get_port_validated(mgr, port);
- if (!port)
- return -EINVAL;
-
port_num = port->port_num;
mstb = drm_dp_mst_topology_get_mstb_validated(mgr, port->parent);
if (!mstb) {
@@ -2111,10 +2107,8 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
port->parent,
&port_num);
- if (!mstb) {
- drm_dp_mst_topology_put_port(port);
+ if (!mstb)
return -EINVAL;
- }
}
txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
@@ -2151,7 +2145,6 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
kfree(txmsg);
fail_put:
drm_dp_mst_topology_put_mstb(mstb);
- drm_dp_mst_topology_put_port(port);
return ret;
}
@@ -2256,15 +2249,16 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
*/
int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
{
- int i, j;
- int cur_slots = 1;
struct drm_dp_payload req_payload;
struct drm_dp_mst_port *port;
+ int i, j;
+ int cur_slots = 1;
mutex_lock(&mgr->payload_lock);
for (i = 0; i < mgr->max_payloads; i++) {
struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
struct drm_dp_payload *payload = &mgr->payloads[i];
+ bool put_port = false;
/* solve the current payloads - compare to the hw ones
- update the hw view */
@@ -2272,12 +2266,20 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr)
if (vcpi) {
port = container_of(vcpi, struct drm_dp_mst_port,
vcpi);
- port = drm_dp_mst_topology_get_port_validated(mgr,
- port);
- if (!port) {
- mutex_unlock(&mgr->payload_lock);
- return -EINVAL;
+
+ /* Validated ports don't matter if we're releasing
+* VCPI
+*/
+ if (vcpi->num_slots) {
+ port = drm_dp_mst_topology_get_port_validated(
+ mgr, port);
+ if (!port) {
+ mutex_unlock(&mgr->payload_lock);
+ return -EINVAL;
+ }
+ put_port = true;
}
+
req_payload.num_slots = vcpi->num_slots;
req_payload.vcpi = vcpi->vcpi;
} else {
@@ -2309,7 +2311,7 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr)
}
cur_slots += req_payload.num_slots;
- if (port)
+ if (put_port)
drm_dp_mst_topology_put_port(port);
}
@@ -3124,6 +3126,8 @@ bool drm_dp_mst_allocate_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n",
pbn, port->vcpi.num_slots);
+ /* Keep port allocated until it's payload has been removed *
[Intel-gfx] [PATCH v2 02/16] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current scheme works like this:
drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When
this refcount hits 0 for either of the two, they're removed from the
topology state, but not immediately freed. Both ports and branch devices
will reinitialize their kref once it's hit 0 before actually destroying
themselves. The intended purpose behind this is so that we can avoid
problems like not being able to free a remote payload that might still
be active, due to us having removed all of the port/branch device
structures in memory, as per:
91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
Which may have worked, but then it caused use-after-free errors. Being
new to MST at the time, I tried fixing it;
263efde31f97 ("drm/dp/mst: Get validated port ref in
drm_dp_update_payload_part1()")
But, that was broken: both drm_dp_mst_port and drm_dp_mst_branch structs
are validated in almost every DP MST helper function. Simply put, this
means we go through the topology and try to see if the given
drm_dp_mst_branch or drm_dp_mst_port is still attached to something
before trying to use it in order to avoid dereferencing freed memory
(something that has happened a LOT in the past with this library).
Because of this it doesn't actually matter whether or not we keep keep
the ports and branches around in memory as that's not enough, because
any function that validates the branches and ports passed to it will
still reject them anyway since they're no longer in the topology
structure. So, use-after-free errors were fixed but payload deallocation
was completely broken.
Two years later, AMD informed me about this issue and I attempted to
come up with a temporary fix, pending a long-overdue cleanup of this
library:
c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, just ref")
But then that introduced use-after-free errors, so I quickly reverted
it:
9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during destruction,
just ref"")
And in the process, learned that there is just no simple fix for this:
the design is just broken. Unfortuntely, the usage of these helpers are
quite broken as well. Some drivers like i915 have been smart enough to
avoid accessing any kind of information from MST port structures, but
others like nouveau have assumed, understandably so, that
drm_dp_mst_port structures are normal and can just be accessed at any
time without worrying about use-after-free errors.
After a lot of discussion, me and Daniel Vetter came up with a better
idea to replace all of this.
To summarize, since this is documented far more indepth in the
documentation this patch introduces, we make it so that drm_dp_mst_port
and drm_dp_mst_branch structures have two different classes of
refcounts: topology_kref, and malloc_kref. topology_kref corresponds to
the lifetime of the given drm_dp_mst_port or drm_dp_mst_branch in it's
given topology. Once it hits zero, any associated connectors are removed
and the branch or port can no longer be validated. malloc_kref
corresponds to the lifetime of the memory allocation for the actual
structure, and will always be non-zero so long as the topology_kref is
non-zero. This gives us a way to allow callers to hold onto port and
branch device structures past their topology lifetime, and dramatically
simplifies the lifetimes of both structures. This also finally fixes the
port deallocation problem, properly.
Additionally: since this now means that we can keep ports and branch
devices allocated in memory for however long we need, we no longer need
a significant amount of the port validation that we currently do.
Additionally, there is one last scenario that this fixes, which couldn't
have been fixed properly beforehand:
- CPU1 unrefs port from topology (refcount 1->0)
- CPU2 refs port in topology(refcount 0->1)
Since we now can guarantee memory safety for ports and branches
as-needed, we also can make our main reference counting functions fix
this problem by using kref_get_unless_zero() internally so that topology
refcounts can only ever reach 0 once.
Changes since v1:
* Remove forward declarations - danvet
* Move "Branch device and port refcounting" section from documentation
into kernel-doc comments - danvet
* Export internal topology lifetime functions into their own section in
the kernel-docs - danvet
* s/@/&/g for struct references in kernel-docs - danvet
* Drop the "when they are no longer being used" bits from the kernel
docs - danvet
* Modify diagrams to show how the DRM driver interacts with the topology
and payloads - danvet
* Make suggested documentation changes for
drm_dp_mst_topology_get_mstb() and drm_dp_mst_topology_get_port() -
[Intel-gfx] [PATCH v2 12/16] drm/nouveau: Grab payload lock in nv50_msto_payload()
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 157d208d37b5..67f7bf97e5d9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -680,6 +680,8 @@ nv50_msto_payload(struct nv50_msto *msto)
struct nv50_mstm *mstm = mstc->mstm;
int vcpi = mstc->port->vcpi.vcpi, i;
+ WARN_ON(!mutex_is_locked(&mstm->mgr.payload_lock));
+
NV_ATOMIC(drm, "%s: vcpi %d\n", msto->encoder.name, vcpi);
for (i = 0; i < mstm->mgr.max_payloads; i++) {
struct drm_dp_payload *payload = &mstm->mgr.payloads[i];
@@ -733,6 +735,8 @@ nv50_msto_prepare(struct nv50_msto *msto)
(0x0100 << msto->head->base.index),
};
+ mutex_lock(&mstm->mgr.payload_lock);
+
NV_ATOMIC(drm, "%s: msto prepare\n", msto->encoder.name);
if (mstc->port->vcpi.vcpi > 0) {
struct drm_dp_payload *payload = nv50_msto_payload(msto);
@@ -748,7 +752,9 @@ nv50_msto_prepare(struct nv50_msto *msto)
msto->encoder.name, msto->head->base.base.name,
args.vcpi.start_slot, args.vcpi.num_slots,
args.vcpi.pbn, args.vcpi.aligned_pbn);
+
nvif_mthd(&drm->display->disp.object, 0, &args, sizeof(args));
+ mutex_unlock(&mstm->mgr.payload_lock);
}
static int
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 06/16] drm/i915: Keep malloc references to MST ports
So that the ports stay around until we've destroyed the connectors, in order to ensure that we don't pass an invalid pointer to any MST helpers once we introduce the new MST VCPI helpers. Changes since v1: * Move drm_dp_mst_get_port_malloc() to where we assign intel_connector->port - danvet Signed-off-by: Lyude Paul Cc: Daniel Vetter Cc: David Airlie Cc: Jerry Zuo Cc: Harry Wentland Cc: Juston Li --- drivers/gpu/drm/i915/intel_connector.c | 4 drivers/gpu/drm/i915/intel_dp_mst.c| 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_connector.c b/drivers/gpu/drm/i915/intel_connector.c index 18e370f607bc..37d2c644f4b8 100644 --- a/drivers/gpu/drm/i915/intel_connector.c +++ b/drivers/gpu/drm/i915/intel_connector.c @@ -95,6 +95,10 @@ void intel_connector_destroy(struct drm_connector *connector) intel_panel_fini(&intel_connector->panel); drm_connector_cleanup(connector); + + if (intel_connector->port) + drm_dp_mst_put_port_malloc(intel_connector->port); + kfree(connector); } diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index f05427b74e34..631fd1537252 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -457,6 +457,7 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo intel_connector->get_hw_state = intel_dp_mst_get_hw_state; intel_connector->mst_port = intel_dp; intel_connector->port = port; + drm_dp_mst_get_port_malloc(port); connector = &intel_connector->base; ret = drm_connector_init(dev, connector, &intel_dp_mst_connector_funcs, -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/16] MST refcounting/atomic helpers cleanup
This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a ton of magic in the atomic helpers to work around properly and in many situations just plain doesn't work as intended. There's still more cleanup that can be done, but I think this is a good place to start off for now :). Lyude Paul (16): drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends drm/dp_mst: Introduce new refcounting scheme for mstbs and ports drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails drm/dp_mst: Stop releasing VCPI when removing ports from topology drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs drm/i915: Keep malloc references to MST ports drm/amdgpu/display: Keep malloc ref to MST port drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector() drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup() drm/nouveau: Keep malloc references to MST ports drm/nouveau: Stop unsetting mstc->port, use malloc refs drm/nouveau: Grab payload lock in nv50_msto_payload() drm/dp_mst: Add some atomic state iterator macros drm/dp_mst: Start tracking per-port VCPI allocations drm/dp_mst: Check payload count in drm_dp_mst_atomic_check() drm/nouveau: Use atomic VCPI helpers for MST .../gpu/dp-mst/topology-figure-1.dot | 52 + .../gpu/dp-mst/topology-figure-2.dot | 56 ++ .../gpu/dp-mst/topology-figure-3.dot | 59 ++ Documentation/gpu/drm-kms-helpers.rst | 26 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 11 +- drivers/gpu/drm/drm_dp_mst_topology.c | 937 ++ drivers/gpu/drm/i915/intel_connector.c| 4 + drivers/gpu/drm/i915/intel_display.c | 4 + drivers/gpu/drm/i915/intel_dp_mst.c | 65 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 94 +- include/drm/drm_dp_mst_helper.h | 151 ++- 11 files changed, 1207 insertions(+), 252 deletions(-) create mode 100644 Documentation/gpu/dp-mst/topology-figure-1.dot create mode 100644 Documentation/gpu/dp-mst/topology-figure-2.dot create mode 100644 Documentation/gpu/dp-mst/topology-figure-3.dot -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dsc: Fix the deadlock in dsc debugfs node
Reviewed-by: Lyude Paul
On Wed, 2018-12-19 at 15:51 -0800, Manasi Navare wrote:
> The DSC debugfs node causes a possible deadlock situation. This patch
> resets the try_again at the beginning of loop to fix this.
>
> Fixes: e845f099f1c6 ('drm/i915/dsc: Add Per connector debugfs node for DSC
> support/enable')
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109097
> Cc: Lyude Paul
> Cc: Chris Wilson
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 77486a614614..aca26a25ed50 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -5108,6 +5108,7 @@ static int i915_dsc_fec_support_show(struct seq_file
> *m, void *data)
> drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
>
> do {
> + try_again = false;
> ret = drm_modeset_lock(&dev->mode_config.connection_mutex,
> &ctx);
> if (ret) {
--
Cheers,
Lyude Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dsc: Fix the deadlock in dsc debugfs node
The DSC debugfs node causes a possible deadlock situation. This patch
resets the try_again at the beginning of loop to fix this.
Fixes: e845f099f1c6 ('drm/i915/dsc: Add Per connector debugfs node for DSC
support/enable')
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109097
Cc: Lyude Paul
Cc: Chris Wilson
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 77486a614614..aca26a25ed50 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5108,6 +5108,7 @@ static int i915_dsc_fec_support_show(struct seq_file *m,
void *data)
drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
do {
+ try_again = false;
ret = drm_modeset_lock(&dev->mode_config.connection_mutex,
&ctx);
if (ret) {
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8] drm/i915/dsc: Add Per connector debugfs node for DSC support/enable
On Wed, Dec 19, 2018 at 08:08:51AM +, Chris Wilson wrote:
> Quoting Manasi Navare (2018-12-06 00:54:07)
> > DSC can be supported per DP connector. This patch adds a per connector
> > debugfs node to expose DSC support capability by the kernel.
> > The same node can be used from userspace to force DSC enable.
>
> So this has a nice deadlock that is killing icl sporadically...
>
> > +static int i915_dsc_fec_support_show(struct seq_file *m, void *data)
> > +{
> > + struct drm_connector *connector = m->private;
> > + struct drm_device *dev = connector->dev;
> > + struct drm_crtc *crtc;
> > + struct intel_dp *intel_dp;
> > + struct drm_modeset_acquire_ctx ctx;
> > + struct intel_crtc_state *crtc_state = NULL;
> > + int ret = 0;
> > + bool try_again = false;
> > +
> > + drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> > +
> > + do {
> > + ret = drm_modeset_lock(&dev->mode_config.connection_mutex,
> > + &ctx);
> > + if (ret) {
> > + ret = -EINTR;
> > + break;
> > + }
> > + crtc = connector->state->crtc;
> > + if (connector->status != connector_status_connected ||
> > !crtc) {
> > + ret = -ENODEV;
> > + break;
> > + }
> > + ret = drm_modeset_lock(&crtc->mutex, &ctx);
> > + if (ret == -EDEADLK) {
> > + ret = drm_modeset_backoff(&ctx);
> > + if (!ret) {
> > + try_again = true;
>
> try_again is never cleared on the next loop, so after you hit the
> backoff, we never escape on success.
Thanks for catching this, teh CI results came green before this patch was
merged so
never noticed this.
I will submit a patch to fix this.
Thanks again Chris and Tomi for catching this bug
Manasi
>
> Reported-by: Tomi Sarvela
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
>
> On Wed, 19 Dec 2018, "C, Ramalingam" wrote:
> > On 12/19/2018 8:05 PM, Daniel Vetter wrote:
> >> On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
> >>> struct intel_hdcp {
> >>> @@ -414,6 +430,24 @@ struct intel_hdcp {
> >>>*/
> >>> u8 content_type;
> >>> struct hdcp_port_data port_data;
> >>> +
> >>> + u8 is_paired;
> >>> + u8 is_repeater;
> >> Make these two bool, will simplify the code a bunch.
> >
> > Seems there is a movement for not to use the bool in structures.
>
> No. Please use bools in structs when it makes sense. Avoid bools in structs
> when you need to care about memory footprint or alignment or packing or
> the like. This is not one of those cases.
>
> > Thats why I have changed these from bool to u8 from v8 onwards.
> > Checkpatch also complains on this
>
> Sorry to say, checkpatch is not the authority although we do send out
> automated checkpatch results.
I believe it was Linus' call to not use bool in structs at all
https://lkml.org/lkml/2017/11/21/384
Thanks
Tomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev4)
== Series Details == Series: series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev4) URL : https://patchwork.freedesktop.org/series/54285/ State : success == Summary == CI Bug Log - changes from CI_DRM_5333_full -> Patchwork_11130_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11130_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11130_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11130_full: ### IGT changes ### Warnings * igt@gem_busy@extended-semaphore-render: - shard-hsw: PASS -> SKIP +3 * igt@gem_eio@in-flight-internal-10ms: - shard-hsw: SKIP -> PASS +2 * igt@kms_cursor_crc@cursor-128x42-offscreen: - shard-apl: SKIP -> PASS +95 * igt@perf_pmu@rc6: - shard-kbl: SKIP -> PASS * igt@pm_rc6_residency@rc6-accuracy: - shard-snb: PASS -> SKIP Known issues Here are the changes found in Patchwork_11130_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vcs0-s3: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] +1 * igt@gem_ppgtt@blt-vs-render-ctxn: - shard-skl: PASS -> TIMEOUT [fdo#108039] * igt@gem_softpin@softpin: - shard-snb: PASS -> INCOMPLETE [fdo#105411] * igt@i915_suspend@shrink: - shard-skl: NOTRUN -> DMESG-WARN [fdo#108784] * igt@kms_available_modes_crc@available_mode_test_crc: - shard-snb: NOTRUN -> FAIL [fdo#106641] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-apl: SKIP -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-pageflip-hang-newfb-render-c: - shard-glk: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: - shard-iclb: PASS -> DMESG-WARN [fdo#107956] * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145] - shard-glk: PASS -> FAIL [fdo#108145] * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_crc@cursor-128x42-sliding: - shard-glk: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_crc@cursor-256x85-sliding: - shard-apl: PASS -> FAIL [fdo#103232] +5 * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +16 * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-untiled: - shard-iclb: PASS -> WARN [fdo#108336] +4 - shard-skl: NOTRUN -> FAIL [fdo#103184] / [fdo#108472] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-move: - shard-glk: PASS -> FAIL [fdo#103167] +6 * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-wc: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +5 * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-wc: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@psr-suspend: - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#106978] * igt@kms_plane@pixel-format-pipe-b-planes: - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-iclb: PASS -> DMESG-FAIL [fdo#103166] / [fdo#107724] +1 * igt@kms_plane_alpha_blend@pipe-a-alpha-basic: - shard-apl: SKIP -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +8 * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@perf_pmu@rc6-runtime-pm: - shard-apl: PASS -> FAIL [fdo#105010] * igt@pm_rpm@basic-pci-d3-state: - shard-iclb: PASS -> INCOMPLETE [fdo#108840] +1 * igt@pm_rpm@fences-dpms: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +14 * igt@pm_rpm@system-suspend-devices:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev4)
== Series Details ==
Series: series starting with [1/9] drm/i915: Remove HW semaphores for gen7
inter-engine synchronisation (rev4)
URL : https://patchwork.freedesktop.org/series/54285/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5333 -> Patchwork_11130
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54285/revisions/4/mbox/
Known issues
Here are the changes found in Patchwork_11130 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: PASS -> FAIL [fdo#108656]
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: PASS -> INCOMPLETE [fdo#108602] / [fdo#108744]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
* {igt@runner@aborted}:
- fi-skl-iommu: NOTRUN -> FAIL [fdo#108602]
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
- fi-apl-guc: DMESG-FAIL -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: DMESG-WARN [fdo#105998] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- fi-icl-u2: INCOMPLETE [fdo#108315] -> DMESG-FAIL [fdo#108569]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
Participating hosts (49 -> 44)
--
Additional (2): fi-icl-y fi-pnv-d510
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-kbl-7560u fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5333 -> Patchwork_11130
CI_DRM_5333: c758693b615deff56e5e2098379b587486cfff8a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4750: f05c8c2739dce89185349703062784a7745cab14 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11130: 8936bdf258cf0da59afb7872322b4fc17b9647cc @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8936bdf258cf drm/i915: Drop unused engine->irq_seqno_barrier w/a
8b8443d13146 drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen5
5adb4cef2bd6 drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen7
309c6a53fe5d drm/i915/ringbuffer: Remove irq-seqno w/a for gen6 xcs
56d38a45dd04 drm/i915/ringbuffer: Remove irq-seqno w/a for gen6/7 rcs
c93d4a8ef91f drm/i915: Remove redundant trailing request flush
b9711280291c drm/i915/ringbuffer: Pull the render flush into breadcrumb emission
f47429a3f787 drm/i915/execlists: Pull the render flush into breadcrumb emission
0f84807bc887 drm/i915: Remove HW semaphores for gen7 inter-engine
synchronisation
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11130/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev4)
== Series Details == Series: series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev4) URL : https://patchwork.freedesktop.org/series/54285/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation -O:drivers/gpu/drm/i915/i915_drv.c:349:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:349:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3550:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3547:16: warning: expression using sizeof(void) Commit: drm/i915/execlists: Pull the render flush into breadcrumb emission Okay! Commit: drm/i915/ringbuffer: Pull the render flush into breadcrumb emission Okay! Commit: drm/i915: Remove redundant trailing request flush Okay! Commit: drm/i915/ringbuffer: Remove irq-seqno w/a for gen6/7 rcs Okay! Commit: drm/i915/ringbuffer: Remove irq-seqno w/a for gen6 xcs Okay! Commit: drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen7 Okay! Commit: drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen5 Okay! Commit: drm/i915: Drop unused engine->irq_seqno_barrier w/a 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 series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev4)
== Series Details == Series: series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev4) URL : https://patchwork.freedesktop.org/series/54285/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0f84807bc887 drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation f47429a3f787 drm/i915/execlists: Pull the render flush into breadcrumb emission b9711280291c drm/i915/ringbuffer: Pull the render flush into breadcrumb emission -:82: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #82: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:332: +} +static const int gen6_rcs_emit_breadcrumb_sz = 14; -:110: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #110: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:432: +} +static const int gen7_rcs_emit_breadcrumb_sz = 6; -:122: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #122: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:444: +} +static const int gen6_xcs_emit_breadcrumb_sz = 4; total: 0 errors, 0 warnings, 3 checks, 185 lines checked c93d4a8ef91f drm/i915: Remove redundant trailing request flush 56d38a45dd04 drm/i915/ringbuffer: Remove irq-seqno w/a for gen6/7 rcs 309c6a53fe5d drm/i915/ringbuffer: Remove irq-seqno w/a for gen6 xcs 5adb4cef2bd6 drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen7 -:54: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #54: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:471: +} +static const int gen7_xcs_emit_breadcrumb_sz = 8 + GEN7_XCS_WA * 3; total: 0 errors, 0 warnings, 1 checks, 110 lines checked 8b8443d13146 drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen5 -:66: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #66: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:905: } +static const int gen5_emit_breadcrumb_sz = GEN5_WA_STORES * 3 + 2; total: 0 errors, 0 warnings, 1 checks, 62 lines checked 8936bdf258cf drm/i915: Drop unused engine->irq_seqno_barrier w/a ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] uABI / Removing DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig
On Wed, 19 Dec 2018 12:08:18 +0200
Joonas Lahtinen wrote:
> To me, it seems almost as if folks are too preoccupied with thinking if
> we somehow can do this through tracepoints, to stop and actually think
> if we should.
Regardless of whether it should or shouldn't, one solution to this is
to make the trace event in question record basically nothing but a
pointer.
DECLARE_EVENT_CLASS(i915_hw_request,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq),
TP_STRUCT__entry(
__field(void *, rq)
),
TP_fast_assign(
__entry->rq = rq;
),
TP_printk("rq=%p", __entry->rq)
);
Define the events from that:
DEFINE_EVENT(i915_hw_request, i915_request_submit,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq)
);
No tool can use that information. But for those that want to, you make a
separate module that you can load that has:
DECLARE_EVENT_CLASS(i915_specific_hw_request,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq),
TP_STRUCT__entry(
__field(u32, dev)
__field(u32, hw_id)
__field(u64, ctx)
__field(u16, class)
__field(u16, instance)
__field(u32, seqno)
__field(u32, global)
),
TP_fast_assign(
__entry->dev = rq->i915->drm.primary->index;
__entry->hw_id = rq->gem_context->hw_id;
__entry->class = rq->engine->uabi_class;
__entry->instance = rq->engine->instance;
__entry->ctx = rq->fence.context;
__entry->seqno = rq->fence.seqno;
__entry->global = rq->global_seqno;
),
TP_printk("dev=%u, engine=%u:%u, hw_id=%u, ctx=%llu, seqno=%u,
global=%u",
__entry->dev, __entry->class, __entry->instance,
__entry->hw_id, __entry->ctx, __entry->seqno,
__entry->global)
);
DEFINE_EVENT_FN(i915_specific_hw_request, i915_specific_request_submit,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq),
start_i915_request, stop_i915_request)
);
In the module:
static void do_i915_hw_request(void *data, struct i915_request *rq)
{
trace_i915_specific_request_submit(rq);
}
static bool i915_trace_enabled;
static void enable_disable_tracepoints(struct work_struct *work)
{
if (i915_trace_enabled)
/* Can not enable tracepoints from a tracepoint callback */
register_trace_i915_hw_request(do_i915_hw_request, NULL);
else
unregister_trace_i915_hw_request(do_i915_hw_request, NULL);
}
int start_i915_request(void)
{
i915_trace_enabled = true;
schedule_work(work_call_enable_disable_tracepoints);
}
int stop_i915_request(void)
{
i915_trace_enabled = false;
schedule_work(work_call_enable_disable_tracepoints);
}
Note, the above can be racy, but I'm just trying to show a possible
solution. Which is to have the tracepoint there but exposing no useful
data (event the pointer shown will be mangled by the KASLR security).
But if someone wants a tool, they can create a new tracepoint that is
called by a handler of this tracepoint (yes its a double tracepoint).
The above work, handle would enable/disable the upstream tracepoint
when the other is enabled. Or that may not even be needed, just have
the tool enable both tracepoints when it wants the second one.
-- Steve
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Remove redundant trailing request flush
Now that we perform the request flushing inline with emitting the
breadcrumb, we can remove the now redundant manual flush. And we can
also remove the infrastructure that remained only for its purpose.
v2: emit_breadcrumb_sz is in dwords, but rq->reserved_space is in bytes
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 14 +++---
drivers/gpu/drm/i915/intel_ringbuffer.c | 16
drivers/gpu/drm/i915/intel_ringbuffer.h | 10 --
drivers/gpu/drm/i915/selftests/mock_engine.c | 2 --
4 files changed, 7 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 6cedcfea33b5..ea4620f2ac9e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -521,10 +521,6 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
reserve_gt(i915);
- ret = intel_ring_wait_for_space(ce->ring, MIN_SPACE_FOR_ADD_REQUEST);
- if (ret)
- goto err_unreserve;
-
/* Move our oldest request to the slab-cache (if not in use!) */
rq = list_first_entry(&ce->ring->request_list, typeof(*rq), ring_link);
if (!list_is_last(&rq->ring_link, &ce->ring->request_list) &&
@@ -616,9 +612,13 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
* i915_request_add() call can't fail. Note that the reserve may need
* to be redone if the request is not actually submitted straight
* away, e.g. because a GPU scheduler has deferred it.
+*
+* Note that due to how we add reserved_space to intel_ring_begin()
+* we need to double our request to ensure that if we need to wrap
+* around inside i915_request_add() there is sufficient space at
+* the beginning of the ring as well.
*/
- rq->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
- GEM_BUG_ON(rq->reserved_space < engine->emit_breadcrumb_sz);
+ rq->reserved_space = 2 * engine->emit_breadcrumb_sz * sizeof(u32);
/*
* Record the position of the start of the request so that
@@ -860,8 +860,8 @@ void i915_request_add(struct i915_request *request)
* should already have been reserved in the ring buffer. Let the ring
* know that it is time to use that space up.
*/
+ GEM_BUG_ON(request->reserved_space > request->ring->space);
request->reserved_space = 0;
- engine->emit_flush(request, EMIT_FLUSH);
/*
* Record the position of the start of the breadcrumb so that
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 169c54995ca9..939ba872bff6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1864,22 +1864,6 @@ static noinline int wait_for_space(struct intel_ring
*ring, unsigned int bytes)
return 0;
}
-int intel_ring_wait_for_space(struct intel_ring *ring, unsigned int bytes)
-{
- GEM_BUG_ON(bytes > ring->effective_size);
- if (unlikely(bytes > ring->effective_size - ring->emit))
- bytes += ring->size - ring->emit;
-
- if (unlikely(bytes > ring->space)) {
- int ret = wait_for_space(ring, bytes);
- if (unlikely(ret))
- return ret;
- }
-
- GEM_BUG_ON(ring->space < bytes);
- return 0;
-}
-
u32 *intel_ring_begin(struct i915_request *rq, unsigned int num_dwords)
{
struct intel_ring *ring = rq->ring;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 32606d795af3..99e2cb75d29a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -754,7 +754,6 @@ void intel_legacy_submission_resume(struct drm_i915_private
*dev_priv);
int __must_check intel_ring_cacheline_align(struct i915_request *rq);
-int intel_ring_wait_for_space(struct intel_ring *ring, unsigned int bytes);
u32 __must_check *intel_ring_begin(struct i915_request *rq, unsigned int n);
static inline void intel_ring_advance(struct i915_request *rq, u32 *cs)
@@ -895,15 +894,6 @@ static inline bool intel_engine_has_started(struct
intel_engine_cs *engine,
void intel_engine_get_instdone(struct intel_engine_cs *engine,
struct intel_instdone *instdone);
-/*
- * Arbitrary size for largest possible 'add request' sequence. The code paths
- * are complex and variable. Empirical measurement shows that the worst case
- * is BDW at 192 bytes (6 + 6 + 36 dwords), then ILK at 136 bytes. However,
- * we need to allocate double the largest single packet within that emission
- * to account for tail wraparound (so 6 + 6 + 72 dwords for BDW).
- */
-#define MIN_SPACE_FOR_ADD_REQUEST 336
-
static inline u32 intel_hws_seqno_address(struct intel_engine_cs *engine)
{
retur
Re: [Intel-gfx] [PATCH v6 04/28] drm/dp: DRM DP helper/macros to get DP sink DSC parameters
On Wed, Oct 24, 2018 at 03:28:16PM -0700, Manasi Navare wrote:
> This patch adds inline functions and helpers for obtaining
> DP sink's supported DSC parameters like DSC sink support,
> eDP compressed BPP supported, maximum slice count supported
> by the sink devices, DSC line buffer bit depth supported on DP sink,
> DSC sink maximum color depth by parsing corresponding DPCD registers.
>
> v4:
> * Add helper to give line buf bit depth (Manasi)
> * Correct the bit masking in color depth helper (manasi)
> v3:
> * Use SLICE_CAP_2 for DP (Anusha)
> v2:
> * Add DSC sink support macro (Jani N)
>
> Cc: Gaurav K Singh
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Signed-off-by: Manasi Navare
> Reviewed-by: Anusha Srivatsa
> Reviewed-by: Gaurav K Singh
> ---
> drivers/gpu/drm/drm_dp_helper.c | 90 +
> include/drm/drm_dp_helper.h | 30 +++
> 2 files changed, 120 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 37c01b6076ec..6d483487f2b4 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1352,3 +1352,93 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct
> drm_dp_desc *desc,
> return 0;
> }
> EXPORT_SYMBOL(drm_dp_read_desc);
> +
> +/**
> + * DRM DP Helpers for DSC
> + */
This isn't really kerneldoc. Can you pls fix it, including all the other
new exported functions?
Thanks, Daniel
> +u8 drm_dp_dsc_sink_max_slice_count(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> +bool is_edp)
> +{
> + u8 slice_cap1 = dsc_dpcd[DP_DSC_SLICE_CAP_1 - DP_DSC_SUPPORT];
> +
> + if (is_edp) {
> + /* For eDP, register DSC_SLICE_CAPABILITIES_1 gives slice count
> */
> + if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
> + return 4;
> + if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
> + return 2;
> + if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
> + return 1;
> + } else {
> + /* For DP, use values from DSC_SLICE_CAP_1 and DSC_SLICE_CAP2 */
> + u8 slice_cap2 = dsc_dpcd[DP_DSC_SLICE_CAP_2 - DP_DSC_SUPPORT];
> +
> + if (slice_cap2 & DP_DSC_24_PER_DP_DSC_SINK)
> + return 24;
> + if (slice_cap2 & DP_DSC_20_PER_DP_DSC_SINK)
> + return 20;
> + if (slice_cap2 & DP_DSC_16_PER_DP_DSC_SINK)
> + return 16;
> + if (slice_cap1 & DP_DSC_12_PER_DP_DSC_SINK)
> + return 12;
> + if (slice_cap1 & DP_DSC_10_PER_DP_DSC_SINK)
> + return 10;
> + if (slice_cap1 & DP_DSC_8_PER_DP_DSC_SINK)
> + return 8;
> + if (slice_cap1 & DP_DSC_6_PER_DP_DSC_SINK)
> + return 6;
> + if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
> + return 4;
> + if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
> + return 2;
> + if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
> + return 1;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_dsc_sink_max_slice_count);
> +
> +u8 drm_dp_dsc_sink_line_buf_depth(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> +{
> + u8 line_buf_depth = dsc_dpcd[DP_DSC_LINE_BUF_BIT_DEPTH -
> DP_DSC_SUPPORT];
> +
> + switch (line_buf_depth & DP_DSC_LINE_BUF_BIT_DEPTH_MASK) {
> + case DP_DSC_LINE_BUF_BIT_DEPTH_9:
> + return 9;
> + case DP_DSC_LINE_BUF_BIT_DEPTH_10:
> + return 10;
> + case DP_DSC_LINE_BUF_BIT_DEPTH_11:
> + return 11;
> + case DP_DSC_LINE_BUF_BIT_DEPTH_12:
> + return 12;
> + case DP_DSC_LINE_BUF_BIT_DEPTH_13:
> + return 13;
> + case DP_DSC_LINE_BUF_BIT_DEPTH_14:
> + return 14;
> + case DP_DSC_LINE_BUF_BIT_DEPTH_15:
> + return 15;
> + case DP_DSC_LINE_BUF_BIT_DEPTH_16:
> + return 16;
> + case DP_DSC_LINE_BUF_BIT_DEPTH_8:
> + return 8;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_dsc_sink_line_buf_depth);
> +
> +u8 drm_dp_dsc_sink_max_color_depth(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> +{
> + u8 color_depth = dsc_dpcd[DP_DSC_DEC_COLOR_DEPTH_CAP - DP_DSC_SUPPORT];
> +
> + if (color_depth & DP_DSC_12_BPC)
> + return 12;
> + if (color_depth & DP_DSC_10_BPC)
> + return 10;
> + if (color_depth & DP_DSC_8_BPC)
> + return 8;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_dsc_sink_max_color_depth);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index dd33d59739f8..7f7f5b965466 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1067,6 +1067,36 @@ drm_dp_is_branch(const u8 dpcd[DP_RECEIVER
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev3)
== Series Details ==
Series: series starting with [1/9] drm/i915: Remove HW semaphores for gen7
inter-engine synchronisation (rev3)
URL : https://patchwork.freedesktop.org/series/54285/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5333_full -> Patchwork_11129_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11129_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11129_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11129_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@mock_requests:
- shard-iclb: PASS -> INCOMPLETE
- shard-skl: NOTRUN -> INCOMPLETE
* {igt@runner@aborted}:
- shard-glk: NOTRUN -> FAIL
- shard-hsw: NOTRUN -> FAIL
- shard-snb: NOTRUN -> FAIL
- shard-kbl: NOTRUN -> FAIL
- shard-skl: NOTRUN -> FAIL
- shard-iclb: NOTRUN -> FAIL
- shard-apl: NOTRUN -> FAIL
Warnings
* igt@gem_busy@extended-semaphore-render:
- shard-hsw: PASS -> SKIP +3
* igt@gem_eio@in-flight-internal-10ms:
- shard-hsw: SKIP -> PASS +2
* igt@kms_cursor_crc@cursor-128x42-offscreen:
- shard-apl: SKIP -> PASS +93
* igt@perf_pmu@rc6:
- shard-kbl: SKIP -> PASS
* igt@pm_rc6_residency@rc6-accuracy:
- shard-snb: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11129_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@mock_requests:
- shard-kbl: PASS -> INCOMPLETE [fdo#103665]
- shard-snb: PASS -> INCOMPLETE [fdo#105411]
- shard-hsw: PASS -> INCOMPLETE [fdo#103540]
- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@i915_suspend@shrink:
- shard-skl: NOTRUN -> INCOMPLETE [fdo#106886]
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-snb: NOTRUN -> FAIL [fdo#106641]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-apl: SKIP -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-pageflip-hang-newfb-render-c:
- shard-glk: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-iclb: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-glk: PASS -> FAIL [fdo#103232] +4
* igt@kms_cursor_crc@cursor-256x256-random:
- shard-apl: PASS -> FAIL [fdo#103232] +5
* igt@kms_cursor_crc@cursor-64x64-sliding:
- shard-apl: SKIP -> FAIL [fdo#103232]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-gtt:
- shard-apl: SKIP -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc:
- shard-iclb: PASS -> FAIL [fdo#103167]
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-rte:
- shard-apl: PASS -> FAIL [fdo#103167] / [fdo#105682]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-move:
- shard-glk: PASS -> FAIL [fdo#103167] +7
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#105959]
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-apl: SKIP -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: PASS -> FAIL [fdo#103166] +2
- shard-iclb: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815]
* igt@perf_pmu@rc6-runtime-pm:
- shard-apl: PASS -> FAIL [fdo#105010]
* igt@pm_rpm@legacy-planes:
- shard-skl: NOTRUN -> INCOMPLE
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On Wed, 19 Dec 2018, "C, Ramalingam" wrote:
> On 12/19/2018 8:05 PM, Daniel Vetter wrote:
>> On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
>>> struct intel_hdcp {
>>> @@ -414,6 +430,24 @@ struct intel_hdcp {
>>> */
>>> u8 content_type;
>>> struct hdcp_port_data port_data;
>>> +
>>> + u8 is_paired;
>>> + u8 is_repeater;
>> Make these two bool, will simplify the code a bunch.
>
> Seems there is a movement for not to use the bool in structures.
No. Please use bools in structs when it makes sense. Avoid bools in
structs when you need to care about memory footprint or alignment or
packing or the like. This is not one of those cases.
> Thats why I have changed these from bool to u8 from v8
> onwards. Checkpatch also complains on this
Sorry to say, checkpatch is not the authority although we do send out
automated checkpatch results.
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
Re: [Intel-gfx] [WIP PATCH 03/15] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
On Wed, 2018-12-19 at 13:48 +0100, Daniel Vetter wrote:
> On Tue, Dec 18, 2018 at 04:27:58PM -0500, Lyude Paul wrote:
> > On Fri, 2018-12-14 at 10:29 +0100, Daniel Vetter wrote:
> > > On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote:
> > > > The current way of handling refcounting in the DP MST helpers is
> > > > really
> > > > confusing and probably just plain wrong because it's been hacked up
> > > > many
> > > > times over the years without anyone actually going over the code and
> > > > seeing if things could be simplified.
> > > >
> > > > To the best of my understanding, the current scheme works like this:
> > > > drm_dp_mst_port and drm_dp_mst_branch both have a single refcount.
> > > > When
> > > > this refcount hits 0 for either of the two, they're removed from the
> > > > topology state, but not immediately freed. Both ports and branch
> > > > devices
> > > > will reinitialize their kref once it's hit 0 before actually
> > > > destroying
> > > > themselves. The intended purpose behind this is so that we can avoid
> > > > problems like not being able to free a remote payload that might still
> > > > be active, due to us having removed all of the port/branch device
> > > > structures in memory, as per:
> > > >
> > > > 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
> > > >
> > > > Which may have worked, but then it caused use-after-free errors. Being
> > > > new to MST at the time, I tried fixing it;
> > > >
> > > > 263efde31f97 ("drm/dp/mst: Get validated port ref in
> > > > drm_dp_update_payload_part1()")
> > > >
> > > > But, that was broken: both drm_dp_mst_port and drm_dp_mst_branch
> > > > structs
> > > > are validated in almost every DP MST helper function. Simply put, this
> > > > means we go through the topology and try to see if the given
> > > > drm_dp_mst_branch or drm_dp_mst_port is still attached to something
> > > > before trying to use it in order to avoid dereferencing freed memory
> > > > (something that has happened a LOT in the past with this library).
> > > > Because of this it doesn't actually matter whether or not we keep keep
> > > > the ports and branches around in memory as that's not enough, because
> > > > any function that validates the branches and ports passed to it will
> > > > still reject them anyway since they're no longer in the topology
> > > > structure. So, use-after-free errors were fixed but payload
> > > > deallocation
> > > > was completely broken.
> > > >
> > > > Two years later, AMD informed me about this issue and I attempted to
> > > > come up with a temporary fix, pending a long-overdue cleanup of this
> > > > library:
> > > >
> > > > c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction,
> > > > just
> > > > ref")
> > > >
> > > > But then that introduced use-after-free errors, so I quickly reverted
> > > > it:
> > > >
> > > > 9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during
> > > > destruction, just ref"")
> > > >
> > > > And in the process, learned that there is just no simple fix for this:
> > > > the design is just broken. Unfortuntely, the usage of these helpers
> > > > are
> > > > quite broken as well. Some drivers like i915 have been smart enough to
> > > > avoid accessing any kind of information from MST port structures, but
> > > > others like nouveau have assumed, understandably so, that
> > > > drm_dp_mst_port structures are normal and can just be accessed at any
> > > > time without worrying about use-after-free errors.
> > > >
> > > > After a lot of discussion, me and Daniel Vetter came up with a better
> > > > idea to replace all of this.
> > > >
> > > > To summarize, since this is documented far more indepth in the
> > > > documentation this patch introduces, we make it so that
> > > > drm_dp_mst_port
> > > > and drm_dp_mst_branch structures have two different classes of
> > > > refcounts: topology_kref, and malloc_kref. topology_kref corresponds
> > > > to
> > > > the lifetime of the given drm_dp_mst_port or drm_dp_mst_branch in it's
> > > > given topology. Once it hits zero, any associated connectors are
> > > > removed
> > > > and the branch or port can no longer be validated. malloc_kref
> > > > corresponds to the lifetime of the memory allocation for the actual
> > > > structure, and will always be non-zero so long as the topology_kref is
> > > > non-zero. This gives us a way to allow callers to hold onto port and
> > > > branch device structures past their topology lifetime, and
> > > > dramatically
> > > > simplifies the lifetimes of both structures. This also finally fixes
> > > > the
> > > > port deallocation problem, properly.
> > > >
> > > > Additionally: since this now means that we can keep ports and branch
> > > > devices allocated in memory for however long we need, we no longer
> > > > need
> > > > a significant amount of the port validation that we currently do.
> > > >
> > > > Additionally, there is one last scenario that this fixes, which
> > > > c
Re: [Intel-gfx] [RFC 3/4] drm/i915/perf: handle interrupts from the OA unit
Quoting Lionel Landwerlin (2018-12-19 18:03:26)
> On 19/12/2018 16:19, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-12-19 14:37:46)
> >> static void free_oa_config(struct drm_i915_private *dev_priv,
> >> @@ -1852,6 +1854,13 @@ static void gen7_oa_enable(struct i915_perf_stream
> >> *stream)
> >> */
> >> gen7_init_oa_buffer(dev_priv);
> >>
> >> + if (stream->oa_interrupt_monitor) {
> >> + spin_lock(&dev_priv->irq_lock);
> > Doesn't look like you are already in interrupt context, so spin_lock_irq()
> > required for dev_priv->irq_lock.
> > -Chris
> >
> Thanks a lot Chris, will fix.
> Any comment on the atomic counter? Does that look like a bad design/idea?
It's not illogical, but conceivably you don't need one at all. You just
use the wakeup from the interrupt as a kick to check buffer status, that
should be cheap enough to not worry about short-circuiting the half-full
interrupt check (and even if we do wakeup twice within the same
half-full period, there may be a few results to move along). Without
adding a hrtimer, there should not be many spurious wakeups to soak up
the cpu.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/4] drm/i915/perf: handle interrupts from the OA unit
On 19/12/2018 16:19, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-12-19 14:37:46)
static void free_oa_config(struct drm_i915_private *dev_priv,
@@ -1852,6 +1854,13 @@ static void gen7_oa_enable(struct i915_perf_stream
*stream)
*/
gen7_init_oa_buffer(dev_priv);
+ if (stream->oa_interrupt_monitor) {
+ spin_lock(&dev_priv->irq_lock);
Doesn't look like you are already in interrupt context, so spin_lock_irq()
required for dev_priv->irq_lock.
-Chris
Thanks a lot Chris, will fix.
Any comment on the atomic counter? Does that look like a bad design/idea?
Cheers,
-
Lionel
___
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/perf: add OA interrupt support
== Series Details ==
Series: drm/i915/perf: add OA interrupt support
URL : https://patchwork.freedesktop.org/series/54280/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5333_full -> Patchwork_11127_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11127_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11127_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11127_full:
### IGT changes ###
Warnings
* igt@kms_cursor_crc@cursor-128x42-offscreen:
- shard-apl: SKIP -> PASS +95
* igt@perf_pmu@rc6:
- shard-kbl: SKIP -> PASS
* igt@pm_rc6_residency@rc6-accuracy:
- shard-snb: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11127_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@i915_suspend@shrink:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#108784]
* igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-snb: NOTRUN -> FAIL [fdo#106641]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-apl: SKIP -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-iclb: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-b-degamma:
- shard-apl: PASS -> FAIL [fdo#104782] +1
* igt@kms_color@pipe-c-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_color@pipe-c-gamma:
- shard-skl: NOTRUN -> FAIL [fdo#104782] / [fdo#108228]
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] +1
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-glk: PASS -> FAIL [fdo#103232] +3
* igt@kms_cursor_crc@cursor-256x256-offscreen:
- shard-skl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +7
* igt@kms_flip@flip-vs-wf_vblank-interruptible:
- shard-kbl: PASS -> DMESG-WARN [fdo#105345]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
- shard-glk: PASS -> FAIL [fdo#103167] +4
* igt@kms_frontbuffer_tracking@fbcpsr-suspend:
- shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#106978] /
[fdo#107773]
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-apl: SKIP -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815]
* igt@perf_pmu@rc6-runtime-pm:
- shard-apl: PASS -> FAIL [fdo#105010]
* igt@pm_rpm@modeset-pc8-residency-stress:
- shard-skl: SKIP -> INCOMPLETE [fdo#107807]
* igt@pm_rpm@universal-planes:
- shard-iclb: PASS -> DMESG-WARN [fdo#108654] / [fdo#108756]
* {igt@runner@aborted}:
- shard-iclb: NOTRUN -> ( 2 FAIL ) [fdo#108315] / [fdo#108654] /
[fdo#108756]
Possible fixes
* igt@gem_ctx_isolation@bcs0-s3:
- shard-apl: DMESG-WARN [fdo#103558] -> PASS
* igt@gem_userptr_blits@readonly-unsync:
- shard-skl: TIMEOUT [fdo#108887] -> PASS
* igt@kms_atomic_transition@1x-modeset-transitions-fencing:
- shard-skl: FAIL [fdo#108470] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-hsw: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_chv_cursor_fail@pipe-b-64x64-right-edge:
- shard-iclb: DMESG-WARN [fdo#107724] / [fdo#108336] -> PASS +5
* igt@kms_cursor_crc@cursor-256x256-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: FAIL [fdo#103191] /
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev3)
== Series Details ==
Series: series starting with [1/9] drm/i915: Remove HW semaphores for gen7
inter-engine synchronisation (rev3)
URL : https://patchwork.freedesktop.org/series/54285/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5333 -> Patchwork_11129
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11129 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11129, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54285/revisions/3/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11129:
### IGT changes ###
Warnings
* igt@pm_rpm@basic-pci-d3-state:
- fi-byt-n2820: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11129 that come from known issues:
### IGT changes ###
Issues hit
* igt@pm_rpm@basic-rte:
- fi-byt-n2820: PASS -> FAIL [fdo#108800]
* {igt@runner@aborted}:
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
- fi-apl-guc: DMESG-FAIL -> PASS
- fi-kbl-7560u: INCOMPLETE [fdo#108044] -> PASS
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: DMESG-WARN [fdo#105998] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- fi-icl-u2: INCOMPLETE [fdo#108315] -> DMESG-FAIL [fdo#108569]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
Participating hosts (49 -> 45)
--
Additional (2): fi-icl-y fi-pnv-d510
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5333 -> Patchwork_11129
CI_DRM_5333: c758693b615deff56e5e2098379b587486cfff8a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4750: f05c8c2739dce89185349703062784a7745cab14 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11129: c3b315a05c483b1b28f4cafa10edac070e805b2f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c3b315a05c48 drm/i915: Drop unused engine->irq_seqno_barrier w/a
4945e36c6334 drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen5
4eaf8067ca16 drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen7
49b0742dacee drm/i915/ringbuffer: Remove irq-seqno w/a for gen6 xcs
d56fe06b0732 drm/i915/ringbuffer: Remove irq-seqno w/a for gen6/7 rcs
b376ae479b23 drm/i915: Remove redundant trailing request flush
303ed6ddd8b9 drm/i915/ringbuffer: Pull the render flush into breadcrumb emission
f0b93d301db9 drm/i915/execlists: Pull the render flush into breadcrumb emission
dd18acd49bb2 drm/i915: Remove HW semaphores for gen7 inter-engine
synchronisation
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11129/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev3)
== Series Details == Series: series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev3) URL : https://patchwork.freedesktop.org/series/54285/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation -O:drivers/gpu/drm/i915/i915_drv.c:349:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:349:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3550:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3547:16: warning: expression using sizeof(void) Commit: drm/i915/execlists: Pull the render flush into breadcrumb emission Okay! Commit: drm/i915/ringbuffer: Pull the render flush into breadcrumb emission Okay! Commit: drm/i915: Remove redundant trailing request flush Okay! Commit: drm/i915/ringbuffer: Remove irq-seqno w/a for gen6/7 rcs Okay! Commit: drm/i915/ringbuffer: Remove irq-seqno w/a for gen6 xcs Okay! Commit: drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen7 Okay! Commit: drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen5 Okay! Commit: drm/i915: Drop unused engine->irq_seqno_barrier w/a Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_workarounds: adding 0xe420 register to WO list
From: talha nassar
HW team confirmed that this register is write-only.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107338
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: talha nassar
---
tests/i915/gem_workarounds.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_workarounds.c b/tests/i915/gem_workarounds.c
index 78478ad..b7d7d9c 100644
--- a/tests/i915/gem_workarounds.c
+++ b/tests/i915/gem_workarounds.c
@@ -51,7 +51,8 @@ static struct write_only_list {
unsigned int gen;
uint32_t addr;
} wo_list[] = {
- { 10, 0xE5F0 } /* WaForceContextSaveRestoreNonCoherent:cnl */
+ { 10, 0xE5F0 }, /* WaForceContextSaveRestoreNonCoherent:cnl */
+ { 11, 0xE420 } /* WaEnableFloatBlendOptimization:icl */
/*
* FIXME: If you are contemplating adding stuff here
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev3)
== Series Details == Series: series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation (rev3) URL : https://patchwork.freedesktop.org/series/54285/ State : warning == Summary == $ dim checkpatch origin/drm-tip dd18acd49bb2 drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation f0b93d301db9 drm/i915/execlists: Pull the render flush into breadcrumb emission 303ed6ddd8b9 drm/i915/ringbuffer: Pull the render flush into breadcrumb emission -:82: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #82: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:332: +} +static const int gen6_rcs_emit_breadcrumb_sz = 14; -:110: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #110: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:432: +} +static const int gen7_rcs_emit_breadcrumb_sz = 6; -:122: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #122: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:444: +} +static const int gen6_xcs_emit_breadcrumb_sz = 4; total: 0 errors, 0 warnings, 3 checks, 185 lines checked b376ae479b23 drm/i915: Remove redundant trailing request flush d56fe06b0732 drm/i915/ringbuffer: Remove irq-seqno w/a for gen6/7 rcs 49b0742dacee drm/i915/ringbuffer: Remove irq-seqno w/a for gen6 xcs 4eaf8067ca16 drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen7 -:54: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #54: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:471: +} +static const int gen7_xcs_emit_breadcrumb_sz = 8 + GEN7_XCS_WA * 3; total: 0 errors, 0 warnings, 1 checks, 110 lines checked 4945e36c6334 drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen5 -:66: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #66: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:905: } +static const int gen5_emit_breadcrumb_sz = GEN5_WA_STORES * 3 + 2; total: 0 errors, 0 warnings, 1 checks, 62 lines checked c3b315a05c48 drm/i915: Drop unused engine->irq_seqno_barrier w/a ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 13/39] drm: HDCP2.2 link check related constants
On 12/19/2018 10:05 PM, Daniel Vetter wrote:
On Wed, Dec 19, 2018 at 5:22 PM C, Ramalingam wrote:
On 12/19/2018 9:28 PM, Daniel Vetter wrote:
On Wed, Dec 19, 2018 at 09:09:00PM +0530, C, Ramalingam wrote:
On 12/19/2018 8:46 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 09:31:15AM +0530, Ramalingam C wrote:
Enums and macros are defined for HDCP2.2 link check.
Signed-off-by: Ramalingam C
---
include/drm/drm_hdcp.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index d8093ecf3ddc..21a128e7020a 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -11,6 +11,14 @@
/* Period of hdcp checks (to ensure we're still authenticated) */
#define DRM_HDCP_CHECK_PERIOD_MS(128 * 16)
+#define DRM_HDCP2_CHECK_PERIOD_MS 500
This one here is good imo, and has my Reviewed-by: Daniel Vetter
+
+enum check_link_response {
+ DRM_HDCP_LINK_PROTECTED = 0,
+ DRM_HDCP_TOPOLOGY_CHANGE,
+ DRM_HDCP_LINK_INTEGRITY_FAILURE,
+ DRM_HDCP_REAUTH_REQUEST
+};
But this one here is just a part of the intel_hdcp_shim interface. I think
we should put into the intel_drv.h header, and change the return value of
the check_2_2_link hook to this enum. I think that would clarify the code
a lot. Plus then ofc merge this part into the first patch that uses it.
daniel,
this is generic link check results as per the HDCP spec. This could be used
by any other driver in DRM. Still should i move as local to intel?
Yeah I think makes more sense. intel_hdcp_shim could also be used as
fairly generic hdcp implementation, but right now it isn't. Better to keep
things together that are used together.
thanks. With this i will use your R-b ?
Just to clarify: R-b with the enum moved to intel_drv.h, together with
the intel_hdcp_shim using it. Just realized that my reply is a bit
confusing.
True. I thought you didn't suggest any change :) I will do that the
changes mentioned.
-Ram
-Daniel
-Ram
-Daniel
-Ram
With that remaining patches have my ack, too.
Cheers, Daniel
/* Shared lengths/masks between HDMI/DVI/DisplayPort */
#define DRM_HDCP_AN_LEN 8
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Remove redundant trailing request flush
Now that we perform the request flushing inline with emitting the
breadcrumb, we can remove the now redundant manual flush. And we can
also remove the infrastructure that remained only for its purpose.
v2: emit_breadcrumb_sz is in dwords, but rq->reserved_space is in bytes
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 15 ---
drivers/gpu/drm/i915/intel_ringbuffer.c | 16
drivers/gpu/drm/i915/intel_ringbuffer.h | 10 --
drivers/gpu/drm/i915/selftests/mock_engine.c | 2 --
4 files changed, 8 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 6cedcfea33b5..f3727f9aad34 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -521,10 +521,6 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
reserve_gt(i915);
- ret = intel_ring_wait_for_space(ce->ring, MIN_SPACE_FOR_ADD_REQUEST);
- if (ret)
- goto err_unreserve;
-
/* Move our oldest request to the slab-cache (if not in use!) */
rq = list_first_entry(&ce->ring->request_list, typeof(*rq), ring_link);
if (!list_is_last(&rq->ring_link, &ce->ring->request_list) &&
@@ -616,9 +612,14 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
* i915_request_add() call can't fail. Note that the reserve may need
* to be redone if the request is not actually submitted straight
* away, e.g. because a GPU scheduler has deferred it.
+*
+* Note that due to how we add reserved_space to intel_ring_begin()
+* we need to double our request to ensure that if we need to wrap
+* around inside i915_request_add() there is sufficient space at
+* the beginning of the ring as well.
*/
- rq->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
- GEM_BUG_ON(rq->reserved_space < engine->emit_breadcrumb_sz);
+ rq->reserved_space = 2 * engine->emit_breadcrumb_sz * sizeof(u32);
+ GEM_BUG_ON(!rq->reserved_space);
/*
* Record the position of the start of the request so that
@@ -860,8 +861,8 @@ void i915_request_add(struct i915_request *request)
* should already have been reserved in the ring buffer. Let the ring
* know that it is time to use that space up.
*/
+ GEM_BUG_ON(request->reserved_space > request->ring->space);
request->reserved_space = 0;
- engine->emit_flush(request, EMIT_FLUSH);
/*
* Record the position of the start of the breadcrumb so that
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 169c54995ca9..939ba872bff6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1864,22 +1864,6 @@ static noinline int wait_for_space(struct intel_ring
*ring, unsigned int bytes)
return 0;
}
-int intel_ring_wait_for_space(struct intel_ring *ring, unsigned int bytes)
-{
- GEM_BUG_ON(bytes > ring->effective_size);
- if (unlikely(bytes > ring->effective_size - ring->emit))
- bytes += ring->size - ring->emit;
-
- if (unlikely(bytes > ring->space)) {
- int ret = wait_for_space(ring, bytes);
- if (unlikely(ret))
- return ret;
- }
-
- GEM_BUG_ON(ring->space < bytes);
- return 0;
-}
-
u32 *intel_ring_begin(struct i915_request *rq, unsigned int num_dwords)
{
struct intel_ring *ring = rq->ring;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 32606d795af3..99e2cb75d29a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -754,7 +754,6 @@ void intel_legacy_submission_resume(struct drm_i915_private
*dev_priv);
int __must_check intel_ring_cacheline_align(struct i915_request *rq);
-int intel_ring_wait_for_space(struct intel_ring *ring, unsigned int bytes);
u32 __must_check *intel_ring_begin(struct i915_request *rq, unsigned int n);
static inline void intel_ring_advance(struct i915_request *rq, u32 *cs)
@@ -895,15 +894,6 @@ static inline bool intel_engine_has_started(struct
intel_engine_cs *engine,
void intel_engine_get_instdone(struct intel_engine_cs *engine,
struct intel_instdone *instdone);
-/*
- * Arbitrary size for largest possible 'add request' sequence. The code paths
- * are complex and variable. Empirical measurement shows that the worst case
- * is BDW at 192 bytes (6 + 6 + 36 dwords), then ILK at 136 bytes. However,
- * we need to allocate double the largest single packet within that emission
- * to account for tail wraparound (so 6 + 6 + 72 dwords for BDW).
- */
-#define MIN_SPACE_FOR_ADD_REQUEST 336
-
static inline u32 intel_hws_seqno_address(struct
Re: [Intel-gfx] [RFC v3 1/3] PM/runtime: Add a new interface to get accounted time
On Wed, 19 Dec 2018 at 17:36, Ulf Hansson wrote:
>
> On Wed, 19 Dec 2018 at 14:26, Vincent Guittot
> wrote:
> >
> > On Wed, 19 Dec 2018 at 11:43, Ulf Hansson wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
> > > wrote:
> > > >
> > > > On Wed, 19 Dec 2018 at 11:21, Ulf Hansson
> > > > wrote:
> > > > >
> >
> > > > > > > >
> > > > > > > > diff --git a/drivers/base/power/runtime.c
> > > > > > > > b/drivers/base/power/runtime.c
> > > > > > > > index 7062469..6461469 100644
> > > > > > > > --- a/drivers/base/power/runtime.c
> > > > > > > > +++ b/drivers/base/power/runtime.c
> > > > > > > > @@ -88,6 +88,32 @@ static void __update_runtime_status(struct
> > > > > > > > device *dev, enum rpm_status status)
> > > > > > > > dev->power.runtime_status = status;
> > > > > > > > }
> > > > > > > >
> > > > > > > > +u64 pm_runtime_accounted_time_get(struct device *dev, enum
> > > > > > > > rpm_status status, bool update)
> > > > > > > > +{
> > > > > > > > + u64 now = ktime_to_ns(ktime_get());
> > > > > > >
> > > > > > > I think you should stay on jiffies here - and then switch to
> > > > > > > ktime in patch 3.
> > > > > > >
> > > > > > > > + u64 delta = 0, time = 0;
> > > > > > > > + unsigned long flags;
> > > > > > > > +
> > > > > > > > + spin_lock_irqsave(&dev->power.lock, flags);
> > > > > > > > +
> > > > > > > > + if (dev->power.disable_depth > 0)
> > > > > > > > + goto unlock;
> > > > > > > > +
> > > > > > > > + /* Add ongoing state if requested */
> > > > > > > > + if (update && dev->power.runtime_status == status)
> > > > > > > > + delta = now - dev->power.accounting_timestamp;
> > > > > > > > +
> > > > > > >
> > > > > > > Hmm. Do we really need to update the accounting timestamp? I would
> > > > > > > rather avoid it if possible.
> > > > > >
> > > > > > i915/drm uses this to track ongoing suspended state. In fact they
> > > > > > are
> > > > > > mainly interested by this part
> > > > >
> > > > > Again, sorry I don't follow.
> > > >
> > > > In fact we don't update dev->power.accounting_timestamp but only use
> > > > it to get how much time has elapsed in the current state.
> > > >
> > > > >
> > > > > My suggested changes below, would do exactly that; track the ongoing
> > > > > suspended state.
> > > > >
> > > > > The user can call the function several times while the device remains
> > > > > RPM_SUSPENDED, and if needed the user could then compute the delta
> > > > > in-between the calls, for whatever reason that may be needed.
> > > >
> > > > So I'm not sure to catch your question:
> > > > Is your problem linked to status != RPM_SUSPENDED or the update
> > > > parameter that compute delta ?
> > >
> > > My intent was to keep things simple.
> > >
> > > 1. Only expose last suspended time, which means tracking the ongoing
> > > suspended state. In other words, you can also remove "enum rpm_status
> > > status" as the in-parameter to pm_runtime_accounted_time_get().
> >
> > Ok for this point if Rafael doesn't see any benefit of keeping the
> > generic interface
> >
> > > 2. Don't allow the user of pm_runtime_accounted_time_get() to update
> > > the current timestamp, in "dev->power.accounting_timestamp".
> >
> > But pm_runtime_accounted_time_get doesn't update
> > dev->power.accounting_timestamp, it only reads it to know when when
> > the last state transition happened
>
> I understand, sorry for not being clear enough.
>
> My point is, you must not update dev->power.suspended_time, without
> also setting a new value for dev->power.accounting_timestamp.
> Otherwise, the next time the core calls
> update_pm_runtime_accounting(), it will end up adding a wrong delta to
> dev->power.suspended_time.
I fully agree on that and that's why dev->power.accounting_timestamp
is not and has never been modified
>
> BTW, it seems like you have based this on top of some patch converting
> from jiffies to ktime, as I can't fine dev->power.suspended_time, but
> instead I have dev->power.suspended_jiffies.
>
> On Wed, 19 Dec 2018 at 14:26, Vincent Guittot
> wrote:
> >
> > On Wed, 19 Dec 2018 at 11:43, Ulf Hansson wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
> > > wrote:
> > > >
> > > > On Wed, 19 Dec 2018 at 11:21, Ulf Hansson
> > > > wrote:
> > > > >
> >
> > > > > > > >
> > > > > > > > diff --git a/drivers/base/power/runtime.c
> > > > > > > > b/drivers/base/power/runtime.c
> > > > > > > > index 7062469..6461469 100644
> > > > > > > > --- a/drivers/base/power/runtime.c
> > > > > > > > +++ b/drivers/base/power/runtime.c
> > > > > > > > @@ -88,6 +88,32 @@ static void __update_runtime_status(struct
> > > > > > > > device *dev, enum rpm_status status)
> > > > > > > > dev->power.runtime_status = status;
> > > > > > > > }
> > > > > > > >
> > > > > > > > +u64 pm_runtime_accounted_time_get(struct device *dev, enum
> > > > > > > > rpm_status status, bool update)
> > > > > > > > +{
> > > > > > > > +
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Prepare for larger CSB status FIFO size (rev4)
== Series Details == Series: series starting with [1/3] drm/i915: Prepare for larger CSB status FIFO size (rev4) URL : https://patchwork.freedesktop.org/series/54213/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5333_full -> Patchwork_11126_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11126_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11126_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11126_full: ### IGT changes ### Possible regressions * igt@debugfs_test@read_all_entries: - shard-iclb: PASS -> INCOMPLETE Warnings * igt@kms_cursor_crc@cursor-128x42-offscreen: - shard-apl: SKIP -> PASS +92 * igt@perf_pmu@rc6: - shard-kbl: SKIP -> PASS * igt@pm_rc6_residency@rc6-accuracy: - shard-snb: PASS -> SKIP Known issues Here are the changes found in Patchwork_11126_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@gem_ppgtt@blt-vs-render-ctxn: - shard-skl: PASS -> TIMEOUT [fdo#108039] * igt@i915_suspend@shrink: - shard-skl: NOTRUN -> DMESG-WARN [fdo#108784] * igt@kms_available_modes_crc@available_mode_test_crc: - shard-snb: NOTRUN -> FAIL [fdo#106641] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-apl: SKIP -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-a: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +13 * igt@kms_busy@extended-pageflip-hang-newfb-render-c: - shard-glk: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#107956] * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-glk: PASS -> FAIL [fdo#108145] * igt@kms_color@pipe-b-degamma: - shard-apl: PASS -> FAIL [fdo#104782] * igt@kms_color@pipe-c-gamma: - shard-skl: NOTRUN -> FAIL [fdo#104782] / [fdo#108228] * igt@kms_cursor_crc@cursor-128x128-random: - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-128x42-sliding: - shard-apl: PASS -> FAIL [fdo#103232] +5 - shard-glk: PASS -> FAIL [fdo#103232] +2 * igt@kms_cursor_crc@cursor-256x256-dpms: - shard-apl: SKIP -> FAIL [fdo#103232] +1 * igt@kms_cursor_crc@cursor-256x256-offscreen: - shard-skl: PASS -> FAIL [fdo#103232] * igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-xtiled: - shard-iclb: PASS -> WARN [fdo#108336] +1 * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt: - shard-apl: SKIP -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: - shard-iclb: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-move: - shard-glk: PASS -> FAIL [fdo#103167] +5 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +1 * igt@kms_frontbuffer_tracking@fbcpsr-stridechange: - shard-iclb: PASS -> FAIL [fdo#105683] * igt@kms_plane@pixel-format-pipe-b-planes: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-apl: PASS -> FAIL [fdo#108948] * igt@kms_plane_alpha_blend@pipe-a-alpha-basic: - shard-apl: SKIP -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] * igt@kms_rotation_crc@primary-yf-tiled-reflect-x-0: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +6 * igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] * igt@perf_pmu@rc6-runtime-pm: - shard
[Intel-gfx] [PATCH v2] drm/i915: Remove redundant trailing request flush
Now that we perform the request flushing inline with emitting the
breadcrumb, we can remove the now redundant manual flush. And we can
also remove the infrastructure that remained only for its purpose.
v2: emit_breadcrumb_sz is in dwords, but rq->reserved_space is in bytes
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 15 ---
drivers/gpu/drm/i915/intel_ringbuffer.c | 16
drivers/gpu/drm/i915/intel_ringbuffer.h | 10 --
drivers/gpu/drm/i915/selftests/mock_engine.c | 2 --
4 files changed, 8 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 6cedcfea33b5..3cb25f1f8aa8 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -521,10 +521,6 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
reserve_gt(i915);
- ret = intel_ring_wait_for_space(ce->ring, MIN_SPACE_FOR_ADD_REQUEST);
- if (ret)
- goto err_unreserve;
-
/* Move our oldest request to the slab-cache (if not in use!) */
rq = list_first_entry(&ce->ring->request_list, typeof(*rq), ring_link);
if (!list_is_last(&rq->ring_link, &ce->ring->request_list) &&
@@ -616,9 +612,14 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
* i915_request_add() call can't fail. Note that the reserve may need
* to be redone if the request is not actually submitted straight
* away, e.g. because a GPU scheduler has deferred it.
+*
+* Note that due to how we add reserved_space to intel_ring_begin()
+* we need to double our request to ensure that if we need to wrap
+* around inside i915_request_add() there is sufficient space at
+* the beginning of the ring as well.
*/
- rq->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
- GEM_BUG_ON(rq->reserved_space < engine->emit_breadcrumb_sz);
+ rq->reserved_space = 2 * engine->emit_breadcrumb_sz * sizeof(u32);
+ GEM_BUG_ON(!rq->reserved_space);
/*
* Record the position of the start of the request so that
@@ -860,8 +861,8 @@ void i915_request_add(struct i915_request *request)
* should already have been reserved in the ring buffer. Let the ring
* know that it is time to use that space up.
*/
+ GEM_BUG_ON(request->reserved_space < request->ring->space);
request->reserved_space = 0;
- engine->emit_flush(request, EMIT_FLUSH);
/*
* Record the position of the start of the breadcrumb so that
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 169c54995ca9..939ba872bff6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1864,22 +1864,6 @@ static noinline int wait_for_space(struct intel_ring
*ring, unsigned int bytes)
return 0;
}
-int intel_ring_wait_for_space(struct intel_ring *ring, unsigned int bytes)
-{
- GEM_BUG_ON(bytes > ring->effective_size);
- if (unlikely(bytes > ring->effective_size - ring->emit))
- bytes += ring->size - ring->emit;
-
- if (unlikely(bytes > ring->space)) {
- int ret = wait_for_space(ring, bytes);
- if (unlikely(ret))
- return ret;
- }
-
- GEM_BUG_ON(ring->space < bytes);
- return 0;
-}
-
u32 *intel_ring_begin(struct i915_request *rq, unsigned int num_dwords)
{
struct intel_ring *ring = rq->ring;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 32606d795af3..99e2cb75d29a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -754,7 +754,6 @@ void intel_legacy_submission_resume(struct drm_i915_private
*dev_priv);
int __must_check intel_ring_cacheline_align(struct i915_request *rq);
-int intel_ring_wait_for_space(struct intel_ring *ring, unsigned int bytes);
u32 __must_check *intel_ring_begin(struct i915_request *rq, unsigned int n);
static inline void intel_ring_advance(struct i915_request *rq, u32 *cs)
@@ -895,15 +894,6 @@ static inline bool intel_engine_has_started(struct
intel_engine_cs *engine,
void intel_engine_get_instdone(struct intel_engine_cs *engine,
struct intel_instdone *instdone);
-/*
- * Arbitrary size for largest possible 'add request' sequence. The code paths
- * are complex and variable. Empirical measurement shows that the worst case
- * is BDW at 192 bytes (6 + 6 + 36 dwords), then ILK at 136 bytes. However,
- * we need to allocate double the largest single packet within that emission
- * to account for tail wraparound (so 6 + 6 + 72 dwords for BDW).
- */
-#define MIN_SPACE_FOR_ADD_REQUEST 336
-
static inline u32 intel_hws_seqno_address(struct
Re: [Intel-gfx] [PATCH 4/9] drm/i915: Remove redundant trailing request flush
Quoting Chris Wilson (2018-12-19 14:57:42) > @@ -616,9 +612,13 @@ i915_request_alloc(struct intel_engine_cs *engine, > struct i915_gem_context *ctx) > * i915_request_add() call can't fail. Note that the reserve may need > * to be redone if the request is not actually submitted straight > * away, e.g. because a GPU scheduler has deferred it. > +* > +* Note that due to how we add reserved_space to intel_ring_begin() > +* we need to double our request to ensure that if we need to wrap > +* around inside i915_request_add() there is sufficient space at > +* the beginning of the ring as well. > */ > - rq->reserved_space = MIN_SPACE_FOR_ADD_REQUEST; > - GEM_BUG_ON(rq->reserved_space < engine->emit_breadcrumb_sz); > + rq->reserved_space = 2 * engine->emit_breadcrumb_sz; Oh. emit_breadcrumb_sz is in dwords, reserved_space is in bytes. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v3 1/3] PM/runtime: Add a new interface to get accounted time
On Wed, 19 Dec 2018 at 14:26, Vincent Guittot
wrote:
>
> On Wed, 19 Dec 2018 at 11:43, Ulf Hansson wrote:
> >
> > On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
> > wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:21, Ulf Hansson wrote:
> > > >
>
> > > > > > >
> > > > > > > diff --git a/drivers/base/power/runtime.c
> > > > > > > b/drivers/base/power/runtime.c
> > > > > > > index 7062469..6461469 100644
> > > > > > > --- a/drivers/base/power/runtime.c
> > > > > > > +++ b/drivers/base/power/runtime.c
> > > > > > > @@ -88,6 +88,32 @@ static void __update_runtime_status(struct
> > > > > > > device *dev, enum rpm_status status)
> > > > > > > dev->power.runtime_status = status;
> > > > > > > }
> > > > > > >
> > > > > > > +u64 pm_runtime_accounted_time_get(struct device *dev, enum
> > > > > > > rpm_status status, bool update)
> > > > > > > +{
> > > > > > > + u64 now = ktime_to_ns(ktime_get());
> > > > > >
> > > > > > I think you should stay on jiffies here - and then switch to ktime
> > > > > > in patch 3.
> > > > > >
> > > > > > > + u64 delta = 0, time = 0;
> > > > > > > + unsigned long flags;
> > > > > > > +
> > > > > > > + spin_lock_irqsave(&dev->power.lock, flags);
> > > > > > > +
> > > > > > > + if (dev->power.disable_depth > 0)
> > > > > > > + goto unlock;
> > > > > > > +
> > > > > > > + /* Add ongoing state if requested */
> > > > > > > + if (update && dev->power.runtime_status == status)
> > > > > > > + delta = now - dev->power.accounting_timestamp;
> > > > > > > +
> > > > > >
> > > > > > Hmm. Do we really need to update the accounting timestamp? I would
> > > > > > rather avoid it if possible.
> > > > >
> > > > > i915/drm uses this to track ongoing suspended state. In fact they are
> > > > > mainly interested by this part
> > > >
> > > > Again, sorry I don't follow.
> > >
> > > In fact we don't update dev->power.accounting_timestamp but only use
> > > it to get how much time has elapsed in the current state.
> > >
> > > >
> > > > My suggested changes below, would do exactly that; track the ongoing
> > > > suspended state.
> > > >
> > > > The user can call the function several times while the device remains
> > > > RPM_SUSPENDED, and if needed the user could then compute the delta
> > > > in-between the calls, for whatever reason that may be needed.
> > >
> > > So I'm not sure to catch your question:
> > > Is your problem linked to status != RPM_SUSPENDED or the update
> > > parameter that compute delta ?
> >
> > My intent was to keep things simple.
> >
> > 1. Only expose last suspended time, which means tracking the ongoing
> > suspended state. In other words, you can also remove "enum rpm_status
> > status" as the in-parameter to pm_runtime_accounted_time_get().
>
> Ok for this point if Rafael doesn't see any benefit of keeping the
> generic interface
>
> > 2. Don't allow the user of pm_runtime_accounted_time_get() to update
> > the current timestamp, in "dev->power.accounting_timestamp".
>
> But pm_runtime_accounted_time_get doesn't update
> dev->power.accounting_timestamp, it only reads it to know when when
> the last state transition happened
I understand, sorry for not being clear enough.
My point is, you must not update dev->power.suspended_time, without
also setting a new value for dev->power.accounting_timestamp.
Otherwise, the next time the core calls
update_pm_runtime_accounting(), it will end up adding a wrong delta to
dev->power.suspended_time.
BTW, it seems like you have based this on top of some patch converting
from jiffies to ktime, as I can't fine dev->power.suspended_time, but
instead I have dev->power.suspended_jiffies.
On Wed, 19 Dec 2018 at 14:26, Vincent Guittot
wrote:
>
> On Wed, 19 Dec 2018 at 11:43, Ulf Hansson wrote:
> >
> > On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
> > wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:21, Ulf Hansson wrote:
> > > >
>
> > > > > > >
> > > > > > > diff --git a/drivers/base/power/runtime.c
> > > > > > > b/drivers/base/power/runtime.c
> > > > > > > index 7062469..6461469 100644
> > > > > > > --- a/drivers/base/power/runtime.c
> > > > > > > +++ b/drivers/base/power/runtime.c
> > > > > > > @@ -88,6 +88,32 @@ static void __update_runtime_status(struct
> > > > > > > device *dev, enum rpm_status status)
> > > > > > > dev->power.runtime_status = status;
> > > > > > > }
> > > > > > >
> > > > > > > +u64 pm_runtime_accounted_time_get(struct device *dev, enum
> > > > > > > rpm_status status, bool update)
> > > > > > > +{
> > > > > > > + u64 now = ktime_to_ns(ktime_get());
> > > > > >
> > > > > > I think you should stay on jiffies here - and then switch to ktime
> > > > > > in patch 3.
> > > > > >
> > > > > > > + u64 delta = 0, time = 0;
> > > > > > > + unsigned long flags;
> > > > > > > +
> > > > > > > + spin_lock_irqsave(&dev->power.lock, flags);
> > > > > > > +
> > > > > > > + if (dev->power.disable_depth > 0)
> > > > > > > +
Re: [Intel-gfx] [PATCH v9 13/39] drm: HDCP2.2 link check related constants
On Wed, Dec 19, 2018 at 5:22 PM C, Ramalingam wrote:
>
>
> On 12/19/2018 9:28 PM, Daniel Vetter wrote:
> > On Wed, Dec 19, 2018 at 09:09:00PM +0530, C, Ramalingam wrote:
> >> On 12/19/2018 8:46 PM, Daniel Vetter wrote:
> >>> On Thu, Dec 13, 2018 at 09:31:15AM +0530, Ramalingam C wrote:
> Enums and macros are defined for HDCP2.2 link check.
>
> Signed-off-by: Ramalingam C
> ---
> include/drm/drm_hdcp.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index d8093ecf3ddc..21a128e7020a 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -11,6 +11,14 @@
> /* Period of hdcp checks (to ensure we're still authenticated) */
> #define DRM_HDCP_CHECK_PERIOD_MS(128 * 16)
> +#define DRM_HDCP2_CHECK_PERIOD_MS 500
> >>> This one here is good imo, and has my Reviewed-by: Daniel Vetter
> >>>
> >>>
> +
> +enum check_link_response {
> + DRM_HDCP_LINK_PROTECTED = 0,
> + DRM_HDCP_TOPOLOGY_CHANGE,
> + DRM_HDCP_LINK_INTEGRITY_FAILURE,
> + DRM_HDCP_REAUTH_REQUEST
> +};
> >>> But this one here is just a part of the intel_hdcp_shim interface. I think
> >>> we should put into the intel_drv.h header, and change the return value of
> >>> the check_2_2_link hook to this enum. I think that would clarify the code
> >>> a lot. Plus then ofc merge this part into the first patch that uses it.
> >> daniel,
> >>
> >> this is generic link check results as per the HDCP spec. This could be used
> >> by any other driver in DRM. Still should i move as local to intel?
> > Yeah I think makes more sense. intel_hdcp_shim could also be used as
> > fairly generic hdcp implementation, but right now it isn't. Better to keep
> > things together that are used together.
>
> thanks. With this i will use your R-b ?
Just to clarify: R-b with the enum moved to intel_drv.h, together with
the intel_hdcp_shim using it. Just realized that my reply is a bit
confusing.
-Daniel
>
> -Ram
>
> > -Daniel
> >
> >> -Ram
> >>
> >>> With that remaining patches have my ack, too.
> >>>
> >>> Cheers, Daniel
> >>>
> /* Shared lengths/masks between HDMI/DVI/DisplayPort */
> #define DRM_HDCP_AN_LEN 8
> --
> 2.7.4
>
--
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 v9 13/39] drm: HDCP2.2 link check related constants
On 12/19/2018 9:28 PM, Daniel Vetter wrote:
On Wed, Dec 19, 2018 at 09:09:00PM +0530, C, Ramalingam wrote:
On 12/19/2018 8:46 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 09:31:15AM +0530, Ramalingam C wrote:
Enums and macros are defined for HDCP2.2 link check.
Signed-off-by: Ramalingam C
---
include/drm/drm_hdcp.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index d8093ecf3ddc..21a128e7020a 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -11,6 +11,14 @@
/* Period of hdcp checks (to ensure we're still authenticated) */
#define DRM_HDCP_CHECK_PERIOD_MS (128 * 16)
+#define DRM_HDCP2_CHECK_PERIOD_MS 500
This one here is good imo, and has my Reviewed-by: Daniel Vetter
+
+enum check_link_response {
+ DRM_HDCP_LINK_PROTECTED = 0,
+ DRM_HDCP_TOPOLOGY_CHANGE,
+ DRM_HDCP_LINK_INTEGRITY_FAILURE,
+ DRM_HDCP_REAUTH_REQUEST
+};
But this one here is just a part of the intel_hdcp_shim interface. I think
we should put into the intel_drv.h header, and change the return value of
the check_2_2_link hook to this enum. I think that would clarify the code
a lot. Plus then ofc merge this part into the first patch that uses it.
daniel,
this is generic link check results as per the HDCP spec. This could be used
by any other driver in DRM. Still should i move as local to intel?
Yeah I think makes more sense. intel_hdcp_shim could also be used as
fairly generic hdcp implementation, but right now it isn't. Better to keep
things together that are used together.
thanks. With this i will use your R-b ?
-Ram
-Daniel
-Ram
With that remaining patches have my ack, too.
Cheers, Daniel
/* Shared lengths/masks between HDMI/DVI/DisplayPort */
#define DRM_HDCP_AN_LEN 8
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/4] drm/i915/perf: handle interrupts from the OA unit
Quoting Lionel Landwerlin (2018-12-19 14:37:46)
> static void free_oa_config(struct drm_i915_private *dev_priv,
> @@ -1852,6 +1854,13 @@ static void gen7_oa_enable(struct i915_perf_stream
> *stream)
> */
> gen7_init_oa_buffer(dev_priv);
>
> + if (stream->oa_interrupt_monitor) {
> + spin_lock(&dev_priv->irq_lock);
Doesn't look like you are already in interrupt context, so spin_lock_irq()
required for dev_priv->irq_lock.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation
== Series Details ==
Series: series starting with [1/9] drm/i915: Remove HW semaphores for gen7
inter-engine synchronisation
URL : https://patchwork.freedesktop.org/series/54285/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5333 -> Patchwork_11128
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11128 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11128, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54285/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11128:
### IGT changes ###
Warnings
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: PASS -> SKIP +2
Known issues
Here are the changes found in Patchwork_11128 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-byt-clapper: PASS -> INCOMPLETE [fdo#102657]
- fi-byt-j1900: PASS -> INCOMPLETE [fdo#102657]
- fi-byt-n2820: PASS -> INCOMPLETE [fdo#102657]
* {igt@runner@aborted}:
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: DMESG-FAIL -> PASS
- fi-kbl-7560u: INCOMPLETE [fdo#108044] -> PASS
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: DMESG-WARN [fdo#105998] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- fi-icl-u2: INCOMPLETE [fdo#108315] -> DMESG-FAIL [fdo#108569]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102657]: https://bugs.freedesktop.org/show_bug.cgi?id=102657
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
Participating hosts (49 -> 45)
--
Additional (2): fi-icl-y fi-pnv-d510
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5333 -> Patchwork_11128
CI_DRM_5333: c758693b615deff56e5e2098379b587486cfff8a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4750: f05c8c2739dce89185349703062784a7745cab14 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11128: 9ee4e74f3eb786a6d2a2de063370a98e85e2765a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9ee4e74f3eb7 drm/i915: Drop unused engine->irq_seqno_barrier w/a
3246358dd150 drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen5
7f98eb1806c5 drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen7
110a4bef6fb3 drm/i915/ringbuffer: Remove irq-seqno w/a for gen6 xcs
2199246f34cd drm/i915/ringbuffer: Remove irq-seqno w/a for gen6/7 rcs
b22db96c7b23 drm/i915: Remove redundant trailing request flush
23f5f5db1a5c drm/i915/ringbuffer: Pull the render flush into breadcrumb emission
9f5924e9ebd6 drm/i915/execlists: Pull the render flush into breadcrumb emission
3578a1217c9a drm/i915: Remove HW semaphores for gen7 inter-engine
synchronisation
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11128/
___
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/perf: add OA interrupt support
== Series Details ==
Series: drm/i915/perf: add OA interrupt support
URL : https://patchwork.freedesktop.org/series/54280/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5333 -> Patchwork_11127
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11127 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11127, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54280/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11127:
### IGT changes ###
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: PASS -> SKIP +33
Known issues
Here are the changes found in Patchwork_11127 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_flip@basic-flip-vs-modeset:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* {igt@runner@aborted}:
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
- fi-apl-guc: DMESG-FAIL -> PASS
- fi-kbl-7560u: INCOMPLETE [fdo#108044] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- fi-icl-u3: DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108315]
- fi-icl-u2: INCOMPLETE [fdo#108315] -> DMESG-FAIL [fdo#108569]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
Participating hosts (49 -> 45)
--
Additional (2): fi-icl-y fi-pnv-d510
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5333 -> Patchwork_11127
CI_DRM_5333: c758693b615deff56e5e2098379b587486cfff8a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4750: f05c8c2739dce89185349703062784a7745cab14 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11127: a117d988841559e920f069e952c66dfee45d0c03 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a117d9888415 drm/i915/perf: add interrupt enabling parameter
fe9e65a1f4ce drm/i915/perf: handle interrupts from the OA unit
f1333882b447 drm/i915/perf: add new open param to configure polling of OA buffer
2834454cd419 drm/i915/perf: rework aging tail workaround
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11127/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 37/39] drm/i915: Fix KBL HDCP2.2 encrypt status signalling
On 12/19/2018 9:10 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 09:31:39AM +0530, Ramalingam C wrote:
Implement the required WA sequence for KBL to fix the
incorrect positioning of the window of oppurtunity and enc_en
signalling.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 42327ed30903..2b9e1b6d0b1e 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
@@ -20,6 +21,27 @@
#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
#define HDCP2_LC_RETRY_CNT3
+static void kbl_repositioning_enc_en_signal(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ struct drm_crtc *crtc = connector->base.state->crtc;
+ struct intel_crtc *intel_crtc = container_of(crtc,
+struct intel_crtc, base);
+ u32 scanline;
+
+ for (;;) {
+ scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
+ if (scanline > 100 && scanline < 200)
+ break;
+ usleep_range(25, 50);
+ }
+
+ hdcp->shim->toggle_signalling(intel_dig_port, false);
+ hdcp->shim->toggle_signalling(intel_dig_port, true);
+}
+
static
bool intel_hdcp_is_ksv_valid(u8 *ksv)
{
@@ -1382,6 +1404,13 @@ static int hdcp2_enable_encryption(struct
intel_connector *connector)
}
if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
+ /*
+* WA: To fix incorrect positioning of the window of
+* opportunity and enc_en signalling in KABYLAKE.
+*/
+ if (IS_KABYLAKE(dev_priv) && hdcp->shim->toggle_signalling)
+ kbl_repositioning_enc_en_signal(connector);
This is a bit a layering violation of the shim. I think it'd be better to
push this into the toggle_signalling implementation, which you call right
above. That can easily check this register too, and retry. That way the
kbl flow is all in one place.
Yes, any way this is a fix for hdcp_signalling for kbl. I will do that.
-Ram
Bspec is down for me, so can't check the w/a itself :-(
-Daniel
+
/* Link is Authenticated. Now set for Encryption */
I915_WRITE(HDCP2_CTL_DDI(port),
I915_READ(HDCP2_CTL_DDI(port)) |
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation
== Series Details == Series: series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation URL : https://patchwork.freedesktop.org/series/54285/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation -O:drivers/gpu/drm/i915/i915_drv.c:349:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:349:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3550:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3547:16: warning: expression using sizeof(void) Commit: drm/i915/execlists: Pull the render flush into breadcrumb emission Okay! Commit: drm/i915/ringbuffer: Pull the render flush into breadcrumb emission Okay! Commit: drm/i915: Remove redundant trailing request flush Okay! Commit: drm/i915/ringbuffer: Remove irq-seqno w/a for gen6/7 rcs Okay! Commit: drm/i915/ringbuffer: Remove irq-seqno w/a for gen6 xcs Okay! Commit: drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen7 Okay! Commit: drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen5 Okay! Commit: drm/i915: Drop unused engine->irq_seqno_barrier w/a Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 13/39] drm: HDCP2.2 link check related constants
On Wed, Dec 19, 2018 at 09:09:00PM +0530, C, Ramalingam wrote:
>
> On 12/19/2018 8:46 PM, Daniel Vetter wrote:
> > On Thu, Dec 13, 2018 at 09:31:15AM +0530, Ramalingam C wrote:
> > > Enums and macros are defined for HDCP2.2 link check.
> > >
> > > Signed-off-by: Ramalingam C
> > > ---
> > > include/drm/drm_hdcp.h | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> > > index d8093ecf3ddc..21a128e7020a 100644
> > > --- a/include/drm/drm_hdcp.h
> > > +++ b/include/drm/drm_hdcp.h
> > > @@ -11,6 +11,14 @@
> > > /* Period of hdcp checks (to ensure we're still authenticated) */
> > > #define DRM_HDCP_CHECK_PERIOD_MS(128 * 16)
> > > +#define DRM_HDCP2_CHECK_PERIOD_MS500
> > This one here is good imo, and has my Reviewed-by: Daniel Vetter
> >
> >
> > > +
> > > +enum check_link_response {
> > > + DRM_HDCP_LINK_PROTECTED = 0,
> > > + DRM_HDCP_TOPOLOGY_CHANGE,
> > > + DRM_HDCP_LINK_INTEGRITY_FAILURE,
> > > + DRM_HDCP_REAUTH_REQUEST
> > > +};
> > But this one here is just a part of the intel_hdcp_shim interface. I think
> > we should put into the intel_drv.h header, and change the return value of
> > the check_2_2_link hook to this enum. I think that would clarify the code
> > a lot. Plus then ofc merge this part into the first patch that uses it.
>
> daniel,
>
> this is generic link check results as per the HDCP spec. This could be used
> by any other driver in DRM. Still should i move as local to intel?
Yeah I think makes more sense. intel_hdcp_shim could also be used as
fairly generic hdcp implementation, but right now it isn't. Better to keep
things together that are used together.
-Daniel
>
> -Ram
>
> >
> > With that remaining patches have my ack, too.
> >
> > Cheers, Daniel
> >
> > > /* Shared lengths/masks between HDMI/DVI/DisplayPort */
> > > #define DRM_HDCP_AN_LEN 8
> > > --
> > > 2.7.4
> > >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation
== Series Details == Series: series starting with [1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation URL : https://patchwork.freedesktop.org/series/54285/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3578a1217c9a drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation 9f5924e9ebd6 drm/i915/execlists: Pull the render flush into breadcrumb emission 23f5f5db1a5c drm/i915/ringbuffer: Pull the render flush into breadcrumb emission -:82: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #82: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:332: +} +static const int gen6_rcs_emit_breadcrumb_sz = 14; -:110: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #110: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:432: +} +static const int gen7_rcs_emit_breadcrumb_sz = 6; -:122: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #122: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:444: +} +static const int gen6_xcs_emit_breadcrumb_sz = 4; total: 0 errors, 0 warnings, 3 checks, 185 lines checked b22db96c7b23 drm/i915: Remove redundant trailing request flush 2199246f34cd drm/i915/ringbuffer: Remove irq-seqno w/a for gen6/7 rcs 110a4bef6fb3 drm/i915/ringbuffer: Remove irq-seqno w/a for gen6 xcs 7f98eb1806c5 drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen7 -:54: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #54: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:471: +} +static const int gen7_xcs_emit_breadcrumb_sz = 8 + GEN7_XCS_WA * 3; total: 0 errors, 0 warnings, 1 checks, 110 lines checked 3246358dd150 drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen5 -:66: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #66: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:905: } +static const int gen5_emit_breadcrumb_sz = GEN5_WA_STORES * 3 + 2; total: 0 errors, 0 warnings, 1 checks, 62 lines checked 9ee4e74f3eb7 drm/i915: Drop unused engine->irq_seqno_barrier w/a ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 09/39] drm/i915: Enable and Disable of HDCP2.2
On Thu, Dec 13, 2018 at 09:31:11AM +0530, Ramalingam C wrote:
> Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
> supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
>
> When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
> enabled.
>
> This change implements a sequence of enabling and disabling of
> HDCP2.2 authentication and HDCP2.2 port encryption.
>
> v2:
> Included few optimization suggestions [Chris Wilson]
> Commit message is updated as per the rebased version.
> intel_wait_for_register is used instead of wait_for. [Chris Wilson]
> v3:
> Extra comment added and Style issue fixed [Uma]
> v4:
> Rebased as part of patch reordering.
> HDCP2 encryption status is tracked.
> HW state check is moved into WARN_ON [Daniel]
> v5:
> Redefined the mei service functions as per comp redesign.
> Merged patches related to hdcp2.2 enabling and disabling [Sean Paul].
> Required shim functionality is defined [Sean Paul]
> v6:
> Return values are handles [Uma]
> Realigned the code.
> Check for comp_master is removed.
> v7:
> HDCP2.2 is attempted only if mei interface is up.
> Adjust to the new interface
> Avoid bool usage in struct [Tomas]
> v8:
> mei_binded status check is removed.
> %s/hdcp2_in_use/hdcp2_encrypted
>
> Signed-off-by: Ramalingam C
lgtm now.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_drv.h | 7 ++
> drivers/gpu/drm/i915/intel_hdcp.c | 202
> +++---
> 2 files changed, 195 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index decd0346c6a7..6d5361616ca3 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -383,6 +383,10 @@ struct intel_hdcp_shim {
>
> /* HDCP adaptation(DP/HDMI) required on the port */
> enum hdcp_wired_protocol protocol;
> +
> + /* Detects whether Panel is HDCP2.2 capable */
> + int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
> + bool *capable);
> };
>
> struct intel_hdcp {
> @@ -400,6 +404,9 @@ struct intel_hdcp {
> /* Flag indicates whether this connector supports HDCP2.2 or not. */
> u8 hdcp2_supported;
>
> + /* HDCP2.2 Encryption status */
> + u8 hdcp2_encrypted;
> +
> /*
>* Content Stream Type defined by content owner. TYPE0(0x0) content can
>* flow in the link protected by HDCP2.2 or HDCP1.4, where as TYPE1(0x1)
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 2b7814a6f12b..f0ee448e6546 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -75,6 +75,23 @@ bool intel_hdcp_capable(struct intel_connector *connector)
> return capable;
> }
>
> +/* Is HDCP2.2 capable on Platform and Sink */
> +static bool intel_hdcp2_capable(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + bool capable = false;
> +
> + /* I915 support for HDCP2.2 */
> + if (!hdcp->hdcp2_supported)
> + return false;
> +
> + /* Sink's capability for HDCP2.2 */
> + hdcp->shim->hdcp_2_2_capable(intel_dig_port, &capable);
> +
> + return capable;
> +}
> +
> static inline bool intel_hdcp_in_use(struct intel_connector *connector)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> @@ -1014,8 +1031,7 @@ int hdcp2_authenticate_port(struct intel_connector
> *connector)
> return ret;
> }
>
> -static __attribute__((unused))
> -int hdcp2_close_mei_session(struct intel_connector *connector)
> +static int hdcp2_close_mei_session(struct intel_connector *connector)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct i915_component_master *comp = dev_priv->comp_master;
> @@ -1024,12 +1040,157 @@ int hdcp2_close_mei_session(struct intel_connector
> *connector)
> &connector->hdcp.port_data);
> }
>
> -static __attribute__((unused))
> -int hdcp2_deauthenticate_port(struct intel_connector *connector)
> +static int hdcp2_deauthenticate_port(struct intel_connector *connector)
> {
> return hdcp2_close_mei_session(connector);
> }
>
> +static int hdcp2_authenticate_sink(struct intel_connector *connector)
> +{
> + DRM_ERROR("Sink authentication is done in subsequent patches\n");
> +
> + return -EINVAL;
> +}
> +
> +static int hdcp2_enable_encryption(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + enum port port = connector->encoder->port;
> + int ret;
> +
> + WARN_ON(I915_REA
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On 12/19/2018 9:05 PM, Daniel Vetter wrote:
On Wed, Dec 19, 2018 at 08:35:48PM +0530, C, Ramalingam wrote:
On 12/19/2018 8:05 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
+ if (!hdcp->is_repeater && shim->config_stream_type) {
+ /*
+* Errata for DP: As Stream type is used for encryption,
+* Receiver should be communicated with stream type for the
+* decryption of the content.
+* Repeater will be communicated with stream type as a
+* part of it's auth later in time.
+*/
I'm not following what you want to say with this comment, and haven't
found anything in the hdcp2 dp spec about this either.
this is there in the errata of DP HDCP2.2 spec.
hdcp2.2 encryption algo involves the stream type as a parameter.
And as part of hdcp auth mentioned in base spec DP repeaters receive that
details to decrypt the content.
But DP receivers dont get it. So errata adds the missing piece for decryption.
Ok I found it, but the fake HDCP_2_2_ERRATA_DP_STREAM_TYPE define is kinda
annoying. It doesn't exist in the spec, but we put it into the drm_hdcp.h
header. Since you have a special ->config_stream_type hook for this
anyway, and it's only needed for DP, please move that into the shim
implementation.
And then a follow-up patch to remove the fake #define from drm_hdcp.h.
This is defined to make the hdcp_shim interface to look common between DP and
HDMI.
We can move this errata msg definition and its msg_id into intel_drv.h just for
the intel's consumption.
-Ram
-Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 08/39] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking
On Thu, Dec 13, 2018 at 09:31:10AM +0530, Ramalingam C wrote:
> "hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
> This SW tracking is used to determine the need for real hdcp1.4 disable
> and hdcp_check_link upon CP_IRQ.
>
> On CP_IRQ we filter the CP_IRQ related to the states like Link failure
> and reauthentication req etc and handle them in hdcp_check_link.
> CP_IRQ corresponding to the authentication msg availability are ignored.
>
> WARN_ON is added for the abrupt stop of HDCP encryption of a port.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 5 ++-
> drivers/gpu/drm/i915/intel_hdcp.c | 89
> ++-
> 3 files changed, 74 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index aba884c64879..89315e15fb34 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4758,7 +4758,7 @@ static void intel_dp_check_service_irq(struct intel_dp
> *intel_dp)
> intel_dp_handle_test_request(intel_dp);
>
> if (val & DP_CP_IRQ)
> - intel_hdcp_check_link(intel_dp->attached_connector);
> + intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
>
> if (val & DP_SINK_SPECIFIC_IRQ)
> DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 191b6e0f086c..decd0346c6a7 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -393,6 +393,9 @@ struct intel_hdcp {
> struct delayed_work check_work;
> struct work_struct prop_work;
>
> + /* HDCP1.4 Encryption status */
> + u8 hdcp_encrypted;
Another bool I guess? Or unsigned : 1;
> +
> /* HDCP2.2 related definitions */
> /* Flag indicates whether this connector supports HDCP2.2 or not. */
> u8 hdcp2_supported;
> @@ -2058,10 +2061,10 @@ int intel_hdcp_init(struct intel_connector *connector,
> bool hdcp2_supported);
> int intel_hdcp_enable(struct intel_connector *connector);
> int intel_hdcp_disable(struct intel_connector *connector);
> -int intel_hdcp_check_link(struct intel_connector *connector);
> bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
> bool intel_hdcp_capable(struct intel_connector *connector);
> bool is_hdcp2_supported(struct drm_i915_private *dev_priv);
> +void intel_hdcp_handle_cp_irq(struct intel_connector *connector);
>
> /* intel_psr.c */
> #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 9405fce07b93..2b7814a6f12b 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -75,6 +75,16 @@ bool intel_hdcp_capable(struct intel_connector *connector)
> return capable;
> }
>
> +static inline bool intel_hdcp_in_use(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + enum port port = connector->encoder->port;
> + u32 reg;
> +
> + reg = I915_READ(PORT_HDCP_STATUS(port));
> + return reg & HDCP_STATUS_ENC;
> +}
> +
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port,
> const struct intel_hdcp_shim *shim)
> {
> @@ -669,6 +679,7 @@ static int _intel_hdcp_disable(struct intel_connector
> *connector)
> DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
> connector->base.name, connector->base.base.id);
>
> + hdcp->hdcp_encrypted = 0;
> I915_WRITE(PORT_HDCP_CONF(port), 0);
> if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
> ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
> @@ -714,8 +725,10 @@ static int _intel_hdcp_enable(struct intel_connector
> *connector)
> /* Incase of authentication failures, HDCP spec expects reauth. */
> for (i = 0; i < tries; i++) {
> ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
> - if (!ret)
> + if (!ret) {
> + hdcp->hdcp_encrypted = 1;
> return 0;
> + }
>
> DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
>
> @@ -742,16 +755,17 @@ int intel_hdcp_check_link(struct intel_connector
> *connector)
> enum port port = intel_dig_port->base.port;
> int ret = 0;
>
> - if (!hdcp->shim)
> - return -ENOENT;
> -
> mutex_lock(&hdcp->mutex);
>
> - if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> + /* Check_link valid only when HDCP1.4 is enabled */
> + if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED ||
> + !hdcp->hdcp_encrypted) {
Re: [Intel-gfx] [PATCH v9 37/39] drm/i915: Fix KBL HDCP2.2 encrypt status signalling
On Thu, Dec 13, 2018 at 09:31:39AM +0530, Ramalingam C wrote:
> Implement the required WA sequence for KBL to fix the
> incorrect positioning of the window of oppurtunity and enc_en
> signalling.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 42327ed30903..2b9e1b6d0b1e 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #include "intel_drv.h"
> #include "i915_reg.h"
> @@ -20,6 +21,27 @@
> #define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
> #define HDCP2_LC_RETRY_CNT 3
>
> +static void kbl_repositioning_enc_en_signal(struct intel_connector
> *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + struct drm_crtc *crtc = connector->base.state->crtc;
> + struct intel_crtc *intel_crtc = container_of(crtc,
> + struct intel_crtc, base);
> + u32 scanline;
> +
> + for (;;) {
> + scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
> + if (scanline > 100 && scanline < 200)
> + break;
> + usleep_range(25, 50);
> + }
> +
> + hdcp->shim->toggle_signalling(intel_dig_port, false);
> + hdcp->shim->toggle_signalling(intel_dig_port, true);
> +}
> +
> static
> bool intel_hdcp_is_ksv_valid(u8 *ksv)
> {
> @@ -1382,6 +1404,13 @@ static int hdcp2_enable_encryption(struct
> intel_connector *connector)
> }
>
> if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
> + /*
> + * WA: To fix incorrect positioning of the window of
> + * opportunity and enc_en signalling in KABYLAKE.
> + */
> + if (IS_KABYLAKE(dev_priv) && hdcp->shim->toggle_signalling)
> + kbl_repositioning_enc_en_signal(connector);
This is a bit a layering violation of the shim. I think it'd be better to
push this into the toggle_signalling implementation, which you call right
above. That can easily check this register too, and retry. That way the
kbl flow is all in one place.
Bspec is down for me, so can't check the w/a itself :-(
-Daniel
> +
> /* Link is Authenticated. Now set for Encryption */
> I915_WRITE(HDCP2_CTL_DDI(port),
> I915_READ(HDCP2_CTL_DDI(port)) |
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
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 v9 13/39] drm: HDCP2.2 link check related constants
On 12/19/2018 8:46 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 09:31:15AM +0530, Ramalingam C wrote:
Enums and macros are defined for HDCP2.2 link check.
Signed-off-by: Ramalingam C
---
include/drm/drm_hdcp.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index d8093ecf3ddc..21a128e7020a 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -11,6 +11,14 @@
/* Period of hdcp checks (to ensure we're still authenticated) */
#define DRM_HDCP_CHECK_PERIOD_MS (128 * 16)
+#define DRM_HDCP2_CHECK_PERIOD_MS 500
This one here is good imo, and has my Reviewed-by: Daniel Vetter
+
+enum check_link_response {
+ DRM_HDCP_LINK_PROTECTED = 0,
+ DRM_HDCP_TOPOLOGY_CHANGE,
+ DRM_HDCP_LINK_INTEGRITY_FAILURE,
+ DRM_HDCP_REAUTH_REQUEST
+};
But this one here is just a part of the intel_hdcp_shim interface. I think
we should put into the intel_drv.h header, and change the return value of
the check_2_2_link hook to this enum. I think that would clarify the code
a lot. Plus then ofc merge this part into the first patch that uses it.
daniel,
this is generic link check results as per the HDCP spec. This could be
used by any other driver in DRM. Still should i move as local to intel?
-Ram
With that remaining patches have my ack, too.
Cheers, Daniel
/* Shared lengths/masks between HDMI/DVI/DisplayPort */
#define DRM_HDCP_AN_LEN 8
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 12/39] drm/i915: Implement HDCP2.2 repeater authentication
On 12/19/2018 8:18 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 09:31:14AM +0530, Ramalingam C wrote:
Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.
v2: Rebased.
v3:
-EINVAL is returned for topology error and rollover scenario.
Endianness conversion func from drm_hdcp.h is used [Uma]
v4:
Rebased as part of patches reordering.
Defined the mei service functions [Daniel]
v5:
Redefined the mei service functions as per comp redesign.
v6:
%s/uintxx_t/uxx
Check for comp_master is removed.
v7:
Adjust to the new mei interface.
style issue fixed.
v8:
drm_hdcp.h change is moved into separate patch [Daniel]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 123 +-
1 file changed, 121 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index f1f0ef294e20..b52da5c3159d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -978,7 +978,7 @@ static int hdcp2_prepare_skey(struct intel_connector
*connector,
return ret;
}
-static __attribute__((unused)) int
+static int
hdcp2_verify_rep_topology_prepare_ack(struct intel_connector *connector,
struct hdcp2_rep_send_receiverid_list
*rep_topology,
@@ -999,7 +999,7 @@ hdcp2_verify_rep_topology_prepare_ack(struct
intel_connector *connector,
return ret;
}
-static __attribute__((unused)) int
+static int
hdcp2_verify_mprime(struct intel_connector *connector,
struct hdcp2_rep_stream_ready *stream_ready)
{
@@ -1182,6 +1182,119 @@ static int hdcp2_session_key_exchange(struct
intel_connector *connector)
return 0;
}
+static
+int hdcp2_propagate_stream_management_info(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ union {
+ struct hdcp2_rep_stream_manage stream_manage;
+ struct hdcp2_rep_stream_ready stream_ready;
+ } msgs;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
+ int ret;
+
+ /* Prepare RepeaterAuth_Stream_Manage msg */
+ msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
+ drm_hdcp2_u32_to_seq_num(msgs.stream_manage.seq_num_m, hdcp->seq_num_m);
+
+ /* K no of streams is fixed as 1. Stored as big-endian. */
+ msgs.stream_manage.k = __swab16(1);
+
+ /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
+ msgs.stream_manage.streams[0].stream_id = 0;
+ msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
+
+ /* Send it to Repeater */
+ ret = shim->write_2_2_msg(intel_dig_port, &msgs.stream_manage,
+ sizeof(msgs.stream_manage));
+ if (ret < 0)
+ return ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_STREAM_READY,
+&msgs.stream_ready, sizeof(msgs.stream_ready));
+ if (ret < 0)
+ return ret;
+
+ hdcp->port_data.seq_num_m = hdcp->seq_num_m;
+ hdcp->port_data.streams[0].stream_type = hdcp->content_type;
+
+ ret = hdcp2_verify_mprime(connector, &msgs.stream_ready);
+ if (ret < 0)
+ return ret;
+
+ hdcp->seq_num_m++;
+
+ if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
+ DRM_DEBUG_KMS("seq_num_m roll over.\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+static
+int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ union {
+ struct hdcp2_rep_send_receiverid_list recvid_list;
+ struct hdcp2_rep_send_ack rep_ack;
+ } msgs;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
+ u8 *rx_info;
+ u32 seq_num_v;
+ int ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_SEND_RECVID_LIST,
+&msgs.recvid_list, sizeof(msgs.recvid_list));
+ if (ret < 0)
+ return ret;
+
+ rx_info = msgs.recvid_list.rx_info;
There's a 2s timeout here that we're not checking, but again probably
follow-up patch.
Timeout is taken care at shim.
+
+ if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
+ HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
+ DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
+ return -EINVAL;
+ }
+
+ /* Converting and Storing the seq_num_v to local variable as DWORD */
+ drm_hdcp2_seq_num_to_u32(&seq_num_v, msgs.recvid_list.seq_num_v);
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On Wed, Dec 19, 2018 at 08:35:48PM +0530, C, Ramalingam wrote:
> On 12/19/2018 8:05 PM, Daniel Vetter wrote:
> > On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
> > > + if (!hdcp->is_repeater && shim->config_stream_type) {
> > > + /*
> > > + * Errata for DP: As Stream type is used for encryption,
> > > + * Receiver should be communicated with stream type for the
> > > + * decryption of the content.
> > > + * Repeater will be communicated with stream type as a
> > > + * part of it's auth later in time.
> > > + */
> > I'm not following what you want to say with this comment, and haven't
> > found anything in the hdcp2 dp spec about this either.
>
> this is there in the errata of DP HDCP2.2 spec.
> hdcp2.2 encryption algo involves the stream type as a parameter.
> And as part of hdcp auth mentioned in base spec DP repeaters receive that
> details to decrypt the content.
> But DP receivers dont get it. So errata adds the missing piece for decryption.
Ok I found it, but the fake HDCP_2_2_ERRATA_DP_STREAM_TYPE define is kinda
annoying. It doesn't exist in the spec, but we put it into the drm_hdcp.h
header. Since you have a special ->config_stream_type hook for this
anyway, and it's only needed for DP, please move that into the shim
implementation.
And then a follow-up patch to remove the fake #define from drm_hdcp.h.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
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/perf: add OA interrupt support
== Series Details == Series: drm/i915/perf: add OA interrupt support URL : https://patchwork.freedesktop.org/series/54280/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/perf: rework aging tail workaround Okay! Commit: drm/i915/perf: add new open param to configure polling of OA buffer -drivers/gpu/drm/i915/selftests/../i915_drv.h:3550:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3556:16: warning: expression using sizeof(void) Commit: drm/i915/perf: handle interrupts from the OA unit -drivers/gpu/drm/i915/selftests/../i915_drv.h:3556:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3577:16: warning: expression using sizeof(void) Commit: drm/i915/perf: add interrupt enabling parameter +drivers/gpu/drm/i915/i915_perf.c:552:9: warning: context imbalance in 'oa_buffer_check' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: add OA interrupt support
== Series Details ==
Series: drm/i915/perf: add OA interrupt support
URL : https://patchwork.freedesktop.org/series/54280/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2834454cd419 drm/i915/perf: rework aging tail workaround
-:197: CHECK:SPACING: No space is necessary after a cast
#197: FILE: drivers/gpu/drm/i915/i915_perf.c:510:
+ u32 *report32 = (void *) report;
-:273: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#273: FILE: drivers/gpu/drm/i915/i915_perf.c:811:
+ report32[0] = report32[1] = 0;
-:308: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#308: FILE: drivers/gpu/drm/i915/i915_perf.c:1020:
+ report32[0] = report32[1] = 0;
total: 0 errors, 0 warnings, 3 checks, 302 lines checked
f1333882b447 drm/i915/perf: add new open param to configure polling of OA buffer
fe9e65a1f4ce drm/i915/perf: handle interrupts from the OA unit
-:28: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible
alignment issues - see: https://lkml.org/lkml/2017/11/21/384
#28: FILE: drivers/gpu/drm/i915/i915_drv.h:1362:
+ bool oa_interrupt_monitor;
total: 0 errors, 0 warnings, 1 checks, 250 lines checked
a117d9888415 drm/i915/perf: add interrupt enabling parameter
-:7: WARNING:TYPO_SPELLING: 'conjuction' may be misspelled - perhaps
'conjunction'?
#7:
mechanism of the HW. In conjuction with long periods for checks for
-:30: CHECK:LINE_SPACING: Please don't use multiple blank lines
#30: FILE: drivers/gpu/drm/i915/i915_perf.c:431:
+
-:80: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'dev_priv->perf.oa.half_full_count_last !=
atomic64_read(&dev_priv->perf.oa.half_full_count)'
#80: FILE: drivers/gpu/drm/i915/i915_perf.c:685:
+ if (stream->oa_interrupt_monitor &&
+ (dev_priv->perf.oa.half_full_count_last !=
+atomic64_read(&dev_priv->perf.oa.half_full_count))) {
-:97: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'dev_priv->perf.oa.half_full_count_last !=
atomic64_read(&dev_priv->perf.oa.half_full_count)'
#97: FILE: drivers/gpu/drm/i915/i915_perf.c:978:
+ if (stream->oa_interrupt_monitor &&
+ (dev_priv->perf.oa.half_full_count_last !=
+atomic64_read(&dev_priv->perf.oa.half_full_count))) {
-:143: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'dev_priv->perf.oa.half_full_count_last !=
atomic64_read(&dev_priv->perf.oa.half_full_count)'
#143: FILE: drivers/gpu/drm/i915/i915_perf.c:2370:
+ if (stream->oa_interrupt_monitor &&
+ (dev_priv->perf.oa.half_full_count_last !=
+atomic64_read(&dev_priv->perf.oa.half_full_count))) {
-:172: WARNING:TYPO_SPELLING: 'conjuction' may be misspelled - perhaps
'conjunction'?
#172: FILE: include/uapi/drm/i915_drm.h:1552:
+* buffer in i915. This option in conjuction with a long polling delay
total: 0 errors, 2 warnings, 4 checks, 147 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v3 1/3] PM/runtime: Add a new interface to get accounted time
On Wed, 19 Dec 2018 at 10:58, Ulf Hansson wrote:
>
> On Tue, 18 Dec 2018 at 15:55, Vincent Guittot
> wrote:
> >
> > Some drivers (like i915/drm) need to get the accounted suspended time.
> > pm_runtime_accounted_time_get() will return the suspended or active
> > accounted time until now.
>
> I suggest to leave the active accounted time out for now. At least
> until we have some users.
>
> That said, perhaps rename the function to something along the lines
> of, pm_runtime_last_suspended_time(), to make it more clear.
>
> >
> > Signed-off-by: Vincent Guittot
> > ---
> > drivers/base/power/runtime.c | 26 ++
> > include/linux/pm_runtime.h | 2 ++
> > 2 files changed, 28 insertions(+)
> >
> > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > index 7062469..6461469 100644
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -88,6 +88,32 @@ static void __update_runtime_status(struct device *dev,
> > enum rpm_status status)
> > dev->power.runtime_status = status;
> > }
> >
> > +u64 pm_runtime_accounted_time_get(struct device *dev, enum rpm_status
> > status, bool update)
> > +{
> > + u64 now = ktime_to_ns(ktime_get());
>
> I think you should stay on jiffies here - and then switch to ktime in patch 3.
I forgot to reply to this comment
Yes I agree that I should stay in jiffies there
>
> > + u64 delta = 0, time = 0;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&dev->power.lock, flags);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] sysfs: Disable lockdep for driver bind/unbind files
On Wed, Dec 19, 2018 at 03:21:56PM +0100, Rafael J. Wysocki wrote:
> On Wed, Dec 19, 2018 at 1:39 PM Daniel Vetter wrote:
> >
> > This is the much more correct fix for my earlier attempt at:
> >
> > https://lkml.org/lkml/2018/12/10/118
> >
> > Short recap:
> >
> > - There's not actually a locking issue, it's just lockdep being a bit
> > too eager to complain about a possible deadlock.
> >
> > - Contrary to what I claimed the real problem is recursion on
> > kn->count. Greg pointed me at sysfs_break_active_protection(), used
> > by the scsi subsystem to allow a sysfs file to unbind itself. That
> > would be a real deadlock, which isn't what's happening here. Also,
> > breaking the active protection means we'd need to manually handle
> > all the lifetime fun.
> >
> > - With Rafael we discussed the task_work approach, which kinda works,
> > but has two downsides: It's a functional change for a lockdep
> > annotation issue, and it won't work for the bind file (which needs
> > to get the errno from the driver load function back to userspace).
> >
> > - Greg also asked why this never showed up: To hit this you need to
> > unregister a 2nd driver from the unload code of your first driver. I
> > guess only gpus do that. The bug has always been there, but only
> > with a recent patch series did we add more locks so that lockdep
> > built a chain from unbinding the snd-hda driver to the
> > acpi_video_unregister call.
> >
> > Full lockdep splat:
> >
> > [12301.898799]
> > [12301.898805] WARNING: possible recursive locking detected
> > [12301.898811] 4.20.0-rc7+ #84 Not tainted
> > [12301.898815]
> > [12301.898821] bash/5297 is trying to acquire lock:
> > [12301.898826] f61c6093 (kn->count#39){}, at:
> > kernfs_remove_by_name_ns+0x3b/0x80
> > [12301.898841] but task is already holding lock:
> > [12301.898847] 5f634021 (kn->count#39){}, at:
> > kernfs_fop_write+0xdc/0x190
> > [12301.898856] other info that might help us debug this:
> > [12301.898862] Possible unsafe locking scenario:
> > [12301.898867]CPU0
> > [12301.898870]
> > [12301.898874] lock(kn->count#39);
> > [12301.898879] lock(kn->count#39);
> > [12301.898883] *** DEADLOCK ***
> > [12301.898891] May be due to missing lock nesting notation
> > [12301.898899] 5 locks held by bash/5297:
> > [12301.898903] #0: cd800e54 (sb_writers#4){.+.+}, at:
> > vfs_write+0x17f/0x1b0
> > [12301.898915] #1: 0465e7c2 (&of->mutex){+.+.}, at:
> > kernfs_fop_write+0xd3/0x190
> > [12301.898925] #2: 5f634021 (kn->count#39){}, at:
> > kernfs_fop_write+0xdc/0x190
> > [12301.898936] #3: 414ef7ac (&dev->mutex){}, at:
> > device_release_driver_internal+0x34/0x240
> > [12301.898950] #4: 3218fbdf (register_count_mutex){+.+.}, at:
> > acpi_video_unregister+0xe/0x40
> > [12301.898960] stack backtrace:
> > [12301.898968] CPU: 1 PID: 5297 Comm: bash Not tainted 4.20.0-rc7+ #84
> > [12301.898974] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS
> > 68SCF Ver. F.01 03/11/2011
> > [12301.898982] Call Trace:
> > [12301.898989] dump_stack+0x67/0x9b
> > [12301.898997] __lock_acquire+0x6ad/0x1410
> > [12301.899003] ? kernfs_remove_by_name_ns+0x3b/0x80
> > [12301.899010] ? find_held_lock+0x2d/0x90
> > [12301.899017] ? mutex_spin_on_owner+0xe4/0x150
> > [12301.899023] ? find_held_lock+0x2d/0x90
> > [12301.899030] ? lock_acquire+0x90/0x180
> > [12301.899036] lock_acquire+0x90/0x180
> > [12301.899042] ? kernfs_remove_by_name_ns+0x3b/0x80
> > [12301.899049] __kernfs_remove+0x296/0x310
> > [12301.899055] ? kernfs_remove_by_name_ns+0x3b/0x80
> > [12301.899060] ? kernfs_name_hash+0xd/0x80
> > [12301.899066] ? kernfs_find_ns+0x6c/0x100
> > [12301.899073] kernfs_remove_by_name_ns+0x3b/0x80
> > [12301.899080] bus_remove_driver+0x92/0xa0
> > [12301.899085] acpi_video_unregister+0x24/0x40
> > [12301.899127] i915_driver_unload+0x42/0x130 [i915]
> > [12301.899160] i915_pci_remove+0x19/0x30 [i915]
> > [12301.899169] pci_device_remove+0x36/0xb0
> > [12301.899176] device_release_driver_internal+0x185/0x240
> > [12301.899183] unbind_store+0xaf/0x180
> > [12301.899189] kernfs_fop_write+0x104/0x190
> > [12301.899195] __vfs_write+0x31/0x180
> > [12301.899203] ? rcu_read_lock_sched_held+0x6f/0x80
> > [12301.899209] ? rcu_sync_lockdep_assert+0x29/0x50
> > [12301.899216] ? __sb_start_write+0x13c/0x1a0
> > [12301.899221] ? vfs_write+0x17f/0x1b0
> > [12301.899227] vfs_write+0xb9/0x1b0
> > [12301.899233] ksys_write+0x50/0xc0
> > [12301.899239] do_syscall_64+0x4b/0x180
> > [12301.899247] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > [12301.899253] RIP: 0033:0x7f452ac7f7a4
> > [12301.899259] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80
> > 00 00 00 00 8b 05 aa f0 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05
> > <48> 3d 00 f0 ff ff 77 54 f3 c3
Re: [Intel-gfx] [PATCH v9 07/39] drm/i915: MEI interface definition
On Wed, Dec 19, 2018 at 08:45:41PM +0530, C, Ramalingam wrote:
>
> On 12/19/2018 7:30 PM, Daniel Vetter wrote:
> > On Thu, Dec 13, 2018 at 09:31:09AM +0530, Ramalingam C wrote:
> > > Defining the mei-i915 interface functions and initialization of
> > > the interface.
> > >
> > > v2:
> > >Adjust to the new interface changes. [Tomas]
> > >Added further debug logs for the failures at MEI i/f.
> > >port in hdcp_port data is equipped to handle -ve values.
> > > v3:
> > >mei comp is matched for global i915 comp master. [Daniel]
> > >In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
> > >mei wrappers are adjusted as per the i/f change [Daniel]
> > Yeah looks all good. Spotted some small stuff below still.
> >
> > > Signed-off-by: Ramalingam C
> > > ---
> > > drivers/gpu/drm/i915/intel_drv.h | 5 +
> > > drivers/gpu/drm/i915/intel_hdcp.c | 248
> > > +-
> > > include/drm/i915_component.h | 7 ++
> > > 3 files changed, 259 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index dd9371647a8c..191b6e0f086c 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -39,6 +39,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > /**
> > > @@ -379,6 +380,9 @@ struct intel_hdcp_shim {
> > > /* Detects panel's hdcp capability. This is optional for HDMI.
> > > */
> > > int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
> > > bool *hdcp_capable);
> > > +
> > > + /* HDCP adaptation(DP/HDMI) required on the port */
> > > + enum hdcp_wired_protocol protocol;
> > > };
> > > struct intel_hdcp {
> > > @@ -399,6 +403,7 @@ struct intel_hdcp {
> > >* content can flow only through a link protected by HDCP2.2.
> > >*/
> > > u8 content_type;
> > > + struct hdcp_port_data port_data;
> > > };
> > > struct intel_connector {
> > > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> > > b/drivers/gpu/drm/i915/intel_hdcp.c
> > > index 584d27f3c699..9405fce07b93 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > > @@ -8,8 +8,10 @@
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > +#include
> > > #include "intel_drv.h"
> > > #include "i915_reg.h"
> > > @@ -833,6 +835,232 @@ bool is_hdcp_supported(struct drm_i915_private
> > > *dev_priv, enum port port)
> > > return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
> > > }
> > > +static __attribute__((unused)) int
> > > +hdcp2_prepare_ake_init(struct intel_connector *connector,
> > > +struct hdcp2_ake_init *ake_data)
> > > +{
> > > + struct hdcp_port_data *data = &connector->hdcp.port_data;
> > > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > > + struct i915_component_master *comp = dev_priv->comp_master;
> > > + int ret;
> > > +
> > > + /* During the connector init encoder might not be initialized */
> > > + if (data->port == PORT_NONE)
> > > + data->port = connector->encoder->port;
> > > +
> > > + ret = comp->hdcp_ops->initiate_hdcp2_session(comp->mei_dev,
> > > + data, ake_data);
> > > + if (ret)
> > > + DRM_DEBUG_KMS("Prepare_ake_init failed. %d\n", ret);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static __attribute__((unused)) int
> > > +hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
> > > + struct hdcp2_ake_send_cert *rx_cert,
> > > + bool *paired,
> > > + struct hdcp2_ake_no_stored_km *ek_pub_km,
> > > + size_t *msg_sz)
> > > +{
> > > + struct hdcp_port_data *data = &connector->hdcp.port_data;
> > > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > > + struct i915_component_master *comp = dev_priv->comp_master;
> > > + int ret;
> > > +
> > > + ret = comp->hdcp_ops->verify_receiver_cert_prepare_km(comp->mei_dev,
> > > + data, rx_cert,
> > > + paired, ek_pub_km,
> > > + msg_sz);
> > > + if (ret < 0)
> > > + DRM_DEBUG_KMS("Verify rx_cert failed. %d\n", ret);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static __attribute__((unused)) int
> > > +hdcp2_verify_hprime(struct intel_connector *connector,
> > > + struct hdcp2_ake_send_hprime *rx_hprime)
> > > +{
> > > + struct hdcp_port_data *data = &connector->hdcp.port_data;
> > > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > > + struct i915_component_master *comp = dev_priv->comp_master;
> > > + int ret;
>
Re: [Intel-gfx] [PATCH v9 13/39] drm: HDCP2.2 link check related constants
On Thu, Dec 13, 2018 at 09:31:15AM +0530, Ramalingam C wrote:
> Enums and macros are defined for HDCP2.2 link check.
>
> Signed-off-by: Ramalingam C
> ---
> include/drm/drm_hdcp.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index d8093ecf3ddc..21a128e7020a 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -11,6 +11,14 @@
>
> /* Period of hdcp checks (to ensure we're still authenticated) */
> #define DRM_HDCP_CHECK_PERIOD_MS (128 * 16)
> +#define DRM_HDCP2_CHECK_PERIOD_MS500
This one here is good imo, and has my Reviewed-by: Daniel Vetter
> +
> +enum check_link_response {
> + DRM_HDCP_LINK_PROTECTED = 0,
> + DRM_HDCP_TOPOLOGY_CHANGE,
> + DRM_HDCP_LINK_INTEGRITY_FAILURE,
> + DRM_HDCP_REAUTH_REQUEST
> +};
But this one here is just a part of the intel_hdcp_shim interface. I think
we should put into the intel_drv.h header, and change the return value of
the check_2_2_link hook to this enum. I think that would clarify the code
a lot. Plus then ofc merge this part into the first patch that uses it.
With that remaining patches have my ack, too.
Cheers, Daniel
>
> /* Shared lengths/masks between HDMI/DVI/DisplayPort */
> #define DRM_HDCP_AN_LEN 8
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
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 v9 07/39] drm/i915: MEI interface definition
On 12/19/2018 7:30 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 09:31:09AM +0530, Ramalingam C wrote:
Defining the mei-i915 interface functions and initialization of
the interface.
v2:
Adjust to the new interface changes. [Tomas]
Added further debug logs for the failures at MEI i/f.
port in hdcp_port data is equipped to handle -ve values.
v3:
mei comp is matched for global i915 comp master. [Daniel]
In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
mei wrappers are adjusted as per the i/f change [Daniel]
Yeah looks all good. Spotted some small stuff below still.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drv.h | 5 +
drivers/gpu/drm/i915/intel_hdcp.c | 248 +-
include/drm/i915_component.h | 7 ++
3 files changed, 259 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dd9371647a8c..191b6e0f086c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
/**
@@ -379,6 +380,9 @@ struct intel_hdcp_shim {
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
bool *hdcp_capable);
+
+ /* HDCP adaptation(DP/HDMI) required on the port */
+ enum hdcp_wired_protocol protocol;
};
struct intel_hdcp {
@@ -399,6 +403,7 @@ struct intel_hdcp {
* content can flow only through a link protected by HDCP2.2.
*/
u8 content_type;
+ struct hdcp_port_data port_data;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 584d27f3c699..9405fce07b93 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -8,8 +8,10 @@
#include
#include
+#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
@@ -833,6 +835,232 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
}
+static __attribute__((unused)) int
+hdcp2_prepare_ake_init(struct intel_connector *connector,
+ struct hdcp2_ake_init *ake_data)
+{
+ struct hdcp_port_data *data = &connector->hdcp.port_data;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_component_master *comp = dev_priv->comp_master;
+ int ret;
+
+ /* During the connector init encoder might not be initialized */
+ if (data->port == PORT_NONE)
+ data->port = connector->encoder->port;
+
+ ret = comp->hdcp_ops->initiate_hdcp2_session(comp->mei_dev,
+data, ake_data);
+ if (ret)
+ DRM_DEBUG_KMS("Prepare_ake_init failed. %d\n", ret);
+
+ return ret;
+}
+
+static __attribute__((unused)) int
+hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
+ struct hdcp2_ake_send_cert *rx_cert,
+ bool *paired,
+ struct hdcp2_ake_no_stored_km *ek_pub_km,
+ size_t *msg_sz)
+{
+ struct hdcp_port_data *data = &connector->hdcp.port_data;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_component_master *comp = dev_priv->comp_master;
+ int ret;
+
+ ret = comp->hdcp_ops->verify_receiver_cert_prepare_km(comp->mei_dev,
+ data, rx_cert,
+ paired, ek_pub_km,
+ msg_sz);
+ if (ret < 0)
+ DRM_DEBUG_KMS("Verify rx_cert failed. %d\n", ret);
+
+ return ret;
+}
+
+static __attribute__((unused)) int
+hdcp2_verify_hprime(struct intel_connector *connector,
+ struct hdcp2_ake_send_hprime *rx_hprime)
+{
+ struct hdcp_port_data *data = &connector->hdcp.port_data;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_component_master *comp = dev_priv->comp_master;
+ int ret;
+
+ ret = comp->hdcp_ops->verify_hprime(comp->mei_dev, data, rx_hprime);
+ if (ret < 0)
+ DRM_DEBUG_KMS("Verify hprime failed. %d\n", ret);
+
+ return ret;
+}
+
+static __attribute__((unused)) int
+hdcp2_store_pairing_info(struct intel_connector *connector,
+struct hdcp2_ake_send_pairing_info *pairing_info)
+{
+ struct hdcp_port_data *data = &connector->hdcp.port_data;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_component_master *comp = de
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Prepare for larger CSB status FIFO size (rev4)
== Series Details ==
Series: series starting with [1/3] drm/i915: Prepare for larger CSB status FIFO
size (rev4)
URL : https://patchwork.freedesktop.org/series/54213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5333 -> Patchwork_11126
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54213/revisions/4/mbox/
Known issues
Here are the changes found in Patchwork_11126 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965]
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: PASS -> DMESG-WARN [fdo#102614]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* {igt@runner@aborted}:
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
- fi-apl-guc: DMESG-FAIL -> PASS
- fi-kbl-7560u: INCOMPLETE [fdo#108044] -> PASS
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: DMESG-WARN [fdo#105998] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- fi-icl-u2: INCOMPLETE [fdo#108315] -> DMESG-FAIL [fdo#108569]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
Participating hosts (49 -> 45)
--
Additional (2): fi-icl-y fi-pnv-d510
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5333 -> Patchwork_11126
CI_DRM_5333: c758693b615deff56e5e2098379b587486cfff8a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4750: f05c8c2739dce89185349703062784a7745cab14 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11126: e050519e52a564a46744301e737f0040ba144ee2 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e050519e52a5 drm/i915/icl: Introduce gen11 flush/invalidate
7cbdc840c1d8 drm/i915/icl: Switch to using 12 deep CSB status FIFO
7854930e939b drm/i915: Prepare for larger CSB status FIFO size
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11126/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On 12/19/2018 8:05 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
Implements HDCP2.2 authentication for hdcp2.2 receivers, with
following steps:
Authentication and Key exchange (AKE).
Locality Check (LC).
Session Key Exchange(SKE).
DP Errata for stream type configuration for receivers.
At AKE, the HDCP Receiver’s public key certificate is verified by the
HDCP Transmitter. A Master Key k m is exchanged.
At LC, the HDCP Transmitter enforces locality on the content by
requiring that the Round Trip Time (RTT) between a pair of messages
is not more than 20 ms.
At SKE, The HDCP Transmitter exchanges Session Key ks with
the HDCP Receiver.
In DP HDCP2.2 encryption and decryption logics use the stream type as
one of the parameter. So Before enabling the Encryption DP HDCP2.2
receiver needs to be communicated with stream type. This is added to
spec as ERRATA.
This generic implementation is complete only with the hdcp2 specific
functions defined at hdcp_shim.
v2: Rebased.
v3:
%s/PARING/PAIRING
Coding style fixing [Uma]
v4:
Rebased as part of patch reordering.
Defined the functions for mei services. [Daniel]
v5:
Redefined the mei service functions as per comp redesign.
Required intel_hdcp members are defined [Sean Paul]
v6:
Typo of cipher is Fixed [Uma]
%s/uintxx_t/uxx
Check for comp_master is removed.
v7:
Adjust to the new interface.
Avoid using bool structure members. [Tomas]
v8: Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drv.h | 34 ++
drivers/gpu/drm/i915/intel_hdcp.c | 211 +++---
2 files changed, 230 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6d5361616ca3..a6b632d71490 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -387,6 +387,22 @@ struct intel_hdcp_shim {
/* Detects whether Panel is HDCP2.2 capable */
int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
bool *capable);
+
+ /* Write HDCP2.2 messages */
+ int (*write_2_2_msg)(struct intel_digital_port *intel_dig_port,
+void *buf, size_t size);
+
+ /* Read HDCP2.2 messages */
+ int (*read_2_2_msg)(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, void *buf, size_t size);
+
+ /*
+* Implementation of DP HDCP2.2 Errata for the communication of stream
+* type to Receivers. In DP HDCP2.2 Stream type is one of the input to
+* the HDCP2.2 Cipher for En/De-Cryption. Not applicable for HDMI.
+*/
+ int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
+ void *buf, size_t size);
};
struct intel_hdcp {
@@ -414,6 +430,24 @@ struct intel_hdcp {
*/
u8 content_type;
struct hdcp_port_data port_data;
+
+ u8 is_paired;
+ u8 is_repeater;
Make these two bool, will simplify the code a bunch.
Seems there is a movement for not to use the bool in structures.
Thats why I have changed these from bool to u8 from v8 onwards. Checkpatch also
complains on this
+
+ /*
+* Count of ReceiverID_List received. Initialized to 0 at AKE_INIT.
+* Incremented after processing the RepeaterAuth_Send_ReceiverID_List.
+* When it rolls over re-auth has to be triggered.
+*/
+ u32 seq_num_v;
+
+ /*
+* Count of RepeaterAuth_Stream_Manage msg propagated.
+* Initialized to 0 on AKE_INIT. Incremented after every successful
+* transmission of RepeaterAuth_Stream_Manage message. When it rolls
+* over re-Auth has to be triggered.
+*/
+ u32 seq_num_m;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index f0ee448e6546..f1f0ef294e20 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -18,6 +18,7 @@
#define KEY_LOAD_TRIES 5
#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
+#define HDCP2_LC_RETRY_CNT 3
static
bool intel_hdcp_is_ksv_valid(u8 *ksv)
@@ -854,7 +855,7 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
}
-static __attribute__((unused)) int
+static int
hdcp2_prepare_ake_init(struct intel_connector *connector,
struct hdcp2_ake_init *ake_data)
{
@@ -875,7 +876,7 @@ hdcp2_prepare_ake_init(struct intel_connector *connector,
return ret;
}
-static __attribute__((unused)) int
+static int
hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
struct hdcp2_ake_send_cert *rx_cert,
bool *paired,
@@ -8
Re: [Intel-gfx] [PATCH v9 04/39] component: alloc component_match without any comp to match
On Wed, Dec 19, 2018 at 02:42:45PM +0100, Daniel Vetter wrote: > On Thu, Dec 13, 2018 at 09:31:06AM +0530, Ramalingam C wrote: > > If all the components associated to a component master is not added > > to the component framework due to the HW capability or Kconfig > > selection, component_match will be NULL at > > component_master_add_with_match(). > > > > To avoid this, component_match_alloc() is added to the framework, > > to allcoate the struct component_match with zero associated components. > > Hence component master can be added with a component_match with zero > > associated components. > > > > This helps the component master bind call to get triggered, > > even if no component is registered for that particular master. > > > > This is meant for big PCI device drivers where small/optional > > features are external components, and based on usecases different > > combination of components are build as entire driver. > > > > In such PCI device driver Load, if we use the component master for > > waiting for few components(features) availability, only if they are > > supported by the underlying HW, then we need to allocate memory for > > component_match using the API introduced in this change before > > the call to component_master_add_with_match. > > > > v2: > > No Change. > > > > Signed-off-by: Ramalingam C > > Suggested-by: Daniel Vetter > > Cc: Greg Kroah-Hartman > > Cc: Kate Stewart > > Cc: Thomas Gleixner > > Cc: Philippe Ombredanne > > Cc: linux-ker...@vger.kernel.org > > Reviewed-by: Daniel Vetter > > Greg, I expect the i915 feature that needs this will only land in 4.22. > I'm also not aware of anyone else using this (all the other component > users always use components). How do you want to get this landed? > > I think either getting this into 4.21, or an ack for merging through drm > trees would work well for us. I have no objection to you taking this through the drm tree. As I really do not know the component code at all (that would be Russell King), feel free to add my: Acked-by: Greg Kroah-Hartman as it looks sane to me. thanks, greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] sysfs: Disable lockdep for driver bind/unbind files
On Wed, Dec 19, 2018 at 02:26:22PM +0100, Daniel Vetter wrote:
> On Wed, Dec 19, 2018 at 02:18:25PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 19, 2018 at 01:49:30PM +0100, Greg Kroah-Hartman wrote:
> > > On Wed, Dec 19, 2018 at 01:39:09PM +0100, Daniel Vetter wrote:
> > > > --- a/include/linux/device.h
> > > > +++ b/include/linux/device.h
> > > > @@ -327,6 +327,7 @@ struct driver_attribute {
> > > > #define DRIVER_ATTR_WO(_name) \
> > > > struct driver_attribute driver_attr_##_name = __ATTR_WO(_name)
> > > >
> > > > +
> > > > extern int __must_check driver_create_file(struct device_driver
> > > > *driver,
> > > > const struct driver_attribute
> > > > *attr);
> > > > extern void driver_remove_file(struct device_driver *driver,
> > > > --
> > >
> > > I'll edit away this last chunk when I apply the patch :)
> >
> > Oops sry. I also forgot to do the s/Locking/Looking/ in the commit message
> > :-/
>
> And I also forgot Rafael's r-b :-(
Ok, rebuilt with both of these things now fixed up, thanks.
greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen5
The irq_seqno_barrier is a tradeoff between doing work on every request
(on the GPU) and doing work after every interrupt (on the CPU). We
presume we have many more requests than interrupts! However, for
Ironlake, the workaround is a pretty hideous usleep() and so even though
it was found we need to repeat the MI_STORE_DWORD_IMM 8 times, doing so
is preferrable than requiring a usleep!
The additional MI_STORE_DWORD_IMM also have the side-effect of flushing
MI operations from userspace which are not caught by MI_FLUSH!
Testcase: igt/gem_sync
Testcase: igt/gem_exec_whisper
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 40 ++---
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 40797ee6a956..323e1e2c1e5e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -881,26 +881,29 @@ static void i9xx_emit_breadcrumb(struct i915_request *rq,
u32 *cs)
rq->tail = intel_ring_offset(rq, cs);
assert_ring_tail_valid(rq->ring, rq->tail);
}
-
static const int i9xx_emit_breadcrumb_sz = 6;
-static void
-gen5_seqno_barrier(struct intel_engine_cs *engine)
+#define GEN5_WA_STORES 8 /* must be at least 1! */
+static void gen5_emit_breadcrumb(struct i915_request *rq, u32 *cs)
{
- /* MI_STORE are internally buffered by the GPU and not flushed
-* either by MI_FLUSH or SyncFlush or any other combination of
-* MI commands.
-*
-* "Only the submission of the store operation is guaranteed.
-* The write result will be complete (coherent) some time later
-* (this is practically a finite period but there is no guaranteed
-* latency)."
-*
-* Empirically, we observe that we need a delay of at least 75us to
-* be sure that the seqno write is visible by the CPU.
-*/
- usleep_range(125, 250);
+ int i;
+
+ *cs++ = MI_FLUSH;
+
+ BUILD_BUG_ON(GEN5_WA_STORES < 1);
+ for (i = 0; i < GEN5_WA_STORES; i++) {
+ *cs++ = MI_STORE_DWORD_INDEX;
+ *cs++ = I915_GEM_HWS_INDEX << MI_STORE_DWORD_INDEX_SHIFT;
+ *cs++ = rq->global_seqno;
+ }
+
+ *cs++ = MI_USER_INTERRUPT;
+
+ rq->tail = intel_ring_offset(rq, cs);
+ assert_ring_tail_valid(rq->ring, rq->tail);
}
+static const int gen5_emit_breadcrumb_sz = GEN5_WA_STORES * 3 + 2;
+#undef GEN5_WA_STORES
static void
gen5_irq_enable(struct intel_engine_cs *engine)
@@ -2108,7 +2111,6 @@ static void intel_ring_init_irq(struct drm_i915_private
*dev_priv,
} else if (INTEL_GEN(dev_priv) >= 5) {
engine->irq_enable = gen5_irq_enable;
engine->irq_disable = gen5_irq_disable;
- engine->irq_seqno_barrier = gen5_seqno_barrier;
} else if (INTEL_GEN(dev_priv) >= 3) {
engine->irq_enable = i9xx_irq_enable;
engine->irq_disable = i9xx_irq_disable;
@@ -2151,6 +2153,10 @@ static void intel_ring_default_vfuncs(struct
drm_i915_private *dev_priv,
engine->emit_breadcrumb = i9xx_emit_breadcrumb;
engine->emit_breadcrumb_sz = i9xx_emit_breadcrumb_sz;
+ if (IS_GEN(dev_priv, 5)) {
+ engine->emit_breadcrumb = gen5_emit_breadcrumb;
+ engine->emit_breadcrumb_sz = gen5_emit_breadcrumb_sz;
+ }
engine->set_default_submission = i9xx_set_default_submission;
--
2.20.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9] drm/i915/ringbuffer: Remove irq-seqno w/a for gen6/7 rcs
Having transitioned to using PIPECONTROL to combine the flush with the
breadcrumb write using their post-sync functions, assume that this will
resolve the serialisation with the subsequent MI_USER_INTERRUPT. That is
when inspecting the breadcrumb after an interrupt we can rely on the write
being posted (i.e. the HWSP will be coherent).
Testing using gem_sync shows that the PIPECONTROL + CS stall does
serialise the command streamer sufficient that the breadcrumb lands
before the MI_USER_INTERRUPT. The same is not true for MI_FLUSH_DW.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 939ba872bff6..668e77b476c7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2178,13 +2178,11 @@ int intel_init_render_ring_buffer(struct
intel_engine_cs *engine)
engine->emit_flush = gen7_render_ring_flush;
engine->emit_breadcrumb = gen7_rcs_emit_breadcrumb;
engine->emit_breadcrumb_sz = gen7_rcs_emit_breadcrumb_sz;
- engine->irq_seqno_barrier = gen6_seqno_barrier;
} else if (IS_GEN(dev_priv, 6)) {
engine->init_context = intel_rcs_ctx_init;
engine->emit_flush = gen6_render_ring_flush;
engine->emit_breadcrumb = gen6_rcs_emit_breadcrumb;
engine->emit_breadcrumb_sz = gen6_rcs_emit_breadcrumb_sz;
- engine->irq_seqno_barrier = gen6_seqno_barrier;
} else if (IS_GEN(dev_priv, 5)) {
engine->emit_flush = gen4_render_ring_flush;
} else {
--
2.20.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/9] drm/i915/ringbuffer: Remove irq-seqno w/a for gen6 xcs
The MI_FLUSH_DW does appear coherent with the following
MI_USER_INTERRUPT, but only on Sandybridge. Ivybridge requires a heavier
hammer, but on Sandybridge we can stop requiring the irq_seqno barrier.
Testcase: igt/gem_sync
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 668e77b476c7..2b8932ab007f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2220,7 +2220,8 @@ int intel_init_bsd_ring_buffer(struct intel_engine_cs
*engine)
engine->emit_breadcrumb = gen6_xcs_emit_breadcrumb;
engine->emit_breadcrumb_sz = gen6_xcs_emit_breadcrumb_sz;
- engine->irq_seqno_barrier = gen6_seqno_barrier;
+ if (!IS_GEN(dev_priv, 6))
+ engine->irq_seqno_barrier = gen6_seqno_barrier;
} else {
engine->emit_flush = bsd_ring_flush;
if (IS_GEN(dev_priv, 5))
@@ -2245,7 +2246,8 @@ int intel_init_blt_ring_buffer(struct intel_engine_cs
*engine)
engine->emit_breadcrumb = gen6_xcs_emit_breadcrumb;
engine->emit_breadcrumb_sz = gen6_xcs_emit_breadcrumb_sz;
- engine->irq_seqno_barrier = gen6_seqno_barrier;
+ if (!IS_GEN(dev_priv, 6))
+ engine->irq_seqno_barrier = gen6_seqno_barrier;
return intel_init_ring_buffer(engine);
}
--
2.20.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 9/9] drm/i915: Drop unused engine->irq_seqno_barrier w/a
Now that we have eliminated the CPU-side irq_seqno_barrier by moving the
delays on the GPU before emitting the MI_USER_INTERRUPT, we can remove
the engine->irq_seqno_barrier infrastructure. Though intentionally
slowing down the GPU is nasty, so is the code we can now remove!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 84
drivers/gpu/drm/i915/i915_gem.c | 7 --
drivers/gpu/drm/i915/i915_irq.c | 7 --
drivers/gpu/drm/i915/i915_request.c | 8 +--
drivers/gpu/drm/i915/intel_breadcrumbs.c | 26
drivers/gpu/drm/i915/intel_engine_cs.c | 6 --
drivers/gpu/drm/i915/intel_hangcheck.c | 10 ---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 --
drivers/gpu/drm/i915/intel_ringbuffer.h | 10 ---
9 files changed, 1 insertion(+), 161 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7da653ece4dd..2ce731d987f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3584,90 +3584,6 @@ wait_remaining_ms_from_jiffies(unsigned long
timestamp_jiffies, int to_wait_ms)
}
}
-static inline bool
-__i915_request_irq_complete(const struct i915_request *rq)
-{
- struct intel_engine_cs *engine = rq->engine;
- u32 seqno;
-
- /* Note that the engine may have wrapped around the seqno, and
-* so our request->global_seqno will be ahead of the hardware,
-* even though it completed the request before wrapping. We catch
-* this by kicking all the waiters before resetting the seqno
-* in hardware, and also signal the fence.
-*/
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &rq->fence.flags))
- return true;
-
- /* The request was dequeued before we were awoken. We check after
-* inspecting the hw to confirm that this was the same request
-* that generated the HWS update. The memory barriers within
-* the request execution are sufficient to ensure that a check
-* after reading the value from hw matches this request.
-*/
- seqno = i915_request_global_seqno(rq);
- if (!seqno)
- return false;
-
- /* Before we do the heavier coherent read of the seqno,
-* check the value (hopefully) in the CPU cacheline.
-*/
- if (__i915_request_completed(rq, seqno))
- return true;
-
- /* Ensure our read of the seqno is coherent so that we
-* do not "miss an interrupt" (i.e. if this is the last
-* request and the seqno write from the GPU is not visible
-* by the time the interrupt fires, we will see that the
-* request is incomplete and go back to sleep awaiting
-* another interrupt that will never come.)
-*
-* Strictly, we only need to do this once after an interrupt,
-* but it is easier and safer to do it every time the waiter
-* is woken.
-*/
- if (engine->irq_seqno_barrier &&
- test_and_clear_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted)) {
- struct intel_breadcrumbs *b = &engine->breadcrumbs;
-
- /* The ordering of irq_posted versus applying the barrier
-* is crucial. The clearing of the current irq_posted must
-* be visible before we perform the barrier operation,
-* such that if a subsequent interrupt arrives, irq_posted
-* is reasserted and our task rewoken (which causes us to
-* do another __i915_request_irq_complete() immediately
-* and reapply the barrier). Conversely, if the clear
-* occurs after the barrier, then an interrupt that arrived
-* whilst we waited on the barrier would not trigger a
-* barrier on the next pass, and the read may not see the
-* seqno update.
-*/
- engine->irq_seqno_barrier(engine);
-
- /* If we consume the irq, but we are no longer the bottom-half,
-* the real bottom-half may not have serialised their own
-* seqno check with the irq-barrier (i.e. may have inspected
-* the seqno before we believe it coherent since they see
-* irq_posted == false but we are still running).
-*/
- spin_lock_irq(&b->irq_lock);
- if (b->irq_wait && b->irq_wait->tsk != current)
- /* Note that if the bottom-half is changed as we
-* are sending the wake-up, the new bottom-half will
-* be woken by whomever made the change. We only have
-* to worry about when we steal the irq-posted for
-* ourself.
-*/
- wake_up_process(b->irq_wait->tsk);
- spin_unlock_irq(&b->irq_lock);
-
[Intel-gfx] [PATCH 7/9] drm/i915/ringbuffer: Move irq seqno barrier to the GPU for gen7
The irq_seqno_barrier is a tradeoff between doing work on every request
(on the GPU) and doing work after every interrupt (on the CPU). We
presume we have many more requests than interrupts! However, the current
w/a for Ivybridge is an implicit delay that currently fails sporadically
and consistently if we move the w/a into the irq handler itself. This
makes the CPU barrier untenable for upcoming interrupt handler changes
and so we need to replace it with a delay on the GPU before we send the
MI_USER_INTERRUPT. As it turns out that delay is 32x MI_STORE_DWORD_IMM,
or about 0.6us per request! Quite nasty, but the lesser of two evils
looking to the future.
Testcase: igt/gem_sync
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 80 ++---
1 file changed, 44 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2b8932ab007f..40797ee6a956 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -443,6 +443,34 @@ static void gen6_xcs_emit_breadcrumb(struct i915_request
*rq, u32 *cs)
}
static const int gen6_xcs_emit_breadcrumb_sz = 4;
+#define GEN7_XCS_WA 32
+static void gen7_xcs_emit_breadcrumb(struct i915_request *rq, u32 *cs)
+{
+ int i;
+
+ *cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW;
+ *cs++ = intel_hws_seqno_address(rq->engine) | MI_FLUSH_DW_USE_GTT;
+ *cs++ = rq->global_seqno;
+
+ for (i = 0; i < GEN7_XCS_WA; i++) {
+ *cs++ = MI_STORE_DWORD_INDEX;
+ *cs++ = I915_GEM_HWS_INDEX << MI_STORE_DWORD_INDEX_SHIFT;
+ *cs++ = rq->global_seqno;
+ }
+
+ *cs++ = MI_FLUSH_DW;
+ *cs++ = 0;
+ *cs++ = 0;
+
+ *cs++ = MI_USER_INTERRUPT;
+ *cs++ = MI_NOOP;
+
+ rq->tail = intel_ring_offset(rq, cs);
+ assert_ring_tail_valid(rq->ring, rq->tail);
+}
+static const int gen7_xcs_emit_breadcrumb_sz = 8 + GEN7_XCS_WA * 3;
+#undef GEN7_XCS_WA
+
static void set_hwstam(struct intel_engine_cs *engine, u32 mask)
{
/*
@@ -874,31 +902,6 @@ gen5_seqno_barrier(struct intel_engine_cs *engine)
usleep_range(125, 250);
}
-static void
-gen6_seqno_barrier(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
-
- /* Workaround to force correct ordering between irq and seqno writes on
-* ivb (and maybe also on snb) by reading from a CS register (like
-* ACTHD) before reading the status page.
-*
-* Note that this effectively stalls the read by the time it takes to
-* do a memory transaction, which more or less ensures that the write
-* from the GPU has sufficient time to invalidate the CPU cacheline.
-* Alternatively we could delay the interrupt from the CS ring to give
-* the write time to land, but that would incur a delay after every
-* batch i.e. much more frequent than a delay when waiting for the
-* interrupt (with the same net latency).
-*
-* Also note that to prevent whole machine hangs on gen7, we have to
-* take the spinlock to guard against concurrent cacheline access.
-*/
- spin_lock_irq(&dev_priv->uncore.lock);
- POSTING_READ_FW(RING_ACTHD(engine->mmio_base));
- spin_unlock_irq(&dev_priv->uncore.lock);
-}
-
static void
gen5_irq_enable(struct intel_engine_cs *engine)
{
@@ -2218,10 +2221,13 @@ int intel_init_bsd_ring_buffer(struct intel_engine_cs
*engine)
engine->emit_flush = gen6_bsd_ring_flush;
engine->irq_enable_mask = GT_BSD_USER_INTERRUPT;
- engine->emit_breadcrumb = gen6_xcs_emit_breadcrumb;
- engine->emit_breadcrumb_sz = gen6_xcs_emit_breadcrumb_sz;
- if (!IS_GEN(dev_priv, 6))
- engine->irq_seqno_barrier = gen6_seqno_barrier;
+ if (IS_GEN(dev_priv, 6)) {
+ engine->emit_breadcrumb = gen6_xcs_emit_breadcrumb;
+ engine->emit_breadcrumb_sz =
gen6_xcs_emit_breadcrumb_sz;
+ } else {
+ engine->emit_breadcrumb = gen7_xcs_emit_breadcrumb;
+ engine->emit_breadcrumb_sz =
gen7_xcs_emit_breadcrumb_sz;
+ }
} else {
engine->emit_flush = bsd_ring_flush;
if (IS_GEN(dev_priv, 5))
@@ -2244,10 +2250,13 @@ int intel_init_blt_ring_buffer(struct intel_engine_cs
*engine)
engine->emit_flush = gen6_ring_flush;
engine->irq_enable_mask = GT_BLT_USER_INTERRUPT;
- engine->emit_breadcrumb = gen6_xcs_emit_breadcrumb;
- engine->emit_breadcrumb_sz = gen6_xcs_emit_breadcrumb_sz;
- if (!IS_GEN(dev_priv, 6))
- engine->irq_seqno_barrier = gen6_seqno_barrier;
+ if (IS_GEN(dev_priv, 6)) {
+ engine->emit_breadcrumb = gen6_xcs_emit_breadcrumb;
+
[Intel-gfx] [PATCH 3/9] drm/i915/ringbuffer: Pull the render flush into breadcrumb emission
In preparation for removing the manual EMIT_FLUSH prior to emitting the
breadcrumb implement the flush inline with writing the breadcrumb for
ringbuffer emission.
With a combined flush+breadcrumb, we can use a single operation to both
flush and after the flush is complete (post-sync) write the breadcrumb.
This gives us a strongly ordered operation that should be sufficient to
serialise the write before we emit the interrupt; and therefore we may
take the opportunity to remove the irq_seqno_barrier w/a for gen6+.
Although using the PIPECONTROL to write the breadcrumb is slower than
MI_STORE_DWORD_IMM, by combining the operations into one and removing the
extra flush (next patch) it is faster
For gen2-5, we simply combine the MI_FLUSH into the breadcrumb emission,
though maybe we could find a solution here to the seqno-vs-interrupt
issue on Ironlake by mixing up the flush? The answer is no, adding an
MI_FLUSH before the interrupt is insufficient.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 104 ++--
1 file changed, 97 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index d5a9edbcf1be..169c54995ca9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -217,7 +217,7 @@ gen4_render_ring_flush(struct i915_request *rq, u32 mode)
* really our business. That leaves only stall at scoreboard.
*/
static int
-intel_emit_post_sync_nonzero_flush(struct i915_request *rq)
+gen6_emit_post_sync_nonzero_flush(struct i915_request *rq)
{
u32 scratch_addr = i915_scratch_offset(rq->i915) + 2 * CACHELINE_BYTES;
u32 *cs;
@@ -257,7 +257,7 @@ gen6_render_ring_flush(struct i915_request *rq, u32 mode)
int ret;
/* Force SNB workarounds for PIPE_CONTROL flushes */
- ret = intel_emit_post_sync_nonzero_flush(rq);
+ ret = gen6_emit_post_sync_nonzero_flush(rq);
if (ret)
return ret;
@@ -300,6 +300,37 @@ gen6_render_ring_flush(struct i915_request *rq, u32 mode)
return 0;
}
+static void gen6_rcs_emit_breadcrumb(struct i915_request *rq, u32 *cs)
+{
+ /* First we do the gen6_emit_post_sync_nonzero_flush w/a */
+ *cs++ = GFX_OP_PIPE_CONTROL(4);
+ *cs++ = PIPE_CONTROL_CS_STALL | PIPE_CONTROL_STALL_AT_SCOREBOARD;
+ *cs++ = 0;
+ *cs++ = 0;
+
+ *cs++ = GFX_OP_PIPE_CONTROL(4);
+ *cs++ = PIPE_CONTROL_QW_WRITE;
+ *cs++ = i915_scratch_offset(rq->i915) | PIPE_CONTROL_GLOBAL_GTT;
+ *cs++ = 0;
+
+ /* Finally we can flush and with it emit the breadcrumb */
+ *cs++ = GFX_OP_PIPE_CONTROL(4);
+ *cs++ = (PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+PIPE_CONTROL_DC_FLUSH_ENABLE |
+PIPE_CONTROL_QW_WRITE |
+PIPE_CONTROL_CS_STALL);
+ *cs++ = intel_hws_seqno_address(rq->engine) | PIPE_CONTROL_GLOBAL_GTT;
+ *cs++ = rq->global_seqno;
+
+ *cs++ = MI_USER_INTERRUPT;
+ *cs++ = MI_NOOP;
+
+ rq->tail = intel_ring_offset(rq, cs);
+ assert_ring_tail_valid(rq->ring, rq->tail);
+}
+static const int gen6_rcs_emit_breadcrumb_sz = 14;
+
static int
gen7_render_ring_cs_stall_wa(struct i915_request *rq)
{
@@ -379,6 +410,39 @@ gen7_render_ring_flush(struct i915_request *rq, u32 mode)
return 0;
}
+static void gen7_rcs_emit_breadcrumb(struct i915_request *rq, u32 *cs)
+{
+ *cs++ = GFX_OP_PIPE_CONTROL(4);
+ *cs++ = (PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+PIPE_CONTROL_DC_FLUSH_ENABLE |
+PIPE_CONTROL_FLUSH_ENABLE |
+PIPE_CONTROL_QW_WRITE |
+PIPE_CONTROL_GLOBAL_GTT_IVB |
+PIPE_CONTROL_CS_STALL);
+ *cs++ = intel_hws_seqno_address(rq->engine);
+ *cs++ = rq->global_seqno;
+
+ *cs++ = MI_USER_INTERRUPT;
+ *cs++ = MI_NOOP;
+
+ rq->tail = intel_ring_offset(rq, cs);
+ assert_ring_tail_valid(rq->ring, rq->tail);
+}
+static const int gen7_rcs_emit_breadcrumb_sz = 6;
+
+static void gen6_xcs_emit_breadcrumb(struct i915_request *rq, u32 *cs)
+{
+ *cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW;
+ *cs++ = intel_hws_seqno_address(rq->engine) | MI_FLUSH_DW_USE_GTT;
+ *cs++ = rq->global_seqno;
+ *cs++ = MI_USER_INTERRUPT;
+
+ rq->tail = intel_ring_offset(rq, cs);
+ assert_ring_tail_valid(rq->ring, rq->tail);
+}
+static const int gen6_xcs_emit_breadcrumb_sz = 4;
+
static void set_hwstam(struct intel_engine_cs *engine, u32 mask)
{
/*
@@ -777,16 +841,20 @@ static void i9xx_submit_request(struct i915_request
*request)
static void i9xx_emit_breadcrumb(struct i915_request *rq, u32 *cs)
{
+ *cs++ = MI_FLUSH;
+
*cs++ = MI_STORE_DWORD_INDEX;
*cs++ = I915_GEM_HWS_INDEX << MI_STORE_DWORD_INDE
[Intel-gfx] [PATCH 4/9] drm/i915: Remove redundant trailing request flush
Now that we perform the request flushing inline with emitting the
breadcrumb, we can remove the now redundant manual flush. And we can
also remove the infrastructure that remained only for its purpose.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 13 ++---
drivers/gpu/drm/i915/intel_ringbuffer.c | 16
drivers/gpu/drm/i915/intel_ringbuffer.h | 10 --
drivers/gpu/drm/i915/selftests/mock_engine.c | 2 --
4 files changed, 6 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 6cedcfea33b5..8f8e844f2e85 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -521,10 +521,6 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
reserve_gt(i915);
- ret = intel_ring_wait_for_space(ce->ring, MIN_SPACE_FOR_ADD_REQUEST);
- if (ret)
- goto err_unreserve;
-
/* Move our oldest request to the slab-cache (if not in use!) */
rq = list_first_entry(&ce->ring->request_list, typeof(*rq), ring_link);
if (!list_is_last(&rq->ring_link, &ce->ring->request_list) &&
@@ -616,9 +612,13 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
* i915_request_add() call can't fail. Note that the reserve may need
* to be redone if the request is not actually submitted straight
* away, e.g. because a GPU scheduler has deferred it.
+*
+* Note that due to how we add reserved_space to intel_ring_begin()
+* we need to double our request to ensure that if we need to wrap
+* around inside i915_request_add() there is sufficient space at
+* the beginning of the ring as well.
*/
- rq->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
- GEM_BUG_ON(rq->reserved_space < engine->emit_breadcrumb_sz);
+ rq->reserved_space = 2 * engine->emit_breadcrumb_sz;
/*
* Record the position of the start of the request so that
@@ -861,7 +861,6 @@ void i915_request_add(struct i915_request *request)
* know that it is time to use that space up.
*/
request->reserved_space = 0;
- engine->emit_flush(request, EMIT_FLUSH);
/*
* Record the position of the start of the breadcrumb so that
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 169c54995ca9..939ba872bff6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1864,22 +1864,6 @@ static noinline int wait_for_space(struct intel_ring
*ring, unsigned int bytes)
return 0;
}
-int intel_ring_wait_for_space(struct intel_ring *ring, unsigned int bytes)
-{
- GEM_BUG_ON(bytes > ring->effective_size);
- if (unlikely(bytes > ring->effective_size - ring->emit))
- bytes += ring->size - ring->emit;
-
- if (unlikely(bytes > ring->space)) {
- int ret = wait_for_space(ring, bytes);
- if (unlikely(ret))
- return ret;
- }
-
- GEM_BUG_ON(ring->space < bytes);
- return 0;
-}
-
u32 *intel_ring_begin(struct i915_request *rq, unsigned int num_dwords)
{
struct intel_ring *ring = rq->ring;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 32606d795af3..99e2cb75d29a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -754,7 +754,6 @@ void intel_legacy_submission_resume(struct drm_i915_private
*dev_priv);
int __must_check intel_ring_cacheline_align(struct i915_request *rq);
-int intel_ring_wait_for_space(struct intel_ring *ring, unsigned int bytes);
u32 __must_check *intel_ring_begin(struct i915_request *rq, unsigned int n);
static inline void intel_ring_advance(struct i915_request *rq, u32 *cs)
@@ -895,15 +894,6 @@ static inline bool intel_engine_has_started(struct
intel_engine_cs *engine,
void intel_engine_get_instdone(struct intel_engine_cs *engine,
struct intel_instdone *instdone);
-/*
- * Arbitrary size for largest possible 'add request' sequence. The code paths
- * are complex and variable. Empirical measurement shows that the worst case
- * is BDW at 192 bytes (6 + 6 + 36 dwords), then ILK at 136 bytes. However,
- * we need to allocate double the largest single packet within that emission
- * to account for tail wraparound (so 6 + 6 + 72 dwords for BDW).
- */
-#define MIN_SPACE_FOR_ADD_REQUEST 336
-
static inline u32 intel_hws_seqno_address(struct intel_engine_cs *engine)
{
return engine->status_page.ggtt_offset + I915_GEM_HWS_INDEX_ADDR;
diff --git a/drivers/gpu/drm/i915/selftests/mock_engine.c
b/drivers/gpu/drm/i915/selftests/mock_engine.c
index d0c44c18db42..50e1a0b1af7e 100644
--- a/drivers/gpu/drm/i915/
[Intel-gfx] [PATCH 2/9] drm/i915/execlists: Pull the render flush into breadcrumb emission
In preparation for removing the manual EMIT_FLUSH prior to emitting the
breadcrumb implement the flush inline with writing the breadcrumb for
execlists. Using one command to both flush and write the breadcrumb is
naturally a tiny bit faster than splitting it into two.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submission.c | 3 ++-
drivers/gpu/drm/i915/intel_lrc.c| 12 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 5 ++---
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 1570dcbe249c..ab1c49b106f2 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -572,7 +572,8 @@ static void inject_preempt_context(struct work_struct *work)
if (engine->id == RCS) {
cs = gen8_emit_ggtt_write_rcs(cs,
GUC_PREEMPT_FINISHED,
- addr);
+ addr,
+ PIPE_CONTROL_CS_STALL);
} else {
cs = gen8_emit_ggtt_write(cs,
GUC_PREEMPT_FINISHED,
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b05d0561f99a..ff08e5d600d4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2061,10 +2061,18 @@ static void gen8_emit_breadcrumb_rcs(struct
i915_request *request, u32 *cs)
/* We're using qword write, seqno should be aligned to 8 bytes. */
BUILD_BUG_ON(I915_GEM_HWS_INDEX & 1);
- cs = gen8_emit_ggtt_write_rcs(cs, request->global_seqno,
- intel_hws_seqno_address(request->engine));
+ cs = gen8_emit_ggtt_write_rcs(cs,
+ request->global_seqno,
+ intel_hws_seqno_address(request->engine),
+ PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+ PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+ PIPE_CONTROL_DC_FLUSH_ENABLE |
+ PIPE_CONTROL_FLUSH_ENABLE |
+ PIPE_CONTROL_CS_STALL);
+
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index c927bdfb1ed0..32606d795af3 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -1003,7 +1003,7 @@ static inline u32 *gen8_emit_pipe_control(u32 *batch, u32
flags, u32 offset)
}
static inline u32 *
-gen8_emit_ggtt_write_rcs(u32 *cs, u32 value, u32 gtt_offset)
+gen8_emit_ggtt_write_rcs(u32 *cs, u32 value, u32 gtt_offset, u32 flags)
{
/* We're using qword write, offset should be aligned to 8 bytes. */
GEM_BUG_ON(!IS_ALIGNED(gtt_offset, 8));
@@ -1013,8 +1013,7 @@ gen8_emit_ggtt_write_rcs(u32 *cs, u32 value, u32
gtt_offset)
* following the batch.
*/
*cs++ = GFX_OP_PIPE_CONTROL(6);
- *cs++ = PIPE_CONTROL_GLOBAL_GTT_IVB | PIPE_CONTROL_CS_STALL |
- PIPE_CONTROL_QW_WRITE;
+ *cs++ = flags | PIPE_CONTROL_QW_WRITE | PIPE_CONTROL_GLOBAL_GTT_IVB;
*cs++ = gtt_offset;
*cs++ = 0;
*cs++ = value;
--
2.20.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/9] drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation
The writing is on the wall for the existence of a single execution queue
along each engine, and as a consequence we will not be able to track
dependencies along the HW queue itself, i.e. we will not be able to use
HW semaphores on gen7 as they use a global set of registers (and unlike
gen8+ we can not effectively target memory to keep per-context seqno and
dependencies).
On the positive side, when we implement request reordering for gen7 we
could also not presume a simple execution queue and would also require
removing the current semaphore generation code. So this bring us another
step closer to request reordering!
The negative side is that using interrupts to drive inter-engine
synchronisation is much slower (4us -> 15us to do a nop on each of the 3
engines on ivb). This is much better than it at the time of introducing
the HW semaphores and equally importantly userspace weaned itself of
intermixing dependent BLT/RENDER operations (the prime culprit was glyph
rendering in UXA). So while we regress the microbenchmarks it should not
impact the user.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 +--
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 -
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_request.c | 126 +---
drivers/gpu/drm/i915/i915_timeline.h| 8 -
drivers/gpu/drm/i915/intel_engine_cs.c | 29 +---
drivers/gpu/drm/i915/intel_hangcheck.c | 155
drivers/gpu/drm/i915/intel_ringbuffer.c | 187 +---
drivers/gpu/drm/i915/intel_ringbuffer.h | 56 +--
10 files changed, 15 insertions(+), 574 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 77486a614614..b0bdf3c0d776 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1041,21 +1041,7 @@ static const struct file_operations
i915_error_state_fops = {
static int
i915_next_seqno_set(void *data, u64 val)
{
- struct drm_i915_private *dev_priv = data;
- struct drm_device *dev = &dev_priv->drm;
- int ret;
-
- ret = mutex_lock_interruptible(&dev->struct_mutex);
- if (ret)
- return ret;
-
- intel_runtime_pm_get(dev_priv);
- ret = i915_gem_set_global_seqno(dev, val);
- intel_runtime_pm_put(dev_priv);
-
- mutex_unlock(&dev->struct_mutex);
-
- return ret;
+ return val ? 0 : -EINVAL;
}
DEFINE_SIMPLE_ATTRIBUTE(i915_next_seqno_fops,
@@ -4219,9 +4205,6 @@ i915_drop_caches_set(void *data, u64 val)
I915_WAIT_LOCKED,
MAX_SCHEDULE_TIMEOUT);
- if (ret == 0 && val & DROP_RESET_SEQNO)
- ret = i915_gem_set_global_seqno(&i915->drm, 1);
-
if (val & DROP_RETIRE)
i915_retire_requests(i915);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index caa055ac9472..dcb935338c63 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -349,7 +349,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
value = min_t(int, INTEL_PPGTT(dev_priv), I915_GEM_PPGTT_FULL);
break;
case I915_PARAM_HAS_SEMAPHORES:
- value = HAS_LEGACY_SEMAPHORES(dev_priv);
+ value = 0;
break;
case I915_PARAM_HAS_SECURE_BATCHES:
value = capable(CAP_SYS_ADMIN);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 815db160b966..7da653ece4dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1948,7 +1948,6 @@ struct drm_i915_private {
struct list_head active_rings;
struct list_head closed_vma;
u32 active_requests;
- u32 request_serial;
/**
* Is the GPU currently considered idle, or busy executing
@@ -2394,8 +2393,6 @@ intel_info(const struct drm_i915_private *dev_priv)
#define HAS_BLT(dev_priv) HAS_ENGINE(dev_priv, BCS)
#define HAS_VEBOX(dev_priv)HAS_ENGINE(dev_priv, VECS)
-#define HAS_LEGACY_SEMAPHORES(dev_priv) IS_GEN(dev_priv, 7)
-
#define HAS_LLC(dev_priv) ((dev_priv)->info.has_llc)
#define HAS_SNOOP(dev_priv)((dev_priv)->info.has_snoop)
#define HAS_EDRAM(dev_priv)(!!((dev_priv)->edram_cap & EDRAM_ENABLED))
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d92147ab4489..f4254e012620 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3318,7 +3318,7 @@ static void nop_submit_request(struct i915_request
*request)
spin_lock_irqsave(&request->engine->timeline.lock, flags);
__i915_request_submit(request);
- intel
Re: [Intel-gfx] [PATCH v9 12/39] drm/i915: Implement HDCP2.2 repeater authentication
On Thu, Dec 13, 2018 at 09:31:14AM +0530, Ramalingam C wrote:
> Implements the HDCP2.2 repeaters authentication steps such as verifying
> the downstream topology and sending stream management information.
>
> v2: Rebased.
> v3:
> -EINVAL is returned for topology error and rollover scenario.
> Endianness conversion func from drm_hdcp.h is used [Uma]
> v4:
> Rebased as part of patches reordering.
> Defined the mei service functions [Daniel]
> v5:
> Redefined the mei service functions as per comp redesign.
> v6:
> %s/uintxx_t/uxx
> Check for comp_master is removed.
> v7:
> Adjust to the new mei interface.
> style issue fixed.
> v8:
> drm_hdcp.h change is moved into separate patch [Daniel]
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 123
> +-
> 1 file changed, 121 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index f1f0ef294e20..b52da5c3159d 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -978,7 +978,7 @@ static int hdcp2_prepare_skey(struct intel_connector
> *connector,
> return ret;
> }
>
> -static __attribute__((unused)) int
> +static int
> hdcp2_verify_rep_topology_prepare_ack(struct intel_connector *connector,
> struct hdcp2_rep_send_receiverid_list
> *rep_topology,
> @@ -999,7 +999,7 @@ hdcp2_verify_rep_topology_prepare_ack(struct
> intel_connector *connector,
> return ret;
> }
>
> -static __attribute__((unused)) int
> +static int
> hdcp2_verify_mprime(struct intel_connector *connector,
> struct hdcp2_rep_stream_ready *stream_ready)
> {
> @@ -1182,6 +1182,119 @@ static int hdcp2_session_key_exchange(struct
> intel_connector *connector)
> return 0;
> }
>
> +static
> +int hdcp2_propagate_stream_management_info(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + union {
> + struct hdcp2_rep_stream_manage stream_manage;
> + struct hdcp2_rep_stream_ready stream_ready;
> + } msgs;
> + const struct intel_hdcp_shim *shim = hdcp->shim;
> + int ret;
> +
> + /* Prepare RepeaterAuth_Stream_Manage msg */
> + msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
> + drm_hdcp2_u32_to_seq_num(msgs.stream_manage.seq_num_m, hdcp->seq_num_m);
> +
> + /* K no of streams is fixed as 1. Stored as big-endian. */
> + msgs.stream_manage.k = __swab16(1);
> +
> + /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
> + msgs.stream_manage.streams[0].stream_id = 0;
> + msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
> +
> + /* Send it to Repeater */
> + ret = shim->write_2_2_msg(intel_dig_port, &msgs.stream_manage,
> + sizeof(msgs.stream_manage));
> + if (ret < 0)
> + return ret;
> +
> + ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_STREAM_READY,
> + &msgs.stream_ready, sizeof(msgs.stream_ready));
> + if (ret < 0)
> + return ret;
> +
> + hdcp->port_data.seq_num_m = hdcp->seq_num_m;
> + hdcp->port_data.streams[0].stream_type = hdcp->content_type;
> +
> + ret = hdcp2_verify_mprime(connector, &msgs.stream_ready);
> + if (ret < 0)
> + return ret;
> +
> + hdcp->seq_num_m++;
> +
> + if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
> + DRM_DEBUG_KMS("seq_num_m roll over.\n");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +static
> +int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + union {
> + struct hdcp2_rep_send_receiverid_list recvid_list;
> + struct hdcp2_rep_send_ack rep_ack;
> + } msgs;
> + const struct intel_hdcp_shim *shim = hdcp->shim;
> + u8 *rx_info;
> + u32 seq_num_v;
> + int ret;
> +
> + ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_SEND_RECVID_LIST,
> + &msgs.recvid_list, sizeof(msgs.recvid_list));
> + if (ret < 0)
> + return ret;
> +
> + rx_info = msgs.recvid_list.rx_info;
There's a 2s timeout here that we're not checking, but again probably
follow-up patch.
> +
> + if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
> + HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
> + DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
> + return -EINVAL;
> + }
> +
> + /* Converting and Storing the seq_num_v to local variable as DWORD */
> + drm_hdcp2_seq_num_to_u32(
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: Prepare for larger CSB status FIFO size (rev4)
== Series Details == Series: series starting with [1/3] drm/i915: Prepare for larger CSB status FIFO size (rev4) URL : https://patchwork.freedesktop.org/series/54213/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7854930e939b drm/i915: Prepare for larger CSB status FIFO size 7cbdc840c1d8 drm/i915/icl: Switch to using 12 deep CSB status FIFO e050519e52a5 drm/i915/icl: Introduce gen11 flush/invalidate -:25: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #25: FILE: drivers/gpu/drm/i915/intel_gpu_commands.h:198: +#define PIPE_CONTROL_COMMAND_CACHE_INVALIDATE(1<<29) /* gen11+ */ ^ -:26: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #26: FILE: drivers/gpu/drm/i915/intel_gpu_commands.h:199: +#define PIPE_CONTROL_TILE_CACHE_FLUSH(1<<28) /* gen11+ */ ^ total: 0 errors, 0 warnings, 2 checks, 81 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for sysfs: Disable lockdep for driver bind/unbind files (rev2)
== Series Details == Series: sysfs: Disable lockdep for driver bind/unbind files (rev2) URL : https://patchwork.freedesktop.org/series/54238/ State : success == Summary == CI Bug Log - changes from CI_DRM_5332_full -> Patchwork_11124_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_11124_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_suspend@shrink: - shard-skl: NOTRUN -> DMESG-WARN [fdo#108784] * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +3 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-hsw: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-a: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +19 * igt@kms_ccs@pipe-b-crc-sprite-planes-basic: - shard-glk: PASS -> FAIL [fdo#108145] * igt@kms_color@pipe-b-ctm-negative: - shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +10 * igt@kms_color@pipe-b-degamma: - shard-apl: PASS -> FAIL [fdo#104782] * igt@kms_color@pipe-c-ctm-max: - shard-apl: PASS -> FAIL [fdo#108147] * igt@kms_cursor_crc@cursor-128x42-random: - shard-glk: PASS -> FAIL [fdo#103232] +3 * igt@kms_cursor_crc@cursor-256x85-random: - shard-apl: PASS -> FAIL [fdo#103232] +4 - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_legacy@cursora-vs-flipa-legacy: - shard-apl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] * igt@kms_draw_crc@draw-method-xrgb2101010-render-untiled: - shard-iclb: PASS -> WARN [fdo#108336] +5 * igt@kms_flip@flip-vs-dpms-interruptible: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#109093] * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-mmap-gtt: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +5 * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt: - shard-iclb: PASS -> DMESG-FAIL [fdo#107720] / [fdo#107724] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render: - shard-apl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu: - shard-glk: PASS -> FAIL [fdo#103167] +4 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-blt: - shard-iclb: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbcpsr-stridechange: - shard-skl: NOTRUN -> FAIL [fdo#105683] - shard-iclb: PASS -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +8 * igt@kms_frontbuffer_tracking@psr-suspend: - shard-iclb: PASS -> INCOMPLETE [fdo#106978] / [fdo#107713] * igt@kms_plane@pixel-format-pipe-a-planes: - shard-iclb: NOTRUN -> FAIL [fdo#103166] * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_multiple@atomic-pipe-a-tiling-x: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-c-tiling-x: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@kms_setmode@basic: - shard-hsw: PASS -> FAIL [fdo#99912] * igt@pm_rpm@gem-idle: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@pm_rpm@legacy-planes: - shard-skl: PASS -> INCOMPLETE [fdo#105959] / [fdo#107807] Possible fixes * igt@gem_workarounds@suspend-resume-context: - shard-iclb: INCOMPLETE [fdo#107713] -> PASS * igt@kms_available_modes_crc@available_mode_test_crc: - shard-apl: FAIL [fdo#106641] -> PASS * igt@kms_chv_cursor_fail@pipe-b-64x64-right-edge: - shard-iclb: DMESG-WARN [fdo#107724] / [fdo#108336] -> PASS +2 * igt@kms_cursor_crc@cursor-128x42-sliding: - shard-glk: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_crc@cursor-64x64-sliding: - shard-apl: FAIL [fdo#103232] -> PASS +3 * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions: - shard-iclb: FAIL [fdo#103355] -> PASS * igt@kms_draw_crc@draw-method-xrgb2101010-blt-ytiled: - shard-iclb: WARN [fdo#108336] -> PASS +2 * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: FAIL [fdo#105363] -> PASS * igt@kms_flip@modeset-vs-vblank-race-interruptible: - shard-glk: FAIL [fdo#103060] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff: - shard-apl:
Re: [Intel-gfx] [PATCH v9 11/39] drm: helper functions for hdcp2 seq_num to from u32
On Thu, Dec 13, 2018 at 09:31:13AM +0530, Ramalingam C wrote:
> Library functions for endianness are aligned for 16/32/64 bits.
> But hdcp sequence numbers are 24bits(big endian).
> So for their conversion to and from u32 helper functions are developed.
>
> Signed-off-by: Ramalingam C
> ---
> include/drm/drm_hdcp.h | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index a6de09c5e47f..d8093ecf3ddc 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -250,4 +250,22 @@ struct hdcp2_dp_errata_stream_type {
> #define HDCP_2_2_HDMI_RXSTATUS_READY(x) ((x) & BIT(2))
> #define HDCP_2_2_HDMI_RXSTATUS_REAUTH_REQ(x) ((x) & BIT(3))
>
> +/*
> + * Library functions for endianness are aligned for 16/32/64 bits.
> + * But hdcp sequence numbers are 24bits(big endian). So for their conversion
> + * from and to u32 below functions are developed.
Comment is a bit confusing, I'd do a simple:
/*
* Helper functions to convert 24bit big endian hdcp sequence number to
* host format and back
*/
Explaining why we need them exactly isn't terribly interesting.
> + */
> +static inline void
> +drm_hdcp2_seq_num_to_u32(u32 *val, u8 seq_num[HDCP_2_2_SEQ_NUM_LEN])
make u32 val the return value of this function, should be cleaner.
> +{
> + *val = seq_num[2] | seq_num[1] << 8 | seq_num[0] << 16;
> +}
> +
> +static inline void drm_hdcp2_u32_to_seq_num(u8 *seq_num, u32 val)
u8 seq_num[HDCP_2_2_SEQ_NUM_LEN]. Not any different in the actual function
type, just a bit more informative.
> +{
> + seq_num[0] = (val & (0xff << 16)) >> 16;
> + seq_num[1] = (val & (0xff << 8)) >> 8;
Shift alone should be enough, since seq_num[x] is of type u8 the & 0xff is
implied.
With the above comments addressed:
Reviewed-by: Daniel Vetter
> + seq_num[2] = val & 0xff;
> +}
> +
> #endif
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/4] drm/i915/perf: handle interrupts from the OA unit
The OA unit can notify that its circular buffer is half full through
an interrupt and we would like to give the application the ability to
make use of this interrupt to get rid of CPU checks on the OA buffer.
This change wires up the interrupt to the i915-perf stream and leaves
it ignored for now.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 21 +
drivers/gpu/drm/i915/i915_irq.c | 39 -
drivers/gpu/drm/i915/i915_perf.c| 26 +
drivers/gpu/drm/i915/i915_reg.h | 7 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
5 files changed, 88 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3669ed0a6376..014294e33b40 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1354,6 +1354,12 @@ struct i915_perf_stream {
* buffer should be checked for available data.
*/
u64 poll_oa_period;
+
+ /**
+* @oa_interrupt_monitor: Whether the stream will be notified by OA
+* interrupts.
+*/
+ bool oa_interrupt_monitor;
};
/**
@@ -1845,6 +1851,21 @@ struct drm_i915_private {
wait_queue_head_t poll_wq;
bool pollin;
+ /**
+* Atomic counter incremented by the interrupt
+* handling code for each OA half full interrupt
+* received.
+*/
+ atomic64_t half_full_count;
+
+ /**
+* Copy of the atomic half_full_count that was last
+* processed in the i915-perf driver. If both counters
+* differ, there is data available to read in the OA
+* buffer.
+*/
+ u64 half_full_count_last;
+
/**
* For rate limiting any notifications of spurious
* invalid OA reports
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d447d7d508f4..b1098118f71e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1222,6 +1222,12 @@ static void notify_ring(struct intel_engine_cs *engine)
trace_intel_engine_notify(engine, wait);
}
+static void notify_perfmon_buffer_half_full(struct drm_i915_private *i915)
+{
+ atomic64_inc(&i915->perf.oa.half_full_count);
+ wake_up_all(&i915->perf.oa.poll_wq);
+}
+
static void vlv_c0_read(struct drm_i915_private *dev_priv,
struct intel_rps_ei *ei)
{
@@ -1486,6 +1492,9 @@ static void snb_gt_irq_handler(struct drm_i915_private
*dev_priv,
GT_RENDER_CS_MASTER_ERROR_INTERRUPT))
DRM_DEBUG("Command parser error, gt_iir 0x%08x\n", gt_iir);
+ if (gt_iir & GT_PERFMON_BUFFER_HALF_FULL_INTERRUPT)
+ notify_perfmon_buffer_half_full(dev_priv);
+
if (gt_iir & GT_PARITY_ERROR(dev_priv))
ivybridge_parity_error_irq_handler(dev_priv, gt_iir);
}
@@ -1507,6 +1516,12 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
tasklet_hi_schedule(&engine->execlists.tasklet);
}
+static void gen8_perfmon_handler(struct drm_i915_private *i915, u32 iir)
+{
+ if (iir & GEN8_GT_PERFMON_BUFFER_HALF_FULL_INTERRUPT)
+ notify_perfmon_buffer_half_full(i915);
+}
+
static void gen8_gt_irq_ack(struct drm_i915_private *i915,
u32 master_ctl, u32 gt_iir[4])
{
@@ -1516,6 +1531,7 @@ static void gen8_gt_irq_ack(struct drm_i915_private *i915,
GEN8_GT_BCS_IRQ | \
GEN8_GT_VCS1_IRQ | \
GEN8_GT_VCS2_IRQ | \
+ GEN8_GT_WDBOX_OACS_IRQ | \
GEN8_GT_VECS_IRQ | \
GEN8_GT_PM_IRQ | \
GEN8_GT_GUC_IRQ)
@@ -1538,7 +1554,7 @@ static void gen8_gt_irq_ack(struct drm_i915_private *i915,
raw_reg_write(regs, GEN8_GT_IIR(2), gt_iir[2]);
}
- if (master_ctl & GEN8_GT_VECS_IRQ) {
+ if (master_ctl & (GEN8_GT_VECS_IRQ | GEN8_GT_WDBOX_OACS_IRQ)) {
gt_iir[3] = raw_reg_read(regs, GEN8_GT_IIR(3));
if (likely(gt_iir[3]))
raw_reg_write(regs, GEN8_GT_IIR(3), gt_iir[3]);
@@ -1562,9 +1578,11 @@ static void gen8_gt_irq_handler(struct drm_i915_private
*i915,
gt_iir[1] >> GEN8_VCS2_IRQ_SHIFT);
}
- if (master_ctl & GEN8_GT_VECS_IRQ) {
+ if (master_ctl & (GEN8_GT_VECS_IRQ | GEN8_GT_WDBOX_OACS_IRQ)) {
gen8_cs_irq_handler(i915->engine[VECS],
gt_iir[3] >> GEN8_VECS_IRQ_SHIFT);
+ gen8_perfm
[Intel-gfx] [RFC 4/4] drm/i915/perf: add interrupt enabling parameter
This let's the application choose to be driven by the interrupt
mechanism of the HW. In conjuction with long periods for checks for
the availability of data on the CPU, this can reduce the CPU load when
doing capture of OA data.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 58
include/uapi/drm/i915_drm.h | 8 +
2 files changed, 59 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 21b05437123d..0a1c7694d3dc 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -252,7 +252,7 @@
* indicates that an updated tail pointer is needed.
*
* Most of the implementation details for this workaround are in
- * oa_buffer_check_unlocked() and _append_oa_reports()
+ * oa_buffer_check() and _append_oa_reports()
*
* Note for posterity: previously the driver used to define an effective tail
* pointer that lagged the real pointer by a 'tail margin' measured in bytes
@@ -428,9 +428,11 @@ static u32 gen7_oa_hw_tail_read(struct drm_i915_private
*dev_priv)
return oastatus1 & GEN7_OASTATUS1_TAIL_MASK;
}
+
/**
- * oa_buffer_check_unlocked - check for data and update tail ptr state
+ * oa_buffer_check - check for data and update tail ptr state
* @dev_priv: i915 device instance
+ * @lock: whether to take the oa_buffer spin lock
*
* This is either called via fops (for blocking reads in user ctx) or the poll
* check hrtimer (atomic ctx) to check the OA buffer tail pointer and check
@@ -452,8 +454,9 @@ static u32 gen7_oa_hw_tail_read(struct drm_i915_private
*dev_priv)
*
* Returns: %true if the OA buffer contains data, else %false
*/
-static bool oa_buffer_check_unlocked(struct drm_i915_private *dev_priv)
+static bool oa_buffer_check(struct drm_i915_private *dev_priv, bool lock)
{
+ u64 half_full_count = atomic64_read(&dev_priv->perf.oa.half_full_count);
int report_size = dev_priv->perf.oa.oa_buffer.format_size;
unsigned long flags;
u32 hw_tail;
@@ -463,7 +466,8 @@ static bool oa_buffer_check_unlocked(struct
drm_i915_private *dev_priv)
* could result in an OA buffer reset which might reset the head,
* tails[] and aged_tail state.
*/
- spin_lock_irqsave(&dev_priv->perf.oa.oa_buffer.ptr_lock, flags);
+ if (lock)
+ spin_lock_irqsave(&dev_priv->perf.oa.oa_buffer.ptr_lock, flags);
hw_tail = dev_priv->perf.oa.ops.oa_hw_tail_read(dev_priv);
@@ -540,7 +544,10 @@ static bool oa_buffer_check_unlocked(struct
drm_i915_private *dev_priv)
dev_priv->perf.oa.oa_buffer.aging_timestamp = now;
}
- spin_unlock_irqrestore(&dev_priv->perf.oa.oa_buffer.ptr_lock, flags);
+ dev_priv->perf.oa.half_full_count_last = half_full_count;
+
+ if (lock)
+ spin_unlock_irqrestore(&dev_priv->perf.oa.oa_buffer.ptr_lock,
flags);
return OA_TAKEN(dev_priv->perf.oa.oa_buffer.tail,
dev_priv->perf.oa.oa_buffer.head) >= report_size;
@@ -671,6 +678,16 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
spin_lock_irqsave(&dev_priv->perf.oa.oa_buffer.ptr_lock, flags);
+ /*
+* Opportunisticly checks for half buffer interrupt if requested by
+* the user.
+*/
+ if (stream->oa_interrupt_monitor &&
+ (dev_priv->perf.oa.half_full_count_last !=
+atomic64_read(&dev_priv->perf.oa.half_full_count))) {
+ dev_priv->perf.oa.pollin = oa_buffer_check(dev_priv, false);
+ }
+
head = dev_priv->perf.oa.oa_buffer.head;
tail = dev_priv->perf.oa.oa_buffer.tail;
@@ -954,6 +971,16 @@ static int gen7_append_oa_reports(struct i915_perf_stream
*stream,
spin_lock_irqsave(&dev_priv->perf.oa.oa_buffer.ptr_lock, flags);
+ /*
+* Opportunisticly checks for half buffer interrupt if requested by
+* the user.
+*/
+ if (stream->oa_interrupt_monitor &&
+ (dev_priv->perf.oa.half_full_count_last !=
+atomic64_read(&dev_priv->perf.oa.half_full_count))) {
+ dev_priv->perf.oa.pollin = oa_buffer_check(dev_priv, false);
+ }
+
head = dev_priv->perf.oa.oa_buffer.head;
tail = dev_priv->perf.oa.oa_buffer.tail;
@@ -1151,7 +1178,7 @@ static int i915_oa_wait_unlocked(struct i915_perf_stream
*stream)
return -EIO;
return wait_event_interruptible(dev_priv->perf.oa.poll_wq,
- oa_buffer_check_unlocked(dev_priv));
+ oa_buffer_check(dev_priv, true));
}
/**
@@ -1970,6 +1997,10 @@ static void i915_oa_stream_disable(struct
i915_perf_stream *stream)
dev_priv->perf.oa.ops.oa_disable(stream);
+ dev_priv->perf.oa.half_full_count_last = 0;
+ atomic64_set(&dev_priv->perf.oa.half_full_count,
+
[Intel-gfx] [RFC 0/4] drm/i915/perf: add OA interrupt support
Hi all, Tests run by the GPA/vTune teams reported a high CPU consumption on polling data from the i915-perf stream. This is due to a design decision to check the OA buffer head/tail pointers 200 times per seconds. The reasonning being not using the interrupt was initially that you could want to process data as soon as it's available. To avoid breaking the existing behavior of the i915-perf stream, we'll introduce 2 new options at opening of the i915-perf stream to allow the application to choose : - how often it wants the OA circular buffer registers to be checked - whether to make sure of the interrupt In the case of GPA, collecting 100k OA reports would initially consume 17~20% CPU. With these 2 new parameters set to 1 second for OA circular buffer checks and the interrupt enabled, CPU usage drops to 2~3%. I'm looking for feedback as to whether those 2 new opening parameters are alright. Since this might be the first time that we add a new parameter to the perf stream open ioctl, we would also need a way to detect their availability. So far in my experiments I've used the following trick : specify an invalid context id parameter at open and expect ENOENT when the parameter is available, EINVAL otherwise. I'm open to other ways of doing this. Cheers, Lionel Landwerlin (4): drm/i915/perf: rework aging tail workaround drm/i915/perf: add new open param to configure polling of OA buffer drm/i915/perf: handle interrupts from the OA unit drm/i915/perf: add interrupt enabling parameter drivers/gpu/drm/i915/i915_drv.h | 59 +++-- drivers/gpu/drm/i915/i915_irq.c | 39 +++- drivers/gpu/drm/i915/i915_perf.c| 273 +++- drivers/gpu/drm/i915/i915_reg.h | 7 + drivers/gpu/drm/i915/intel_ringbuffer.c | 2 + include/uapi/drm/i915_drm.h | 15 ++ 6 files changed, 276 insertions(+), 119 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 1/4] drm/i915/perf: rework aging tail workaround
We're about to introduce an options to open the perf stream, giving
the user ability to configure how often it wants the kernel to pull
the OA registers for available data.
Right now the workaround against the OA tail pointer race condition
requires at least twice the internal kernel pulling timer to make any
data available.
This changes introduce checks on the OA data written into the circular
buffer to make as much data as possible available on the first
iteration of the pulling timer.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 32 +++---
drivers/gpu/drm/i915/i915_perf.c | 162 +++
2 files changed, 95 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0689e67c966e..09c4b5de141b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1845,6 +1845,12 @@ struct drm_i915_private {
*/
struct ratelimit_state spurious_report_rs;
+ /**
+* For rate limiting any notifications of tail pointer
+* race.
+*/
+ struct ratelimit_state tail_pointer_race;
+
bool periodic;
int period_exponent;
@@ -1885,23 +1891,11 @@ struct drm_i915_private {
spinlock_t ptr_lock;
/**
-* One 'aging' tail pointer and one 'aged'
-* tail pointer ready to used for reading.
-*
-* Initial values of 0x are invalid
-* and imply that an update is required
-* (and should be ignored by an attempted
-* read)
-*/
- struct {
- u32 offset;
- } tails[2];
-
- /**
-* Index for the aged tail ready to read()
-* data up to.
+* The last HW tail reported by HW. The data
+* might not have made it to memory yet
+* though.
*/
- unsigned int aged_tail_idx;
+ u32 aging_tail;
/**
* A monotonic timestamp for when the current
@@ -1920,6 +1914,12 @@ struct drm_i915_private {
* data to userspace.
*/
u32 head;
+
+ /**
+* The last tail verified tail that can be
+* read by userspace.
+*/
+ u32 tail;
} oa_buffer;
u32 gen7_latched_oastatus1;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4529edfdcfc8..d54142f1cff4 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -451,8 +451,7 @@ static bool oa_buffer_check_unlocked(struct
drm_i915_private *dev_priv)
{
int report_size = dev_priv->perf.oa.oa_buffer.format_size;
unsigned long flags;
- unsigned int aged_idx;
- u32 head, hw_tail, aged_tail, aging_tail;
+ u32 hw_tail;
u64 now;
/* We have to consider the (unlikely) possibility that read() errors
@@ -461,16 +460,6 @@ static bool oa_buffer_check_unlocked(struct
drm_i915_private *dev_priv)
*/
spin_lock_irqsave(&dev_priv->perf.oa.oa_buffer.ptr_lock, flags);
- /* NB: The head we observe here might effectively be a little out of
-* date (between head and tails[aged_idx].offset if there is currently
-* a read() in progress.
-*/
- head = dev_priv->perf.oa.oa_buffer.head;
-
- aged_idx = dev_priv->perf.oa.oa_buffer.aged_tail_idx;
- aged_tail = dev_priv->perf.oa.oa_buffer.tails[aged_idx].offset;
- aging_tail = dev_priv->perf.oa.oa_buffer.tails[!aged_idx].offset;
-
hw_tail = dev_priv->perf.oa.ops.oa_hw_tail_read(dev_priv);
/* The tail pointer increases in 64 byte increments,
@@ -480,63 +469,76 @@ static bool oa_buffer_check_unlocked(struct
drm_i915_private *dev_priv)
now = ktime_get_mono_fast_ns();
- /* Update the aged tail
-*
-* Flip the tail pointer available for read()s once the aging tail is
-* old enough to trust that the corresponding data will be visible to
-* the CPU...
-*
-
[Intel-gfx] [RFC 2/4] drm/i915/perf: add new open param to configure polling of OA buffer
This new parameter let's the application choose how often the OA
buffer should be checked on the CPU side for data availability. Longer
polling period tend to reduce CPU overhead if the application does not
care about somewhat real time data collection.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_perf.c | 27 +--
include/uapi/drm/i915_drm.h | 7 +++
3 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 09c4b5de141b..3669ed0a6376 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1348,6 +1348,12 @@ struct i915_perf_stream {
* @oa_config: The OA configuration used by the stream.
*/
struct i915_oa_config *oa_config;
+
+ /**
+* @poll_oa_period: The period in nanoseconds at which the OA
+* buffer should be checked for available data.
+*/
+ u64 poll_oa_period;
};
/**
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d54142f1cff4..a8df58ec7d75 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -264,11 +264,11 @@
#define OA_TAIL_MARGIN_NSEC10ULL
#define INVALID_TAIL_PTR 0x
-/* frequency for checking whether the OA unit has written new reports to the
- * circular OA buffer...
+/* The default frequency for checking whether the OA unit has written new
+ * reports to the circular OA buffer...
*/
-#define POLL_FREQUENCY 200
-#define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY)
+#define DEFAULT_POLL_FREQUENCY 200
+#define DEFAULT_POLL_PERIOD (NSEC_PER_SEC / DEFAULT_POLL_FREQUENCY)
/* for sysctl proc_dointvec_minmax of dev.i915.perf_stream_paranoid */
static int zero;
@@ -345,6 +345,8 @@ static const struct i915_oa_format
gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
* @oa_format: An OA unit HW report format
* @oa_periodic: Whether to enable periodic OA unit sampling
* @oa_period_exponent: The OA unit sampling period is derived from this
+ * @poll_oa_period: The period at which the CPU will check for OA data
+ * availability
*
* As read_properties_unlocked() enumerates and validates the properties given
* to open a stream of metrics the configuration is built up in the structure
@@ -361,6 +363,7 @@ struct perf_open_properties {
int oa_format;
bool oa_periodic;
int oa_period_exponent;
+ u64 poll_oa_period;
};
static void free_oa_config(struct drm_i915_private *dev_priv,
@@ -1902,7 +1905,7 @@ static void i915_oa_stream_enable(struct i915_perf_stream
*stream)
if (dev_priv->perf.oa.periodic)
hrtimer_start(&dev_priv->perf.oa.poll_check_timer,
- ns_to_ktime(POLL_PERIOD),
+ ns_to_ktime(stream->poll_oa_period),
HRTIMER_MODE_REL_PINNED);
}
@@ -2266,13 +2269,15 @@ static enum hrtimer_restart
oa_poll_check_timer_cb(struct hrtimer *hrtimer)
struct drm_i915_private *dev_priv =
container_of(hrtimer, typeof(*dev_priv),
perf.oa.poll_check_timer);
+ struct i915_perf_stream *stream = dev_priv->perf.oa.exclusive_stream;
if (oa_buffer_check_unlocked(dev_priv)) {
dev_priv->perf.oa.pollin = true;
wake_up(&dev_priv->perf.oa.poll_wq);
}
- hrtimer_forward_now(hrtimer, ns_to_ktime(POLL_PERIOD));
+ hrtimer_forward_now(hrtimer,
+ ns_to_ktime(stream->poll_oa_period));
return HRTIMER_RESTART;
}
@@ -2593,6 +2598,7 @@ i915_perf_open_ioctl_locked(struct drm_i915_private
*dev_priv,
stream->dev_priv = dev_priv;
stream->ctx = specific_ctx;
+ stream->poll_oa_period = props->poll_oa_period;
ret = i915_oa_stream_init(stream, param, props);
if (ret)
@@ -2669,6 +2675,7 @@ static int read_properties_unlocked(struct
drm_i915_private *dev_priv,
u32 i;
memset(props, 0, sizeof(struct perf_open_properties));
+ props->poll_oa_period = DEFAULT_POLL_PERIOD;
if (!n_props) {
DRM_DEBUG("No i915 perf properties given\n");
@@ -2772,6 +2779,14 @@ static int read_properties_unlocked(struct
drm_i915_private *dev_priv,
props->oa_periodic = true;
props->oa_period_exponent = value;
break;
+ case DRM_I915_PERF_PROP_POLL_OA_DELAY:
+ if (value < 10 /* 100us */) {
+ DRM_DEBUG("OA availability timer too small
(%lluns < 100us)\n",
+ value);
+ return -EINVAL;
+ }
+ props->poll_oa_period = value;
+ break;
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
> Implements HDCP2.2 authentication for hdcp2.2 receivers, with
> following steps:
> Authentication and Key exchange (AKE).
> Locality Check (LC).
> Session Key Exchange(SKE).
> DP Errata for stream type configuration for receivers.
>
> At AKE, the HDCP Receiver’s public key certificate is verified by the
> HDCP Transmitter. A Master Key k m is exchanged.
>
> At LC, the HDCP Transmitter enforces locality on the content by
> requiring that the Round Trip Time (RTT) between a pair of messages
> is not more than 20 ms.
>
> At SKE, The HDCP Transmitter exchanges Session Key ks with
> the HDCP Receiver.
>
> In DP HDCP2.2 encryption and decryption logics use the stream type as
> one of the parameter. So Before enabling the Encryption DP HDCP2.2
> receiver needs to be communicated with stream type. This is added to
> spec as ERRATA.
>
> This generic implementation is complete only with the hdcp2 specific
> functions defined at hdcp_shim.
>
> v2: Rebased.
> v3:
> %s/PARING/PAIRING
> Coding style fixing [Uma]
> v4:
> Rebased as part of patch reordering.
> Defined the functions for mei services. [Daniel]
> v5:
> Redefined the mei service functions as per comp redesign.
> Required intel_hdcp members are defined [Sean Paul]
> v6:
> Typo of cipher is Fixed [Uma]
> %s/uintxx_t/uxx
> Check for comp_master is removed.
> v7:
> Adjust to the new interface.
> Avoid using bool structure members. [Tomas]
> v8: Rebased.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_drv.h | 34 ++
> drivers/gpu/drm/i915/intel_hdcp.c | 211
> +++---
> 2 files changed, 230 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 6d5361616ca3..a6b632d71490 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -387,6 +387,22 @@ struct intel_hdcp_shim {
> /* Detects whether Panel is HDCP2.2 capable */
> int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
> bool *capable);
> +
> + /* Write HDCP2.2 messages */
> + int (*write_2_2_msg)(struct intel_digital_port *intel_dig_port,
> + void *buf, size_t size);
> +
> + /* Read HDCP2.2 messages */
> + int (*read_2_2_msg)(struct intel_digital_port *intel_dig_port,
> + u8 msg_id, void *buf, size_t size);
> +
> + /*
> + * Implementation of DP HDCP2.2 Errata for the communication of stream
> + * type to Receivers. In DP HDCP2.2 Stream type is one of the input to
> + * the HDCP2.2 Cipher for En/De-Cryption. Not applicable for HDMI.
> + */
> + int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
> + void *buf, size_t size);
> };
>
> struct intel_hdcp {
> @@ -414,6 +430,24 @@ struct intel_hdcp {
>*/
> u8 content_type;
> struct hdcp_port_data port_data;
> +
> + u8 is_paired;
> + u8 is_repeater;
Make these two bool, will simplify the code a bunch.
> +
> + /*
> + * Count of ReceiverID_List received. Initialized to 0 at AKE_INIT.
> + * Incremented after processing the RepeaterAuth_Send_ReceiverID_List.
> + * When it rolls over re-auth has to be triggered.
> + */
> + u32 seq_num_v;
> +
> + /*
> + * Count of RepeaterAuth_Stream_Manage msg propagated.
> + * Initialized to 0 on AKE_INIT. Incremented after every successful
> + * transmission of RepeaterAuth_Stream_Manage message. When it rolls
> + * over re-Auth has to be triggered.
> + */
> + u32 seq_num_m;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index f0ee448e6546..f1f0ef294e20 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -18,6 +18,7 @@
>
> #define KEY_LOAD_TRIES 5
> #define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
> +#define HDCP2_LC_RETRY_CNT 3
>
> static
> bool intel_hdcp_is_ksv_valid(u8 *ksv)
> @@ -854,7 +855,7 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
> enum port port)
> return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
> }
>
> -static __attribute__((unused)) int
> +static int
> hdcp2_prepare_ake_init(struct intel_connector *connector,
> struct hdcp2_ake_init *ake_data)
> {
> @@ -875,7 +876,7 @@ hdcp2_prepare_ake_init(struct intel_connector *connector,
> return ret;
> }
>
> -static __attribute__((unused)) int
> +static int
> hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
> struct hdcp2_ake_send_cert *rx_cert,
> bool *paired,
> @@ -897,9 +898,8 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_con
Re: [Intel-gfx] [PATCH] sysfs: Disable lockdep for driver bind/unbind files
On Wed, Dec 19, 2018 at 1:39 PM Daniel Vetter wrote:
>
> This is the much more correct fix for my earlier attempt at:
>
> https://lkml.org/lkml/2018/12/10/118
>
> Short recap:
>
> - There's not actually a locking issue, it's just lockdep being a bit
> too eager to complain about a possible deadlock.
>
> - Contrary to what I claimed the real problem is recursion on
> kn->count. Greg pointed me at sysfs_break_active_protection(), used
> by the scsi subsystem to allow a sysfs file to unbind itself. That
> would be a real deadlock, which isn't what's happening here. Also,
> breaking the active protection means we'd need to manually handle
> all the lifetime fun.
>
> - With Rafael we discussed the task_work approach, which kinda works,
> but has two downsides: It's a functional change for a lockdep
> annotation issue, and it won't work for the bind file (which needs
> to get the errno from the driver load function back to userspace).
>
> - Greg also asked why this never showed up: To hit this you need to
> unregister a 2nd driver from the unload code of your first driver. I
> guess only gpus do that. The bug has always been there, but only
> with a recent patch series did we add more locks so that lockdep
> built a chain from unbinding the snd-hda driver to the
> acpi_video_unregister call.
>
> Full lockdep splat:
>
> [12301.898799]
> [12301.898805] WARNING: possible recursive locking detected
> [12301.898811] 4.20.0-rc7+ #84 Not tainted
> [12301.898815]
> [12301.898821] bash/5297 is trying to acquire lock:
> [12301.898826] f61c6093 (kn->count#39){}, at:
> kernfs_remove_by_name_ns+0x3b/0x80
> [12301.898841] but task is already holding lock:
> [12301.898847] 5f634021 (kn->count#39){}, at:
> kernfs_fop_write+0xdc/0x190
> [12301.898856] other info that might help us debug this:
> [12301.898862] Possible unsafe locking scenario:
> [12301.898867]CPU0
> [12301.898870]
> [12301.898874] lock(kn->count#39);
> [12301.898879] lock(kn->count#39);
> [12301.898883] *** DEADLOCK ***
> [12301.898891] May be due to missing lock nesting notation
> [12301.898899] 5 locks held by bash/5297:
> [12301.898903] #0: cd800e54 (sb_writers#4){.+.+}, at:
> vfs_write+0x17f/0x1b0
> [12301.898915] #1: 0465e7c2 (&of->mutex){+.+.}, at:
> kernfs_fop_write+0xd3/0x190
> [12301.898925] #2: 5f634021 (kn->count#39){}, at:
> kernfs_fop_write+0xdc/0x190
> [12301.898936] #3: 414ef7ac (&dev->mutex){}, at:
> device_release_driver_internal+0x34/0x240
> [12301.898950] #4: 3218fbdf (register_count_mutex){+.+.}, at:
> acpi_video_unregister+0xe/0x40
> [12301.898960] stack backtrace:
> [12301.898968] CPU: 1 PID: 5297 Comm: bash Not tainted 4.20.0-rc7+ #84
> [12301.898974] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS
> 68SCF Ver. F.01 03/11/2011
> [12301.898982] Call Trace:
> [12301.898989] dump_stack+0x67/0x9b
> [12301.898997] __lock_acquire+0x6ad/0x1410
> [12301.899003] ? kernfs_remove_by_name_ns+0x3b/0x80
> [12301.899010] ? find_held_lock+0x2d/0x90
> [12301.899017] ? mutex_spin_on_owner+0xe4/0x150
> [12301.899023] ? find_held_lock+0x2d/0x90
> [12301.899030] ? lock_acquire+0x90/0x180
> [12301.899036] lock_acquire+0x90/0x180
> [12301.899042] ? kernfs_remove_by_name_ns+0x3b/0x80
> [12301.899049] __kernfs_remove+0x296/0x310
> [12301.899055] ? kernfs_remove_by_name_ns+0x3b/0x80
> [12301.899060] ? kernfs_name_hash+0xd/0x80
> [12301.899066] ? kernfs_find_ns+0x6c/0x100
> [12301.899073] kernfs_remove_by_name_ns+0x3b/0x80
> [12301.899080] bus_remove_driver+0x92/0xa0
> [12301.899085] acpi_video_unregister+0x24/0x40
> [12301.899127] i915_driver_unload+0x42/0x130 [i915]
> [12301.899160] i915_pci_remove+0x19/0x30 [i915]
> [12301.899169] pci_device_remove+0x36/0xb0
> [12301.899176] device_release_driver_internal+0x185/0x240
> [12301.899183] unbind_store+0xaf/0x180
> [12301.899189] kernfs_fop_write+0x104/0x190
> [12301.899195] __vfs_write+0x31/0x180
> [12301.899203] ? rcu_read_lock_sched_held+0x6f/0x80
> [12301.899209] ? rcu_sync_lockdep_assert+0x29/0x50
> [12301.899216] ? __sb_start_write+0x13c/0x1a0
> [12301.899221] ? vfs_write+0x17f/0x1b0
> [12301.899227] vfs_write+0xb9/0x1b0
> [12301.899233] ksys_write+0x50/0xc0
> [12301.899239] do_syscall_64+0x4b/0x180
> [12301.899247] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [12301.899253] RIP: 0033:0x7f452ac7f7a4
> [12301.899259] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00
> 00 00 00 8b 05 aa f0 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d
> 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
> [12301.899273] RSP: 002b:7ffceafa6918 EFLAGS: 0246 ORIG_RAX:
> 0001
> [12301.899282] RAX: ffda RBX: 000d RCX:
> 7f452ac7f7a4
> [12301.899288] RDX: 000d RSI: 5612a1ab
Re: [Intel-gfx] [PATCH v9 07/39] drm/i915: MEI interface definition
On Thu, Dec 13, 2018 at 09:31:09AM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
>
> v2:
> Adjust to the new interface changes. [Tomas]
> Added further debug logs for the failures at MEI i/f.
> port in hdcp_port data is equipped to handle -ve values.
> v3:
> mei comp is matched for global i915 comp master. [Daniel]
> In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
> mei wrappers are adjusted as per the i/f change [Daniel]
Yeah looks all good. Spotted some small stuff below still.
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_drv.h | 5 +
> drivers/gpu/drm/i915/intel_hdcp.c | 248
> +-
> include/drm/i915_component.h | 7 ++
> 3 files changed, 259 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index dd9371647a8c..191b6e0f086c 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> /**
> @@ -379,6 +380,9 @@ struct intel_hdcp_shim {
> /* Detects panel's hdcp capability. This is optional for HDMI. */
> int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
> bool *hdcp_capable);
> +
> + /* HDCP adaptation(DP/HDMI) required on the port */
> + enum hdcp_wired_protocol protocol;
> };
>
> struct intel_hdcp {
> @@ -399,6 +403,7 @@ struct intel_hdcp {
>* content can flow only through a link protected by HDCP2.2.
>*/
> u8 content_type;
> + struct hdcp_port_data port_data;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 584d27f3c699..9405fce07b93 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -8,8 +8,10 @@
>
> #include
> #include
> +#include
> #include
> #include
> +#include
>
> #include "intel_drv.h"
> #include "i915_reg.h"
> @@ -833,6 +835,232 @@ bool is_hdcp_supported(struct drm_i915_private
> *dev_priv, enum port port)
> return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
> }
>
> +static __attribute__((unused)) int
> +hdcp2_prepare_ake_init(struct intel_connector *connector,
> +struct hdcp2_ake_init *ake_data)
> +{
> + struct hdcp_port_data *data = &connector->hdcp.port_data;
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct i915_component_master *comp = dev_priv->comp_master;
> + int ret;
> +
> + /* During the connector init encoder might not be initialized */
> + if (data->port == PORT_NONE)
> + data->port = connector->encoder->port;
> +
> + ret = comp->hdcp_ops->initiate_hdcp2_session(comp->mei_dev,
> + data, ake_data);
> + if (ret)
> + DRM_DEBUG_KMS("Prepare_ake_init failed. %d\n", ret);
> +
> + return ret;
> +}
> +
> +static __attribute__((unused)) int
> +hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
> + struct hdcp2_ake_send_cert *rx_cert,
> + bool *paired,
> + struct hdcp2_ake_no_stored_km *ek_pub_km,
> + size_t *msg_sz)
> +{
> + struct hdcp_port_data *data = &connector->hdcp.port_data;
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct i915_component_master *comp = dev_priv->comp_master;
> + int ret;
> +
> + ret = comp->hdcp_ops->verify_receiver_cert_prepare_km(comp->mei_dev,
> + data, rx_cert,
> + paired, ek_pub_km,
> + msg_sz);
> + if (ret < 0)
> + DRM_DEBUG_KMS("Verify rx_cert failed. %d\n", ret);
> +
> + return ret;
> +}
> +
> +static __attribute__((unused)) int
> +hdcp2_verify_hprime(struct intel_connector *connector,
> + struct hdcp2_ake_send_hprime *rx_hprime)
> +{
> + struct hdcp_port_data *data = &connector->hdcp.port_data;
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct i915_component_master *comp = dev_priv->comp_master;
> + int ret;
> +
> + ret = comp->hdcp_ops->verify_hprime(comp->mei_dev, data, rx_hprime);
> + if (ret < 0)
> + DRM_DEBUG_KMS("Verify hprime failed. %d\n", ret);
> +
> + return ret;
> +}
> +
> +static __attribute__((unused)) int
> +hdcp2_store_pairing_info(struct intel_connector *connector,
> + struct hdcp2_ake_send_pairing_info *pairing_info)
> +{
> + struct hdcp_port_data *data = &connector->hdcp.port_data;
> + struct drm_i915_private *d
