aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/gt/selftest_rps.c
AgeCommit message (Collapse)AuthorFilesLines
2020-11-21drm/i915/gt: Plug IPS into intel_rps_setChris Wilson1-1/+4
The old IPS interface did not match the RPS interface that we tried to plug it into (bool vs int return). Once repaired, our minimal selftesting is finally happy! Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-23drm/i915/selftests: Skip RPS tests on Ironlake (only IPS)Chris Wilson1-4/+4
Since Ironlake uses intel_ips.ko for its dynamic frequency adjustment, we do not have direct control over the frequency management so such tests are defunct. Similarly, we can't check the gen6+ RPS registers on Ironlake. Hopefully this catches all the invalid tests now that Ironlake has rejoined the dynamic GPU frequency club. There is an opportunity for the reader to add tests to exercise MEMINTRSTS and co. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-07drm/i915: Move i915_vma_lock in the selftests to avoid lock inversion, v3.Maarten Lankhorst1-12/+18
Make sure vma_lock is not used as inner lock when kernel context is used, and add ww handling where appropriate. Ensure that execbuf selftests keep passing by using ww handling. Changes since v2: - Fix i915_gem_context finally. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Joonas Lahtinen <[email protected]>
2020-08-17drm/i915/selftests: Downgrade severity of CS/SRM frequency scaling testsChris Wilson1-2/+2
Gracefully skip over the failures in the frequency scaling for the moment, the results are under review. References: https://gitlab.freedesktop.org/drm/intel/-/issues/1754 Signed-off-by: Chris Wilson <[email protected]> Cc: "Sundaresan, Sujaritha" <[email protected]> Cc: "Ewins, Jon" <[email protected]> Reviewed-by: Sujaritha Sundaresan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2020-07-24Merge v5.8-rc6 into drm-nextDave Airlie1-4/+4
I've got a silent conflict + two trees based on fixes to merge. Fixes a silent merge with amdgpu Signed-off-by: Dave Airlie <[email protected]>
2020-07-14drm/i915/selftests: Fix compare functions provided for sortingSudeep Holla1-4/+4
Both cmp_u32 and cmp_u64 are comparing the pointers instead of the value at those pointers. This will result in incorrect/unsorted list. Fix it by deferencing the pointers before comparison. Fixes: 4ba74e53ada3 ("drm/i915/selftests: Verify frequency scaling with RPS") Fixes: 8757797ff9c9 ("drm/i915/selftests: Repeat the rps clock frequency measurement") Cc: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Signed-off-by: Sudeep Holla <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 2196dfea896f7027b43bae848890ce4aec5c8724) Signed-off-by: Jani Nikula <[email protected]>
2020-06-18drm/i915/selftests: Enable selftesting of busy-statsChris Wilson1-39/+29
A couple of very simple tests to ensure that the basic properties of per-engine busyness accounting [0% and 100% busy] are faithful. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-16drm/i915/selftests: Restore to default heartbeatChris Wilson1-41/+28
Since we temporarily disable the heartbeat and restore back to the default value, we can use the stored defaults on the engine and avoid using a local. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3a230a554dbbc6cd5016cf1b56ee77cfcd48c7d8) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-05-19drm/i915/selftests: Restore to default heartbeatChris Wilson1-41/+28
Since we temporarily disable the heartbeat and restore back to the default value, we can use the stored defaults on the engine and avoid using a local. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/i915/selftests: Always flush before unpining after writingChris Wilson1-0/+2
Be consistent, and even when we know we had used a WC, flush the mapped object after writing into it. The flush understands the mapping type and will only clflush if !I915_MAP_WC, but will always insert a wmb [sfence] so that we can be sure that all writes are visible. v2: Add the unconditional wmb so we are know that we always flush the writes to memory/HW at that point. Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-04drm/i915/selftests: Repeat the rps clock frequency measurementChris Wilson1-14/+40
Repeat the measurement of the clock frequency a few times and use the median to try and reduce the systematic measurement error. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-30drm/i915/gt: Track use of RPS interrupts in flagsChris Wilson1-1/+1
Use the new intel_rps.flags field to store whether or not interrupts are being used with RPS. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-30drm/i915/gt: Move rps.enabled/active to flagsChris Wilson1-11/+11
Pull the boolean intel_rps.enabled and intel_rps.active into a single flags field, in preparation for more. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-28drm/i915/selftests: Tweak the tolerance for clock ticks to 12.5%Chris Wilson1-4/+4
Give a small bump for our tolerance on comparing the expected vs measured clock ticks/time from 10% to 12.5% to accommodate a bad result on Sandybridge that was off by 10.3%. Hopefully, that is the worst we will see. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1802 Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-28drm/i915/gt: fix spelling mistake "evalution" -> "evaluation"Colin Ian King1-1/+1
There is a spelling mistaking in a pr_notice message. Fix it. Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-27drm/i915/gt: Fix up clock frequencyChris Wilson1-0/+139
The bspec lists both the clock frequency and the effective interval. The interval corresponds to observed behaviour, so adjust the frequency to match. v2: Mika rightfully asked if we could measure the clock frequency from a selftest. Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Acked-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-24drm/i915/gt: Use the RPM config register to determine clk frequenciesChris Wilson1-2/+5
For many configuration details within RC6 and RPS we are programming intervals for the internal clocks. From gen11, these clocks are configuration via the RPM_CONFIG and so for convenience, we would like to convert to/from more natural units (ns). Signed-off-by: Chris Wilson <[email protected]> Cc: Andi Shyti <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-22drm/i915/selftests: Disable heartbeat around RPS interrupt testingChris Wilson1-4/+55
For verifying reciving the EI interrupts, we need to hold the GPU in very precise conditions (in terms of C0 cycles during the EI). If we preempt the busy load to handle the heartbeat, this may perturb the busy load causing us to miss the interrupt. The other tests, while not as time sensitive, may also be slightly perturbed, so apply the heartbeat protection across all the measurements. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-21drm/i915/selftests: Unroll the CS frequency loopChris Wilson1-13/+20
Having noticed that MI_BB_START is incurring a memory stall (see the correlation with uncore frequency), we have to unroll the loop in order to diminish the impact of the MI_BB_START on the instruction throughput. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-21drm/i915/selftests: Disable C-states when measuring RPS frequency responseChris Wilson1-0/+18
Let's isolate the impact of cpu frequency selection on determing the GPU throughput in response to selection of RPS frequencies. For real systems, we do have to be concerned with the impact of integrating c-states, p-states and rp-states, but for the sake of proving whether or not RPS works, one baby step at a time. For the record, as one would hope, it does not seem to impact on the measured performance, but we do it anyway to reduce the number of variables. Later, we can extend the testing to encourage the the cpu/pkg to try and sleep while the GPU is busy. Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-21drm/i915/selftests: Show the full scaling curve on failureChris Wilson1-0/+40
If we detect that the RPS end points do not scale perfectly, take the time to measure all the in between values as well. We are aborting the test, so we might as well spend the available time gathering critical debug information instead. Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-21drm/i915/selftests: Show the pstate limits on any failure to reset minChris Wilson1-0/+2
We want to see the pstate limits whenever we fail to set the minimum frequency as that may help for debugging. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-20drm/i915/selftests: Exercise dynamic reclocking with RPSChris Wilson1-10/+102
After having testing all the RPS controls individually, we need to take a step back and check how our RPS worker integrates them to perform dynamic GPU reclocking. So do that by submitting a spinner and wait and see what happens. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-20drm/i915/selftests: Show the pcode frequency table on errorChris Wilson1-0/+39
If we encounter an error while scaling, read back the frequency tables from the pcu. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-20drm/i915/selftests: Split RPS frequency measurementChris Wilson1-7/+150
Split the frequency measurement into two modes, so that we can judge the impact of the llc setup on top of the pure CS frequency scaling. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-20drm/i915/selftests: Check RPS controlsChris Wilson1-24/+188
Check that the GPU does respond to our RPS frequency requests by setting our desired frequency. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-20drm/i915/selftests: Skip energy consumption tests if not controlling freqChris Wilson1-14/+23
If we can not manipulate the frequency with RPS, then comparing min/max power consumption is pointless / misleading. We will leave the warning about not being able to control the frequency selection via RPS to other tests so as not to confuse this more specialised check. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-20drm/i915/selftests: Verify frequency scaling with RPSChris Wilson1-12/+237
One of the core tenents of reclocking the GPU is that its throughput scales with the clock frequency. We can observe this by incrementing a loop counter on the GPU, and compare the different execution rates at the notional RPS frequencies. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-17drm/i915/selftests: Check power consumption at min/max frequenciesChris Wilson1-0/+138
A basic premise of RPS is that at lower frequencies, not only do we run slower, but we save power compared to higher frequencies. For example, when idle, we set the minimum frequency just in case there is some residual current. Since the power curve should be a physical relationship, if we find no power saving it's likely that we've broken our frequency handling, so test! Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Andi Shyti <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-17drm/i915/selftests: Take the engine wakeref around __rps_up_interruptChris Wilson1-5/+11
Since we are touching the device to read the registers, we are required to ensure the device is awake at the time. Currently, we believe ourselves to be inside the active request [thus an active engine wakeref], but since that may be retired in the background, we can spontaneously lose the wakeref and the ability to probe the HW. <4> [379.686703] RPM wakelock ref not held during HW access <4> [379.686805] WARNING: CPU: 7 PID: 4869 at ./drivers/gpu/drm/i915/intel_runtime_pm.h:115 gen12_fwtable_read32+0x233/0x300 [i915] <4> [379.686808] Modules linked in: i915(+) vgem snd_hda_codec_hdmi mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ax88179_178a usbnet mii ghash_clmulni_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm e1000e mei_me ptp mei pps_core intel_lpss_pci prime_numbers [last unloaded: i915] <4> [379.686827] CPU: 7 PID: 4869 Comm: i915_selftest Tainted: G U 5.7.0-rc1-CI-CI_DRM_8313+ #1 <4> [379.686830] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2457.A13.1912190237 12/19/2019 <4> [379.686883] RIP: 0010:gen12_fwtable_read32+0x233/0x300 [i915] <4> [379.686887] Code: d8 ea e0 0f 0b e9 19 fe ff ff 80 3d ad 12 2d 00 00 0f 85 17 fe ff ff 48 c7 c7 b0 32 3e a0 c6 05 99 12 2d 00 01 e8 2d d8 ea e0 <0f> 0b e9 fd fd ff ff 8b 05 c4 75 56 e2 85 c0 0f 85 84 00 00 00 48 <4> [379.686889] RSP: 0018:ffffc90000727970 EFLAGS: 00010286 <4> [379.686892] RAX: 0000000000000000 RBX: ffff88848cc20ee8 RCX: 0000000000000001 <4> [379.686894] RDX: 0000000080000001 RSI: ffff88843b1f0900 RDI: 00000000ffffffff <4> [379.686896] RBP: 0000000000000000 R08: ffff88843b1f0900 R09: 0000000000000000 <4> [379.686898] R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000a058 <4> [379.686900] R13: 0000000000000001 R14: ffff88848cc2bf30 R15: 00000000ffffffea <4> [379.686902] FS: 00007f7d63f5e300(0000) GS:ffff8884a0180000(0000) knlGS:0000000000000000 <4> [379.686904] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [379.686907] CR2: 000055e5c30f4988 CR3: 000000042e190002 CR4: 0000000000760ee0 <4> [379.686910] PKRU: 55555554 <4> [379.686911] Call Trace: <4> [379.686986] live_rps_interrupt+0xb14/0xc10 [i915] <4> [379.687051] ? intel_rps_unpark+0xb0/0xb0 [i915] <4> [379.687057] ? __trace_bprintk+0x57/0x80 <4> [379.687143] __i915_subtests+0xb8/0x210 [i915] <4> [379.687222] ? __i915_live_teardown+0x50/0x50 [i915] <4> [379.687291] ? __intel_gt_live_setup+0x30/0x30 [i915] <4> [379.687361] __run_selftests+0x112/0x170 [i915] <4> [379.687431] i915_live_selftests+0x2c/0x60 [i915] <4> [379.687491] i915_pci_probe+0x93/0x1b0 [i915] Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-17drm/i915/selftests: Delay spinner before waiting for an interruptChris Wilson1-12/+16
It seems that although (perhaps because of the memory stall?) the spinner has signaled that it has started, it still takes some time to spin up to 100% utilisation of the HW. Since the test depends on the full utilisation of the HW to trigger the RPS interrupt, wait a little bit and flush the interrupt status to be sure that the event we see if from the spinner. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-16drm/i915/selftests: Exercise basic RPS interrupt generationChris Wilson1-0/+223
Since we depend upon RPS generating interrupts after evaluation intervals to determine when to up/down clock the GPU, it is imperative that we successfully enable interrupt generation! Verify that we do see an interrupt if we keep the GPU busy for an entire EI. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.