[Intel-gfx] ✓ Fi.CI.IGT: success for Polish DRAM information readout code (rev5)
== Series Details == Series: Polish DRAM information readout code (rev5) URL : https://patchwork.freedesktop.org/series/57213/ State : success == Summary == CI Bug Log - changes from CI_DRM_5663_full -> Patchwork_12312_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12312_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_workarounds@suspend-resume: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_busy@basic-modeset-d: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-glk: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_color@pipe-b-ctm-max: - shard-apl: PASS -> FAIL [fdo#108147] * igt@kms_cursor_crc@cursor-256x256-random: - shard-apl: PASS -> FAIL [fdo#103232] +1 * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: PASS -> FAIL [fdo#102887] / [fdo#105363] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-apl: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu: - shard-apl: NOTRUN -> SKIP [fdo#109271] +1 * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-wc: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +44 * igt@kms_plane@plane-position-covered-pipe-c-planes: - shard-glk: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_setmode@basic: - shard-kbl: PASS -> FAIL [fdo#99912] * igt@kms_vblank@pipe-c-ts-continuation-modeset-hang: - shard-apl: PASS -> INCOMPLETE [fdo#103927] Possible fixes * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: SKIP [fdo#109271] -> PASS * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-hsw: DMESG-WARN [fdo#107956] -> PASS * igt@kms_color@pipe-c-ctm-red-to-blue: - shard-skl: FAIL [fdo#107201] -> PASS * igt@kms_cursor_crc@cursor-256x256-dpms: - shard-apl: FAIL [fdo#103232] -> PASS * igt@kms_cursor_crc@cursor-64x64-onscreen: - shard-skl: FAIL [fdo#103232] -> PASS * igt@kms_flip_tiling@flip-changes-tiling-yf: - shard-skl: FAIL [fdo#108228] / [fdo#108303] -> PASS * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: FAIL [fdo#107815] -> PASS * igt@kms_plane_multiple@atomic-pipe-b-tiling-none: - shard-glk: FAIL [fdo#103166] -> PASS * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: - shard-apl: FAIL [fdo#103166] -> PASS +3 * igt@kms_setmode@basic: - shard-hsw: FAIL [fdo#99912] -> PASS [fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887 [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108 [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363 [fdo#107201]: https://bugs.freedesktop.org/show_bug.cgi?id=107201 [fdo#107773]: https://bugs.freedesktop.org/show_bug.cgi?id=107773 [fdo#107815]: https://bugs.freedesktop.org/show_bug.cgi?id=107815 [fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956 [fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147 [fdo#108228]: https://bugs.freedesktop.org/show_bug.cgi?id=108228 [fdo#108303]: https://bugs.freedesktop.org/show_bug.cgi?id=108303 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912 Participating hosts (6 -> 6) -- No changes in participating hosts Build changes - * Linux: CI_DRM_5663 -> Patchwork_12312 CI_DRM_5663: b3edf5fc71aad143ed214a72901a2c75da5535d2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4859: 1d8f3320cbc06fa73ad1487453a63993f17b9d57 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12312: 72c9e18ef286c47016fe0f17dd9e32ff709a5b6c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12312/
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
> > At the end of the day, I don't really care that much. I get it, we > > all have large projects with scarce resources. I just think a few > > years down the road we'll all regret it as a community. > > AMD and others have also spent years tuning TTM for both UMA and VRAM, > but especially VRAM. It comes across a bit daft to complain about the > effort to move to TTM, but say nothing about the effort to tune GEM > for optimal VRAM performance. Effort that has already been expended > that you could take advantage of. I'm with Alex here, the patches you have now are just the start, I realise you think they are all you'll need, but I expect once Chris gets going with real VRAM hardware he'll generate reams for stuff. People have been tuning and making TTM run on VRAM using GPUs for longer than you've been making VRAM using GPUs, there had better be good and well thought out reasons for avoiding using it, and so far you haven't made that argument to me all. In fact your scheduler arguments works against you. If we should have abstracted i915 scheduler out and used it because it had more features and pre-existed, then i915 should be using TTM since it's already abstracted out and has more features. Like we've pulled other stuff out of TTM like reservation objects, I don't think i915 uses those yet either when it clearly could be. Maybe if we started by fixing that, moving to TTM would be less of a problem. Anyways, I expect moving to TTM is a big change for i915, and probably more than you are able to bite off at present, but I'm going to be watching closely what stuff you add on top of this sort of thing, and if it starts getting large and messier as you tune it, I'll have to start reconsidering how big a NO I have to use. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/mei-hdcp for char-misc-next
Hi Greg topic/mei-hdcp-2019-02-26: mei-hdcp driver mei driver for the me hdcp client, for use by drm/i915. Including the following prep work: - whitelist hdcp client in mei bus - merge to include char-misc-next because of another mei bus prep patch to export a helper macro to drivers - drm/i915 side of the mei_hdcp/i915 component interface (already pulled into drm-intel for 5.2 as a topic branch) - component prep work (including one patch touching i915), already pulled by you into drivers-base-next for 5.1 mei-hdcp patches all reviewed and acked by Tomas Winkler. All other bits and pieces acked by relevant subsystem people. Took a bit longer than planned, but so does the 5.0 release. Up to you whether you still want to pull for 5.1 merge window or delay for 5.2, either totally fine for us. The drm/i915 of this will only land in 5.2 completely. Cheers, Daniel Note: diffstat below generated against Linus' tree. Which is wrong, but since this both contains drivers-base-next, char-misc-next and stuff queued for drm-i915 (but which isn't in linux-next yet because that's aimed for 5.2) it's a bit a mess. Given that shrugged and just went with this. I can regenerate some other diffstat if you want something else, just didn't know what's really the right thing here. The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9: Linux 5.0-rc6 (2019-02-10 14:42:20 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/topic/mei-hdcp-2019-02-26 for you to fetch changes up to fa301ad9fa8f6f738b9c22da3ede7824e3286693: misc/mei/hdcp: Component framework for I915 Interface (2019-02-25 17:03:01 +0100) mei-hdcp driver mei driver for the me hdcp client, for use by drm/i915. Including the following prep work: - whitelist hdcp client in mei bus - merge to include char-misc-next - drm/i915 side of the mei_hdcp/i915 component interface - component prep work (including one patch touching i915) Aditya Pakki (1): misc/ics932s401: Add a missing check to i2c_smbus_read_word_data Alan Tull (1): fpga: altera_freeze_bridge: remove restriction to socfpga Alban Bedel (7): nvmem: core: Set the provider read-only when no write callback is given nvmem: core: Fix of_nvmem_cell_get() for optional cells nvmem: core: Fix cell lookup when no cell is found nvmem: core: Properly handle connection ID in of_nvmem_device_get() nvmem: core: Always reference the device returned by nvmem_device_get() nvmem: core: Fix device reference leak nvmem: core: Avoid useless iterations in nvmem_cell_get_from_lookup() Alexander Kapshuk (1): ver_linux: Assign constant RE to variable name for clarity Alexander Usyskin (1): mei: squash single_recv_buf into one bit in client properties Anson Huang (2): dt-bindings: nvmem: imx-ocotp: add compatible string for i.MX7ULP nvmem: imx-ocotp: add i.MX7ULP support Buland Singh (1): hpet: Fix missing '=' character in the __setup() code of hpet_mmap_enable Chengguang Xu (2): uio: fix potential memory leak in error case uio: remove redundant check Christophe Leroy (2): lkdtm: Print real addresses lkdtm: Add tests for NULL pointer dereference Colin Ian King (2): drivers: misc: ad525x_dpot: clean indentation issue, remove tabs fpga: mgr: altera-ps-spi: make array dummy static, shrinks object size Daniel Vetter (4): component: Add documentation components: multiple components for a device i915/snd_hdac: I915 subcomponent for the snd_hdac Pull in char-misc-next from Greg David Dai (2): interconnect: qcom: Add sdm845 interconnect provider driver arm64: dts: sdm845: Add interconnect provider DT nodes Finn Thain (22): scsi/atari_scsi: Don't select CONFIG_NVRAM m68k/atari: Move Atari-specific code out of drivers/char/nvram.c char/nvram: Re-order functions to remove forward declarations and #ifdefs nvram: Replace nvram_* function exports with static functions m68k/atari: Implement arch_nvram_ops struct powerpc: Replace nvram_* extern declarations with standard header char/nvram: Adopt arch_nvram_ops char/nvram: Allow the set_checksum and initialize ioctls to be omitted char/nvram: Implement NVRAM read/write methods m68k/atari: Implement arch_nvram_ops methods and enable CONFIG_HAVE_ARCH_NVRAM_OPS m68k/mac: Adopt naming and calling conventions for PRAM routines m68k/mac: Use macros for RTC accesses not magic numbers m68k/mac: Fix PRAM accessors macintosh/via-cuda: Don't rely on Cuda to end a transfer m68k: Dispatch nvram_ops calls to Atari or Mac functions char/nvram: Add "devname:nvram" module alias powerpc: Define missing ppc_md.nvram_size for CHRP and PowerMac
Re: [Intel-gfx] [PATCH 02/46] drm/i915: Revoke mmaps and prevent access to fence registers across reset
Quoting Rodrigo Vivi (2019-02-26 19:53:47)
> On Wed, Feb 06, 2019 at 01:03:12PM +, Chris Wilson wrote:
> > Previously, we were able to rely on the recursive properties of
> > struct_mutex to allow us to serialise revoking mmaps and reacquiring the
> > FENCE registers with them being clobbered over a global device reset.
> > I then proceeded to throw out the baby with the bath water in order to
> > pursue a struct_mutex-less reset.
> >
> > Perusing LWN for alternative strategies, the dilemma on how to serialise
> > access to a global resource on one side was answered by
> > https://lwn.net/Articles/202847/ -- Sleepable RCU:
> >
> > 1 int readside(void) {
> > 2 int idx;
> > 3 rcu_read_lock();
> > 4if (nomoresrcu) {
> > 5 rcu_read_unlock();
> > 6return -EINVAL;
> > 7 }
> > 8idx = srcu_read_lock();
> > 9rcu_read_unlock();
> > 10 /* SRCU read-side critical section. */
> > 11 srcu_read_unlock(, idx);
> > 12 return 0;
> > 13 }
> > 14
> > 15 void cleanup(void)
> > 16 {
> > 17 nomoresrcu = 1;
> > 18 synchronize_rcu();
> > 19 synchronize_srcu();
> > 20 cleanup_srcu_struct();
> > 21 }
> >
> > No more worrying about stop_machine, just an uber-complex mutex,
> > optimised for reads, with the overhead pushed to the rare reset path.
> >
> > However, we do run the risk of a deadlock as we allocate underneath the
> > SRCU read lock, and the allocation may require a GPU reset, causing a
> > dependency cycle via the in-flight requests. We resolve that by declaring
> > the driver wedged and cancelling all in-flight rendering.
> >
> > v2: Use expedited rcu barriers to match our earlier timing
> > characteristics.
> > v3: Try to annotate locking contexts for sparse
> > v4: Reduce selftest lock duration to avoid a reset deadlock with fences
> > v5: s/srcu/reset_backoff_srcu/
> >
> > Testcase: igt/gem_mmap_gtt/hang
> > Fixes: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on
> > struct_mutex")
>
> Hi Chris,
>
> this patch didn't applied cleanly on dinf
> so I noticed that I could also get
>
> 115ff80a97cf ("drm/i915: Defer removing fence register tracking to rpm
> wakeup")
>
> so that applies, but then I noticed that there's a Fixes of
> this patch here:
>
> de3a87cf6352 ("drm/i915: Recursive i915_reset_trylock() verboten")
>
> It seems sane to pick 3 of them, but I'd like to confirm with you first.
>
> Thoughts?
There's a at least one later patch as well. I think the safest course of
option is to ignore these fixups, as the glitch is very rare (after a
gpu hang as well), only temporary and does not impact stability or security
(they can only see their own buffers/data in a slightly different order).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/46] drm/i915: Revoke mmaps and prevent access to fence registers across reset
On Wed, Feb 06, 2019 at 01:03:12PM +, Chris Wilson wrote:
> Previously, we were able to rely on the recursive properties of
> struct_mutex to allow us to serialise revoking mmaps and reacquiring the
> FENCE registers with them being clobbered over a global device reset.
> I then proceeded to throw out the baby with the bath water in order to
> pursue a struct_mutex-less reset.
>
> Perusing LWN for alternative strategies, the dilemma on how to serialise
> access to a global resource on one side was answered by
> https://lwn.net/Articles/202847/ -- Sleepable RCU:
>
> 1 int readside(void) {
> 2 int idx;
> 3 rcu_read_lock();
> 4if (nomoresrcu) {
> 5 rcu_read_unlock();
> 6return -EINVAL;
> 7 }
> 8idx = srcu_read_lock();
> 9rcu_read_unlock();
> 10 /* SRCU read-side critical section. */
> 11 srcu_read_unlock(, idx);
> 12 return 0;
> 13 }
> 14
> 15 void cleanup(void)
> 16 {
> 17 nomoresrcu = 1;
> 18 synchronize_rcu();
> 19 synchronize_srcu();
> 20 cleanup_srcu_struct();
> 21 }
>
> No more worrying about stop_machine, just an uber-complex mutex,
> optimised for reads, with the overhead pushed to the rare reset path.
>
> However, we do run the risk of a deadlock as we allocate underneath the
> SRCU read lock, and the allocation may require a GPU reset, causing a
> dependency cycle via the in-flight requests. We resolve that by declaring
> the driver wedged and cancelling all in-flight rendering.
>
> v2: Use expedited rcu barriers to match our earlier timing
> characteristics.
> v3: Try to annotate locking contexts for sparse
> v4: Reduce selftest lock duration to avoid a reset deadlock with fences
> v5: s/srcu/reset_backoff_srcu/
>
> Testcase: igt/gem_mmap_gtt/hang
> Fixes: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex")
Hi Chris,
this patch didn't applied cleanly on dinf
so I noticed that I could also get
115ff80a97cf ("drm/i915: Defer removing fence register tracking to rpm wakeup")
so that applies, but then I noticed that there's a Fixes of
this patch here:
de3a87cf6352 ("drm/i915: Recursive i915_reset_trylock() verboten")
It seems sane to pick 3 of them, but I'd like to confirm with you first.
Thoughts?
Thanks in advance,
Rodrigo.
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 12 +-
> drivers/gpu/drm/i915/i915_drv.h | 18 +--
> drivers/gpu/drm/i915/i915_gem.c | 56 +++--
> drivers/gpu/drm/i915/i915_gem_fence_reg.c | 31 +
> drivers/gpu/drm/i915/i915_gpu_error.h | 12 +-
> drivers/gpu/drm/i915/i915_reset.c | 109 +++---
> drivers/gpu/drm/i915/i915_reset.h | 4 +
> .../gpu/drm/i915/selftests/intel_hangcheck.c | 5 +-
> .../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
> 9 files changed, 109 insertions(+), 139 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 0bd890c04fe4..a6fd157b1637 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1281,14 +1281,11 @@ static int i915_hangcheck_info(struct seq_file *m,
> void *unused)
> intel_wakeref_t wakeref;
> enum intel_engine_id id;
>
> + seq_printf(m, "Reset flags: %lx\n", dev_priv->gpu_error.flags);
> if (test_bit(I915_WEDGED, _priv->gpu_error.flags))
> - seq_puts(m, "Wedged\n");
> + seq_puts(m, "\tWedged\n");
> if (test_bit(I915_RESET_BACKOFF, _priv->gpu_error.flags))
> - seq_puts(m, "Reset in progress: struct_mutex backoff\n");
> - if (waitqueue_active(_priv->gpu_error.wait_queue))
> - seq_puts(m, "Waiter holding struct mutex\n");
> - if (waitqueue_active(_priv->gpu_error.reset_queue))
> - seq_puts(m, "struct_mutex blocked for reset\n");
> + seq_puts(m, "\tDevice (global) reset in progress\n");
>
> if (!i915_modparams.enable_hangcheck) {
> seq_puts(m, "Hangcheck disabled\n");
> @@ -3885,9 +3882,6 @@ i915_wedged_set(void *data, u64 val)
>* while it is writing to 'i915_wedged'
>*/
>
> - if (i915_reset_backoff(>gpu_error))
> - return -EAGAIN;
> -
> i915_handle_error(i915, val, I915_ERROR_CAPTURE,
> "Manually set wedged engine mask = %llx", val);
> return 0;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a2293152cb6a..37230ae7fbe6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2989,7 +2989,12 @@ i915_gem_obj_finish_shmem_access(struct
> drm_i915_gem_object *obj)
> i915_gem_object_unpin_pages(obj);
> }
>
> -int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
> +static
[Intel-gfx] ✓ Fi.CI.BAT: success for Polish DRAM information readout code (rev5)
== Series Details ==
Series: Polish DRAM information readout code (rev5)
URL : https://patchwork.freedesktop.org/series/57213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5663 -> Patchwork_12312
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/57213/revisions/5/
Known issues
Here are the changes found in Patchwork_12312 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: PASS -> SKIP [fdo#109271] / [fdo#109278] +2
* igt@kms_busy@basic-flip-c:
- fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
- fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +48
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@i915_pm_rpm@module-reload:
- {fi-icl-y}: INCOMPLETE [fdo#108840] -> PASS
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: WARN [fdo#109380] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: SKIP [fdo#109271] -> PASS +33
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
Participating hosts (44 -> 37)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan
fi-byt-n2820 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5663 -> Patchwork_12312
CI_DRM_5663: b3edf5fc71aad143ed214a72901a2c75da5535d2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4859: 1d8f3320cbc06fa73ad1487453a63993f17b9d57 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12312: 72c9e18ef286c47016fe0f17dd9e32ff709a5b6c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
72c9e18ef286 drm/i915: Read out memory type
3b0ad2d82a0c drm/i915: Extract DIMM info on cnl+
20981e507547 drm/i915: Clean up intel_get_dram_info() a bit
c3619070b3e2 drm/i914: s/l_info/dimm_l/ etc.
ddb21bce2745 drm/i915: Generalize intel_is_dram_symmetric()
fb64928b7757 drm/i915: Use dram_dimm_info more
1b42808bab0c drm/i915: Extract DIMM info on GLK too
26478c23b10c drm/i915: Fix DRAM size reporting for BXT
09497aef64c1 drm/i915: Extract BXT DIMM helpers
7037185e1bfe drm/i915: Polish skl_is_16gb_dimm()
00c9d4441d97 drm/i915: Extract functions to derive SKL+ DIMM info
011c8a3291c3 drm/i915: Store DIMM rank information as a number
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12312/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: remove unused bits from Panel Power Sequence State
On Tue, Feb 26, 2019 at 12:10:29PM +0200, Jani Nikula wrote:
On Mon, 25 Feb 2019, Lucas De Marchi wrote:
On Mon, Feb 25, 2019 at 09:28:06PM +0200, Ville Syrjälä wrote:
On Fri, Feb 22, 2019 at 04:34:48PM -0800, Lucas De Marchi wrote:
No change in behavior. Just removing the unused bits since it makes it
easier to compare them on new platforms and one of them was wrong
(PP_SEQUENCE_STATE_ON_S1_0 vs the supposedly correct name
PP_SEQUENCE_STATE_ON_S1_1)
Cc: Rodrigo Vivi
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_reg.h | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 730bb1917fd1..e855dae978db 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4717,15 +4717,9 @@ enum {
#define PP_SEQUENCE_SHIFT28
#define PP_CYCLE_DELAY_ACTIVE(1 << 27)
#define PP_SEQUENCE_STATE_MASK 0x000f
-#define PP_SEQUENCE_STATE_OFF_IDLE (0x0 << 0)
-#define PP_SEQUENCE_STATE_OFF_S0_1 (0x1 << 0)
-#define PP_SEQUENCE_STATE_OFF_S0_2 (0x2 << 0)
-#define PP_SEQUENCE_STATE_OFF_S0_3 (0x3 << 0)
-#define PP_SEQUENCE_STATE_ON_IDLE(0x8 << 0)
-#define PP_SEQUENCE_STATE_ON_S1_0(0x9 << 0)
-#define PP_SEQUENCE_STATE_ON_S1_2(0xa << 0)
-#define PP_SEQUENCE_STATE_ON_S1_3(0xb << 0)
-#define PP_SEQUENCE_STATE_RESET (0xf << 0)
+#define PP_SEQUENCE_STATE_OFF_IDLE 0x0
+#define PP_SEQUENCE_STATE_ON_IDLE0x8
+#define PP_SEQUENCE_STATE_RESET 0xf
But how am I supposed to remember what the register values mean?
We only care for a small subset of those and the name should already be
enough, no? We don't need to bring in all the possible bits from spec,
even worse when they are misnamed. If we keep defining what we don't use
it actually makes our life harder to crosscheck with the spec if
everything is correct. Makes sense?
Dunno, my guideline has always been to add macros for the entire
register contents if you're adding anything.
Ok. I disagree because it's a pain when unrelated bits change in the
spec and we have to check if we need to do anything.
But it seems I'm alone here, so I will withdraw this patch and replace
it with the typo fix.
Lucas De Marchi
BR,
Jani.
Lucas De Marchi
#define _PP_CONTROL0x61204
#define PP_CONTROL(pps_idx)_MMIO_PPS(pps_idx, _PP_CONTROL)
--
2.20.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Polish DRAM information readout code (rev5)
== Series Details == Series: Polish DRAM information readout code (rev5) URL : https://patchwork.freedesktop.org/series/57213/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Store DIMM rank information as a number -O:drivers/gpu/drm/i915/i915_drv.c:1192:35: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_drv.c:1192:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1187:36: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1187:36: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3581:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3576:16: warning: expression using sizeof(void) Commit: drm/i915: Extract functions to derive SKL+ DIMM info Okay! Commit: drm/i915: Polish skl_is_16gb_dimm() -drivers/gpu/drm/i915/selftests/../i915_drv.h:3576:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3578:16: warning: expression using sizeof(void) Commit: drm/i915: Extract BXT DIMM helpers Okay! Commit: drm/i915: Fix DRAM size reporting for BXT Okay! Commit: drm/i915: Extract DIMM info on GLK too Okay! Commit: drm/i915: Use dram_dimm_info more Okay! Commit: drm/i915: Generalize intel_is_dram_symmetric() Okay! Commit: drm/i914: s/l_info/dimm_l/ etc. Okay! Commit: drm/i915: Clean up intel_get_dram_info() a bit Okay! Commit: drm/i915: Extract DIMM info on cnl+ Okay! Commit: drm/i915: Read out memory type -drivers/gpu/drm/i915/selftests/../i915_drv.h:3578:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3585:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/icl: move MG pll hw_state readout
On Tue, Feb 26, 2019 at 04:21:01PM +0200, Ville Syrjälä wrote:
On Mon, Feb 25, 2019 at 04:03:05PM -0800, Lucas De Marchi wrote:
On Mon, Feb 25, 2019 at 10:42:12PM +0200, Ville Syrjälä wrote:
>On Fri, Feb 22, 2019 at 03:23:22PM -0800, Lucas De Marchi wrote:
>> Let the MG plls have their own hooks since it shares very little with
>> other PLL types. It's also better so the platform info contains the info
>> if the PLL is for MG PHY rather than relying on the PLL ids.
>>
>> Signed-off-by: Lucas De Marchi
>
>There's quite a bit more cleanup to be done in this area. As a start
>https://patchwork.freedesktop.org/series/56354/ ;)
I started reviewing that and even gave my r-b in some patches - first
patches cause several conflicts with in-flight patches though. Not sure
how beneficial they are.
The current code is quite messy, and thus hard to follow.
It should be cleaned up before we pile even more stuff on top.
People had already cargo culted all the crud from the older
implementations to the later ones.
We can't let the dirt accumulate indefinitely because eventually
the point comes where the thing either collapses under its own weight
or someone just decides to not even look at the previous code and
does the new thing totally differently. And that approach does not
scale because then everyone has to keep in mind N different ways
of doing the exact same thing. And also all the learnings from the
old code are forgotten and we probably get more bugs as a result.
I agree with all of that. I'm talking about those particular changes and
the timing with the pending work going upstream, not generically.
IMO last 3 patches could be standalone
(particularly the one that is a bug fix, and doesn't depend on the
previous ones)
Nothing prevents the patches from being reviewed/merged out of order.
CI running on them and they taking more time to be merged waiting for
the other patches to be reviewed.
Lucas De Marchi
>This patch looks good to me. It'll conflict with my series though, but
>no biggie.
>Reviewed-by: Ville Syrjälä
thanks
Lucas De Marchi
>
>> ---
>> drivers/gpu/drm/i915/intel_dpll_mgr.c | 122 --
>> 1 file changed, 74 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> index 0a42d11c4c33..e4ec73d415d9 100644
>> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
>> @@ -2966,6 +2966,68 @@ static i915_reg_t icl_pll_id_to_enable_reg(enum
intel_dpll_id id)
>>return MG_PLL_ENABLE(icl_pll_id_to_tc_port(id));
>> }
>>
>> +static bool mg_pll_get_hw_state(struct drm_i915_private *dev_priv,
>> + struct intel_shared_dpll *pll,
>> + struct intel_dpll_hw_state *hw_state)
>> +{
>> + const enum intel_dpll_id id = pll->info->id;
>> + enum tc_port tc_port = icl_pll_id_to_tc_port(id);
>> + intel_wakeref_t wakeref;
>> + bool ret = false;
>> + u32 val;
>> +
>> + wakeref = intel_display_power_get_if_enabled(dev_priv,
>> + POWER_DOMAIN_PLLS);
>> + if (!wakeref)
>> + return false;
>> +
>> + val = I915_READ(MG_PLL_ENABLE(tc_port));
>> + if (!(val & PLL_ENABLE))
>> + goto out;
>> +
>> + hw_state->mg_refclkin_ctl = I915_READ(MG_REFCLKIN_CTL(tc_port));
>> + hw_state->mg_refclkin_ctl &= MG_REFCLKIN_CTL_OD_2_MUX_MASK;
>> +
>> + hw_state->mg_clktop2_coreclkctl1 =
>> + I915_READ(MG_CLKTOP2_CORECLKCTL1(tc_port));
>> + hw_state->mg_clktop2_coreclkctl1 &=
>> + MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK;
>> +
>> + hw_state->mg_clktop2_hsclkctl =
>> + I915_READ(MG_CLKTOP2_HSCLKCTL(tc_port));
>> + hw_state->mg_clktop2_hsclkctl &=
>> + MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL_MASK |
>> + MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL_MASK |
>> + MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK |
>> + MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK;
>> +
>> + hw_state->mg_pll_div0 = I915_READ(MG_PLL_DIV0(tc_port));
>> + hw_state->mg_pll_div1 = I915_READ(MG_PLL_DIV1(tc_port));
>> + hw_state->mg_pll_lf = I915_READ(MG_PLL_LF(tc_port));
>> + hw_state->mg_pll_frac_lock = I915_READ(MG_PLL_FRAC_LOCK(tc_port));
>> + hw_state->mg_pll_ssc = I915_READ(MG_PLL_SSC(tc_port));
>> +
>> + hw_state->mg_pll_bias = I915_READ(MG_PLL_BIAS(tc_port));
>> + hw_state->mg_pll_tdc_coldst_bias =
>> + I915_READ(MG_PLL_TDC_COLDST_BIAS(tc_port));
>> +
>> + if (dev_priv->cdclk.hw.ref == 38400) {
>> + hw_state->mg_pll_tdc_coldst_bias_mask =
MG_PLL_TDC_COLDST_COLDSTART;
>> + hw_state->mg_pll_bias_mask = 0;
>> + } else {
>> + hw_state->mg_pll_tdc_coldst_bias_mask = -1U;
>> + hw_state->mg_pll_bias_mask = -1U;
>> + }
>> +
>> +
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
On Tue, Feb 26, 2019 at 12:20 PM Alex Deucher wrote: > > On Tue, Feb 26, 2019 at 7:17 AM Joonas Lahtinen > wrote: > > > > Quoting Alex Deucher (2019-02-25 21:31:43) > > > On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen > > > wrote: > > > > > > > > Quoting Dave Airlie (2019-02-25 12:24:48) > > > > > On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen > > > > > wrote: > > > > > > > > > > > > + dri-devel mailing list, especially for the buddy allocator part > > > > > > > > > > > > Quoting Dave Airlie (2019-02-15 02:47:07) > > > > > > > On Fri, 15 Feb 2019 at 00:57, Matthew Auld > > > > > > > wrote: > > > > > > > > > > > > > > > > In preparation for upcoming devices with device local memory, > > > > > > > > introduce the > > > > > > > > concept of different memory regions, and a simple buddy > > > > > > > > allocator to manage > > > > > > > > them. > > > > > > > > > > > > > > This is missing the information on why it's not TTM. > > > > > > > > > > > > > > Nothing against extending i915 gem off into doing stuff we already > > > > > > > have examples off in tree, but before you do that it would be > > > > > > > good to > > > > > > > have a why we can't use TTM discussion in public. > > > > > > > > > > > > Glad that you asked. It's my fault that it was not included in > > > > > > the cover letter. I anticipated the question, but was travelling > > > > > > for a couple of days at the time this was sent. I didn't want > > > > > > to write a hasty explanation and then disappear, leaving others to > > > > > > take the heat. > > > > > > > > > > > > So here goes the less-hasty version: > > > > > > > > > > > > We did an analysis on the effort needed vs benefit gained of using > > > > > > TTM when this was started initially. The conclusion was that we > > > > > > already share the interesting bits of code through core DRM, really. > > > > > > > > > > > > Re-writing the memory handling to TTM would buy us more fine-grained > > > > > > locking. But it's more a trait of rewriting the memory handling with > > > > > > the information we have learned, than rewriting it to use TTM :) > > > > > > > > > > > > And further, we've been getting rid of struct_mutex at a steady > > > > > > phase > > > > > > in the past years, so we have a clear path to the fine-grained > > > > > > locking > > > > > > already in the not-so-distant future. With all this we did not see > > > > > > much gained from converting over, as the code sharing is already > > > > > > substantial. > > > > > > > > > > > > We also wanted to have the buddy allocator instead of a for loop > > > > > > making > > > > > > drm_mm allocations to make sure we can keep the memory fragmentation > > > > > > at bay. The intent is to move the buddy allocator to core DRM, to > > > > > > the > > > > > > benefit of all the drivers, if there is interest from community. It > > > > > > has > > > > > > been written as a strictly separate component with that in mind. > > > > > > > > > > > > And if you take the buddy allocator out of the patch set, the rest > > > > > > is > > > > > > mostly just vfuncing things up to be able to have different backing > > > > > > storages for objects. We took the opportunity to move over to the > > > > > > more > > > > > > valgrind friendly mmap while touching things, but it's something we > > > > > > have been contemplating anyway. And yeah, loads of selftests. > > > > > > > > > > > > That's really all that needed adding, and most of it is internal to > > > > > > i915 and not to do with uAPI. This means porting over an userspace > > > > > > driver doesn't require a substantial rewrite, but adding new a few > > > > > > new IOCTLs to set the preferred backing storage placements. > > > > > > > > > > > > All the previous GEM abstractions keep applying, so we did not see > > > > > > a justification to rewrite the kernel driver and userspace drivers. > > > > > > It would have just to made things look like TTM, when we already > > > > > > have the important parts of the code shared with TTM drivers > > > > > > behind the GEM interfaces which all our drivers sit on top of. > > > > > > > > > > a) you guys should be the community as well, if the buddy allocator is > > > > > useful in the core DRM get out there and try and see if anyone else > > > > > has a use case for it, like the GPU scheduler we have now (can i915 > > > > > use that yet? :-) > > > > > > > > Well, the buddy allocator should be useful for anybody wishing to have > > > > as continuous physical allocations as possible. I have naively assumed > > > > that would be almost everyone. So it would be only a question if others > > > > see the amount of work required to convert over is justified for them. > > > > > > > > For the common DRM scheduler, I think a solid move from the beginning > > > > would have been to factor out the i915 scheduler as it was most advanced > > > > in features :) Now there is a way more trivial common scheduler core > > > > with > > > > no easy path to transition
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Polish DRAM information readout code (rev5)
== Series Details == Series: Polish DRAM information readout code (rev5) URL : https://patchwork.freedesktop.org/series/57213/ State : warning == Summary == $ dim checkpatch origin/drm-tip 011c8a3291c3 drm/i915: Store DIMM rank information as a number 00c9d4441d97 drm/i915: Extract functions to derive SKL+ DIMM info 7037185e1bfe drm/i915: Polish skl_is_16gb_dimm() 09497aef64c1 drm/i915: Extract BXT DIMM helpers 26478c23b10c drm/i915: Fix DRAM size reporting for BXT 1b42808bab0c drm/i915: Extract DIMM info on GLK too fb64928b7757 drm/i915: Use dram_dimm_info more ddb21bce2745 drm/i915: Generalize intel_is_dram_symmetric() c3619070b3e2 drm/i914: s/l_info/dimm_l/ etc. 20981e507547 drm/i915: Clean up intel_get_dram_info() a bit 3b0ad2d82a0c drm/i915: Extract DIMM info on cnl+ 72c9e18ef286 drm/i915: Read out memory type -:25: ERROR:BRACKET_SPACE: space prohibited before open square bracket '[' #25: FILE: drivers/gpu/drm/i915/i915_drv.c:1071: +#define DRAM_TYPE_STR(type) [INTEL_DRAM_ ## type] = #type total: 1 errors, 0 warnings, 0 checks, 167 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: decouple dpll ids from type
On Tue, Feb 26, 2019 at 04:48:23PM +0200, Ville Syrjälä wrote:
>This seems a rather roundabout way of doing things when we already have
>the vfuncs.
>
>How about just:
>
>mg_pll_enable()
>{
>icl_pll_enable(MG_REG);
>}
>
>combo_pll_enable()
>{
>icl_pll_enable(COMBO_REG);
>}
>
>or something along those lines.
humn... I thought about this approach as an intermediate step to the
full blown "add another vfunc struct and pass that instead". Platforms
are free to use this for small differences that don't justify going that
route.
In your approach you go the route of "always use vfunc and add
additional arguments to the common function".
Compared to the approach here, it's not subjective on what to do in
similar cases, but has its downsides as well.
1) The function can't be inlined so there's and extra hop when calling
the vfunc
We already have the vfunc. And even if we didn't, an extra vfunc in
modesetting code is probably in the noise.
I'm talking about the extra function you added here. The vfunc will call
this, which then calls the real common function.
2) if the callee is inlined we basically duplicate .text, but I doubt
any compiler would do that
Either it inlines or not. Why should we care in this particular case?
In this case I'm referring to icl_pll_enable() being inlined inside
mg_pll_enable() and combo_pll_enable().
But let's leave alone the inlines and extra function calls and talk
about the organization below.
3) reg as the argument is probably not a good choice as it may change
in the next platform - so we would need to add a "type" nonetheless
Not sure what you mean. If the reg changes you pass in a different reg.
If other things differ significantly you write a new function.
because here the function can share more when I consider the *type* of
the pll, not if it's reg 0x10, 0x30 or 0x40.
Since flags is already there
and under-utilized I don't see much
advantage on the vfunc-only approach. I'm not strongly opposed though:
IMO both are better than the current state.
If the existing mechanism is sufficient to the task then we should
generally use it rather than adding yet another mechanism. This
keeps the code more uniform and thus easier for everyone to
understand.
both of them already exist - flags is already there. If I handle the
*types* differently with your approach I would basically have:
enum pll_type {
A,
B,
C,
}
pll_enable()
{
...
if (type == A)
else if (type == B)
else
...
}
a_pll_enable()
{
return pll_enable(A);
}
b_pll_enable()
{
return pll_enable(B);
}
c_pll_enable()
{
return pll_enable(C);
}
static const struct funcs a_funcs = {
.enable = a_pll_enable(),
};
static const struct funcs b_funcs = {
.eanble = b_pll_enable(),
};
static const struct funcs c_funcs = {
.enable = c_pll_enable(),
};
static const struct plls[] = {
{ a_funcs, ... },
{ b_funcs, ... },
{ c_funcs, ... },
};
This approach has its value when the implementations are completely
different - e.g. the mg vs combo approach in patch 1. When the
implementation is very similar, what I'm proposing is to be able to do:
enum pll_type {
A,
B,
C,
}
pll_enable()
{
...
if (type == A)
else if (type == B)
else
...
}
static const struct funcs funcs = {
.enable = pll_enable(),
};
static const struct plls[] = {
{ funcs, A, ... }
{ funcs, B, ... }
{ funcs, C, ... }
}
We have less boilerplate code and the information is in the table rather
than spread across multiple functions. Don't get me wrong, the other
approach has its place and is even used in patch 1 because the impl
is totally different.
In the ICL case, the type in the table is used to tweak the behavior for
MG vs TBT, because they reuse most of the same calls. Combo vs MG is
handled in patch 1, not here.
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 18/42] drm/i915/lmem: support CPU relocations
Quoting Matthew Auld (2019-02-26 18:53:17) > On Thu, 14 Feb 2019 at 15:48, Chris Wilson wrote: > > > > Quoting Matthew Auld (2019-02-14 14:57:16) > > > We need to support doing relocations from the CPU when dealing with LMEM > > > objects. > > > > Why not just use the GPU reloc? Please do explain the relative merits. > > Are you suggesting just default to the GPU reloc path for LMEM, and > don't bother with CPU relocs? I guess that would work, I'm just > wondering if keeping the CPU reloc path around for debug might be > useful, it's at least been useful in the past, although maybe it's not > that relevant for upstream. Debug is a good argument; I just want to hear about the relative merits of each path. At the moment, we only use the GPU path if already busy, but maybe we need to reconsider? There's even more fun to be had where reservation is async and we need to defer the relocation processing until after we've acquired the memory and vma :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 18/42] drm/i915/lmem: support CPU relocations
On Thu, 14 Feb 2019 at 15:48, Chris Wilson wrote: > > Quoting Matthew Auld (2019-02-14 14:57:16) > > We need to support doing relocations from the CPU when dealing with LMEM > > objects. > > Why not just use the GPU reloc? Please do explain the relative merits. Are you suggesting just default to the GPU reloc path for LMEM, and don't bother with CPU relocs? I guess that would work, I'm just wondering if keeping the CPU reloc path around for debug might be useful, it's at least been useful in the past, although maybe it's not that relevant for upstream. > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
Am 26.02.19 um 18:20 schrieb Alex Deucher: On Tue, Feb 26, 2019 at 7:17 AM Joonas Lahtinen wrote: Quoting Alex Deucher (2019-02-25 21:31:43) On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen wrote: Quoting Dave Airlie (2019-02-25 12:24:48) On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen wrote: + dri-devel mailing list, especially for the buddy allocator part Quoting Dave Airlie (2019-02-15 02:47:07) On Fri, 15 Feb 2019 at 00:57, Matthew Auld wrote: In preparation for upcoming devices with device local memory, introduce the concept of different memory regions, and a simple buddy allocator to manage them. This is missing the information on why it's not TTM. Nothing against extending i915 gem off into doing stuff we already have examples off in tree, but before you do that it would be good to have a why we can't use TTM discussion in public. Glad that you asked. It's my fault that it was not included in the cover letter. I anticipated the question, but was travelling for a couple of days at the time this was sent. I didn't want to write a hasty explanation and then disappear, leaving others to take the heat. So here goes the less-hasty version: We did an analysis on the effort needed vs benefit gained of using TTM when this was started initially. The conclusion was that we already share the interesting bits of code through core DRM, really. Re-writing the memory handling to TTM would buy us more fine-grained locking. But it's more a trait of rewriting the memory handling with the information we have learned, than rewriting it to use TTM :) And further, we've been getting rid of struct_mutex at a steady phase in the past years, so we have a clear path to the fine-grained locking already in the not-so-distant future. With all this we did not see much gained from converting over, as the code sharing is already substantial. We also wanted to have the buddy allocator instead of a for loop making drm_mm allocations to make sure we can keep the memory fragmentation at bay. The intent is to move the buddy allocator to core DRM, to the benefit of all the drivers, if there is interest from community. It has been written as a strictly separate component with that in mind. And if you take the buddy allocator out of the patch set, the rest is mostly just vfuncing things up to be able to have different backing storages for objects. We took the opportunity to move over to the more valgrind friendly mmap while touching things, but it's something we have been contemplating anyway. And yeah, loads of selftests. That's really all that needed adding, and most of it is internal to i915 and not to do with uAPI. This means porting over an userspace driver doesn't require a substantial rewrite, but adding new a few new IOCTLs to set the preferred backing storage placements. All the previous GEM abstractions keep applying, so we did not see a justification to rewrite the kernel driver and userspace drivers. It would have just to made things look like TTM, when we already have the important parts of the code shared with TTM drivers behind the GEM interfaces which all our drivers sit on top of. a) you guys should be the community as well, if the buddy allocator is useful in the core DRM get out there and try and see if anyone else has a use case for it, like the GPU scheduler we have now (can i915 use that yet? :-) Well, the buddy allocator should be useful for anybody wishing to have as continuous physical allocations as possible. I have naively assumed that would be almost everyone. So it would be only a question if others see the amount of work required to convert over is justified for them. For the common DRM scheduler, I think a solid move from the beginning would have been to factor out the i915 scheduler as it was most advanced in features :) Now there is a way more trivial common scheduler core with no easy path to transition without a feature regression. Can you elaborate? What features are missing from the drm gpu scheduler? Priority based pre-emption is the big thing coming to mind. But maybe we should not derail the discussion in this thread. The discussion should be in the archives, or we can start a new thread. Probably not worth continuing here, but I think there are probably features that the drm scheduler has that the i915 scheduler does not. For example, engine load balancing. So i wouldn't necessarily say it's more advanced, just different feature sets. We could all be enjoying all of these features if we all worked on the same infrastructure. Actually it is worth continuing. To be honest the DRM scheduler came first and the i915 scheduler should have been pushed back a bit more. Additional to that it does support priority based pre-emption from the very beginning, you guys just didn't cared to take a look :( Regards, Christian. We'd have to rewrite many of the more advanced features for that codebase before we could transition over. It's hard to justify such work, for that
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: add OA interrupt support (rev4)
== Series Details == Series: drm/i915/perf: add OA interrupt support (rev4) URL : https://patchwork.freedesktop.org/series/54280/ State : success == Summary == CI Bug Log - changes from CI_DRM_5660_full -> Patchwork_12310_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12310_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_parallel@bsd1: - shard-skl: NOTRUN -> SKIP [fdo#109271] +127 * igt@gem_exec_params@no-blt: - shard-snb: NOTRUN -> SKIP [fdo#109271] +84 * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-e: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-f: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_busy@extended-modeset-hang-oldfb-render-f: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +12 * igt@kms_chamelium@vga-edid-read: - shard-apl: NOTRUN -> SKIP [fdo#109271] +16 * igt@kms_color@pipe-c-ctm-max: - shard-apl: PASS -> FAIL [fdo#108147] * igt@kms_cursor_crc@cursor-128x42-offscreen: - shard-skl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-dpms: - shard-kbl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x21-offscreen: - shard-skl: NOTRUN -> FAIL [fdo#103232] +1 * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] * igt@kms_cursor_crc@cursor-size-change: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: PASS -> FAIL [fdo#105767] * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled: - shard-skl: NOTRUN -> FAIL [fdo#103184] * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: NOTRUN -> FAIL [fdo#103833] * igt@kms_flip@2x-flip-vs-modeset-vs-hang: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +19 * igt@kms_flip@2x-flip-vs-suspend: - shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133] * igt@kms_flip@flip-vs-expired-vblank: - shard-snb: PASS -> FAIL [fdo#105363] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render: - shard-skl: PASS -> FAIL [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: - shard-glk: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-wc: - shard-skl: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-pwrite: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-skl: PASS -> FAIL [fdo#103166] * igt@kms_plane@plane-panning-top-left-pipe-a-planes: - shard-skl: NOTRUN -> FAIL [fdo#103166] * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-basic: - shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590] * igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * 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-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_setmode@basic: - shard-skl: NOTRUN -> FAIL [fdo#99912] * igt@kms_vblank@pipe-b-wait-forked-busy-hang: - shard-hsw: PASS -> DMESG-WARN [fdo#102614] * igt@prime_busy@hang-bsd: - shard-kbl: PASS -> INCOMPLETE [fdo#103665] * igt@tools_test@tools_test: - shard-snb: PASS -> SKIP [fdo#109271] Possible fixes * igt@gem_ctx_isolation@vcs0-s3: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: SKIP [fdo#109271] -> PASS * igt@i915_pm_rpm@gem-idle: - shard-skl: INCOMPLETE [fdo#107807] -> PASS * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-apl: DMESG-WARN [fdo#107956] -> PASS *
[Intel-gfx] [PATCH v2 12/12] drm/i915: Read out memory type
From: Ville Syrjälä
We'll need to know the memory type in the system for some
bandwidth limitations and whatnot. Let's read that out on
gen9+.
v2: Rebase
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 84 +++--
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/i915_reg.h | 13 +
3 files changed, 100 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 47d1a8734f2d..03ad9a8e32f4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1068,6 +1068,26 @@ static void intel_sanitize_options(struct
drm_i915_private *dev_priv)
intel_gvt_sanitize_options(dev_priv);
}
+#define DRAM_TYPE_STR(type) [INTEL_DRAM_ ## type] = #type
+
+static const char *intel_dram_type_str(enum intel_dram_type type)
+{
+ static const char * const str[] = {
+ DRAM_TYPE_STR(UNKNOWN),
+ DRAM_TYPE_STR(DDR3),
+ DRAM_TYPE_STR(DDR4),
+ DRAM_TYPE_STR(LPDDR3),
+ DRAM_TYPE_STR(LPDDR4),
+ };
+
+ if (type >= ARRAY_SIZE(str))
+ type = INTEL_DRAM_UNKNOWN;
+
+ return str[type];
+}
+
+#undef DRAM_TYPE_STR
+
static int intel_dimm_num_devices(const struct dram_dimm_info *dimm)
{
return dimm->ranks * 64 / (dimm->width ?: 1);
@@ -1252,6 +1272,28 @@ skl_dram_get_channels_info(struct drm_i915_private
*dev_priv)
return 0;
}
+static enum intel_dram_type
+skl_get_dram_type(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ val = I915_READ(SKL_MAD_INTER_CHANNEL_0_0_0_MCHBAR_MCMAIN);
+
+ switch (val & SKL_DRAM_DDR_TYPE_MASK) {
+ case SKL_DRAM_DDR_TYPE_DDR3:
+ return INTEL_DRAM_DDR3;
+ case SKL_DRAM_DDR_TYPE_DDR4:
+ return INTEL_DRAM_DDR4;
+ case SKL_DRAM_DDR_TYPE_LPDDR3:
+ return INTEL_DRAM_LPDDR3;
+ case SKL_DRAM_DDR_TYPE_LPDDR4:
+ return INTEL_DRAM_LPDDR4;
+ default:
+ MISSING_CASE(val);
+ return INTEL_DRAM_UNKNOWN;
+ }
+}
+
static int
skl_get_dram_info(struct drm_i915_private *dev_priv)
{
@@ -1259,6 +1301,9 @@ skl_get_dram_info(struct drm_i915_private *dev_priv)
u32 mem_freq_khz, val;
int ret;
+ dram_info->type = skl_get_dram_type(dev_priv);
+ DRM_DEBUG_KMS("DRAM type: %s\n", intel_dram_type_str(dram_info->type));
+
ret = skl_dram_get_channels_info(dev_priv);
if (ret)
return ret;
@@ -1324,6 +1369,26 @@ static int bxt_get_dimm_ranks(u32 val)
}
}
+static enum intel_dram_type bxt_get_dimm_type(u32 val)
+{
+ if (!bxt_get_dimm_size(val))
+ return INTEL_DRAM_UNKNOWN;
+
+ switch (val & BXT_DRAM_TYPE_MASK) {
+ case BXT_DRAM_TYPE_DDR3:
+ return INTEL_DRAM_DDR3;
+ case BXT_DRAM_TYPE_LPDDR3:
+ return INTEL_DRAM_LPDDR3;
+ case BXT_DRAM_TYPE_DDR4:
+ return INTEL_DRAM_DDR4;
+ case BXT_DRAM_TYPE_LPDDR4:
+ return INTEL_DRAM_LPDDR4;
+ default:
+ MISSING_CASE(val);
+ return INTEL_DRAM_UNKNOWN;
+ }
+}
+
static void bxt_get_dimm_info(struct dram_dimm_info *dimm,
u32 val)
{
@@ -1366,6 +1431,7 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
*/
for (i = BXT_D_CR_DRP0_DUNIT_START; i <= BXT_D_CR_DRP0_DUNIT_END; i++) {
struct dram_dimm_info dimm;
+ enum intel_dram_type type;
val = I915_READ(BXT_D_CR_DRP0_DUNIT(i));
if (val == 0x)
@@ -1374,10 +1440,16 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
dram_info->num_channels++;
bxt_get_dimm_info(, val);
+ type = bxt_get_dimm_type(val);
+
+ WARN_ON(type != INTEL_DRAM_UNKNOWN &&
+ dram_info->type != INTEL_DRAM_UNKNOWN &&
+ dram_info->type != type);
- DRM_DEBUG_KMS("CH%d DIMM size: %d GB, width: X%d, ranks: %d\n",
+ DRM_DEBUG_KMS("CH%d DIMM size: % dGB, width: X%d, ranks: %d,
type: %s\n",
i - BXT_D_CR_DRP0_DUNIT_START,
- dimm.size, dimm.width, dimm.ranks);
+ dimm.size, dimm.width, dimm.ranks,
+ intel_dram_type_str(type));
/*
* If any of the channel is single rank channel,
@@ -1388,10 +1460,14 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
dram_info->ranks = dimm.ranks;
else if (dimm.ranks == 1)
dram_info->ranks = 1;
+
+ if (type != INTEL_DRAM_UNKNOWN)
+ dram_info->type = type;
}
- if (dram_info->ranks == 0) {
- DRM_INFO("couldn't get
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
On Tue, Feb 26, 2019 at 7:17 AM Joonas Lahtinen wrote: > > Quoting Alex Deucher (2019-02-25 21:31:43) > > On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen > > wrote: > > > > > > Quoting Dave Airlie (2019-02-25 12:24:48) > > > > On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen > > > > wrote: > > > > > > > > > > + dri-devel mailing list, especially for the buddy allocator part > > > > > > > > > > Quoting Dave Airlie (2019-02-15 02:47:07) > > > > > > On Fri, 15 Feb 2019 at 00:57, Matthew Auld > > > > > > wrote: > > > > > > > > > > > > > > In preparation for upcoming devices with device local memory, > > > > > > > introduce the > > > > > > > concept of different memory regions, and a simple buddy allocator > > > > > > > to manage > > > > > > > them. > > > > > > > > > > > > This is missing the information on why it's not TTM. > > > > > > > > > > > > Nothing against extending i915 gem off into doing stuff we already > > > > > > have examples off in tree, but before you do that it would be good > > > > > > to > > > > > > have a why we can't use TTM discussion in public. > > > > > > > > > > Glad that you asked. It's my fault that it was not included in > > > > > the cover letter. I anticipated the question, but was travelling > > > > > for a couple of days at the time this was sent. I didn't want > > > > > to write a hasty explanation and then disappear, leaving others to > > > > > take the heat. > > > > > > > > > > So here goes the less-hasty version: > > > > > > > > > > We did an analysis on the effort needed vs benefit gained of using > > > > > TTM when this was started initially. The conclusion was that we > > > > > already share the interesting bits of code through core DRM, really. > > > > > > > > > > Re-writing the memory handling to TTM would buy us more fine-grained > > > > > locking. But it's more a trait of rewriting the memory handling with > > > > > the information we have learned, than rewriting it to use TTM :) > > > > > > > > > > And further, we've been getting rid of struct_mutex at a steady phase > > > > > in the past years, so we have a clear path to the fine-grained locking > > > > > already in the not-so-distant future. With all this we did not see > > > > > much gained from converting over, as the code sharing is already > > > > > substantial. > > > > > > > > > > We also wanted to have the buddy allocator instead of a for loop > > > > > making > > > > > drm_mm allocations to make sure we can keep the memory fragmentation > > > > > at bay. The intent is to move the buddy allocator to core DRM, to the > > > > > benefit of all the drivers, if there is interest from community. It > > > > > has > > > > > been written as a strictly separate component with that in mind. > > > > > > > > > > And if you take the buddy allocator out of the patch set, the rest is > > > > > mostly just vfuncing things up to be able to have different backing > > > > > storages for objects. We took the opportunity to move over to the more > > > > > valgrind friendly mmap while touching things, but it's something we > > > > > have been contemplating anyway. And yeah, loads of selftests. > > > > > > > > > > That's really all that needed adding, and most of it is internal to > > > > > i915 and not to do with uAPI. This means porting over an userspace > > > > > driver doesn't require a substantial rewrite, but adding new a few > > > > > new IOCTLs to set the preferred backing storage placements. > > > > > > > > > > All the previous GEM abstractions keep applying, so we did not see > > > > > a justification to rewrite the kernel driver and userspace drivers. > > > > > It would have just to made things look like TTM, when we already > > > > > have the important parts of the code shared with TTM drivers > > > > > behind the GEM interfaces which all our drivers sit on top of. > > > > > > > > a) you guys should be the community as well, if the buddy allocator is > > > > useful in the core DRM get out there and try and see if anyone else > > > > has a use case for it, like the GPU scheduler we have now (can i915 > > > > use that yet? :-) > > > > > > Well, the buddy allocator should be useful for anybody wishing to have > > > as continuous physical allocations as possible. I have naively assumed > > > that would be almost everyone. So it would be only a question if others > > > see the amount of work required to convert over is justified for them. > > > > > > For the common DRM scheduler, I think a solid move from the beginning > > > would have been to factor out the i915 scheduler as it was most advanced > > > in features :) Now there is a way more trivial common scheduler core with > > > no easy path to transition without a feature regression. > > > > Can you elaborate? What features are missing from the drm gpu scheduler? > > Priority based pre-emption is the big thing coming to mind. But maybe we > should not derail the discussion in this thread. The discussion should > be in the archives, or we can start a new thread.
Re: [Intel-gfx] [RFC PATCH 05/42] drm/i915/region: support basic eviction
Quoting Matthew Auld (2019-02-26 14:58:31)
> On Thu, 14 Feb 2019 at 15:25, Chris Wilson wrote:
> >
> > Quoting Matthew Auld (2019-02-14 14:57:03)
> > > + list_for_each_entry(obj, >purgeable, region_link) {
> > > + if (!i915_gem_object_has_pages(obj))
> > > + continue;
> > > +
> > > + if (READ_ONCE(obj->pin_global))
> > > + continue;
> > > +
> > > + if (atomic_read(>mm.pages_pin_count) >
> > > obj->bind_count)
> > > + continue;
> > > +
> > > + list_add(>tmp_link, );
> >
> > Oh crikey.
>
> What's the crikey for? We do the purging in two passes? Yeah, I guess
> that's kinda garbage. There is definitely some leftover baggage from
> when we did "interesting" things in here, which needs to be fixed up.
"tmp_link" has a very bad taste (prior experience turned sour), and this
turns out to be lacking in locking. Pesky little global thing.
Alternatives tend to be to dynamically allocate list entries. My favourite
half-baked idea is to use an XArray for a chunked list (so we get storage
allocated for a bunch of entries at once).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 1/3] drm: Add CRTC background color property (v5)
On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote: > Hey, > > Op 21-02-2019 om 01:28 schreef Matt Roper: > > Some display controllers can be programmed to present non-black colors > > for pixels not covered by any plane (or pixels covered by the > > transparent regions of higher planes). Compositors that want a UI with > > a solid color background can potentially save memory bandwidth by > > setting the CRTC background property and using smaller planes to display > > the rest of the content. > > > > To avoid confusion between different ways of encoding RGB data, we > > define a standard 64-bit format that should be used for this property's > > value. Helper functions and macros are provided to generate and dissect > > values in this standard format with varying component precision values. > > > > v2: > > - Swap internal representation's blue and red bits to make it easier > >to read if printed out. (Ville) > > - Document bgcolor property in drm_blend.c. (Sean Paul) > > - s/background_color/bgcolor/ for consistency between property name and > >value storage field. (Sean Paul) > > - Add a convenience function to attach property to a given crtc. > > > > v3: > > - Restructure ARGB component extraction macros to be easier to > >understand and enclose the parameters in () to avoid calculations > >if expressions are passed. (Sean Paul) > > - s/rgba/argb/ in helper function/macro names. Even though the idea is > >to not worry about the internal representation of the u64, it can > >still be confusing to look at code that uses 'rgba' terminology, but > >stores values with argb ordering. (Ville) > > > > v4: > > - Drop the bgcolor_changed flag. (Ville, Brian Starkey) > > - Clarify in kerneldoc that background color is expected to undergo the > >same pipe-level degamma/csc/gamma transformations that planes do. > >(Brian Starkey) > > - Update kerneldoc to indicate non-opaque colors are allowed, but are > >generally only useful in special cases such as when writeback > >connectors are used (Brian Starkey / Eric Anholt) > > > > v5: > > - Set crtc->state->bgcolor to solid black inside > >drm_crtc_add_bgcolor_property() in case drivers don't do this > >themselves. (Ville) > > - Add kerneldoc to drm_crtc_add_bgcolor_property() function. > > > > Cc: dri-de...@lists.freedesktop.org > > Cc: wei.c...@intel.com > > Cc: harish.krupo@intel.com > > Cc: Ville Syrjälä > > Cc: Sean Paul > > Cc: Brian Starkey > > Cc: Eric Anholt > > Cc: Stéphane Marchesin > > Cc: Daniel Vetter > > Signed-off-by: Matt Roper > > Reviewed-by(v2): Sean Paul > > Reviewed-by: Brian Starkey > > I like how bgcolor is a u64 now, but there is an issue with setting > crtc->state->bgcolor in attaching the property. > > We should do it in atomic core init instead, like we already do for > connector/plane properties.. > > See for example https://patchwork.freedesktop.org/series/52363/ > > This was specificallly for the background color proposal, but we > probalby have to split out the non-trivial conversions of > __drm_atomic_helper_crtc_reset. Makes sense. What's the status of that patch? It looks like it has a lot of a-b's/r-b's but hasn't landed yet. Is there anything blocking it? If you're still driving it forward, I can wait for that to land and then build on top of it. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_switch: Use minimum qlen over all engines and measure switches
Quoting Caz Yokoyama (2019-02-26 16:14:18) > Reviewed-by: Caz Yokoyama And pushed, thanks for raising the issue and review. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_switch: Use minimum qlen over all engines and measure switches
Reviewed-by: Caz Yokoyama -caz On Mon, 2019-02-25 at 18:29 +, Chris Wilson wrote: > Quoting Caz Yokoyama (2019-02-25 18:28:34) > > Chris, > > By your patch, measure_qlen() reports how many gem_execbuf() can be > > executed(queue length) within timeout of the slowest engine, > > correct? > > More or less, yes. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20190226]
[cannot apply to v5.0-rc8]
[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/Hans-de-Goede/Propagate-DP-over-Type-C-hotplug-events-from-Type-C-subsys-to-drm-drivers/20190226-005334
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-s1-02261802 (attached as .config)
compiler: gcc-6 (Debian 6.5.0-2) 6.5.0 20181026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
ld: drivers/usb/typec/altmodes/displayport.o: in function
`dp_altmode_remove':
>> drivers/usb/typec/altmodes/displayport.c:570: undefined reference to
>> `drm_kms_call_oob_hotplug_notifier_chain'
ld: drivers/usb/typec/altmodes/displayport.o: in function
`dp_altmode_notify':
drivers/usb/typec/altmodes/displayport.c:79: undefined reference to
`drm_kms_call_oob_hotplug_notifier_chain'
vim +570 drivers/usb/typec/altmodes/displayport.c
562
563 static void dp_altmode_remove(struct typec_altmode *alt)
564 {
565 struct dp_altmode *dp = typec_altmode_get_drvdata(alt);
566
567 sysfs_remove_group(>dev.kobj, _altmode_group);
568 cancel_work_sync(>work);
569
> 570
> drm_kms_call_oob_hotplug_notifier_chain(DRM_OOB_HOTPLUG_TYPE_C_DP);
571 }
572
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/fence: Do not use TIMER_IRQSAFE
On 2019-02-12 17:28:57 [+0100], To linux-ker...@vger.kernel.org wrote: > The timer is initialized with TIMER_IRQSAFE flag. It does look like the > timer callback requires this flag at all. Its sole purpose is to ensure > synchronisation in the workqueue code. > > Remove TIMER_IRQSAFE flag because it is not required. ping > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > Cc: David Airlie > Cc: Daniel Vetter > Cc: intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Sebastian Andrzej Siewior > --- > drivers/gpu/drm/i915/i915_sw_fence.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c > b/drivers/gpu/drm/i915/i915_sw_fence.c > index fc2eeab823b70..6d22d9df6a433 100644 > --- a/drivers/gpu/drm/i915/i915_sw_fence.c > +++ b/drivers/gpu/drm/i915/i915_sw_fence.c > @@ -461,8 +461,7 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence > *fence, > timer->dma = dma_fence_get(dma); > init_irq_work(>work, irq_i915_sw_fence_work); > > - timer_setup(>timer, > - timer_i915_sw_fence_wake, TIMER_IRQSAFE); > + timer_setup(>timer, timer_i915_sw_fence_wake, 0); > mod_timer(>timer, round_jiffies_up(jiffies + timeout)); > > func = dma_i915_sw_fence_wake_timer; Sebastian ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Polish DRAM information readout code (rev4)
== Series Details == Series: Polish DRAM information readout code (rev4) URL : https://patchwork.freedesktop.org/series/57213/ State : failure == Summary == Applying: drm/i915: Store DIMM rank information as a number Applying: drm/i915: Extract functions to derive SKL+ DIMM info Applying: drm/i915: Polish skl_is_16gb_dimm() Applying: drm/i915: Extract BXT DIMM helpers Applying: drm/i915: Fix DRAM size reporting for BXT Applying: drm/i915: Extract DIMM info on GLK too Applying: drm/i915: Use dram_dimm_info more Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_drv.c Applying: drm/i915: Generalize intel_is_dram_symmetric() Applying: drm/i914: s/l_info/dimm_l/ etc. Applying: drm/i915: Clean up intel_get_dram_info() a bit Applying: drm/i915: Extract DIMM info on cnl+ Applying: drm/i915: Read out memory type Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_drv.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0012 drm/i915: Read out memory type When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Probe again type-c connectors that failed
On Tue, 26 Feb 2019, Imre Deak wrote:
> On Fri, Feb 22, 2019 at 01:08:34PM -0800, José Roberto de Souza wrote:
>> Unpowered type-c dongles can take some time to boot and be
>> responsible, causing the probe to fail and sink never be detected
>> without further actions from userspace.
>>
>> It was not a issue for older platforms because there was a hardware
>> bridge between DDI/DP ports and type-c controller adding a implicit
>> delay that hid this issue but ICL have type-c controllers integrated
>> to the SOC bring this issue to users.
>>
>> So here if the probe failed when coming from a IRQ it returns
>> INTEL_HOTPLUG_RETRY that will schedule another run of
>> i915_hotplug_work_func() after 1 second what is time enough for
>> those type-c dongles to boot.
>>
>> Cc: Ville Syrjälä
>> Cc: Imre Deak
>> Cc: Jani Nikula
>> Signed-off-by: José Roberto de Souza
>> ---
>> drivers/gpu/drm/i915/intel_ddi.c | 13 +
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 1676a87f18cb..96bbcf5c9787 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -4056,6 +4056,8 @@ intel_ddi_hotplug(struct intel_encoder *encoder,
>>struct intel_connector *connector,
>>bool irq_received)
>> {
>> +struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>> +struct intel_digital_port *dig_port = enc_to_dig_port(>base);
>> struct drm_modeset_acquire_ctx ctx;
>> enum intel_hotplug_state state;
>> int ret;
>> @@ -4082,6 +4084,17 @@ intel_ddi_hotplug(struct intel_encoder *encoder,
>> drm_modeset_acquire_fini();
>> WARN(ret, "Acquiring modeset locks failed with %i\n", ret);
>>
>> +/*
>> + * Unpowered type-c dongles can take some time to boot and be
>> + * responsible, so here giving some type to those dongles to power up
>> + * and then retrying the probe.
>> + */
>> +if (state == INTEL_HOTPLUG_NOCHANGE &&
>> +connector->base.status != connector_status_connected &&
>> +irq_received && intel_port_is_tc(dev_priv, encoder->port) &&
>> +!dig_port->tc_legacy_port && !dig_port->dp.is_mst)
>
> Based on the investigation by Jani et al, we have the similar problem with
> HDMI, only during disconnect. So I think we could generalize by retrying
> any time there is no change (except for MST where the driver always keeps
> the connector in a disconnected state), regardless of the type of the
> sink, since a no-change is suspect in any case: why would the sink signal
> (with a long pulse) if there is no change?
>
> For HDMI we'd also need to handle this in intel_hdmi.c.
>
> Then Ville suggested to add a Chamelium test for this to IGT, could you
> Jose look into that as well? Both the connect and disconnect races could
> be tested, both on HDMI and DP, by generating the HPD early/late wrt. to
> AUX/DDC starting/stopping to return valid data. I don't know if
> Chamelium can do this, you'd have to find that out first.
Guang Bai also kept referencing a pathological customer test case which
we're not privy to.
BR,
Jani.
>
> --Imre
>
>> +state = INTEL_HOTPLUG_RETRY;
>> +
>> return state;
>> }
>>
>> --
>> 2.20.1
>>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/12] drm/i915: Fix DRAM size reporting for BXT
From: Ville Syrjälä
The BXT DUNIT register tells us the size of each DRAM device
in Gb. We want to report the size of the whole DIMM in GB, so
that it matches how we report it for non-LP platforms.
v2: Deobfuscate the math (Chris)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f948d475bdf4..08fb1b1502a0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1291,9 +1291,14 @@ static int bxt_get_dimm_ranks(u32 val)
static void bxt_get_dimm_info(struct dram_dimm_info *dimm,
u32 val)
{
- dimm->size = bxt_get_dimm_size(val);
dimm->width = bxt_get_dimm_width(val);
dimm->ranks = bxt_get_dimm_ranks(val);
+
+ /*
+* Size in register is Gb per DRAM device. Convert to total
+* GB to match the way we report this for non-LP platforms.
+*/
+ dimm->size = bxt_get_dimm_size(val) * intel_dimm_num_devices(dimm) / 8;
}
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 04/12] drm/i915: Extract BXT DIMM helpers
From: Ville Syrjälä
Polish the bxt DIMM parsing by extracting a few small helpers.
v2: Use struct dram_dimm_info
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 93 ++---
1 file changed, 62 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d84f3485e775..f948d475bdf4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1243,6 +1243,59 @@ skl_get_dram_info(struct drm_i915_private *dev_priv)
return 0;
}
+static int bxt_get_dimm_size(u32 val)
+{
+ switch (val & BXT_DRAM_SIZE_MASK) {
+ case BXT_DRAM_SIZE_4GB:
+ return 4;
+ case BXT_DRAM_SIZE_6GB:
+ return 6;
+ case BXT_DRAM_SIZE_8GB:
+ return 8;
+ case BXT_DRAM_SIZE_12GB:
+ return 12;
+ case BXT_DRAM_SIZE_16GB:
+ return 16;
+ default:
+ MISSING_CASE(val);
+ return 0;
+ }
+}
+
+static int bxt_get_dimm_width(u32 val)
+{
+ if (!bxt_get_dimm_size(val))
+ return 0;
+
+ val = (val & BXT_DRAM_WIDTH_MASK) >> BXT_DRAM_WIDTH_SHIFT;
+
+ return 8 << val;
+}
+
+static int bxt_get_dimm_ranks(u32 val)
+{
+ if (!bxt_get_dimm_size(val))
+ return 0;
+
+ switch (val & BXT_DRAM_RANK_MASK) {
+ case BXT_DRAM_RANK_SINGLE:
+ return 1;
+ case BXT_DRAM_RANK_DUAL:
+ return 2;
+ default:
+ MISSING_CASE(val);
+ return 0;
+ }
+}
+
+static void bxt_get_dimm_info(struct dram_dimm_info *dimm,
+ u32 val)
+{
+ dimm->size = bxt_get_dimm_size(val);
+ dimm->width = bxt_get_dimm_width(val);
+ dimm->ranks = bxt_get_dimm_ranks(val);
+}
+
static int
bxt_get_dram_info(struct drm_i915_private *dev_priv)
{
@@ -1271,41 +1324,19 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
* Now read each DUNIT8/9/10/11 to check the rank of each dimms.
*/
for (i = BXT_D_CR_DRP0_DUNIT_START; i <= BXT_D_CR_DRP0_DUNIT_END; i++) {
- u8 size, width, ranks;
- u32 tmp;
+ struct dram_dimm_info dimm;
val = I915_READ(BXT_D_CR_DRP0_DUNIT(i));
if (val == 0x)
continue;
dram_info->num_channels++;
- tmp = val & BXT_DRAM_RANK_MASK;
-
- if (tmp == BXT_DRAM_RANK_SINGLE)
- ranks = 1;
- else if (tmp == BXT_DRAM_RANK_DUAL)
- ranks = 2;
- else
- ranks = 0;
-
- tmp = val & BXT_DRAM_SIZE_MASK;
- if (tmp == BXT_DRAM_SIZE_4GB)
- size = 4;
- else if (tmp == BXT_DRAM_SIZE_6GB)
- size = 6;
- else if (tmp == BXT_DRAM_SIZE_8GB)
- size = 8;
- else if (tmp == BXT_DRAM_SIZE_12GB)
- size = 12;
- else if (tmp == BXT_DRAM_SIZE_16GB)
- size = 16;
- else
- size = 0;
-
- tmp = (val & BXT_DRAM_WIDTH_MASK) >> BXT_DRAM_WIDTH_SHIFT;
- width = (1 << tmp) * 8;
- DRM_DEBUG_KMS("dram size:%dGB width:X%d ranks:%d\n",
- size, width, ranks);
+
+ bxt_get_dimm_info(, val);
+
+ DRM_DEBUG_KMS("CH%d DIMM size: %d GB, width: X%d, ranks: %d\n",
+ i - BXT_D_CR_DRP0_DUNIT_START,
+ dimm.size, dimm.width, dimm.ranks);
/*
* If any of the channel is single rank channel,
@@ -1313,8 +1344,8 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
* memory, so consider single rank memory.
*/
if (dram_info->ranks == 0)
- dram_info->ranks = ranks;
- else if (ranks == 1)
+ dram_info->ranks = dimm.ranks;
+ else if (dimm.ranks == 1)
dram_info->ranks = 1;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 03/12] drm/i915: Polish skl_is_16gb_dimm()
From: Ville Syrjälä
Pass the dimm struct to skl_is_16gb_dimm() rather than passing each
value separately. And let's replace the hardcoded set of values with
some simple arithmetic.
Also fix the byte vs. bit inconsistency in the debug message,
and polish the wording otherwise as well.
v2: Deobfuscate the math (Chris)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 28
drivers/gpu/drm/i915/i915_drv.h | 8 +---
2 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b94bf475b04c..d84f3485e775 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1068,6 +1068,11 @@ static void intel_sanitize_options(struct
drm_i915_private *dev_priv)
intel_gvt_sanitize_options(dev_priv);
}
+static int intel_dimm_num_devices(const struct dram_dimm_info *dimm)
+{
+ return dimm->ranks * 64 / (dimm->width ?: 1);
+}
+
static int skl_get_dimm_size(u16 val)
{
return val & SKL_DRAM_SIZE_MASK;
@@ -1107,18 +1112,10 @@ static int skl_get_dimm_ranks(u16 val)
}
static bool
-skl_is_16gb_dimm(u8 ranks, u8 size, u8 width)
+skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
{
- if (ranks == 1 && width == 8 && size == 16)
- return true;
- else if (ranks == 2 && width == 8 && size == 32)
- return true;
- else if (ranks == 1 && width == 16 && size == 8)
- return true;
- else if (ranks == 2 && width == 16 && size == 16)
- return true;
-
- return false;
+ /* Convert total GB to Gb per DRAM device */
+ return 8 * dimm->size / (intel_dimm_num_devices(dimm) ?: 1) == 16;
}
static int
@@ -1148,10 +1145,9 @@ skl_dram_get_channel_info(struct dram_channel_info *ch,
u32 val)
else
ch->ranks = 1;
- ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.ranks, ch->l_info.size,
- ch->l_info.width) ||
- skl_is_16gb_dimm(ch->s_info.ranks, ch->s_info.size,
- ch->s_info.width);
+ ch->is_16gb_dimm =
+ skl_is_16gb_dimm(>l_info) ||
+ skl_is_16gb_dimm(>s_info);
DRM_DEBUG_KMS("(size:width:ranks) L(%dGB:X%d:%d) S(%dGB:X%d:%d)\n",
ch->l_info.size, ch->l_info.width, ch->l_info.ranks,
@@ -1369,7 +1365,7 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
sprintf(bandwidth_str, "unknown");
DRM_DEBUG_KMS("DRAM bandwidth:%s, total-channels: %u\n",
bandwidth_str, dram_info->num_channels);
- DRM_DEBUG_KMS("DRAM ranks: %d, 16GB-dimm:%s\n",
+ DRM_DEBUG_KMS("DRAM ranks: %d, 16Gb DIMMs: %s\n",
dram_info->ranks, yesno(dram_info->is_16gb_dimm));
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9cb13a6edaf..fcde09934bb5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2065,10 +2065,12 @@ struct drm_i915_private {
*/
};
+struct dram_dimm_info {
+ u8 size, width, ranks;
+};
+
struct dram_channel_info {
- struct info {
- u8 size, width, ranks;
- } l_info, s_info;
+ struct dram_dimm_info l_info, s_info;
u8 ranks;
bool is_16gb_dimm;
};
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: add OA interrupt support (rev4)
== Series Details ==
Series: drm/i915/perf: add OA interrupt support (rev4)
URL : https://patchwork.freedesktop.org/series/54280/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5660 -> Patchwork_12310
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54280/revisions/4/
Known issues
Here are the changes found in Patchwork_12310 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-gdg-551: NOTRUN -> SKIP [fdo#109271] +106
* igt@gem_exec_basic@readonly-bsd2:
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_selftest@live_hangcheck:
- fi-icl-u2: PASS -> INCOMPLETE [fdo#108569]
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: NOTRUN -> FAIL [fdo#103182] +1
* igt@kms_busy@basic-flip-c:
- fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-gdg-551: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] +52
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: SKIP [fdo#109271] -> PASS
* igt@i915_pm_rpm@basic-rte:
- fi-bsw-kefka: FAIL [fdo#108800] -> PASS
* igt@i915_pm_rpm@module-reload:
- {fi-icl-y}: INCOMPLETE [fdo#108840] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
Participating hosts (42 -> 39)
--
Additional (3): fi-byt-j1900 fi-gdg-551 fi-pnv-d510
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-ctg-p8600
fi-icl-u3 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5660 -> Patchwork_12310
CI_DRM_5660: 2cca9f74156f1061298a7249f7af80dcbb9178d9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4857: 25911cdde500aa6ddede601faec91741c6963c27 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12310: 6f8b7eacba5725ea1d264885eaa2d8ecf1f530a6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6f8b7eacba57 drm/i915/perf: bump i915-perf revision
eaf300781632 drm/i915/perf: add flushing ioctl
4f1ddad50b51 drm/i915/perf: add interrupt enabling parameter
1c4d948d1927 drm/i915: handle interrupts from the OA unit
b2e1e260205b drm/i915/perf: add new open param to configure polling of OA buffer
68722d5b65d6 drm/i915/perf: introduce a versioning of the i915-perf uapi
30f143c5ed22 drm/i915/perf: only append status when data is available
01ae7ed1bd49 drm/i915/perf: move pollin setup to non hw specific code
1cdda900a014 drm/i915/perf: rework aging tail workaround
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12310/
___
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 [01/11] drm/i915: Skip scanning for signalers if we are already inflight (rev2)
== Series Details == Series: series starting with [01/11] drm/i915: Skip scanning for signalers if we are already inflight (rev2) URL : https://patchwork.freedesktop.org/series/57244/ State : success == Summary == CI Bug Log - changes from CI_DRM_5660_full -> Patchwork_12309_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12309_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_parallel@bsd1: - shard-skl: NOTRUN -> SKIP [fdo#109271] +127 * igt@gem_exec_params@no-blt: - shard-snb: NOTRUN -> SKIP [fdo#109271] +84 * igt@i915_pm_rpm@gem-execbuf-stress-extra-wait: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-e: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-f: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_busy@extended-modeset-hang-oldfb-render-f: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +12 * igt@kms_chamelium@vga-edid-read: - shard-apl: NOTRUN -> SKIP [fdo#109271] +16 * igt@kms_color@pipe-c-ctm-max: - shard-apl: PASS -> FAIL [fdo#108147] * igt@kms_cursor_crc@cursor-128x42-offscreen: - shard-skl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-dpms: - shard-kbl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x21-onscreen: - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-alpha-opaque: - shard-glk: PASS -> FAIL [fdo#109350] * igt@kms_cursor_crc@cursor-size-change: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: NOTRUN -> FAIL [fdo#103833] * igt@kms_flip@2x-flip-vs-modeset-vs-hang: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +18 * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-wc: - shard-skl: PASS -> FAIL [fdo#105682] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-pwrite: - shard-skl: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-pwrite: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-skl: PASS -> FAIL [fdo#103166] * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] * igt@kms_plane_alpha_blend@pipe-c-alpha-basic: - shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590] * igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] +2 * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> FAIL [fdo#109016] * igt@kms_rotation_crc@primary-rotation-270: - shard-skl: PASS -> FAIL [fdo#103925] / [fdo#107815] * igt@kms_setmode@basic: - shard-skl: NOTRUN -> FAIL [fdo#99912] Possible fixes * igt@gem_busy@extended-semaphore-blt: - shard-kbl: SKIP [fdo#109271] -> PASS +5 - shard-glk: SKIP [fdo#109271] -> PASS +3 * igt@gem_busy@extended-semaphore-vebox: - shard-apl: SKIP [fdo#109271] -> PASS +3 - shard-skl: SKIP [fdo#109271] -> PASS +3 * igt@gem_ctx_isolation@vcs0-s3: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS * igt@i915_pm_rpm@gem-idle: - shard-skl: INCOMPLETE [fdo#107807] -> PASS * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-hsw: DMESG-WARN [fdo#107956] -> PASS * igt@kms_cursor_crc@cursor-128x42-onscreen: - shard-apl: FAIL [fdo#103232] -> PASS * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS * igt@kms_flip_tiling@flip-changes-tiling-y:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/perf: add OA interrupt support (rev4)
== Series Details == Series: drm/i915/perf: add OA interrupt support (rev4) 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: move pollin setup to non hw specific code -O:drivers/gpu/drm/i915/i915_perf.c:1391:15: warning: memset with byte count of 16777216 -O:drivers/gpu/drm/i915/i915_perf.c:1449:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1391:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1444:15: warning: memset with byte count of 16777216 Commit: drm/i915/perf: only append status when data is available Okay! Commit: drm/i915/perf: introduce a versioning of the i915-perf uapi Okay! Commit: drm/i915/perf: add new open param to configure polling of OA buffer -drivers/gpu/drm/i915/selftests/../i915_drv.h:3581:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3587:16: warning: expression using sizeof(void) Commit: drm/i915: handle interrupts from the OA unit -drivers/gpu/drm/i915/selftests/../i915_drv.h:3587:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3608:16: warning: expression using sizeof(void) Commit: drm/i915/perf: add interrupt enabling parameter +drivers/gpu/drm/i915/i915_perf.c:542:9: warning: context imbalance in 'oa_buffer_check' - different lock contexts for basic block Commit: drm/i915/perf: add flushing ioctl Okay! Commit: drm/i915/perf: bump i915-perf revision Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 05/42] drm/i915/region: support basic eviction
On Thu, 14 Feb 2019 at 15:25, Chris Wilson wrote:
>
> Quoting Matthew Auld (2019-02-14 14:57:03)
> > Support basic eviction for regions.
> >
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtinen
> > Cc: Abdiel Janulgue
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > drivers/gpu/drm/i915/i915_gem.c | 16
> > drivers/gpu/drm/i915/i915_gem_object.h| 7 ++
> > drivers/gpu/drm/i915/i915_gem_shrinker.c | 59 ++
> > drivers/gpu/drm/i915/intel_memory_region.c| 40 +-
> > drivers/gpu/drm/i915/intel_memory_region.h| 7 ++
> > .../drm/i915/selftests/intel_memory_region.c | 76 +++
> > drivers/gpu/drm/i915/selftests/mock_region.c | 1 +
> > 8 files changed, 204 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 0bea7d889284..3df27769b978 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3196,6 +3196,8 @@ void i915_gem_shrinker_register(struct
> > drm_i915_private *i915);
> > void i915_gem_shrinker_unregister(struct drm_i915_private *i915);
> > void i915_gem_shrinker_taints_mutex(struct drm_i915_private *i915,
> > struct mutex *mutex);
> > +int i915_gem_shrink_memory_region(struct intel_memory_region *mem,
> > + resource_size_t target);
> >
> > /* i915_gem_tiling.c */
> > static inline bool i915_gem_object_needs_bit17_swizzle(struct
> > drm_i915_gem_object *obj)
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 92768ab294a4..7f044b643a75 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4095,6 +4095,22 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void
> > *data,
> > !i915_gem_object_has_pages(obj))
> > i915_gem_object_truncate(obj);
> >
> > + if (obj->memory_region) {
> > + mutex_lock(>memory_region->obj_lock);
> > +
> > + switch (obj->mm.madv) {
> > + case I915_MADV_WILLNEED:
> > + list_move(>region_link,
> > >memory_region->objects);
> > + break;
> > + default:
> > + list_move(>region_link,
> > + >memory_region->purgeable);
> > + break;
> > + }
> > +
> > + mutex_unlock(>memory_region->obj_lock);
> > + }
> > +
> > args->retained = obj->mm.madv != __I915_MADV_PURGED;
> > mutex_unlock(>mm.lock);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
> > b/drivers/gpu/drm/i915/i915_gem_object.h
> > index ac52f61e8ad1..76947a6f49f1 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_object.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_object.h
> > @@ -95,6 +95,13 @@ struct drm_i915_gem_object {
> > * List of memory region blocks allocated for this object.
> > */
> > struct list_head blocks;
> > + /**
> > +* Element within memory_region->objects or
> > memory_region->purgeable if
> > +* the object is marked as DONTNEED. Access is protected by
> > +* memory_region->obj_lock.
>
> Lies. ;-p
>
> > +*/
> > + struct list_head region_link;
> > + struct list_head tmp_link;
> >
> > struct {
> > /**
> > diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > index 6da795c7e62e..713c6c93cf30 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > @@ -308,6 +308,65 @@ unsigned long i915_gem_shrink_all(struct
> > drm_i915_private *i915)
> > return freed;
> > }
> >
> > +int i915_gem_shrink_memory_region(struct intel_memory_region *mem,
> > + resource_size_t target)
>
> If it's not going to be coupled into the mm.shrinker callback, do not put
> it here! And there's no reason why we would ever couple local memory to
> the generic mm shrinker!
Yup.
>
> > +{
> > + struct drm_i915_private *i915 = mem->i915;
> > + struct drm_i915_gem_object *obj, *on;
> > + resource_size_t found;
> > + LIST_HEAD(purgeable);
> > + bool unlock;
> > + int err;
> > +
> > + if (!shrinker_lock(i915, 0, ))
> > + return 0;
>
> Don't...
>
> > +
> > + i915_retire_requests(i915);
>
> And this, don't do this.
>
> > + err = 0;
> > + found = 0;
> > +
> > + mutex_lock(>obj_lock);
>
> That's all the top-level locking we should ever need.
>
> > + list_for_each_entry(obj, >purgeable, region_link) {
> > + if (!i915_gem_object_has_pages(obj))
> > + continue;
> > +
> > + if (READ_ONCE(obj->pin_global))
> > +
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: add OA interrupt support (rev4)
== Series Details ==
Series: drm/i915/perf: add OA interrupt support (rev4)
URL : https://patchwork.freedesktop.org/series/54280/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1cdda900a014 drm/i915/perf: rework aging tail workaround
-:241: CHECK:SPACING: No space is necessary after a cast
#241: FILE: drivers/gpu/drm/i915/i915_perf.c:500:
+ u32 *report32 = (void *) report;
-:319: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#319: FILE: drivers/gpu/drm/i915/i915_perf.c:795:
+ report32[0] = report32[1] = 0;
-:363: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#363: FILE: drivers/gpu/drm/i915/i915_perf.c:998:
+ report32[0] = report32[1] = 0;
total: 0 errors, 0 warnings, 3 checks, 354 lines checked
01ae7ed1bd49 drm/i915/perf: move pollin setup to non hw specific code
30f143c5ed22 drm/i915/perf: only append status when data is available
68722d5b65d6 drm/i915/perf: introduce a versioning of the i915-perf uapi
b2e1e260205b drm/i915/perf: add new open param to configure polling of OA buffer
1c4d948d1927 drm/i915: handle interrupts from the OA unit
4f1ddad50b51 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
-:32: CHECK:LINE_SPACING: Please don't use multiple blank lines
#32: FILE: drivers/gpu/drm/i915/i915_perf.c:421:
+
-:124: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'dev_priv->perf.oa.half_full_count_last !=
atomic64_read(_priv->perf.oa.half_full_count)'
#124: FILE: drivers/gpu/drm/i915/i915_perf.c:2342:
+ if (stream->oa_interrupt_monitor &&
+ (dev_priv->perf.oa.half_full_count_last !=
+atomic64_read(_priv->perf.oa.half_full_count))) {
-:172: WARNING:TYPO_SPELLING: 'conjuction' may be misspelled - perhaps
'conjunction'?
#172: FILE: include/uapi/drm/i915_drm.h:1662:
+* buffer in i915. This option in conjuction with a long polling delay
total: 0 errors, 2 warnings, 2 checks, 147 lines checked
eaf300781632 drm/i915/perf: add flushing ioctl
6f8b7eacba57 drm/i915/perf: bump i915-perf revision
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: decouple dpll ids from type
On Mon, Feb 25, 2019 at 01:28:23PM -0800, Lucas De Marchi wrote:
> On Mon, Feb 25, 2019 at 10:45:34PM +0200, Ville Syrjälä wrote:
> >On Fri, Feb 22, 2019 at 03:23:24PM -0800, Lucas De Marchi wrote:
> >> Use the first 3 bits of dpll_info.platform_flags to mark the type of the
> >> PLL instead of relying on the IDs. This is more future proof for
> >> allowing the same set of functions to be reused, even if the IDs change.
> >>
> >> The warning about PLL id not corresponding to a combo phy in intel_display
> >> was removed as I don't think it should ever trigger.
> >>
> >> Signed-off-by: Lucas De Marchi
> >> ---
> >> drivers/gpu/drm/i915/intel_display.c | 3 --
> >> drivers/gpu/drm/i915/intel_dpll_mgr.c | 54 +--
> >> drivers/gpu/drm/i915/intel_dpll_mgr.h | 1 -
> >> 3 files changed, 35 insertions(+), 23 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index b1d63c32ca94..a2be35118dd5 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -9592,9 +9592,6 @@ static void icelake_get_ddi_pll(struct
> >> drm_i915_private *dev_priv,
> >>temp = I915_READ(DPCLKA_CFGCR0_ICL) &
> >> DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
> >>id = temp >> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port);
> >> -
> >> - if (WARN_ON(!intel_dpll_is_combophy(id)))
> >> - return;
> >>} else if (intel_port_is_tc(dev_priv, port)) {
> >>id = icl_tc_port_to_pll_id(intel_port_to_tc(dev_priv, port));
> >>} else {
> >> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> >> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> >> index e4ec73d415d9..cdb4463bab5d 100644
> >> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> >> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> >> @@ -2639,6 +2639,13 @@ int icl_calc_dp_combo_pll_link(struct
> >> drm_i915_private *dev_priv,
> >>return link_clock;
> >> }
> >>
> >> +enum icl_dpll_flags {
> >> + ICL_DPLL_TYPE_COMBOPHY,
> >> + ICL_DPLL_TYPE_TBT,
> >> + ICL_DPLL_TYPE_MG,
> >> + _ICL_DPLL_TYPE_MASK = 0x7,
> >> +};
> >> +
> >> static enum tc_port icl_pll_id_to_tc_port(enum intel_dpll_id id)
> >> {
> >>return id - DPLL_ID_ICL_MGPLL1;
> >> @@ -2649,9 +2656,9 @@ enum intel_dpll_id icl_tc_port_to_pll_id(enum
> >> tc_port tc_port)
> >>return tc_port + DPLL_ID_ICL_MGPLL1;
> >> }
> >>
> >> -bool intel_dpll_is_combophy(enum intel_dpll_id id)
> >> +static enum icl_dpll_flags icl_dpll_type(const struct dpll_info *info)
> >> {
> >> - return id == DPLL_ID_ICL_DPLL0 || id == DPLL_ID_ICL_DPLL1;
> >> + return info->platform_flags & _ICL_DPLL_TYPE_MASK;
> >> }
> >>
> >> static bool icl_mg_pll_find_divisors(int clock_khz, bool is_dp, bool
> >> use_ssc,
> >> @@ -2956,14 +2963,22 @@ icl_get_dpll(struct intel_crtc *crtc, struct
> >> intel_crtc_state *crtc_state,
> >>return pll;
> >> }
> >>
> >> -static i915_reg_t icl_pll_id_to_enable_reg(enum intel_dpll_id id)
> >> +static i915_reg_t
> >> +icl_pll_info_to_enable_reg(const struct dpll_info *info)
> >> {
> >> - if (intel_dpll_is_combophy(id))
> >> - return CNL_DPLL_ENABLE(id);
> >> - else if (id == DPLL_ID_ICL_TBTPLL)
> >> - return TBT_PLL_ENABLE;
> >> + enum icl_dpll_flags type = icl_dpll_type(info);
> >>
> >> - return MG_PLL_ENABLE(icl_pll_id_to_tc_port(id));
> >> + switch (type) {
> >> + case ICL_DPLL_TYPE_COMBOPHY:
> >> + return CNL_DPLL_ENABLE(info->id);
> >> + case ICL_DPLL_TYPE_TBT:
> >> + return TBT_PLL_ENABLE;
> >> + case ICL_DPLL_TYPE_MG:
> >> + return MG_PLL_ENABLE(icl_pll_id_to_tc_port(info->id));
> >> + default:
> >> + MISSING_CASE(type);
> >> + return CNL_DPLL_ENABLE(info->id);
> >> + }
> >> }
> >
> >This seems a rather roundabout way of doing things when we already have
> >the vfuncs.
> >
> >How about just:
> >
> >mg_pll_enable()
> >{
> > icl_pll_enable(MG_REG);
> >}
> >
> >combo_pll_enable()
> >{
> > icl_pll_enable(COMBO_REG);
> >}
> >
> >or something along those lines.
>
> humn... I thought about this approach as an intermediate step to the
> full blown "add another vfunc struct and pass that instead". Platforms
> are free to use this for small differences that don't justify going that
> route.
>
> In your approach you go the route of "always use vfunc and add
> additional arguments to the common function".
> Compared to the approach here, it's not subjective on what to do in
> similar cases, but has its downsides as well.
>
> 1) The function can't be inlined so there's and extra hop when calling
> the vfunc
We already have the vfunc. And even if we didn't, an extra vfunc in
modesetting code is probably in the noise.
> 2) if the callee is inlined we basically duplicate .text, but I doubt
> any compiler would do that
Either it inlines or not. Why should we care in this particular case?
> 3) reg as the argument is probably not a
[Intel-gfx] [PATCH v3 8/9] drm/i915/perf: add flushing ioctl
With the currently available parameters for the i915-perf stream,
there are still situations that are not well covered :
If an application opens the stream with polling disable or at very low
frequency and OA interrupt enabled, no data will be available even
though somewhere between nothing and half of the OA buffer worth of
data might have landed in memory.
To solve this issue we have a new flush ioctl on the perf stream that
forces the i915-perf driver to look at the state of the buffer when
called and makes any data available through both poll() & read() type
syscalls.
v2: Version the ioctl (Joonas)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 17 +
include/uapi/drm/i915_drm.h | 21 +
2 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 39801a6e3021..7067a0f1700e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2431,6 +2431,20 @@ static void i915_perf_disable_locked(struct
i915_perf_stream *stream)
stream->ops->disable(stream);
}
+/**
+ * i915_perf_flush_data - handle `I915_PERF_IOCTL_FLUSH_DATA` ioctl
+ * @stream: An enabled i915 perf stream
+ *
+ * The intention is to flush all the data available for reading from the OA
+ * buffer
+ */
+static void i915_perf_flush_data(struct i915_perf_stream *stream)
+{
+ struct drm_i915_private *dev_priv = stream->dev_priv;
+
+ dev_priv->perf.oa.pollin = oa_buffer_check(stream->dev_priv, true);
+}
+
/**
* i915_perf_ioctl - support ioctl() usage with i915 perf stream FDs
* @stream: An i915 perf stream
@@ -2454,6 +2468,9 @@ static long i915_perf_ioctl_locked(struct
i915_perf_stream *stream,
case I915_PERF_IOCTL_DISABLE:
i915_perf_disable_locked(stream);
return 0;
+ case I915_PERF_IOCTL_FLUSH_DATA:
+ i915_perf_flush_data(stream);
+ return 0;
}
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index d04ce7ba6bd2..54cd3099b2d9 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1709,6 +1709,27 @@ struct drm_i915_perf_open_param {
*/
#define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
+/**
+ * Actively check the availability of data from a stream.
+ *
+ * A stream data availability can be driven by two types of events :
+ *
+ * - if enabled, the kernel's hrtimer checking the amount of available data
+ * in the OA buffer through head/tail registers.
+ *
+ * - if enabled, the OA unit's interrupt mechanism
+ *
+ * The kernel hrtimer incur a cost of running callback at fixed time
+ * intervals, while the OA interrupt might only happen rarely. In the
+ * situation where the application has disabled the kernel's hrtimer and only
+ * uses the OA interrupt to know about available data, the application can
+ * request an active check of the available OA data through this ioctl. This
+ * will make any data in the OA buffer available with either poll() or read().
+ *
+ * This ioctl is available in perf revision 2.
+ */
+#define I915_PERF_IOCTL_FLUSH_DATA _IO('i', 0x2)
+
/**
* Common to all i915 perf records
*/
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 9/9] drm/i915/perf: bump i915-perf revision
This makes the following opening parameters available to
applications :
- DRM_I915_PERF_PROP_POLL_OA_DELAY
- DRM_I915_PERF_PROP_OA_ENABLE_INTERRUPT
As well as this new ioctl on the i915-perf file descriptor :
- I915_PERF_IOCTL_FLUSH_DATA
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1ce58036dbb3..654a6c9c2e56 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -448,7 +448,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
value = INTEL_INFO(dev_priv)->has_coherent_ggtt;
break;
case I915_PARAM_PERF_REVISION:
- value = 1;
+ value = 2;
break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 5/9] 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.
v2: Allow disabling polling completely with 0 value (Lionel)
v3: Version the new parameter (Joonas)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/i915_perf.c | 43 ++--
include/uapi/drm/i915_drm.h | 10
3 files changed, 52 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index feb0a377f353..b54929cbf1f9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1394,6 +1394,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 4504d4e18633..5ef9164a22a0 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -254,11 +254,11 @@
*/
#define OA_TAIL_MARGIN_NSEC10ULL
-/* 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;
@@ -335,6 +335,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
@@ -351,6 +353,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,
@@ -1892,9 +1895,9 @@ static void i915_oa_stream_enable(struct i915_perf_stream
*stream)
dev_priv->perf.oa.ops.oa_enable(stream);
- if (dev_priv->perf.oa.periodic)
+ if (dev_priv->perf.oa.periodic && stream->poll_oa_period)
hrtimer_start(_priv->perf.oa.poll_check_timer,
- ns_to_ktime(POLL_PERIOD),
+ ns_to_ktime(stream->poll_oa_period),
HRTIMER_MODE_REL_PINNED);
}
@@ -2258,13 +2261,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(_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;
}
@@ -2585,6 +2590,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)
@@ -2640,6 +2646,7 @@ static u64 oa_exponent_to_ns(struct drm_i915_private
*dev_priv, int exponent)
/**
* read_properties_unlocked - validate + copy userspace stream open properties
* @dev_priv: i915 device instance
+ * @open_flags: Flags set by userspace for the opening of the stream
* @uprops: The array of u64 key value pairs given by userspace
* @n_props: The number of key value pairs expected in @uprops
* @props: The stream configuration built up while validating properties
@@ -2653,6 +2660,7 @@ static u64 oa_exponent_to_ns(struct drm_i915_private
*dev_priv, int exponent)
* rule out defining new properties with ordering requirements in the future.
*/
static int read_properties_unlocked(struct drm_i915_private *dev_priv,
+ u32 open_flags,
[Intel-gfx] [PATCH v3 4/9] drm/i915/perf: introduce a versioning of the i915-perf uapi
Reporting this version will help application figure out what level of
the support the running kernel provides.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
include/uapi/drm/i915_drm.h | 20
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c6354f6cdbdb..1ce58036dbb3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -447,6 +447,9 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
case I915_PARAM_MMAP_GTT_COHERENT:
value = INTEL_INFO(dev_priv)->has_coherent_ggtt;
break;
+ case I915_PARAM_PERF_REVISION:
+ value = 1;
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 8304a7f1ec3f..d92d6e8f2cc7 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -562,6 +562,12 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_MMAP_GTT_COHERENT 52
+/*
+ * Revision of the i915-perf uAPI. The value returned helps determine what
+ * i915-perf features are available. See drm_i915_perf_property_id.
+ */
+#define I915_PARAM_PERF_REVISION 53
+
/* Must be kept compact -- no holes and well documented */
typedef struct drm_i915_getparam {
@@ -1602,23 +1608,31 @@ enum drm_i915_perf_property_id {
* Open the stream for a specific context handle (as used with
* execbuffer2). A stream opened for a specific context this way
* won't typically require root privileges.
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_CTX_HANDLE = 1,
/**
* A value of 1 requests the inclusion of raw OA unit reports as
* part of stream samples.
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_SAMPLE_OA,
/**
* The value specifies which set of OA unit metrics should be
* be configured, defining the contents of any OA unit reports.
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_OA_METRICS_SET,
/**
* The value specifies the size and layout of OA unit reports.
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_OA_FORMAT,
@@ -1628,6 +1642,8 @@ enum drm_i915_perf_property_id {
* from this exponent as follows:
*
* 80ns * 2^(period_exponent + 1)
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_OA_EXPONENT,
@@ -1659,6 +1675,8 @@ struct drm_i915_perf_open_param {
* to close and re-open a stream with the same configuration.
*
* It's undefined whether any pending data for the stream will be lost.
+ *
+ * This ioctl is available in perf revision 1.
*/
#define I915_PERF_IOCTL_ENABLE _IO('i', 0x0)
@@ -1666,6 +1684,8 @@ struct drm_i915_perf_open_param {
* Disable data capture for a stream.
*
* It is an error to try and read a stream that is disabled.
+ *
+ * This ioctl is available in perf revision 1.
*/
#define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/9] 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 poll
the OA registers for available data.
Right now the workaround against the OA tail pointer race condition
requires at least twice the internal kernel polling 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 polling timer.
v2: Use OA_TAKEN macro without the gtt_offset (Lionel)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 32 ++---
drivers/gpu/drm/i915/i915_perf.c | 200 ++-
2 files changed, 103 insertions(+), 129 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cc09caf3870e..feb0a377f353 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1892,6 +1892,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;
@@ -1932,23 +1938,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
@@ -1967,6 +1961,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 9ebf99f3d8d3..4687ab719fa7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -233,23 +233,14 @@
* for this earlier, as part of the oa_buffer_check to avoid lots of redundant
* read() attempts.
*
- * In effect we define a tail pointer for reading that lags the real tail
- * pointer by at least %OA_TAIL_MARGIN_NSEC nanoseconds, which gives enough
- * time for the corresponding reports to become visible to the CPU.
- *
- * To manage this we actually track two tail pointers:
- * 1) An 'aging' tail with an associated timestamp that is tracked until we
- * can trust the corresponding data is visible to the CPU; at which point
- * it is considered 'aged'.
- * 2) An 'aged' tail that can be used for read()ing.
- *
- * The two separate pointers let us decouple read()s from tail pointer aging.
- *
- * The tail pointers are checked and updated at a limited rate within a hrtimer
- * callback (the same callback that is used for delivering EPOLLIN events)
- *
- * Initially the tails are marked invalid with %INVALID_TAIL_PTR which
- * indicates that an updated tail pointer is needed.
+ * We workaround this issue in oa_buffer_check() by reading the reports in the
+ * OA buffer, starting from the tail reported by the HW until we find 2
+ * consecutive reports with their first 2 dwords of not at 0. Those dwords are
+ * also set to 0 once read and the whole buffer is cleared upon OA buffer
+ * initialization. The first dword is the reason for this report while the
+ * second is the timestamp, making the chances of having those 2
[Intel-gfx] [PATCH v3 7/9] 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.
v2: Version the new parameter (Joonas)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 54 +++-
include/uapi/drm/i915_drm.h | 10 ++
2 files changed, 50 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3ab389edf1de..39801a6e3021 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -243,7 +243,7 @@
* oa_buffer_check().
*
* 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
@@ -418,9 +418,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
@@ -442,8 +444,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(_priv->perf.oa.half_full_count);
u32 gtt_offset = i915_ggtt_offset(dev_priv->perf.oa.oa_buffer.vma);
int report_size = dev_priv->perf.oa.oa_buffer.format_size;
unsigned long flags;
@@ -454,7 +457,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(_priv->perf.oa.oa_buffer.ptr_lock, flags);
+ if (lock)
+ spin_lock_irqsave(_priv->perf.oa.oa_buffer.ptr_lock, flags);
hw_tail = dev_priv->perf.oa.ops.oa_hw_tail_read(dev_priv);
@@ -530,7 +534,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(_priv->perf.oa.oa_buffer.ptr_lock, flags);
+ dev_priv->perf.oa.half_full_count_last = half_full_count;
+
+ if (lock)
+ spin_unlock_irqrestore(_priv->perf.oa.oa_buffer.ptr_lock,
flags);
return OA_TAKEN(dev_priv->perf.oa.oa_buffer.tail - gtt_offset,
dev_priv->perf.oa.oa_buffer.head - gtt_offset) >=
report_size;
@@ -1124,9 +1131,9 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
* i915_oa_wait_unlocked - handles blocking IO until OA data available
* @stream: An i915-perf stream opened for OA metrics
*
- * Called when userspace tries to read() from a blocking stream FD opened
- * for OA metrics. It waits until the hrtimer callback finds a non-empty
- * OA buffer and wakes us.
+ * Called when userspace tries to read() from a blocking stream FD opened for
+ * OA metrics. It waits until either the hrtimer callback finds a non-empty OA
+ * buffer or the OA interrupt kicks in and wakes us.
*
* Note: it's acceptable to have this return with some false positives
* since any subsequent read handling will return -EAGAIN if there isn't
@@ -1143,7 +1150,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));
}
/**
@@ -1962,6 +1969,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(_priv->perf.oa.half_full_count,
+dev_priv->perf.oa.half_full_count_last);
+
if (dev_priv->perf.oa.periodic)
hrtimer_cancel(_priv->perf.oa.poll_check_timer);
}
@@ -2288,7 +2299,7 @@ static enum hrtimer_restart oa_poll_check_timer_cb(struct
hrtimer *hrtimer)
perf.oa.poll_check_timer);
struct i915_perf_stream *stream = dev_priv->perf.oa.exclusive_stream;
- if (oa_buffer_check_unlocked(dev_priv)) {
+
[Intel-gfx] [PATCH v3 0/9] drm/i915/perf: add OA interrupt support
Hi all, This third iteration adds an i915 perf revision number through getparam so that application can more easily find out what feature of i915-perf are available. The patches containing uAPI updates have been updated to indicate what version is required to those changes to be available. Cheers, Lionel Landwerlin (9): drm/i915/perf: rework aging tail workaround drm/i915/perf: move pollin setup to non hw specific code drm/i915/perf: only append status when data is available drm/i915/perf: introduce a versioning of the i915-perf uapi drm/i915/perf: add new open param to configure polling of OA buffer drm/i915: handle interrupts from the OA unit drm/i915/perf: add interrupt enabling parameter drm/i915/perf: add flushing ioctl drm/i915/perf: bump i915-perf revision drivers/gpu/drm/i915/i915_drv.c | 3 + drivers/gpu/drm/i915/i915_drv.h | 59 +++- drivers/gpu/drm/i915/i915_irq.c | 39 ++- drivers/gpu/drm/i915/i915_perf.c| 403 ++-- drivers/gpu/drm/i915/i915_reg.h | 7 + drivers/gpu/drm/i915/intel_ringbuffer.c | 2 + include/uapi/drm/i915_drm.h | 61 7 files changed, 390 insertions(+), 184 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 3/9] drm/i915/perf: only append status when data is available
The only bit of the status register we currently report in the
i915-perf stream is the "report loss" bit. Only report this when we
have some data to report with it. There was a kind of inconsistency
here in that we could report report loss without appending the reports
associated with the loss.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 54
1 file changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 55d25255bd67..4504d4e18633 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -636,6 +636,7 @@ static int append_oa_sample(struct i915_perf_stream *stream,
* Returns: 0 on success, negative error code on failure.
*/
static int gen8_append_oa_reports(struct i915_perf_stream *stream,
+ u32 oastatus,
char __user *buf,
size_t count,
size_t *offset)
@@ -681,6 +682,21 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
head, tail))
return -EIO;
+ /*
+* If there is nothing to read, don't append the status report yet,
+* wait until we have some data available.
+*/
+ if (!OA_TAKEN(tail, head))
+ return 0;
+
+ if (oastatus & GEN8_OASTATUS_REPORT_LOST) {
+ ret = append_oa_status(stream, buf, count, offset,
+ DRM_I915_PERF_RECORD_OA_REPORT_LOST);
+ if (ret)
+ return ret;
+ I915_WRITE(GEN8_OASTATUS,
+ oastatus & ~GEN8_OASTATUS_REPORT_LOST);
+ }
for (/* none */;
(taken = OA_TAKEN(tail, head));
@@ -880,16 +896,7 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
oastatus = I915_READ(GEN8_OASTATUS);
}
- if (oastatus & GEN8_OASTATUS_REPORT_LOST) {
- ret = append_oa_status(stream, buf, count, offset,
- DRM_I915_PERF_RECORD_OA_REPORT_LOST);
- if (ret)
- return ret;
- I915_WRITE(GEN8_OASTATUS,
- oastatus & ~GEN8_OASTATUS_REPORT_LOST);
- }
-
- return gen8_append_oa_reports(stream, buf, count, offset);
+ return gen8_append_oa_reports(stream, oastatus, buf, count, offset);
}
/**
@@ -913,6 +920,7 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
* Returns: 0 on success, negative error code on failure.
*/
static int gen7_append_oa_reports(struct i915_perf_stream *stream,
+ u32 oastatus1,
char __user *buf,
size_t count,
size_t *offset)
@@ -956,6 +964,21 @@ static int gen7_append_oa_reports(struct i915_perf_stream
*stream,
head, tail))
return -EIO;
+ /*
+* If there is nothing to read, don't append the status report yet,
+* wait until we have some data available.
+*/
+ if (!OA_TAKEN(tail, head))
+ return 0;
+
+ if (unlikely(oastatus1 & GEN7_OASTATUS1_REPORT_LOST)) {
+ ret = append_oa_status(stream, buf, count, offset,
+ DRM_I915_PERF_RECORD_OA_REPORT_LOST);
+ if (ret)
+ return ret;
+ dev_priv->perf.oa.gen7_latched_oastatus1 |=
+ GEN7_OASTATUS1_REPORT_LOST;
+ }
for (/* none */;
(taken = OA_TAKEN(tail, head));
@@ -1089,16 +1112,7 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
oastatus1 = I915_READ(GEN7_OASTATUS1);
}
- if (unlikely(oastatus1 & GEN7_OASTATUS1_REPORT_LOST)) {
- ret = append_oa_status(stream, buf, count, offset,
- DRM_I915_PERF_RECORD_OA_REPORT_LOST);
- if (ret)
- return ret;
- dev_priv->perf.oa.gen7_latched_oastatus1 |=
- GEN7_OASTATUS1_REPORT_LOST;
- }
-
- return gen7_append_oa_reports(stream, buf, count, offset);
+ return gen7_append_oa_reports(stream, oastatus1, buf, count, offset);
}
/**
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/9] drm/i915/perf: move pollin setup to non hw specific code
This isn't really gen specific stuff, so just move it to the common
code.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4687ab719fa7..55d25255bd67 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1389,11 +1389,6 @@ static void gen7_init_oa_buffer(struct drm_i915_private
*dev_priv)
* memory...
*/
memset(dev_priv->perf.oa.oa_buffer.vaddr, 0, OA_BUFFER_SIZE);
-
- /* Maybe make ->pollin per-stream state if we support multiple
-* concurrent streams in the future.
-*/
- dev_priv->perf.oa.pollin = false;
}
static void gen8_init_oa_buffer(struct drm_i915_private *dev_priv)
@@ -1447,12 +1442,6 @@ static void gen8_init_oa_buffer(struct drm_i915_private
*dev_priv)
* memory...
*/
memset(dev_priv->perf.oa.oa_buffer.vaddr, 0, OA_BUFFER_SIZE);
-
- /*
-* Maybe make ->pollin per-stream state if we support multiple
-* concurrent streams in the future.
-*/
- dev_priv->perf.oa.pollin = false;
}
static int alloc_oa_buffer(struct drm_i915_private *dev_priv)
@@ -1881,6 +1870,12 @@ static void i915_oa_stream_enable(struct
i915_perf_stream *stream)
{
struct drm_i915_private *dev_priv = stream->dev_priv;
+ /*
+* Maybe make ->pollin per-stream state if we support multiple
+* concurrent streams in the future.
+*/
+ dev_priv->perf.oa.pollin = false;
+
dev_priv->perf.oa.ops.oa_enable(stream);
if (dev_priv->perf.oa.periodic)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 6/9] drm/i915: 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.
v2: Use spin_lock_irq() to access the IMR register on Haswell (Chris)
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 b54929cbf1f9..8faa9cb2b620 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1400,6 +1400,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;
};
/**
@@ -1892,6 +1898,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 7c7e84e86c6a..1028d0d5542d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1171,6 +1171,12 @@ static void ironlake_rps_change_irq_handler(struct
drm_i915_private *dev_priv)
return;
}
+static void notify_perfmon_buffer_half_full(struct drm_i915_private *i915)
+{
+ atomic64_inc(>perf.oa.half_full_count);
+ wake_up_all(>perf.oa.poll_wq);
+}
+
static void vlv_c0_read(struct drm_i915_private *dev_priv,
struct intel_rps_ei *ei)
{
@@ -1447,6 +1453,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);
}
@@ -1468,6 +1477,12 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
tasklet_hi_schedule(>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])
{
@@ -1477,6 +1492,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)
@@ -1499,7 +1515,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]);
@@ -1523,9 +1539,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] >>
Re: [Intel-gfx] [PATCH 1/3] drm/i915/icl: move MG pll hw_state readout
On Mon, Feb 25, 2019 at 04:03:05PM -0800, Lucas De Marchi wrote:
> On Mon, Feb 25, 2019 at 10:42:12PM +0200, Ville Syrjälä wrote:
> >On Fri, Feb 22, 2019 at 03:23:22PM -0800, Lucas De Marchi wrote:
> >> Let the MG plls have their own hooks since it shares very little with
> >> other PLL types. It's also better so the platform info contains the info
> >> if the PLL is for MG PHY rather than relying on the PLL ids.
> >>
> >> Signed-off-by: Lucas De Marchi
> >
> >There's quite a bit more cleanup to be done in this area. As a start
> >https://patchwork.freedesktop.org/series/56354/ ;)
>
> I started reviewing that and even gave my r-b in some patches - first
> patches cause several conflicts with in-flight patches though. Not sure
> how beneficial they are.
The current code is quite messy, and thus hard to follow.
It should be cleaned up before we pile even more stuff on top.
People had already cargo culted all the crud from the older
implementations to the later ones.
We can't let the dirt accumulate indefinitely because eventually
the point comes where the thing either collapses under its own weight
or someone just decides to not even look at the previous code and
does the new thing totally differently. And that approach does not
scale because then everyone has to keep in mind N different ways
of doing the exact same thing. And also all the learnings from the
old code are forgotten and we probably get more bugs as a result.
> IMO last 3 patches could be standalone
> (particularly the one that is a bug fix, and doesn't depend on the
> previous ones)
Nothing prevents the patches from being reviewed/merged out of order.
>
> >This patch looks good to me. It'll conflict with my series though, but
> >no biggie.
> >Reviewed-by: Ville Syrjälä
>
> thanks
> Lucas De Marchi
>
> >
> >> ---
> >> drivers/gpu/drm/i915/intel_dpll_mgr.c | 122 --
> >> 1 file changed, 74 insertions(+), 48 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> >> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> >> index 0a42d11c4c33..e4ec73d415d9 100644
> >> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> >> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> >> @@ -2966,6 +2966,68 @@ static i915_reg_t icl_pll_id_to_enable_reg(enum
> >> intel_dpll_id id)
> >>return MG_PLL_ENABLE(icl_pll_id_to_tc_port(id));
> >> }
> >>
> >> +static bool mg_pll_get_hw_state(struct drm_i915_private *dev_priv,
> >> + struct intel_shared_dpll *pll,
> >> + struct intel_dpll_hw_state *hw_state)
> >> +{
> >> + const enum intel_dpll_id id = pll->info->id;
> >> + enum tc_port tc_port = icl_pll_id_to_tc_port(id);
> >> + intel_wakeref_t wakeref;
> >> + bool ret = false;
> >> + u32 val;
> >> +
> >> + wakeref = intel_display_power_get_if_enabled(dev_priv,
> >> + POWER_DOMAIN_PLLS);
> >> + if (!wakeref)
> >> + return false;
> >> +
> >> + val = I915_READ(MG_PLL_ENABLE(tc_port));
> >> + if (!(val & PLL_ENABLE))
> >> + goto out;
> >> +
> >> + hw_state->mg_refclkin_ctl = I915_READ(MG_REFCLKIN_CTL(tc_port));
> >> + hw_state->mg_refclkin_ctl &= MG_REFCLKIN_CTL_OD_2_MUX_MASK;
> >> +
> >> + hw_state->mg_clktop2_coreclkctl1 =
> >> + I915_READ(MG_CLKTOP2_CORECLKCTL1(tc_port));
> >> + hw_state->mg_clktop2_coreclkctl1 &=
> >> + MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK;
> >> +
> >> + hw_state->mg_clktop2_hsclkctl =
> >> + I915_READ(MG_CLKTOP2_HSCLKCTL(tc_port));
> >> + hw_state->mg_clktop2_hsclkctl &=
> >> + MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL_MASK |
> >> + MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL_MASK |
> >> + MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK |
> >> + MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK;
> >> +
> >> + hw_state->mg_pll_div0 = I915_READ(MG_PLL_DIV0(tc_port));
> >> + hw_state->mg_pll_div1 = I915_READ(MG_PLL_DIV1(tc_port));
> >> + hw_state->mg_pll_lf = I915_READ(MG_PLL_LF(tc_port));
> >> + hw_state->mg_pll_frac_lock = I915_READ(MG_PLL_FRAC_LOCK(tc_port));
> >> + hw_state->mg_pll_ssc = I915_READ(MG_PLL_SSC(tc_port));
> >> +
> >> + hw_state->mg_pll_bias = I915_READ(MG_PLL_BIAS(tc_port));
> >> + hw_state->mg_pll_tdc_coldst_bias =
> >> + I915_READ(MG_PLL_TDC_COLDST_BIAS(tc_port));
> >> +
> >> + if (dev_priv->cdclk.hw.ref == 38400) {
> >> + hw_state->mg_pll_tdc_coldst_bias_mask =
> >> MG_PLL_TDC_COLDST_COLDSTART;
> >> + hw_state->mg_pll_bias_mask = 0;
> >> + } else {
> >> + hw_state->mg_pll_tdc_coldst_bias_mask = -1U;
> >> + hw_state->mg_pll_bias_mask = -1U;
> >> + }
> >> +
> >> + hw_state->mg_pll_tdc_coldst_bias &=
> >> hw_state->mg_pll_tdc_coldst_bias_mask;
> >> + hw_state->mg_pll_bias &= hw_state->mg_pll_bias_mask;
> >> +
> >> + ret = true;
> >> +out:
> >> + intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS, wakeref);
> >> + return ret;
> >> +}
> >> +
> >> static bool
Re: [Intel-gfx] [RFC PATCH 04/42] drm/i915: introduce intel_memory_region
On Tue, 26 Feb 2019 at 13:00, Tvrtko Ursulin
wrote:
>
>
> Hi,
>
> Just some quick comments, not a full review. Possibly a repeat of some
> same comments from way back, not sure.
>
> On 14/02/2019 14:57, Matthew Auld wrote:
> > Support memory regions, as defined by a given (start, end), and allow
> > creating GEM objects which are backed by said region.
> >
> > Signed-off-by: Matthew Auld
> > Signed-off-by: Abdiel Janulgue
> > Cc: Joonas Lahtinen
> > ---
> > drivers/gpu/drm/i915/Makefile | 1 +
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_gem.c | 1 +
> > drivers/gpu/drm/i915/i915_gem_object.h| 9 +
> > drivers/gpu/drm/i915/intel_memory_region.c| 232 ++
> > drivers/gpu/drm/i915/intel_memory_region.h| 126 ++
> > drivers/gpu/drm/i915/selftests/huge_pages.c | 81 ++
> > .../drm/i915/selftests/i915_mock_selftests.h | 1 +
> > .../drm/i915/selftests/intel_memory_region.c | 128 ++
> > .../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
> > drivers/gpu/drm/i915/selftests/mock_region.c | 71 ++
> > drivers/gpu/drm/i915/selftests/mock_region.h | 35 +++
> > 12 files changed, 687 insertions(+)
> > create mode 100644 drivers/gpu/drm/i915/intel_memory_region.c
> > create mode 100644 drivers/gpu/drm/i915/intel_memory_region.h
> > create mode 100644 drivers/gpu/drm/i915/selftests/intel_memory_region.c
> > create mode 100644 drivers/gpu/drm/i915/selftests/mock_region.c
> > create mode 100644 drivers/gpu/drm/i915/selftests/mock_region.h
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index e5ce813d1936..96be264fa382 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -88,6 +88,7 @@ i915-y += \
> > intel_engine_cs.o \
> > intel_hangcheck.o \
> > intel_lrc.o \
> > + intel_memory_region.o \
> > intel_mocs.o \
> > intel_ringbuffer.o \
> > intel_uncore.o \
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 17fe942eaafa..0bea7d889284 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -72,6 +72,7 @@
> > #include "intel_wopcm.h"
> > #include "intel_workarounds.h"
> > #include "intel_uc.h"
> > +#include "intel_memory_region.h"
> >
> > #include "i915_gem.h"
> > #include "i915_gem_context.h"
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index b421bc7a2e26..92768ab294a4 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -5706,4 +5706,5 @@ int i915_gem_object_attach_phys(struct
> > drm_i915_gem_object *obj, int align)
> > #include "selftests/i915_gem_object.c"
> > #include "selftests/i915_gem_coherency.c"
> > #include "selftests/i915_gem.c"
> > +#include "selftests/intel_memory_region.c"
> > #endif
> > diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
> > b/drivers/gpu/drm/i915/i915_gem_object.h
> > index fab040331cdb..ac52f61e8ad1 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_object.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_object.h
> > @@ -87,6 +87,15 @@ struct drm_i915_gem_object {
> >
> > const struct drm_i915_gem_object_ops *ops;
> >
> > + /**
> > + * Memory region for this object.
> > + */
> > + struct intel_memory_region *memory_region;
> > + /**
> > + * List of memory region blocks allocated for this object.
> > + */
> > + struct list_head blocks;
> > +
> > struct {
> > /**
> >* @vma.lock: protect the list/tree of vmas
> > diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
> > b/drivers/gpu/drm/i915/intel_memory_region.c
> > new file mode 100644
> > index ..405d6d51194f
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/intel_memory_region.c
> > @@ -0,0 +1,232 @@
> > +/*
> > + * Copyright © 2018 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the
> > next
> > + * paragraph) shall be included in all copies or substantial portions of
> > the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND
Re: [Intel-gfx] [RFC PATCH 04/42] drm/i915: introduce intel_memory_region
Quoting Matthew Auld (2019-02-26 14:03:10)
> On Thu, 14 Feb 2019 at 15:16, Chris Wilson wrote:
> >
> > Quoting Matthew Auld (2019-02-14 14:57:02)
> > > +int
> > > +i915_memory_region_get_pages_buddy(struct drm_i915_gem_object *obj)
> > > +{
> > > + struct intel_memory_region *mem = obj->memory_region;
> > > + resource_size_t size = obj->base.size;
> > > + struct sg_table *st;
> > > + struct scatterlist *sg;
> > > + unsigned int sg_page_sizes;
> > > + unsigned long n_pages;
> > > +
> > > + GEM_BUG_ON(!IS_ALIGNED(size, mem->mm.min_size));
> > > + GEM_BUG_ON(!list_empty(>blocks));
> > > +
> > > + st = kmalloc(sizeof(*st), GFP_KERNEL);
> > > + if (!st)
> > > + return -ENOMEM;
> > > +
> > > + n_pages = div64_u64(size, mem->mm.min_size);
> >
> > min_size is a power of two.
> >
> > n_pages = size >> ilog2(min_size);
> >
> > would suffice. Keeping min_order would come in handy later.
> >
> > > +
> > > + if (sg_alloc_table(st, n_pages, GFP_KERNEL)) {
> > > + kfree(st);
> > > + return -ENOMEM;
> > > + }
> > > +
> > > + sg = st->sgl;
> > > + st->nents = 0;
> > > + sg_page_sizes = 0;
> > > +
> > > + mutex_lock(>mm_lock);
> > > +
> > > + do {
> > > + struct i915_gem_buddy_block *block;
> > > + unsigned int order;
> > > + u64 block_size;
> > > + u64 offset;
> > > +
> > > + order = fls(n_pages) - 1;
> > > + GEM_BUG_ON(order > mem->mm.max_order);
> > > +
> > > + do {
> > > + block = i915_gem_buddy_alloc(>mm, order);
> > > + if (!IS_ERR(block))
> > > + break;
> > > +
> > > + /* XXX: some kind of eviction pass, local to the
> > > device */
> > > + if (!order--)
> > > + goto err_free_blocks;
> > > + } while (1);
> > > +
> > > + n_pages -= 1 << order;
> >
> > BIT(order) so you don't have sign extension fun. Need to fix
> > i915_gem_internal.c!
> >
> > > +struct intel_memory_region_ops {
> > > + unsigned int flags;
> > > +
> > > + int (*init)(struct intel_memory_region *);
> > > + void (*release)(struct intel_memory_region *);
> > > +
> > > + struct drm_i915_gem_object *
> > > + (*object_create)(struct intel_memory_region *,
> > > +resource_size_t,
> > > +unsigned int);
> >
> > create_object()
> >
> > ops is acting as a factory here; and we are not operating on the object
> > itself.
> >
> > > +static int igt_mock_fill(void *arg)
> > > +{
> > > + struct intel_memory_region *mem = arg;
> > > + resource_size_t total = resource_size(>region);
> > > + resource_size_t page_size;
> > > + resource_size_t rem;
> > > + unsigned long max_pages;
> > > + unsigned long page_num;
> > > + LIST_HEAD(objects);
> > > + int err = 0;
> > > +
> > > + page_size = mem->mm.min_size;
> > > + max_pages = total / page_size;
> >
> > Hmm, 32b? Can resource_size_t be 64b on a 32b system?
> >
> > It must be to accommodate PAE.
> >
> > > +static struct drm_i915_gem_object *
> > > +mock_object_create(struct intel_memory_region *mem,
> > > + resource_size_t size,
> > > + unsigned int flags)
> > > +{
> > > + struct drm_i915_private *i915 = mem->i915;
> > > + struct drm_i915_gem_object *obj;
> > > +
> > > + if (size > BIT(mem->mm.max_order) * mem->mm.min_size)
> >
> > A mix of 64b and 32b types.
> >
> > if (size >> mem->mm.max_order + mem->mm.min_order)
> >
> > > + return ERR_PTR(-E2BIG);
> >
> > GEM_BUG_ON(overflows_type(size, obj->base.size);
> >
> > > + obj = i915_gem_object_alloc(i915);
> > > + if (!obj)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + drm_gem_private_object_init(>drm, >base, size);
> > > + i915_gem_object_init(obj, _region_obj_ops);
> > > +
> > > + obj->read_domains = I915_GEM_DOMAIN_CPU | I915_GEM_DOMAIN_GTT;
> > > + obj->cache_level = HAS_LLC(i915) ? I915_CACHE_LLC :
> > > I915_CACHE_NONE;
> >
> > i915_gem_object_set_cache_coherency() ?
>
> We do that as part of object_create_region(), but maybe that's not so hot?
I think tidier done together; and maybe you'll feel inspired to clean up
it a bit more as well.
> Also I just noticed that get_pages_buddy() returns -ENOSPC if we can't
> satisfy the request, for consistency that should probably be -ENOMEM?
Yes. ENOSPC returned to userspace currently means "batch could not fit
into the GTT after all constraints applied", and since this errno can
propagate to execbuf, we should strive for uniqueness. In this case not
being able to find memory on the device... ENOMEM. Although -ENOXMEM
would be better to indicate we ran out
Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Probe again type-c connectors that failed
On Fri, Feb 22, 2019 at 01:08:34PM -0800, José Roberto de Souza wrote:
> Unpowered type-c dongles can take some time to boot and be
> responsible, causing the probe to fail and sink never be detected
> without further actions from userspace.
>
> It was not a issue for older platforms because there was a hardware
> bridge between DDI/DP ports and type-c controller adding a implicit
> delay that hid this issue but ICL have type-c controllers integrated
> to the SOC bring this issue to users.
>
> So here if the probe failed when coming from a IRQ it returns
> INTEL_HOTPLUG_RETRY that will schedule another run of
> i915_hotplug_work_func() after 1 second what is time enough for
> those type-c dongles to boot.
>
> Cc: Ville Syrjälä
> Cc: Imre Deak
> Cc: Jani Nikula
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 1676a87f18cb..96bbcf5c9787 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -4056,6 +4056,8 @@ intel_ddi_hotplug(struct intel_encoder *encoder,
> struct intel_connector *connector,
> bool irq_received)
> {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> struct drm_modeset_acquire_ctx ctx;
> enum intel_hotplug_state state;
> int ret;
> @@ -4082,6 +4084,17 @@ intel_ddi_hotplug(struct intel_encoder *encoder,
> drm_modeset_acquire_fini();
> WARN(ret, "Acquiring modeset locks failed with %i\n", ret);
>
> + /*
> + * Unpowered type-c dongles can take some time to boot and be
> + * responsible, so here giving some type to those dongles to power up
> + * and then retrying the probe.
> + */
> + if (state == INTEL_HOTPLUG_NOCHANGE &&
> + connector->base.status != connector_status_connected &&
> + irq_received && intel_port_is_tc(dev_priv, encoder->port) &&
> + !dig_port->tc_legacy_port && !dig_port->dp.is_mst)
Based on the investigation by Jani et al, we have the similar problem with
HDMI, only during disconnect. So I think we could generalize by retrying
any time there is no change (except for MST where the driver always keeps
the connector in a disconnected state), regardless of the type of the
sink, since a no-change is suspect in any case: why would the sink signal
(with a long pulse) if there is no change?
For HDMI we'd also need to handle this in intel_hdmi.c.
Then Ville suggested to add a Chamelium test for this to IGT, could you
Jose look into that as well? Both the connect and disconnect races could
be tested, both on HDMI and DP, by generating the HPD early/late wrt. to
AUX/DDC starting/stopping to return valid data. I don't know if
Chamelium can do this, you'd have to find that out first.
--Imre
> + state = INTEL_HOTPLUG_RETRY;
> +
> return state;
> }
>
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 04/42] drm/i915: introduce intel_memory_region
On Thu, 14 Feb 2019 at 15:16, Chris Wilson wrote:
>
> Quoting Matthew Auld (2019-02-14 14:57:02)
> > +int
> > +i915_memory_region_get_pages_buddy(struct drm_i915_gem_object *obj)
> > +{
> > + struct intel_memory_region *mem = obj->memory_region;
> > + resource_size_t size = obj->base.size;
> > + struct sg_table *st;
> > + struct scatterlist *sg;
> > + unsigned int sg_page_sizes;
> > + unsigned long n_pages;
> > +
> > + GEM_BUG_ON(!IS_ALIGNED(size, mem->mm.min_size));
> > + GEM_BUG_ON(!list_empty(>blocks));
> > +
> > + st = kmalloc(sizeof(*st), GFP_KERNEL);
> > + if (!st)
> > + return -ENOMEM;
> > +
> > + n_pages = div64_u64(size, mem->mm.min_size);
>
> min_size is a power of two.
>
> n_pages = size >> ilog2(min_size);
>
> would suffice. Keeping min_order would come in handy later.
>
> > +
> > + if (sg_alloc_table(st, n_pages, GFP_KERNEL)) {
> > + kfree(st);
> > + return -ENOMEM;
> > + }
> > +
> > + sg = st->sgl;
> > + st->nents = 0;
> > + sg_page_sizes = 0;
> > +
> > + mutex_lock(>mm_lock);
> > +
> > + do {
> > + struct i915_gem_buddy_block *block;
> > + unsigned int order;
> > + u64 block_size;
> > + u64 offset;
> > +
> > + order = fls(n_pages) - 1;
> > + GEM_BUG_ON(order > mem->mm.max_order);
> > +
> > + do {
> > + block = i915_gem_buddy_alloc(>mm, order);
> > + if (!IS_ERR(block))
> > + break;
> > +
> > + /* XXX: some kind of eviction pass, local to the
> > device */
> > + if (!order--)
> > + goto err_free_blocks;
> > + } while (1);
> > +
> > + n_pages -= 1 << order;
>
> BIT(order) so you don't have sign extension fun. Need to fix
> i915_gem_internal.c!
>
> > +struct intel_memory_region_ops {
> > + unsigned int flags;
> > +
> > + int (*init)(struct intel_memory_region *);
> > + void (*release)(struct intel_memory_region *);
> > +
> > + struct drm_i915_gem_object *
> > + (*object_create)(struct intel_memory_region *,
> > +resource_size_t,
> > +unsigned int);
>
> create_object()
>
> ops is acting as a factory here; and we are not operating on the object
> itself.
>
> > +static int igt_mock_fill(void *arg)
> > +{
> > + struct intel_memory_region *mem = arg;
> > + resource_size_t total = resource_size(>region);
> > + resource_size_t page_size;
> > + resource_size_t rem;
> > + unsigned long max_pages;
> > + unsigned long page_num;
> > + LIST_HEAD(objects);
> > + int err = 0;
> > +
> > + page_size = mem->mm.min_size;
> > + max_pages = total / page_size;
>
> Hmm, 32b? Can resource_size_t be 64b on a 32b system?
>
> It must be to accommodate PAE.
>
> > +static struct drm_i915_gem_object *
> > +mock_object_create(struct intel_memory_region *mem,
> > + resource_size_t size,
> > + unsigned int flags)
> > +{
> > + struct drm_i915_private *i915 = mem->i915;
> > + struct drm_i915_gem_object *obj;
> > +
> > + if (size > BIT(mem->mm.max_order) * mem->mm.min_size)
>
> A mix of 64b and 32b types.
>
> if (size >> mem->mm.max_order + mem->mm.min_order)
>
> > + return ERR_PTR(-E2BIG);
>
> GEM_BUG_ON(overflows_type(size, obj->base.size);
>
> > + obj = i915_gem_object_alloc(i915);
> > + if (!obj)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + drm_gem_private_object_init(>drm, >base, size);
> > + i915_gem_object_init(obj, _region_obj_ops);
> > +
> > + obj->read_domains = I915_GEM_DOMAIN_CPU | I915_GEM_DOMAIN_GTT;
> > + obj->cache_level = HAS_LLC(i915) ? I915_CACHE_LLC : I915_CACHE_NONE;
>
> i915_gem_object_set_cache_coherency() ?
We do that as part of object_create_region(), but maybe that's not so hot?
Also I just noticed that get_pages_buddy() returns -ENOSPC if we can't
satisfy the request, for consistency that should probably be -ENOMEM?
> -Chris
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: remove unused bits from Panel Power Sequence State
On Mon, Feb 25, 2019 at 01:54:16PM -0800, Lucas De Marchi wrote:
> On Mon, Feb 25, 2019 at 09:28:06PM +0200, Ville Syrjälä wrote:
> >On Fri, Feb 22, 2019 at 04:34:48PM -0800, Lucas De Marchi wrote:
> >> No change in behavior. Just removing the unused bits since it makes it
> >> easier to compare them on new platforms and one of them was wrong
> >> (PP_SEQUENCE_STATE_ON_S1_0 vs the supposedly correct name
> >> PP_SEQUENCE_STATE_ON_S1_1)
> >>
> >> Cc: Rodrigo Vivi
> >> Signed-off-by: Lucas De Marchi
> >> ---
> >> drivers/gpu/drm/i915/i915_reg.h | 12 +++-
> >> 1 file changed, 3 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> index 730bb1917fd1..e855dae978db 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -4717,15 +4717,9 @@ enum {
> >> #define PP_SEQUENCE_SHIFT 28
> >> #define PP_CYCLE_DELAY_ACTIVE (1 << 27)
> >> #define PP_SEQUENCE_STATE_MASK 0x000f
> >> -#define PP_SEQUENCE_STATE_OFF_IDLE (0x0 << 0)
> >> -#define PP_SEQUENCE_STATE_OFF_S0_1 (0x1 << 0)
> >> -#define PP_SEQUENCE_STATE_OFF_S0_2 (0x2 << 0)
> >> -#define PP_SEQUENCE_STATE_OFF_S0_3 (0x3 << 0)
> >> -#define PP_SEQUENCE_STATE_ON_IDLE (0x8 << 0)
> >> -#define PP_SEQUENCE_STATE_ON_S1_0 (0x9 << 0)
> >> -#define PP_SEQUENCE_STATE_ON_S1_2 (0xa << 0)
> >> -#define PP_SEQUENCE_STATE_ON_S1_3 (0xb << 0)
> >> -#define PP_SEQUENCE_STATE_RESET (0xf << 0)
> >> +#define PP_SEQUENCE_STATE_OFF_IDLE 0x0
> >> +#define PP_SEQUENCE_STATE_ON_IDLE 0x8
> >> +#define PP_SEQUENCE_STATE_RESET 0xf
> >
> >But how am I supposed to remember what the register values mean?
>
> We only care for a small subset of those and the name should already be
> enough, no? We don't need to bring in all the possible bits from spec,
> even worse when they are misnamed. If we keep defining what we don't use
> it actually makes our life harder to crosscheck with the spec if
> everything is correct. Makes sense?
I have in the past looked at logs where I had to decode the state
bits to figure out where it was going.
>
> Lucas De Marchi
>
> >
> >>
> >> #define _PP_CONTROL 0x61204
> >> #define PP_CONTROL(pps_idx) _MMIO_PPS(pps_idx, _PP_CONTROL)
> >> --
> >> 2.20.0
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >--
> >Ville Syrjälä
> >Intel
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 30/42] drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET
Quoting Tvrtko Ursulin (2019-02-26 13:34:51) > > On 14/02/2019 14:57, Matthew Auld wrote: > > From: Abdiel Janulgue > > > > CPU mmap implementation depending on the object's backing pages. > > depends? > > > At the moment we introduce shmem and local-memory BAR fault handlers > > Note that the mmap type is done one at a time to circumvent the DRM > > offset manager limitation. Note that we multiplex mmap_gtt and > > Perhaps it is time to sort out the offset manager? I have a feeling that > would make things much easier/cleaner for us. I had skipped the changelog and didn't realise that was being blamed for getting mmaps so wrong... I don't buy that excuse. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 30/42] drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET
On 14/02/2019 14:57, Matthew Auld wrote:
From: Abdiel Janulgue
CPU mmap implementation depending on the object's backing pages.
depends?
At the moment we introduce shmem and local-memory BAR fault handlers
Note that the mmap type is done one at a time to circumvent the DRM
offset manager limitation. Note that we multiplex mmap_gtt and
Perhaps it is time to sort out the offset manager? I have a feeling that
would make things much easier/cleaner for us.
And I at least find mmap_origin a confusing term. It is nor a origin of
a mapping, but location of object backing store what matters, right?
mmap_offset through the same ioctl, and use the zero extending behaviour
of drm to differentiate between them, when we inspect the flags.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c| 5 +-
drivers/gpu/drm/i915/i915_drv.h| 3 +
drivers/gpu/drm/i915/i915_gem.c| 94 ++
drivers/gpu/drm/i915/i915_gem_object.h | 10 +++
include/uapi/drm/i915_drm.h| 30
5 files changed, 126 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b1200d7ebd13..90785030a0dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -423,6 +423,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
case I915_PARAM_HAS_EXEC_CAPTURE:
case I915_PARAM_HAS_EXEC_BATCH_FIRST:
case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
+ case I915_PARAM_MMAP_OFFSET_VERSION:
/* For the time being all of these are always true;
* if some supported hardware does not have one of these
* features this value needs to be provided from
@@ -2936,7 +2937,7 @@ const struct dev_pm_ops i915_pm_ops = {
static const struct vm_operations_struct i915_gem_vm_ops = {
.fault = i915_gem_fault,
.open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
+ .close = i915_gem_close,
};
static const struct file_operations i915_driver_fops = {
@@ -2991,7 +2992,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_OFFSET, i915_gem_mmap_gtt_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling_ioctl,
DRM_RENDER_ALLOW),
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 065953a9264f..c6ae157d0ede 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2770,6 +2770,8 @@ int i915_gem_mmap_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
int i915_gem_mmap_gtt_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+int i915_gem_mmap_offset_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
int i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
@@ -3073,6 +3075,7 @@ void i915_gem_suspend_late(struct drm_i915_private
*dev_priv);
void i915_gem_resume(struct drm_i915_private *dev_priv);
int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma);
vm_fault_t i915_gem_fault(struct vm_fault *vmf);
+void i915_gem_close(struct vm_area_struct *vma);
int i915_gem_object_wait(struct drm_i915_gem_object *obj,
unsigned int flags,
long timeout);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 48dbb57fbc6d..cc6c88ec749d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2123,11 +2123,12 @@ static void i915_gem_object_free_mmap_offset(struct
drm_i915_gem_object *obj)
drm_gem_free_mmap_offset(>base);
}
-int
-i915_gem_mmap_gtt(struct drm_file *file,
- struct drm_device *dev,
- u32 handle,
- u64 *offset)
+static int
+__assign_gem_object_mmap_data(struct drm_file *file,
+ u32 handle,
+ enum i915_cpu_mmap_origin_type mmap_type,
+ u64 mmap_flags,
+ u64 *offset)
{
struct drm_i915_gem_object *obj;
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno (rev2)
== Series Details == Series: series starting with [v2] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno (rev2) URL : https://patchwork.freedesktop.org/series/57203/ State : success == Summary == CI Bug Log - changes from CI_DRM_5659_full -> Patchwork_12304_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12304_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_mocs_settings@mocs-reset-bsd2: - shard-snb: NOTRUN -> SKIP [fdo#109271] +103 * igt@gem_mocs_settings@mocs-settings-vebox: - shard-iclb: NOTRUN -> SKIP [fdo#109287] +2 * igt@gem_softpin@evict-snoop-interruptible: - shard-iclb: NOTRUN -> SKIP [fdo#109312] * igt@i915_pm_rpm@fences: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +5 * igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9 * igt@kms_atomic_transition@5x-modeset-transitions-nonblocking: - shard-glk: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_atomic_transition@6x-modeset-transitions-nonblocking-fencing: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-snb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-glk: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-oldfb-render-d: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_chamelium@hdmi-crc-single: - shard-iclb: NOTRUN -> SKIP [fdo#109284] * igt@kms_cursor_crc@cursor-128x128-random: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x21-random: - shard-apl: PASS -> FAIL [fdo#103232] +2 * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: PASS -> FAIL [fdo#105767] * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-render: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +17 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen: - shard-iclb: PASS -> FAIL [fdo#103167] +8 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-onoff: - shard-glk: NOTRUN -> SKIP [fdo#109271] +8 * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-pgflip-blt: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +2 * igt@kms_invalid_dotclock: - shard-iclb: NOTRUN -> SKIP [fdo#109310] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-glk: PASS -> FAIL [fdo#108948] * igt@kms_plane@plane-position-covered-pipe-c-planes: - shard-apl: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_multiple@atomic-pipe-c-tiling-none: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_plane_scaling@pipe-a-scaler-with-rotation: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724] * igt@kms_psr@psr2_sprite_render: - shard-iclb: NOTRUN -> SKIP [fdo#109441] * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> FAIL [fdo#109016] - shard-glk: PASS -> DMESG-FAIL [fdo#105763] / [fdo#106538] * igt@kms_vblank@pipe-a-ts-continuation-modeset-hang: - shard-apl: PASS -> FAIL [fdo#104894] * igt@prime_vgem@fence-wait-bsd2: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +5 * igt@prime_vgem@fence-write-hang: - shard-apl: NOTRUN -> SKIP [fdo#109271] +8 * igt@v3d_get_param@get-bad-param: - shard-iclb: NOTRUN -> SKIP [fdo#109315] Possible fixes * igt@i915_pm_rpm@gem-idle: - shard-iclb: DMESG-WARN [fdo#107724] -> PASS +5 * igt@i915_pm_rpm@legacy-planes-dpms: - shard-iclb: INCOMPLETE [fdo#108840] / [fdo#109369] -> PASS * igt@i915_suspend@sysfs-reader: - shard-iclb: INCOMPLETE [fdo#107713] -> PASS * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-kbl: DMESG-WARN [fdo#107956] -> PASS +2 * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-hsw: DMESG-WARN [fdo#107956] -> PASS +1 - shard-iclb: DMESG-WARN [fdo#107956] -> PASS * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-snb: DMESG-WARN [fdo#107956] -> PASS +1 * igt@kms_color@pipe-a-ctm-max: -
Re: [Intel-gfx] [RFC PATCH 04/42] drm/i915: introduce intel_memory_region
Hi,
Just some quick comments, not a full review. Possibly a repeat of some
same comments from way back, not sure.
On 14/02/2019 14:57, Matthew Auld wrote:
Support memory regions, as defined by a given (start, end), and allow
creating GEM objects which are backed by said region.
Signed-off-by: Matthew Auld
Signed-off-by: Abdiel Janulgue
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 1 +
drivers/gpu/drm/i915/i915_gem_object.h| 9 +
drivers/gpu/drm/i915/intel_memory_region.c| 232 ++
drivers/gpu/drm/i915/intel_memory_region.h| 126 ++
drivers/gpu/drm/i915/selftests/huge_pages.c | 81 ++
.../drm/i915/selftests/i915_mock_selftests.h | 1 +
.../drm/i915/selftests/intel_memory_region.c | 128 ++
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
drivers/gpu/drm/i915/selftests/mock_region.c | 71 ++
drivers/gpu/drm/i915/selftests/mock_region.h | 35 +++
12 files changed, 687 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_memory_region.c
create mode 100644 drivers/gpu/drm/i915/intel_memory_region.h
create mode 100644 drivers/gpu/drm/i915/selftests/intel_memory_region.c
create mode 100644 drivers/gpu/drm/i915/selftests/mock_region.c
create mode 100644 drivers/gpu/drm/i915/selftests/mock_region.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index e5ce813d1936..96be264fa382 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -88,6 +88,7 @@ i915-y += \
intel_engine_cs.o \
intel_hangcheck.o \
intel_lrc.o \
+ intel_memory_region.o \
intel_mocs.o \
intel_ringbuffer.o \
intel_uncore.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 17fe942eaafa..0bea7d889284 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -72,6 +72,7 @@
#include "intel_wopcm.h"
#include "intel_workarounds.h"
#include "intel_uc.h"
+#include "intel_memory_region.h"
#include "i915_gem.h"
#include "i915_gem_context.h"
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b421bc7a2e26..92768ab294a4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5706,4 +5706,5 @@ int i915_gem_object_attach_phys(struct
drm_i915_gem_object *obj, int align)
#include "selftests/i915_gem_object.c"
#include "selftests/i915_gem_coherency.c"
#include "selftests/i915_gem.c"
+#include "selftests/intel_memory_region.c"
#endif
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index fab040331cdb..ac52f61e8ad1 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -87,6 +87,15 @@ struct drm_i915_gem_object {
const struct drm_i915_gem_object_ops *ops;
+ /**
+* Memory region for this object.
+*/
+ struct intel_memory_region *memory_region;
+ /**
+* List of memory region blocks allocated for this object.
+*/
+ struct list_head blocks;
+
struct {
/**
* @vma.lock: protect the list/tree of vmas
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
new file mode 100644
index ..405d6d51194f
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -0,0 +1,232 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "intel_memory_region.h"
+#include "i915_drv.h"
+
+static void
+memory_region_free_pages(struct drm_i915_gem_object *obj,
+struct sg_table *pages)
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
Quoting Alex Deucher (2019-02-25 21:31:43) > On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen > wrote: > > > > Quoting Dave Airlie (2019-02-25 12:24:48) > > > On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen > > > wrote: > > > > > > > > + dri-devel mailing list, especially for the buddy allocator part > > > > > > > > Quoting Dave Airlie (2019-02-15 02:47:07) > > > > > On Fri, 15 Feb 2019 at 00:57, Matthew Auld > > > > > wrote: > > > > > > > > > > > > In preparation for upcoming devices with device local memory, > > > > > > introduce the > > > > > > concept of different memory regions, and a simple buddy allocator > > > > > > to manage > > > > > > them. > > > > > > > > > > This is missing the information on why it's not TTM. > > > > > > > > > > Nothing against extending i915 gem off into doing stuff we already > > > > > have examples off in tree, but before you do that it would be good to > > > > > have a why we can't use TTM discussion in public. > > > > > > > > Glad that you asked. It's my fault that it was not included in > > > > the cover letter. I anticipated the question, but was travelling > > > > for a couple of days at the time this was sent. I didn't want > > > > to write a hasty explanation and then disappear, leaving others to > > > > take the heat. > > > > > > > > So here goes the less-hasty version: > > > > > > > > We did an analysis on the effort needed vs benefit gained of using > > > > TTM when this was started initially. The conclusion was that we > > > > already share the interesting bits of code through core DRM, really. > > > > > > > > Re-writing the memory handling to TTM would buy us more fine-grained > > > > locking. But it's more a trait of rewriting the memory handling with > > > > the information we have learned, than rewriting it to use TTM :) > > > > > > > > And further, we've been getting rid of struct_mutex at a steady phase > > > > in the past years, so we have a clear path to the fine-grained locking > > > > already in the not-so-distant future. With all this we did not see > > > > much gained from converting over, as the code sharing is already > > > > substantial. > > > > > > > > We also wanted to have the buddy allocator instead of a for loop making > > > > drm_mm allocations to make sure we can keep the memory fragmentation > > > > at bay. The intent is to move the buddy allocator to core DRM, to the > > > > benefit of all the drivers, if there is interest from community. It has > > > > been written as a strictly separate component with that in mind. > > > > > > > > And if you take the buddy allocator out of the patch set, the rest is > > > > mostly just vfuncing things up to be able to have different backing > > > > storages for objects. We took the opportunity to move over to the more > > > > valgrind friendly mmap while touching things, but it's something we > > > > have been contemplating anyway. And yeah, loads of selftests. > > > > > > > > That's really all that needed adding, and most of it is internal to > > > > i915 and not to do with uAPI. This means porting over an userspace > > > > driver doesn't require a substantial rewrite, but adding new a few > > > > new IOCTLs to set the preferred backing storage placements. > > > > > > > > All the previous GEM abstractions keep applying, so we did not see > > > > a justification to rewrite the kernel driver and userspace drivers. > > > > It would have just to made things look like TTM, when we already > > > > have the important parts of the code shared with TTM drivers > > > > behind the GEM interfaces which all our drivers sit on top of. > > > > > > a) you guys should be the community as well, if the buddy allocator is > > > useful in the core DRM get out there and try and see if anyone else > > > has a use case for it, like the GPU scheduler we have now (can i915 > > > use that yet? :-) > > > > Well, the buddy allocator should be useful for anybody wishing to have > > as continuous physical allocations as possible. I have naively assumed > > that would be almost everyone. So it would be only a question if others > > see the amount of work required to convert over is justified for them. > > > > For the common DRM scheduler, I think a solid move from the beginning > > would have been to factor out the i915 scheduler as it was most advanced > > in features :) Now there is a way more trivial common scheduler core with > > no easy path to transition without a feature regression. > > Can you elaborate? What features are missing from the drm gpu scheduler? Priority based pre-emption is the big thing coming to mind. But maybe we should not derail the discussion in this thread. The discussion should be in the archives, or we can start a new thread. > > We'd have to rewrite many of the more advanced features for that codebase > > before we could transition over. It's hard to justify such work, for > > that it would buy us very little compared to amount of work. > > > > Situation would be different if there was something
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] drm/i915: Skip scanning for signalers if we are already inflight (rev2)
== Series Details ==
Series: series starting with [01/11] drm/i915: Skip scanning for signalers if
we are already inflight (rev2)
URL : https://patchwork.freedesktop.org/series/57244/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5660 -> Patchwork_12309
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/57244/revisions/2/
Known issues
Here are the changes found in Patchwork_12309 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-gdg-551: NOTRUN -> SKIP [fdo#109271] +106
* igt@kms_busy@basic-flip-c:
- fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-gdg-551: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] +52
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#108566]
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: SKIP [fdo#109271] -> PASS
* igt@i915_pm_rpm@basic-rte:
- fi-bsw-kefka: FAIL [fdo#108800] -> PASS
* igt@i915_pm_rpm@module-reload:
- {fi-icl-y}: INCOMPLETE [fdo#108840] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
Participating hosts (42 -> 39)
--
Additional (2): fi-byt-j1900 fi-gdg-551
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5660 -> Patchwork_12309
CI_DRM_5660: 2cca9f74156f1061298a7249f7af80dcbb9178d9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4857: 25911cdde500aa6ddede601faec91741c6963c27 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12309: 37624d9dc7aa1a7e6b49ffaef07c05c01146b572 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
37624d9dc7aa drm/i915: Use __ffs() in for_each_priolist for more compact code
b09202593de8 drm/i915/execlists: Skip direct submission if only lite-restore
b6cd8c175fd0 drm/i915: Prioritise non-busywait semaphore workloads
1296737150c9 drm/i915: Use HW semaphores for inter-engine synchronisation on
gen8+
dcfb15979ec2 drm/i915: Compute the global scheduler caps
135a214d2a38 drm/i915: Keep timeline HWSP allocated until idle across the system
1531ba977791 drm/i915: Introduce i915_timeline.mutex
ef2ec8aa3d7a drm/i915: Make request allocation caches global
5e85ba1f drm/i915/execlists: Suppress redundant preemption
d2afc58479f7 drm/i915/execlists: Suppress mere WAIT preemption
2fb1e47f69e3 drm/i915: Skip scanning for signalers if we are already inflight
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12309/
___
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 [01/11] drm/i915: Skip scanning for signalers if we are already inflight (rev2)
== Series Details == Series: series starting with [01/11] drm/i915: Skip scanning for signalers if we are already inflight (rev2) URL : https://patchwork.freedesktop.org/series/57244/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Skip scanning for signalers if we are already inflight Okay! Commit: drm/i915/execlists: Suppress mere WAIT preemption Okay! Commit: drm/i915/execlists: Suppress redundant preemption Okay! Commit: drm/i915: Make request allocation caches global -drivers/gpu/drm/i915/selftests/../i915_drv.h:3581:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3578:16: warning: expression using sizeof(void) Commit: drm/i915: Introduce i915_timeline.mutex Okay! Commit: drm/i915: Keep timeline HWSP allocated until idle across the system Okay! Commit: drm/i915: Compute the global scheduler caps Okay! Commit: drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+ -O:drivers/gpu/drm/i915/i915_drv.c:351:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:351:25: warning: expression using sizeof(void) Commit: drm/i915: Prioritise non-busywait semaphore workloads Okay! Commit: drm/i915/execlists: Skip direct submission if only lite-restore Okay! Commit: drm/i915: Use __ffs() in for_each_priolist for more compact code 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 [01/11] drm/i915: Skip scanning for signalers if we are already inflight (rev2)
== Series Details == Series: series starting with [01/11] drm/i915: Skip scanning for signalers if we are already inflight (rev2) URL : https://patchwork.freedesktop.org/series/57244/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2fb1e47f69e3 drm/i915: Skip scanning for signalers if we are already inflight d2afc58479f7 drm/i915/execlists: Suppress mere WAIT preemption 5e85ba1f drm/i915/execlists: Suppress redundant preemption ef2ec8aa3d7a drm/i915: Make request allocation caches global -:162: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #162: new file mode 100644 -:167: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #167: FILE: drivers/gpu/drm/i915/i915_globals.c:1: +/* -:286: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #286: FILE: drivers/gpu/drm/i915/i915_globals.h:1: +/* -:627: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plist' - possible side-effects? #627: FILE: drivers/gpu/drm/i915/i915_scheduler.h:95: +#define priolist_for_each_request(it, plist, idx) \ + for (idx = 0; idx < ARRAY_SIZE((plist)->requests); idx++) \ + list_for_each_entry(it, &(plist)->requests[idx], sched.link) -:627: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'idx' - possible side-effects? #627: FILE: drivers/gpu/drm/i915/i915_scheduler.h:95: +#define priolist_for_each_request(it, plist, idx) \ + for (idx = 0; idx < ARRAY_SIZE((plist)->requests); idx++) \ + list_for_each_entry(it, &(plist)->requests[idx], sched.link) -:631: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plist' - possible side-effects? #631: FILE: drivers/gpu/drm/i915/i915_scheduler.h:99: +#define priolist_for_each_request_consume(it, n, plist, idx) \ + for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \ + list_for_each_entry_safe(it, n, \ +&(plist)->requests[idx - 1], \ +sched.link) -:631: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'idx' - possible side-effects? #631: FILE: drivers/gpu/drm/i915/i915_scheduler.h:99: +#define priolist_for_each_request_consume(it, n, plist, idx) \ + for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \ + list_for_each_entry_safe(it, n, \ +&(plist)->requests[idx - 1], \ +sched.link) total: 0 errors, 3 warnings, 4 checks, 808 lines checked 1531ba977791 drm/i915: Introduce i915_timeline.mutex 135a214d2a38 drm/i915: Keep timeline HWSP allocated until idle across the system dcfb15979ec2 drm/i915: Compute the global scheduler caps 1296737150c9 drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+ -:335: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #335: FILE: drivers/gpu/drm/i915/intel_gpu_commands.h:109: +#define MI_SEMAPHORE_SAD_GT_SDD (0<<12) ^ -:337: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #337: FILE: drivers/gpu/drm/i915/intel_gpu_commands.h:111: +#define MI_SEMAPHORE_SAD_LT_SDD (2<<12) ^ -:338: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #338: FILE: drivers/gpu/drm/i915/intel_gpu_commands.h:112: +#define MI_SEMAPHORE_SAD_LTE_SDD (3<<12) ^ -:339: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #339: FILE: drivers/gpu/drm/i915/intel_gpu_commands.h:113: +#define MI_SEMAPHORE_SAD_EQ_SDD (4<<12) ^ -:340: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #340: FILE: drivers/gpu/drm/i915/intel_gpu_commands.h:114: +#define MI_SEMAPHORE_SAD_NEQ_SDD (5<<12) ^ total: 0 errors, 0 warnings, 5 checks, 300 lines checked b6cd8c175fd0 drm/i915: Prioritise non-busywait semaphore workloads b09202593de8 drm/i915/execlists: Skip direct submission if only lite-restore 37624d9dc7aa drm/i915: Use __ffs() in for_each_priolist for more compact code ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for HDCP2.2 Phase II
== Series Details ==
Series: HDCP2.2 Phase II
URL : https://patchwork.freedesktop.org/series/57232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5659_full -> Patchwork_12303_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12303_full:
### IGT changes ###
Possible regressions
* {igt@kms_content_protection@type1} (NEW):
- shard-iclb: NOTRUN -> SKIP +2
New tests
-
New tests have been introduced between CI_DRM_5659_full and
Patchwork_12303_full:
### New IGT tests (3) ###
* igt@kms_content_protection@srm:
- Statuses : 6 skip(s)
- Exec time: [0.0] s
* igt@kms_content_protection@type1:
- Statuses : 6 skip(s)
- Exec time: [0.0] s
* igt@kms_content_protection@type1_mei_interface:
- Statuses : 6 skip(s)
- Exec time: [0.00, 0.02] s
Known issues
Here are the changes found in Patchwork_12303_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@bad-open:
- shard-snb: PASS -> INCOMPLETE [fdo#105411] / [fdo#107469]
* igt@gem_mocs_settings@mocs-reset-bsd2:
- shard-snb: NOTRUN -> SKIP [fdo#109271] +97
* igt@gem_mocs_settings@mocs-settings-vebox:
- shard-iclb: NOTRUN -> SKIP [fdo#109287] +2
* igt@gem_softpin@evict-snoop-interruptible:
- shard-iclb: NOTRUN -> SKIP [fdo#109312]
* igt@i915_pm_rpm@gem-mmap-gtt:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +3
* igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing:
- shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +7
* igt@kms_atomic_transition@5x-modeset-transitions-nonblocking:
- shard-glk: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-snb: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-hsw: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-glk: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-hang-oldfb-render-d:
- shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_chamelium@hdmi-crc-single:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]
* igt@kms_color@pipe-c-legacy-gamma:
- shard-glk: PASS -> FAIL [fdo#104782]
* {igt@kms_content_protection@srm} (NEW):
- shard-glk: NOTRUN -> SKIP [fdo#109271] +15
* {igt@kms_content_protection@type1} (NEW):
- shard-hsw: NOTRUN -> SKIP [fdo#109271] +2
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-apl: PASS -> FAIL [fdo#103232] +3
- shard-kbl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-kbl: PASS -> FAIL [fdo#109350]
- shard-apl: PASS -> FAIL [fdo#109350]
- shard-glk: PASS -> FAIL [fdo#109350]
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-ytiled:
- shard-glk: PASS -> FAIL [fdo#103184]
* igt@kms_fbcon_fbt@fbc:
- shard-iclb: PASS -> DMESG-WARN [fdo#109593]
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1
* igt@kms_flip@2x-modeset-vs-vblank-race-interruptible:
- shard-glk: PASS -> FAIL [fdo#103060]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen:
- shard-glk: PASS -> FAIL [fdo#103167] +2
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl: PASS -> INCOMPLETE [fdo#103665]
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-render:
- shard-kbl: NOTRUN -> SKIP [fdo#109271] +34
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen:
- shard-iclb: PASS -> FAIL [fdo#103167] +7
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-pgflip-blt:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +2
* igt@kms_invalid_dotclock:
- shard-iclb: NOTRUN -> SKIP [fdo#109310]
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713]
* igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb:
- shard-apl: NOTRUN -> FAIL [fdo#108145]
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
*
[Intel-gfx] [PATCH i-g-t 6/7] i915/gem_exec_nop: poll-sequential requires ordering between rings
In order to correctly serialise the order of execution between rings, we
need to flag the scratch address as being written. Make it so.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_nop.c | 152 +-
1 file changed, 133 insertions(+), 19 deletions(-)
diff --git a/tests/i915/gem_exec_nop.c b/tests/i915/gem_exec_nop.c
index 59a08ad08..b91b4d0f6 100644
--- a/tests/i915/gem_exec_nop.c
+++ b/tests/i915/gem_exec_nop.c
@@ -104,7 +104,7 @@ static double nop_on_ring(int fd, uint32_t handle, unsigned
ring_id,
return elapsed(, );
}
-static void poll_ring(int fd, unsigned ring, const char *name, int timeout)
+static void poll_ring(int fd, unsigned engine, const char *name, int timeout)
{
const int gen = intel_gen(intel_get_drm_devid(fd));
const uint32_t MI_ARB_CHK = 0x5 << 23;
@@ -112,29 +112,17 @@ static void poll_ring(int fd, unsigned ring, const char
*name, int timeout)
struct drm_i915_gem_exec_object2 obj;
struct drm_i915_gem_relocation_entry reloc[4], *r;
uint32_t *bbe[2], *state, *batch;
- unsigned engines[16], nengine, flags;
struct timespec tv = {};
unsigned long cycles;
+ unsigned flags;
uint64_t elapsed;
flags = I915_EXEC_NO_RELOC;
if (gen == 4 || gen == 5)
flags |= I915_EXEC_SECURE;
- nengine = 0;
- if (ring == ALL_ENGINES) {
- for_each_physical_engine(fd, ring) {
- if (!gem_can_store_dword(fd, ring))
- continue;
-
- engines[nengine++] = ring;
- }
- } else {
- gem_require_ring(fd, ring);
- igt_require(gem_can_store_dword(fd, ring));
- engines[nengine++] = ring;
- }
- igt_require(nengine);
+ gem_require_ring(fd, engine);
+ igt_require(gem_can_store_dword(fd, engine));
memset(, 0, sizeof(obj));
obj.handle = gem_create(fd, 4096);
@@ -198,7 +186,7 @@ static void poll_ring(int fd, unsigned ring, const char
*name, int timeout)
memset(, 0, sizeof(execbuf));
execbuf.buffers_ptr = to_user_pointer();
execbuf.buffer_count = 1;
- execbuf.flags = engines[0];
+ execbuf.flags = engine | flags;
cycles = 0;
do {
@@ -208,7 +196,6 @@ static void poll_ring(int fd, unsigned ring, const char
*name, int timeout)
execbuf.batch_start_offset =
(bbe[idx] - batch) * sizeof(*batch) - 64;
- execbuf.flags = engines[cycles % nengine] | flags;
gem_execbuf(fd, );
*bbe[!idx] = MI_BATCH_BUFFER_END;
@@ -227,6 +214,133 @@ static void poll_ring(int fd, unsigned ring, const char
*name, int timeout)
gem_close(fd, obj.handle);
}
+static void poll_sequential(int fd, const char *name, int timeout)
+{
+ const int gen = intel_gen(intel_get_drm_devid(fd));
+ const uint32_t MI_ARB_CHK = 0x5 << 23;
+ struct drm_i915_gem_execbuffer2 execbuf;
+ struct drm_i915_gem_exec_object2 obj[2];
+ struct drm_i915_gem_relocation_entry reloc[4], *r;
+ uint32_t *bbe[2], *state, *batch;
+ unsigned engines[16], nengine, engine, flags;
+ struct timespec tv = {};
+ unsigned long cycles;
+ uint64_t elapsed;
+ bool cached;
+
+ flags = I915_EXEC_NO_RELOC;
+ if (gen == 4 || gen == 5)
+ flags |= I915_EXEC_SECURE;
+
+ nengine = 0;
+ for_each_physical_engine(fd, engine) {
+ if (!gem_can_store_dword(fd, engine))
+ continue;
+
+ engines[nengine++] = engine;
+ }
+ igt_require(nengine);
+
+ memset(obj, 0, sizeof(obj));
+ obj[0].handle = gem_create(fd, 4096);
+ obj[0].flags = EXEC_OBJECT_WRITE;
+ cached = __gem_set_caching(fd, obj[0].handle, 1) == 0;
+ obj[1].handle = gem_create(fd, 4096);
+ obj[1].relocs_ptr = to_user_pointer(reloc);
+ obj[1].relocation_count = ARRAY_SIZE(reloc);
+
+ r = memset(reloc, 0, sizeof(reloc));
+ batch = gem_mmap__wc(fd, obj[1].handle, 0, 4096, PROT_WRITE);
+
+ for (unsigned int start_offset = 0;
+start_offset <= 128;
+start_offset += 128) {
+ uint32_t *b = batch + start_offset / sizeof(*batch);
+
+ r->target_handle = obj[0].handle;
+ r->offset = (b - batch + 1) * sizeof(uint32_t);
+ r->delta = 0;
+ r->read_domains = I915_GEM_DOMAIN_RENDER;
+ r->write_domain = I915_GEM_DOMAIN_RENDER;
+
+ *b = MI_STORE_DWORD_IMM | (gen < 6 ? 1 << 22 : 0);
+ if (gen >= 8) {
+ *++b = r->delta;
+ *++b = 0;
+ } else if (gen >= 4) {
+ r->offset += sizeof(uint32_t);
+ *++b = 0;
+ *++b
[Intel-gfx] [PATCH i-g-t 4/7] i915/gem_exec_whisper: Measure total power consumed
Show the total power consumed across all the whispers.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_whisper.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_whisper.c b/tests/i915/gem_exec_whisper.c
index 0b15fe431..6c3b53756 100644
--- a/tests/i915/gem_exec_whisper.c
+++ b/tests/i915/gem_exec_whisper.c
@@ -28,8 +28,9 @@
*/
#include "igt.h"
-#include "igt_gt.h"
#include "igt_debugfs.h"
+#include "igt_gpu_power.h"
+#include "igt_gt.h"
#include "igt_rand.h"
#include "igt_sysfs.h"
@@ -192,6 +193,8 @@ static void whisper(int fd, unsigned engine, unsigned flags)
unsigned int reloc_migrations = 0;
unsigned int reloc_interruptions = 0;
unsigned int eb_migrations = 0;
+ struct gpu_power_sample sample[2];
+ struct gpu_power power;
uint64_t old_offset;
int i, n, loc;
int debugfs;
@@ -202,6 +205,7 @@ static void whisper(int fd, unsigned engine, unsigned flags)
}
debugfs = igt_debugfs_dir(fd);
+ gpu_power_open();
nengine = 0;
if (engine == ALL_ENGINES) {
@@ -226,6 +230,7 @@ static void whisper(int fd, unsigned engine, unsigned flags)
init_hang();
intel_detect_and_clear_missed_interrupts(fd);
+ gpu_power_read(, [0]);
igt_fork(child, flags & FORKED ? sysconf(_SC_NPROCESSORS_ONLN) : 1) {
unsigned int pass;
@@ -495,6 +500,10 @@ static void whisper(int fd, unsigned engine, unsigned
flags)
fini_hang();
else
igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
+ if (gpu_power_read(, [1])) {
+ igt_info("Total energy used: %.1fmJ\n",
+gpu_power_J(, [0], [1]) * 1e3);
+ }
close(debugfs);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/7] lib: Add GPU power measurement
Read the RAPL power metrics courtesy of perf. Or your local HW
equivalent?
v2: uselocale()
Signed-off-by: Chris Wilson
---
lib/Makefile.sources | 2 +
lib/igt_gpu_power.c | 114 +++
lib/igt_gpu_power.h | 59 ++
lib/meson.build | 2 +
4 files changed, 177 insertions(+)
create mode 100644 lib/igt_gpu_power.c
create mode 100644 lib/igt_gpu_power.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 9711fef34..8763753b0 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -24,6 +24,8 @@ lib_source_list = \
igt_color_encoding.c\
igt_color_encoding.h\
igt_edid_template.h \
+ igt_gpu_power.c \
+ igt_gpu_power.h \
igt_gt.c\
igt_gt.h\
igt_gvt.c \
diff --git a/lib/igt_gpu_power.c b/lib/igt_gpu_power.c
new file mode 100644
index 0..a4e3c1420
--- /dev/null
+++ b/lib/igt_gpu_power.c
@@ -0,0 +1,114 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "igt_gpu_power.h"
+#include "igt_perf.h"
+
+static int filename_to_buf(const char *filename, char *buf, unsigned int sz)
+{
+ int fd;
+ ssize_t ret;
+
+ fd = open(filename, O_RDONLY);
+ if (fd < 0)
+ return -1;
+
+ ret = read(fd, buf, sz - 1);
+ close(fd);
+ if (ret < 1)
+ return -1;
+
+ buf[ret] = '\0';
+
+ return 0;
+}
+
+static uint64_t filename_to_u64(const char *filename, int base)
+{
+ char buf[64], *b;
+
+ if (filename_to_buf(filename, buf, sizeof(buf)))
+ return 0;
+
+ /*
+* Handle both single integer and key=value formats by skipping
+* leading non-digits.
+*/
+ b = buf;
+ while (*b && !isdigit(*b))
+ b++;
+
+ return strtoull(b, NULL, base);
+}
+
+static double filename_to_double(const char *filename)
+{
+ locale_t locale, oldlocale;
+ char buf[80];
+ double v;
+
+ if (filename_to_buf(filename, buf, sizeof(buf)))
+ return 0;
+
+ /* Replace user environment with plain C to match kernel format */
+ locale = newlocale(LC_ALL, "C", 0);
+ oldlocale = uselocale(locale);
+
+ v = strtod(buf, NULL);
+
+ uselocale(oldlocale);
+ freelocale(locale);
+
+ return v;
+}
+
+static uint64_t rapl_type_id(void)
+{
+ return filename_to_u64("/sys/devices/power/type", 10);
+}
+
+static uint64_t rapl_gpu_power(void)
+{
+ return filename_to_u64("/sys/devices/power/events/energy-gpu", 0);
+}
+
+static double rapl_gpu_power_scale(void)
+{
+ return filename_to_double("/sys/devices/power/events/energy-gpu.scale");
+}
+
+int gpu_power_open(struct gpu_power *power)
+{
+ power->fd = igt_perf_open(rapl_type_id(), rapl_gpu_power());
+ if (power->fd < 0) {
+ power->fd = -errno;
+ goto err;
+ }
+
+ power->scale = rapl_gpu_power_scale();
+ if (isnan(power->scale) || !power->scale) {
+ close(power->fd);
+ goto err;
+ }
+ power->scale *= 1e9;
+
+ return 0;
+
+err:
+ errno = 0;
+ return power->fd;
+}
+
+bool gpu_power_read(struct gpu_power *power, struct gpu_power_sample *s)
+{
+ return read(power->fd, s, sizeof(*s)) == sizeof(*s);
+}
+
+void gpu_power_close(struct gpu_power *power)
+{
+ close(power->fd);
+}
diff --git a/lib/igt_gpu_power.h b/lib/igt_gpu_power.h
new file mode 100644
index 0..4e1b747c0
--- /dev/null
+++ b/lib/igt_gpu_power.h
@@ -0,0 +1,59 @@
+/*
+ * Copyright © 2019 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#ifndef IGT_GPU_POWER_H
+#define IGT_GPU_POWER_H
+
+#include
+#include
+
+struct gpu_power {
+ int fd;
+
[Intel-gfx] [PATCH i-g-t 7/7] i915/gem_sync: Make switch-default asymmetric
To make the demonstration of the cheeky preemption more impactful, make
the second context a nop to contrast the first being 1024
MI_STORE_DWORD_IMM. Then if we execute and wait on the second context
before executing the first, the client latency is even more drastically
reduced.
To more clearly show any effect on wait reordering, measure the
alternative path and present both.
Signed-off-by: Chris Wilson
---
tests/i915/gem_sync.c | 40 +---
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/tests/i915/gem_sync.c b/tests/i915/gem_sync.c
index fb209977d..3e4feff32 100644
--- a/tests/i915/gem_sync.c
+++ b/tests/i915/gem_sync.c
@@ -651,7 +651,7 @@ switch_ring(int fd, unsigned ring, int num_children, int
timeout)
struct drm_i915_gem_relocation_entry reloc[1024];
struct drm_i915_gem_execbuffer2 execbuf;
} contexts[2];
- double start, elapsed;
+ double elapsed, baseline;
unsigned long cycles;
for (int i = 0; i < ARRAY_SIZE(contexts); i++) {
@@ -679,7 +679,7 @@ switch_ring(int fd, unsigned ring, int num_children, int
timeout)
c->object[1].handle = gem_create(fd, sz);
c->object[1].relocs_ptr = to_user_pointer(c->reloc);
- c->object[1].relocation_count = 1024;
+ c->object[1].relocation_count = 1024 * i;
batch = gem_mmap__cpu(fd, c->object[1].handle, 0, sz,
PROT_WRITE | PROT_READ);
@@ -688,7 +688,7 @@ switch_ring(int fd, unsigned ring, int num_children, int
timeout)
memset(c->reloc, 0, sizeof(c->reloc));
b = batch;
- for (int r = 0; r < 1024; r++) {
+ for (int r = 0; r < c->object[1].relocation_count; r++)
{
uint64_t offset;
c->reloc[r].presumed_offset =
c->object[0].offset;
@@ -722,26 +722,44 @@ switch_ring(int fd, unsigned ring, int num_children, int
timeout)
}
cycles = 0;
- elapsed = 0;
- start = gettime();
- do {
+ baseline = 0;
+ igt_until_timeout(timeout) {
do {
double this;
- gem_execbuf(fd, [0].execbuf);
gem_execbuf(fd, [1].execbuf);
+ gem_execbuf(fd, [0].execbuf);
this = gettime();
gem_sync(fd, contexts[1].object[1].handle);
- elapsed += gettime() - this;
+ gem_sync(fd, contexts[0].object[1].handle);
+ baseline += gettime() - this;
+ } while (++cycles & 1023);
+ }
+ baseline /= cycles;
+
+ cycles = 0;
+ elapsed = 0;
+ igt_until_timeout(timeout) {
+ do {
+ double this;
+ gem_execbuf(fd, [1].execbuf);
+ gem_execbuf(fd, [0].execbuf);
+
+ this = gettime();
gem_sync(fd, contexts[0].object[1].handle);
+ elapsed += gettime() - this;
+
+ gem_sync(fd, contexts[1].object[1].handle);
} while (++cycles & 1023);
- } while ((gettime() - start) < timeout);
- igt_info("%s%sompleted %ld cycles: %.3f us\n",
+ }
+ elapsed /= cycles;
+
+ igt_info("%s%sompleted %ld cycles: %.3f us, baseline %.3f us\n",
names[child % num_engines] ?: "",
names[child % num_engines] ? " c" : "C",
-cycles, elapsed*1e6/cycles);
+cycles, elapsed*1e6, baseline*1e6);
for (int i = 0; i < ARRAY_SIZE(contexts); i++) {
gem_close(fd, contexts[i].object[1].handle);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/7] lib/i915: Pretty print HW semaphores
Include whether the scheduler is using HW semaphore assistance in our
pretty debug strings, and make the caps known for requires.
Signed-off-by: Chris Wilson
---
lib/i915/gem_scheduler.c | 22 +++---
lib/i915/gem_scheduler.h | 2 ++
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/lib/i915/gem_scheduler.c b/lib/i915/gem_scheduler.c
index ad156306f..f9e052278 100644
--- a/lib/i915/gem_scheduler.c
+++ b/lib/i915/gem_scheduler.c
@@ -67,7 +67,7 @@ unsigned gem_scheduler_capability(int fd)
}
/**
- * gem_has_scheduler:
+ * gem_scheduler_enabled:
* @fd: open i915 drm file descriptor
*
* Feature test macro to query whether the driver has scheduling capability.
@@ -79,7 +79,7 @@ bool gem_scheduler_enabled(int fd)
}
/**
- * gem_has_ctx_priority:
+ * gem_scheduler_has_ctx_priority:
* @fd: open i915 drm file descriptor
*
* Feature test macro to query whether the driver supports assigning custom
@@ -92,7 +92,7 @@ bool gem_scheduler_has_ctx_priority(int fd)
}
/**
- * gem_has_preemption:
+ * gem_scheduler_has_preemption:
* @fd: open i915 drm file descriptor
*
* Feature test macro to query whether the driver supports preempting active
@@ -104,6 +104,20 @@ bool gem_scheduler_has_preemption(int fd)
LOCAL_I915_SCHEDULER_CAP_PREEMPTION;
}
+/**
+ * gem_scheduler_has_semaphores:
+ * @fd: open i915 drm file descriptor
+ *
+ * Feature test macro to query whether the driver supports using HW semaphores
+ * to schedule dependencies in parallel (using the HW to delay execution until
+ * ready to reduce latency).
+ */
+bool gem_scheduler_has_semaphores(int fd)
+{
+ return gem_scheduler_capability(fd) &
+ LOCAL_I915_SCHEDULER_CAP_SEMAPHORES;
+}
+
/**
* gem_scheduler_print_capability:
* @fd: open i915 drm file descriptor
@@ -122,4 +136,6 @@ void gem_scheduler_print_capability(int fd)
igt_info(" - With priority sorting\n");
if (caps & LOCAL_I915_SCHEDULER_CAP_PREEMPTION)
igt_info(" - With preemption enabled\n");
+ if (caps & LOCAL_I915_SCHEDULER_CAP_SEMAPHORES)
+ igt_info(" - With HW semaphores enabled\n");
}
diff --git a/lib/i915/gem_scheduler.h b/lib/i915/gem_scheduler.h
index 9fcb02665..ead3eacb5 100644
--- a/lib/i915/gem_scheduler.h
+++ b/lib/i915/gem_scheduler.h
@@ -27,11 +27,13 @@
#define LOCAL_I915_SCHEDULER_CAP_ENABLED (1 << 0)
#define LOCAL_I915_SCHEDULER_CAP_PRIORITY (1 << 1)
#define LOCAL_I915_SCHEDULER_CAP_PREEMPTION(1 << 2)
+#define LOCAL_I915_SCHEDULER_CAP_SEMAPHORES(1 << 3)
unsigned gem_scheduler_capability(int fd);
bool gem_scheduler_enabled(int fd);
bool gem_scheduler_has_ctx_priority(int fd);
bool gem_scheduler_has_preemption(int fd);
+bool gem_scheduler_has_semaphores(int fd);
void gem_scheduler_print_capability(int fd);
#endif /* GEM_SCHEDULER_H */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/7] i915/gem_exec_schedule: Measure semaphore power consumption
How much energy does spinning on a semaphore consume relative to plain
old spinning?
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 72 +-
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index a9383000a..4f0577b4e 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -29,9 +29,10 @@
#include
#include "igt.h"
-#include "igt_vgem.h"
+#include "igt_gpu_power.h"
#include "igt_rand.h"
#include "igt_sysfs.h"
+#include "igt_vgem.h"
#include "i915/gem_ring.h"
#define LO 0
@@ -1202,6 +1203,65 @@ static void test_pi_ringfull(int fd, unsigned int engine)
munmap(result, 4096);
}
+static void measure_semaphore_power(int i915)
+{
+ struct gpu_power power;
+ unsigned int engine, signaler;
+
+ igt_require(gpu_power_open() == 0);
+
+ for_each_physical_engine(i915, signaler) {
+ struct gpu_power_sample s_spin[2];
+ struct gpu_power_sample s_sema[2];
+ double baseline, total;
+ int64_t jiffie = 1;
+ igt_spin_t *spin;
+
+ spin = __igt_spin_batch_new(i915,
+ .engine = signaler,
+ .flags = IGT_SPIN_POLL_RUN);
+ gem_wait(i915, spin->handle, ); /* waitboost */
+ igt_assert(spin->running);
+ igt_spin_busywait_until_running(spin);
+
+ gpu_power_read(, _spin[0]);
+ usleep(100*1000);
+ gpu_power_read(, _spin[1]);
+
+ /* Add a waiter to each engine */
+ for_each_physical_engine(i915, engine) {
+ igt_spin_t *sema;
+
+ if (engine == signaler)
+ continue;
+
+ sema = __igt_spin_batch_new(i915,
+ .engine = engine,
+ .dependency = spin->handle);
+
+ igt_spin_batch_free(i915, sema);
+ }
+ usleep(10); /* just give the tasklets a chance to run */
+
+ gpu_power_read(, _sema[0]);
+ usleep(100*1000);
+ gpu_power_read(, _sema[1]);
+
+ igt_spin_batch_free(i915, spin);
+
+ baseline = gpu_power_W(, _spin[0], _spin[1]);
+ total = gpu_power_W(, _sema[0], _sema[1]);
+
+ igt_info("%s: %.1fmW + %.1fmW (total %1.fmW)\n",
+e__->name,
+1e3 * baseline,
+1e3 * (total - baseline),
+1e3 * total);
+ }
+
+ gpu_power_close();
+}
+
igt_main
{
const struct intel_execution_engine *e;
@@ -1362,6 +1422,16 @@ igt_main
}
}
+ igt_subtest_group {
+ igt_fixture {
+ igt_require(gem_scheduler_enabled(fd));
+ igt_require(gem_scheduler_has_semaphores(fd));
+ }
+
+ igt_subtest("semaphore-power")
+ measure_semaphore_power(fd);
+ }
+
igt_fixture {
igt_stop_hang_detector();
close(fd);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 5/7] i915/gem_exec_schedule: Verify that using HW semaphores doesn't block
We may use HW semaphores to schedule nearly-ready work such that they
are already spinning on the GPU waiting for the completion on another
engine. However, we don't want for that spinning task to actually block
any real work should it be scheduled.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 87 ++
1 file changed, 87 insertions(+)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 4f0577b4e..ae850c4a3 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -48,6 +48,10 @@
#define MAX_CONTEXTS 1024
+#define LOCAL_I915_EXEC_BSD_SHIFT (13)
+#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
+#define ENGINE_MASK (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
+
IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
static inline
@@ -320,6 +324,86 @@ static void smoketest(int fd, unsigned ring, unsigned
timeout)
}
}
+static uint32_t __batch_create(int i915, uint32_t offset)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle;
+
+ handle = gem_create(i915, ALIGN(offset + 4, 4096));
+ gem_write(i915, handle, offset, , sizeof(bbe));
+
+ return handle;
+}
+
+static uint32_t batch_create(int i915)
+{
+ return __batch_create(i915, 0);
+}
+
+static void semaphore_userlock(int i915)
+{
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = batch_create(i915),
+ };
+ igt_spin_t *spin = NULL;
+ unsigned int engine;
+ uint32_t scratch;
+
+ igt_require(gem_scheduler_has_preemption(i915));
+
+ /*
+* Given the use of semaphores to govern parallel submission
+* of nearly-ready work to HW, we still want to run actually
+* ready work immediately. Without semaphores, the dependent
+* work wouldn't be submitted so our ready work will run.
+*/
+
+ scratch = gem_create(i915, 4096);
+ for_each_physical_engine(i915, engine) {
+ if (!spin) {
+ spin = igt_spin_batch_new(i915,
+ .dependency = scratch,
+ .engine = engine);
+ } else {
+ typeof(spin->execbuf.flags) saved = spin->execbuf.flags;
+
+ spin->execbuf.flags &= ~ENGINE_MASK;
+ spin->execbuf.flags |= engine;
+
+ gem_execbuf(i915, >execbuf);
+
+ spin->execbuf.flags = saved;
+ }
+ }
+ igt_require(spin);
+ gem_close(i915, scratch);
+
+ /*
+* On all dependent engines, the request may be executing (busywaiting
+* on a HW semaphore) but it should not prevent any real work from
+* taking precedence.
+*/
+ scratch = gem_context_create(i915);
+ for_each_physical_engine(i915, engine) {
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ .flags = engine,
+ .rsvd1 = scratch,
+ };
+
+ if (engine == (spin->execbuf.flags & ENGINE_MASK))
+ continue;
+
+ gem_execbuf(i915, );
+ }
+ gem_context_destroy(i915, scratch);
+ gem_sync(i915, obj.handle); /* to hang unless we can preempt */
+ gem_close(i915, obj.handle);
+
+ igt_spin_batch_free(i915, spin);
+}
+
static void reorder(int fd, unsigned ring, unsigned flags)
#define EQUAL 1
{
@@ -1307,6 +1391,9 @@ igt_main
igt_require(gem_scheduler_has_ctx_priority(fd));
}
+ igt_subtest("semaphore-user")
+ semaphore_userlock(fd);
+
igt_subtest("smoketest-all")
smoketest(fd, ALL_ENGINES, 30);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/11] drm/i915: Skip scanning for signalers if we are already inflight
== Series Details == Series: series starting with [01/11] drm/i915: Skip scanning for signalers if we are already inflight URL : https://patchwork.freedesktop.org/series/57244/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h Kernel: arch/x86/boot/bzImage is ready (#1) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/4] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno
== Series Details == Series: series starting with [CI,1/4] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno URL : https://patchwork.freedesktop.org/series/57242/ State : failure == Summary == Applying: drm/i915: Replace global_seqno with a hangcheck heartbeat seqno Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_debugfs.c M drivers/gpu/drm/i915/intel_engine_cs.c M drivers/gpu/drm/i915/intel_hangcheck.c M drivers/gpu/drm/i915/intel_lrc.c M drivers/gpu/drm/i915/intel_ringbuffer.c M drivers/gpu/drm/i915/intel_ringbuffer.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_ringbuffer.h Auto-merging drivers/gpu/drm/i915/intel_ringbuffer.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_ringbuffer.c Auto-merging drivers/gpu/drm/i915/intel_lrc.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c Auto-merging drivers/gpu/drm/i915/intel_engine_cs.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_engine_cs.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915: Replace global_seqno with a hangcheck heartbeat seqno When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
So I'm not going to go into technical detail here, which I'll happily leave to Joonas et al, but I think a couple of general points deserve to be addressed. On Tue, 26 Feb 2019, Alex Deucher wrote: > On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen > wrote: >> Adding the suggested smaller amount of code vs. doing a much bigger >> rewrite is something of a straightforward choice with the amount of >> platforms and features in flight, especially when the end result is >> the same. > > Because you will probably never do it. It's almost always easier to > just incrementally add on to existing code. One could argue that GEM > evolved into more or less the exact same thing as TTM anyway so why > not bite the bullet and switch at some point? TTM works fine even for > UMA hardware. Surely we have lots of faults, but being averse to refactoring, reworking, and continuously rewriting parts of the driver is not among them by any stretch. Sometimes it's just for the general maintainability, sometimes to remodel stuff to neatly plug in support for that new piece of hardware, and everything in between. > There is a common misconception in big companies that if you utilize > shared infrastructure it will slow you down or you'll lose control of > your code which is I think what you are referring to. Ultimately, it > does sometimes raise the bar, but in the long term it benefits > everyone and usually it doesn't really add that much overhead. It > sounds like you are just feeding that misconception; you can't > contribute to or take advantage of any shared infrastructure because > that might slow you down. If that is the case, then why does upstream > first even matter? It seems like the only common code you want to > support is common code that you wrote in the first place. Again, on a general note, without actually checking the stats, I like to think we're pretty good citizens wrt actively using and contributing to shared infrastructure, and shared uapi. Especially so for KMS, and even when it really has slowed us down. So while you may have fair points about a specific case, and again I'll let Joonas address the specific case, I'll have to ask you to please not generalize that to the whole driver. 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 v3] drm/i915/query: Split out query item checks
Quoting Tvrtko Ursulin (2019-02-11 17:49:11) > > On 11/02/2019 17:32, Abdiel Janulgue wrote: > > This simplifies adding new query item objects. > > > > v2: Use query_hdr (Tvrtko, Chris). > > int instead of u32 in return (Tvrtko) > > v3: More naming fixes (Tvrtko) > > > > Signed-off-by: Abdiel Janulgue > > Cc: Joonas Lahtinen [snip] > Reviewed-by: Tvrtko Ursulin And pushed. Thanks for the patch and review, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/11] drm/i915: Skip scanning for signalers if we are already inflight
When a request has its priority changed, we traverse the graph of all of
its signalers to raise their priorities to match (priority inheritance).
If the request has already started executing its payload, we know that
all of its signalers must have signaled and we do not need to process
our list of signalers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 8bc042551692..38efefd22dce 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -18,6 +18,11 @@ node_to_request(const struct i915_sched_node *node)
return container_of(node, const struct i915_request, sched);
}
+static inline bool node_started(const struct i915_sched_node *node)
+{
+ return i915_request_started(node_to_request(node));
+}
+
static inline bool node_signaled(const struct i915_sched_node *node)
{
return i915_request_completed(node_to_request(node));
@@ -301,6 +306,10 @@ static void __i915_schedule(struct i915_request *rq,
list_for_each_entry(dep, , dfs_link) {
struct i915_sched_node *node = dep->signaler;
+ /* If we are already flying, we know we have no signalers */
+ if (node_started(node))
+ continue;
+
/*
* Within an engine, there can be no cycle, but we may
* refer to the same dependency chain multiple times
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/11] drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+
Having introduced per-context seqno, we now have a means to identity
progress across the system without feel of rollback as befell the
global_seqno. That is we can program a MI_SEMAPHORE_WAIT operation in
advance of submission safe in the knowledge that our target seqno and
address is stable.
However, since we are telling the GPU to busy-spin on the target address
until it matches the signaling seqno, we only want to do so when we are
sure that busy-spin will be completed quickly. To achieve this we only
submit the request to HW once the signaler is itself executing (modulo
preemption causing us to wait longer), and we only do so for default and
above priority requests (so that idle priority tasks never themselves
hog the GPU waiting for others).
As might be reasonably expected, HW semaphores excel in inter-engine
synchronisation microbenchmarks (where the reduced latency / increased
throughput more than offset the power cost of spinning on a second ring)
and have significant improvement for single clients that utilize multiple
engines (typically media players), without regressing multiple clients
that can saturate the system.
v3: Drop the older NEQ branch, now we pin the signaler's HWSP anyway.
v4: Tell the world and include it as part of scheduler caps.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 138 +-
drivers/gpu/drm/i915/i915_request.h | 1 +
drivers/gpu/drm/i915/i915_sw_fence.c | 4 +-
drivers/gpu/drm/i915/i915_sw_fence.h | 3 +
drivers/gpu/drm/i915/intel_engine_cs.c| 1 +
drivers/gpu/drm/i915/intel_gpu_commands.h | 5 +
drivers/gpu/drm/i915/intel_lrc.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 ++
include/uapi/drm/i915_drm.h | 1 +
10 files changed, 158 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c6354f6cdbdb..c08abdef5eb6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -351,7 +351,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 = 0;
+ value = !!(dev_priv->caps.scheduler &
I915_SCHEDULER_CAP_SEMAPHORES);
break;
case I915_PARAM_HAS_SECURE_BATCHES:
value = capable(CAP_SYS_ADMIN);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d354967d6ae8..59e30b8c4ee9 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -22,8 +22,9 @@
*
*/
-#include
#include
+#include
+#include
#include
#include
#include
@@ -32,9 +33,16 @@
#include "i915_active.h"
#include "i915_reset.h"
+struct execute_cb {
+ struct list_head link;
+ struct irq_work work;
+ struct i915_sw_fence *fence;
+};
+
static struct i915_global_request {
struct kmem_cache *slab_requests;
struct kmem_cache *slab_dependencies;
+ struct kmem_cache *slab_execute_cbs;
} global;
static const char *i915_fence_get_driver_name(struct dma_fence *fence)
@@ -325,6 +333,69 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (tmp != rq);
}
+static void irq_execute_cb(struct irq_work *wrk)
+{
+ struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
+
+ i915_sw_fence_complete(cb->fence);
+ kmem_cache_free(global.slab_execute_cbs, cb);
+}
+
+static void __notify_execute_cb(struct i915_request *rq)
+{
+ struct execute_cb *cb;
+
+ lockdep_assert_held(>lock);
+
+ if (list_empty(>execute_cb))
+ return;
+
+ list_for_each_entry(cb, >execute_cb, link)
+ irq_work_queue(>work);
+
+ /*
+* XXX Rollback on __i915_request_unsubmit()
+*
+* In the future, perhaps when we have an active time-slicing scheduler,
+* it will be interesting to unsubmit parallel execution and remove
+* busywaits from the GPU until their master is restarted. This is
+* quite hairy, we have to carefully rollback the fence and do a
+* preempt-to-idle cycle on the target engine, all the while the
+* master execute_cb may refire.
+*/
+ INIT_LIST_HEAD(>execute_cb);
+}
+
+static int
+i915_request_await_execution(struct i915_request *rq,
+struct i915_request *signal,
+gfp_t gfp)
+{
+ struct execute_cb *cb;
+
+ if (i915_request_is_active(signal))
+ return 0;
+
+ cb = kmem_cache_alloc(global.slab_execute_cbs, gfp);
+ if (!cb)
+ return -ENOMEM;
+
+ cb->fence = >submit;
+ i915_sw_fence_await(cb->fence);
+ init_irq_work(>work, irq_execute_cb);
[Intel-gfx] [PATCH 07/11] drm/i915: Compute the global scheduler caps
Do a pass over all the engines upon starting to determine the global
scheduler capability flags (those that are agreed upon by all).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 39 +
drivers/gpu/drm/i915/intel_lrc.c| 6
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++
4 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 713ed6fbdcc8..f6fe10fce0ec 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4700,6 +4700,8 @@ static int __i915_gem_restart_engines(void *data)
}
}
+ intel_engines_set_scheduler_caps(i915);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index b7b626195eda..ef49b1b0537b 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -608,6 +608,45 @@ int intel_engine_setup_common(struct intel_engine_cs
*engine)
return err;
}
+void intel_engines_set_scheduler_caps(struct drm_i915_private *i915)
+{
+ static const struct {
+ u8 engine;
+ u8 sched;
+ } map[] = {
+#define MAP(x, y) { ilog2(I915_ENGINE_HAS_##x), ilog2(I915_SCHEDULER_CAP_##y) }
+ MAP(PREEMPTION, PREEMPTION),
+#undef MAP
+ };
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ u32 enabled, disabled;
+
+ enabled = 0;
+ disabled = 0;
+ for_each_engine(engine, i915, id) { /* all engines must agree! */
+ int i;
+
+ if (engine->schedule)
+ enabled |= (I915_SCHEDULER_CAP_ENABLED |
+ I915_SCHEDULER_CAP_PRIORITY);
+ else
+ disabled |= (I915_SCHEDULER_CAP_ENABLED |
+I915_SCHEDULER_CAP_PRIORITY);
+
+ for (i = 0; i < ARRAY_SIZE(map); i++) {
+ if (engine->flags & BIT(map[i].engine))
+ enabled |= BIT(map[i].sched);
+ else
+ disabled |= BIT(map[i].sched);
+ }
+ }
+
+ i915->caps.scheduler = enabled & ~disabled;
+ if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_ENABLED))
+ i915->caps.scheduler = 0;
+}
+
static void __intel_context_unpin(struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 29b2a2f34edb..f57cfe2fc078 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2327,12 +2327,6 @@ void intel_execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->flags |= I915_ENGINE_SUPPORTS_STATS;
if (engine->i915->preempt_context)
engine->flags |= I915_ENGINE_HAS_PREEMPTION;
-
- engine->i915->caps.scheduler =
- I915_SCHEDULER_CAP_ENABLED |
- I915_SCHEDULER_CAP_PRIORITY;
- if (intel_engine_has_preemption(engine))
- engine->i915->caps.scheduler |= I915_SCHEDULER_CAP_PREEMPTION;
}
static void
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 5284f243931a..b8ec7e40a59b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -576,6 +576,8 @@ intel_engine_has_preemption(const struct intel_engine_cs
*engine)
return engine->flags & I915_ENGINE_HAS_PREEMPTION;
}
+void intel_engines_set_scheduler_caps(struct drm_i915_private *i915);
+
static inline bool __execlists_need_preempt(int prio, int last)
{
/*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/11] drm/i915: Keep timeline HWSP allocated until idle across the system
In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until its use across entire system has completed,
as any other timeline active on the GPU may still refer back to the
already retired timeline. We both have to delay recycling available
cachelines and unpinning old HWSP until the next idle point.
An easy option would be to simply keep all used HWSP until the system as
a whole was idle, i.e. we could release them all at once on parking.
However, on a busy system, we may never see a global idle point,
essentially meaning the resource will be leaked until we are forced to
do a GC pass. We already employ a fine-grained idle detection mechanism
for vma, which we can reuse here so that each cacheline can be freed
immediately after the last request using it is retired.
v3: Keep track of the activity of each cacheline.
v4: cacheline_free() on canceling the seqno tracking
v5: Finally with a testcase to exercise wraparound
v6: Pack cacheline into empty bits of page-aligned vaddr
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin #v5
---
drivers/gpu/drm/i915/i915_request.c | 31 +-
drivers/gpu/drm/i915/i915_request.h | 11 +
drivers/gpu/drm/i915/i915_timeline.c | 290 --
drivers/gpu/drm/i915/i915_timeline.h | 11 +-
.../gpu/drm/i915/selftests/i915_timeline.c| 113 +++
5 files changed, 417 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 719d1a5ab082..d354967d6ae8 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -325,11 +325,6 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (tmp != rq);
}
-static u32 timeline_get_seqno(struct i915_timeline *tl)
-{
- return tl->seqno += 1 + tl->has_initial_breadcrumb;
-}
-
static void move_to_timeline(struct i915_request *request,
struct i915_timeline *timeline)
{
@@ -532,8 +527,10 @@ struct i915_request *
i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context
*ctx)
{
struct drm_i915_private *i915 = engine->i915;
- struct i915_request *rq;
struct intel_context *ce;
+ struct i915_timeline *tl;
+ struct i915_request *rq;
+ u32 seqno;
int ret;
lockdep_assert_held(>drm.struct_mutex);
@@ -610,24 +607,27 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
}
}
- rq->rcustate = get_state_synchronize_rcu();
-
INIT_LIST_HEAD(>active_list);
+
+ tl = ce->ring->timeline;
+ ret = i915_timeline_get_seqno(tl, rq, );
+ if (ret)
+ goto err_free;
+
rq->i915 = i915;
rq->engine = engine;
rq->gem_context = ctx;
rq->hw_context = ce;
rq->ring = ce->ring;
- rq->timeline = ce->ring->timeline;
+ rq->timeline = tl;
GEM_BUG_ON(rq->timeline == >timeline);
- rq->hwsp_seqno = rq->timeline->hwsp_seqno;
+ rq->hwsp_seqno = tl->hwsp_seqno;
+ rq->hwsp_cacheline = tl->hwsp_cacheline;
+ rq->rcustate = get_state_synchronize_rcu(); /* acts as smp_mb() */
spin_lock_init(>lock);
- dma_fence_init(>fence,
- _fence_ops,
- >lock,
- rq->timeline->fence_context,
- timeline_get_seqno(rq->timeline));
+ dma_fence_init(>fence, _fence_ops, >lock,
+ tl->fence_context, seqno);
/* We bump the ref for the fence chain */
i915_sw_fence_init(_request_get(rq)->submit, submit_notify);
@@ -687,6 +687,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
GEM_BUG_ON(!list_empty(>sched.signalers_list));
GEM_BUG_ON(!list_empty(>sched.waiters_list));
+err_free:
kmem_cache_free(global.slab_requests, rq);
err_unreserve:
mutex_unlock(>ring->timeline->mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index be3ded6bcf56..ea1e6f0ade53 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -38,6 +38,7 @@ struct drm_file;
struct drm_i915_gem_object;
struct i915_request;
struct i915_timeline;
+struct i915_timeline_cacheline;
struct i915_capture_list {
struct i915_capture_list *next;
@@ -148,6 +149,16 @@ struct i915_request {
*/
const u32 *hwsp_seqno;
+ /*
+* If we need to access the timeline's seqno for this request in
+* another request, we need to keep a read reference to this associated
+* cacheline, so that we do not free and recycle it before the foriegn
+* observers have completed. Hence, we keep a pointer to the cacheline
+* inside the timeline's HWSP vma, but it is only valid while this
+* request has not completed
[Intel-gfx] [PATCH 11/11] drm/i915: Use __ffs() in for_each_priolist for more compact code
Gcc has a slight preference if we use __ffs() to subtract one from the
index once rather than each use:
__execlists_submission_tasklet 28672847 -20
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
b/drivers/gpu/drm/i915/i915_scheduler.h
index 24c2c027fd2c..068a6750540f 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -100,9 +100,11 @@ struct i915_priolist {
list_for_each_entry(it, &(plist)->requests[idx], sched.link)
#define priolist_for_each_request_consume(it, n, plist, idx) \
- for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \
+ for (; \
+(plist)->used ? (idx = __ffs((plist)->used)), 1 : 0; \
+(plist)->used &= ~BIT(idx)) \
list_for_each_entry_safe(it, n, \
-&(plist)->requests[idx - 1], \
+&(plist)->requests[idx], \
sched.link)
void i915_sched_node_init(struct i915_sched_node *node);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/11] drm/i915: Introduce i915_timeline.mutex
A simple mutex used for guarding the flow of requests in and out of the
timeline. In the short-term, it will be used only to guard the addition
of requests into the timeline, taken on alloc and released on commit so
that only one caller can construct a request into the timeline
(important as the seqno and ring pointers must be serialised). This will
be used by observers to ensure that the seqno/hwsp is stable. Later,
when we have reduced retiring to only operate on a single timeline at a
time, we can then use the mutex as the sole guard required for retiring.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c| 6 +-
drivers/gpu/drm/i915/i915_timeline.c | 1 +
drivers/gpu/drm/i915/i915_timeline.h | 2 ++
drivers/gpu/drm/i915/selftests/i915_request.c | 4 +---
drivers/gpu/drm/i915/selftests/mock_timeline.c | 1 +
5 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index c65f6c990fdd..719d1a5ab082 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -563,6 +563,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
return ERR_CAST(ce);
reserve_gt(i915);
+ mutex_lock(>ring->timeline->mutex);
/* Move our oldest request to the slab-cache (if not in use!) */
rq = list_first_entry(>ring->request_list, typeof(*rq), ring_link);
@@ -688,6 +689,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
kmem_cache_free(global.slab_requests, rq);
err_unreserve:
+ mutex_unlock(>ring->timeline->mutex);
unreserve_gt(i915);
intel_context_unpin(ce);
return ERR_PTR(ret);
@@ -880,7 +882,7 @@ void i915_request_add(struct i915_request *request)
GEM_TRACE("%s fence %llx:%lld\n",
engine->name, request->fence.context, request->fence.seqno);
- lockdep_assert_held(>i915->drm.struct_mutex);
+ lockdep_assert_held(>timeline->mutex);
trace_i915_request_add(request);
/*
@@ -991,6 +993,8 @@ void i915_request_add(struct i915_request *request)
*/
if (prev && i915_request_completed(prev))
i915_request_retire_upto(prev);
+
+ mutex_unlock(>timeline->mutex);
}
static unsigned long local_clock_us(unsigned int *cpu)
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index b2202d2e58a2..87a80558da28 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -162,6 +162,7 @@ int i915_timeline_init(struct drm_i915_private *i915,
timeline->fence_context = dma_fence_context_alloc(1);
spin_lock_init(>lock);
+ mutex_init(>mutex);
INIT_ACTIVE_REQUEST(>barrier);
INIT_ACTIVE_REQUEST(>last_request);
diff --git a/drivers/gpu/drm/i915/i915_timeline.h
b/drivers/gpu/drm/i915/i915_timeline.h
index 7bec7d2e45bf..36c3849f7108 100644
--- a/drivers/gpu/drm/i915/i915_timeline.h
+++ b/drivers/gpu/drm/i915/i915_timeline.h
@@ -44,6 +44,8 @@ struct i915_timeline {
#define TIMELINE_CLIENT 0 /* default subclass */
#define TIMELINE_ENGINE 1
+ struct mutex mutex; /* protects the flow of requests */
+
unsigned int pin_count;
const u32 *hwsp_seqno;
struct i915_vma *hwsp_ggtt;
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 7da52e3d67af..7e1b65b8eb19 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -141,14 +141,12 @@ static int igt_fence_wait(void *arg)
err = -ENOMEM;
goto out_locked;
}
- mutex_unlock(>drm.struct_mutex); /* safe as we are single user */
if (dma_fence_wait_timeout(>fence, false, T) != -ETIME) {
pr_err("fence wait success before submit (expected
timeout)!\n");
- goto out_device;
+ goto out_locked;
}
- mutex_lock(>drm.struct_mutex);
i915_request_add(request);
mutex_unlock(>drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/selftests/mock_timeline.c
b/drivers/gpu/drm/i915/selftests/mock_timeline.c
index d2de9ece2118..416d85233263 100644
--- a/drivers/gpu/drm/i915/selftests/mock_timeline.c
+++ b/drivers/gpu/drm/i915/selftests/mock_timeline.c
@@ -14,6 +14,7 @@ void mock_timeline_init(struct i915_timeline *timeline, u64
context)
timeline->fence_context = context;
spin_lock_init(>lock);
+ mutex_init(>mutex);
INIT_ACTIVE_REQUEST(>barrier);
INIT_ACTIVE_REQUEST(>last_request);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/11] drm/i915/execlists: Suppress redundant preemption
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We can avoid this if we take the boost into account when
checking if the preemption request is valid.
v2: After preemption the active request will be after the preemptee if
they end up with equal priority.
v3: Tvrtko pointed out that this, the existing logic, makes
I915_PRIORITY_WAIT non-preemptible. Document this interesting quirk!
v4: Prove Tvrtko was right about WAIT being non-preemptible and test it.
v5: Except not all priorities were made equal, and the WAIT not preempting
is only if we start off as !NEWCLIENT.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 38
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0e20f3bc8210..dba19baf6808 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -164,6 +164,8 @@
#define WA_TAIL_DWORDS 2
#define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
+#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT)
+
static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
struct intel_engine_cs *engine,
struct intel_context *ce);
@@ -190,8 +192,30 @@ static inline int rq_prio(const struct i915_request *rq)
static int effective_prio(const struct i915_request *rq)
{
+ int prio = rq_prio(rq);
+
+ /*
+* On unwinding the active request, we give it a priority bump
+* equivalent to a freshly submitted request. This protects it from
+* being gazumped again, but it would be preferable if we didn't
+* let it be gazumped in the first place!
+*
+* See __unwind_incomplete_requests()
+*/
+ if (~prio & ACTIVE_PRIORITY && __i915_request_has_started(rq)) {
+ /*
+* After preemption, we insert the active request at the
+* end of the new priority level. This means that we will be
+* _lower_ priority than the preemptee all things equal (and
+* so the preemption is valid), so adjust our comparison
+* accordingly.
+*/
+ prio |= ACTIVE_PRIORITY;
+ prio--;
+ }
+
/* Restrict mere WAIT boosts from triggering preemption */
- return rq_prio(rq) | __NO_PREEMPTION;
+ return prio | __NO_PREEMPTION;
}
static int queue_prio(const struct intel_engine_execlists *execlists)
@@ -359,7 +383,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
{
struct i915_request *rq, *rn, *active = NULL;
struct list_head *uninitialized_var(pl);
- int prio = I915_PRIORITY_INVALID | I915_PRIORITY_NEWCLIENT;
+ int prio = I915_PRIORITY_INVALID | ACTIVE_PRIORITY;
lockdep_assert_held(>timeline.lock);
@@ -390,9 +414,15 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
* The active request is now effectively the start of a new client
* stream, so give it the equivalent small priority bump to prevent
* it being gazumped a second time by another peer.
+*
+* One consequence of this preemption boost is that we may jump
+* over lesser priorities (such as I915_PRIORITY_WAIT), effectively
+* making those priorities non-preemptible. They will be moved forward
+* in the priority queue, but they will not gain immediate access to
+* the GPU.
*/
- if (!(prio & I915_PRIORITY_NEWCLIENT)) {
- prio |= I915_PRIORITY_NEWCLIENT;
+ if (~prio & ACTIVE_PRIORITY && __i915_request_has_started(active)) {
+ prio |= ACTIVE_PRIORITY;
active->sched.attr.priority = prio;
list_move_tail(>sched.link,
i915_sched_lookup_priolist(engine, prio));
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/11] drm/i915: Prioritise non-busywait semaphore workloads
We don't want to busywait on the GPU if we have other work to do. If we
give non-busywaiting workloads higher (initial) priority than workloads
that require a busywait, we will prioritise work that is ready to run
immediately. We then also have to be careful that we don't give earlier
semaphores an accidental boost because later work doesn't wait on other
rings, hence we keep a history of semaphore usage of the dependency chain.
Testcase: igt/gem_exec_schedule/semaphore
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 16
drivers/gpu/drm/i915/i915_scheduler.c | 5 +
drivers/gpu/drm/i915/i915_scheduler.h | 9 ++---
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
4 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 59e30b8c4ee9..1524de65b37f 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -813,6 +813,7 @@ emit_semaphore_wait(struct i915_request *to,
*cs++ = 0;
intel_ring_advance(to, cs);
+ to->sched.semaphore |= I915_SCHED_HAS_SEMAPHORE;
return 0;
}
@@ -1083,6 +1084,21 @@ void i915_request_add(struct i915_request *request)
if (engine->schedule) {
struct i915_sched_attr attr = request->gem_context->sched;
+ /*
+* Boost actual workloads past semaphores!
+*
+* With semaphores we spin on one engine waiting for another,
+* simply to reduce the latency of starting our work when
+* the signaler completes. However, if there is any other
+* work that we could be doing on this engine instead, that
+* is better utilisation and will reduce the overall duration
+* of the current work. To avoid PI boosting a semaphore
+* far in the distance past over useful work, we keep a history
+* of any semaphore use along our dependency chain.
+*/
+ if (!request->sched.semaphore)
+ attr.priority |= I915_PRIORITY_NOSEMAPHORE;
+
/*
* Boost priorities to new clients (new request flows).
*
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 50018ad30233..fd684b9ed108 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -39,6 +39,7 @@ void i915_sched_node_init(struct i915_sched_node *node)
INIT_LIST_HEAD(>waiters_list);
INIT_LIST_HEAD(>link);
node->attr.priority = I915_PRIORITY_INVALID;
+ node->semaphore = 0;
}
static struct i915_dependency *
@@ -69,6 +70,10 @@ bool __i915_sched_node_add_dependency(struct i915_sched_node
*node,
dep->signaler = signal;
dep->flags = flags;
+ /* Keep track of whether anyone on this chain has a semaphore */
+ if (signal->semaphore && !node_started(signal))
+ node->semaphore |= signal->semaphore << 1;
+
ret = true;
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
b/drivers/gpu/drm/i915/i915_scheduler.h
index 5196ce07b6c2..24c2c027fd2c 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -24,14 +24,15 @@ enum {
I915_PRIORITY_INVALID = INT_MIN
};
-#define I915_USER_PRIORITY_SHIFT 2
+#define I915_USER_PRIORITY_SHIFT 3
#define I915_USER_PRIORITY(x) ((x) << I915_USER_PRIORITY_SHIFT)
#define I915_PRIORITY_COUNT BIT(I915_USER_PRIORITY_SHIFT)
#define I915_PRIORITY_MASK (I915_PRIORITY_COUNT - 1)
-#define I915_PRIORITY_WAIT ((u8)BIT(0))
-#define I915_PRIORITY_NEWCLIENT((u8)BIT(1))
+#define I915_PRIORITY_WAIT ((u8)BIT(0))
+#define I915_PRIORITY_NEWCLIENT((u8)BIT(1))
+#define I915_PRIORITY_NOSEMAPHORE ((u8)BIT(2))
#define __NO_PREEMPTION (I915_PRIORITY_WAIT)
@@ -74,6 +75,8 @@ struct i915_sched_node {
struct list_head waiters_list; /* those after us, they depend upon us */
struct list_head link;
struct i915_sched_attr attr;
+ unsigned long semaphore;
+#define I915_SCHED_HAS_SEMAPHORE BIT(0)
};
struct i915_dependency {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 53d6f7fdb50e..2268860cca44 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -164,7 +164,7 @@
#define WA_TAIL_DWORDS 2
#define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
-#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT)
+#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT | I915_PRIORITY_NOSEMAPHORE)
static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
struct intel_engine_cs *engine,
--
2.20.1
[Intel-gfx] [PATCH 02/11] drm/i915/execlists: Suppress mere WAIT preemption
WAIT is occasionally suppressed by virtue of preempted requests being
promoted to NEWCLIENT if they have not all ready received that boost.
Make this consistent for all WAIT boosts that they are not allowed to
preempt executing contexts and are merely granted the right to be at the
front of the queue for the next execution slot. This is in keeping with
the desire that the WAIT boost be a minor tweak that does not give
excessive promotion to its user and open ourselves to trivial abuse.
The problem with the inconsistent WAIT preemption becomes more apparent
as the preemption is propagated across the engines, where one engine may
preempt and the other not, and we be relying on the exact execution
order being consistent across engines (e.g. using HW semaphores to
coordinate parallel execution).
v2: Also protect GuC submission from false preemption loops.
v3: Build bug safeguards and better debug messages for st.
v4: Do the priority bumping in unsubmit (i.e. on preemption/reset
unwind), applying it earlier during submit causes out-of-order execution
combined with execute fences.
v5: Call sw_fence_fini for our dummy request (Matthew)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin #v3
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_request.c | 15 ++
drivers/gpu/drm/i915/i915_scheduler.c | 1 -
drivers/gpu/drm/i915/i915_scheduler.h | 2 +
drivers/gpu/drm/i915/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 9 +-
drivers/gpu/drm/i915/selftests/intel_lrc.c | 163
6 files changed, 189 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 935db5548f80..00a1ea7cd907 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -353,11 +353,14 @@ void __i915_request_submit(struct i915_request *request)
/* We may be recursing from the signal callback of another i915 fence */
spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+
GEM_BUG_ON(test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags));
set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
+
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags) &&
!i915_request_enable_breadcrumb(request))
intel_engine_queue_breadcrumbs(engine);
+
spin_unlock(>lock);
engine->emit_fini_breadcrumb(request,
@@ -401,10 +404,22 @@ void __i915_request_unsubmit(struct i915_request *request)
/* We may be recursing from the signal callback of another i915 fence */
spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+
+ /*
+* As we do not allow WAIT to preempt inflight requests,
+* once we have executed a request, along with triggering
+* any execution callbacks, we must preserve its ordering
+* within the non-preemptible FIFO.
+*/
+ BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
+ request->sched.attr.priority |= __NO_PREEMPTION;
+
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
i915_request_cancel_breadcrumb(request);
+
GEM_BUG_ON(!test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags));
clear_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
+
spin_unlock(>lock);
/* Transfer back from the global per-engine timeline to per-context */
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 38efefd22dce..9fb96ff57a29 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -322,7 +322,6 @@ static void __i915_schedule(struct i915_request *rq,
if (node_signaled(p->signaler))
continue;
- GEM_BUG_ON(p->signaler->attr.priority <
node->attr.priority);
if (prio > READ_ONCE(p->signaler->attr.priority))
list_move_tail(>dfs_link, );
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
b/drivers/gpu/drm/i915/i915_scheduler.h
index dbe9cb7ecd82..54bd6c89817e 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -33,6 +33,8 @@ enum {
#define I915_PRIORITY_WAIT ((u8)BIT(0))
#define I915_PRIORITY_NEWCLIENT((u8)BIT(1))
+#define __NO_PREEMPTION (I915_PRIORITY_WAIT)
+
struct i915_sched_attr {
/**
* @priority: execution and service priority
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 20cbceeabeae..a2846ea1e62c 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -720,7 +720,7 @@ static inline int rq_prio(const struct i915_request *rq)
static inline int port_prio(const struct execlist_port *port)
{
- return
[Intel-gfx] [PATCH 04/11] drm/i915: Make request allocation caches global
As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity lifetimes, but you can
also argue that activity is temporal across the system) it is the
default behaviour of the system at large to amalgamate matching caches.
The benefit for us is much reduced pointer dancing along the frequent
allocation paths.
v2: Defer shrinking until after a global grace period for futureproofing
multiple consumers of the slab caches, similar to the current strategy
for avoiding shrinking too early.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_active.c| 7 +-
drivers/gpu/drm/i915/i915_active.h| 1 +
drivers/gpu/drm/i915/i915_drv.h | 3 -
drivers/gpu/drm/i915/i915_gem.c | 34 +-
drivers/gpu/drm/i915/i915_globals.c | 113 ++
drivers/gpu/drm/i915/i915_globals.h | 15 +++
drivers/gpu/drm/i915/i915_pci.c | 8 +-
drivers/gpu/drm/i915/i915_request.c | 53 ++--
drivers/gpu/drm/i915/i915_request.h | 10 ++
drivers/gpu/drm/i915/i915_scheduler.c | 66 +++---
drivers/gpu/drm/i915/i915_scheduler.h | 34 +-
drivers/gpu/drm/i915/intel_guc_submission.c | 3 +-
drivers/gpu/drm/i915/intel_lrc.c | 6 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 17 ---
drivers/gpu/drm/i915/selftests/intel_lrc.c| 2 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 45 ---
.../gpu/drm/i915/selftests/mock_gem_device.c | 26
drivers/gpu/drm/i915/selftests/mock_request.c | 12 +-
drivers/gpu/drm/i915/selftests/mock_request.h | 7 --
20 files changed, 313 insertions(+), 150 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_globals.c
create mode 100644 drivers/gpu/drm/i915/i915_globals.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1787e1299b1b..a1d834068765 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -77,6 +77,7 @@ i915-y += \
i915_gem_tiling.o \
i915_gem_userptr.o \
i915_gemfs.o \
+ i915_globals.o \
i915_query.o \
i915_request.o \
i915_scheduler.o \
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index db7bb5bd5add..d9f6471ac16c 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -294,7 +294,12 @@ int __init i915_global_active_init(void)
return 0;
}
-void __exit i915_global_active_exit(void)
+void i915_global_active_shrink(void)
+{
+ kmem_cache_shrink(global.slab_cache);
+}
+
+void i915_global_active_exit(void)
{
kmem_cache_destroy(global.slab_cache);
}
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index 12b5c1d287d1..5fbd9102384b 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -420,6 +420,7 @@ static inline void i915_active_fini(struct i915_active
*ref) { }
#endif
int i915_global_active_init(void);
+void i915_global_active_shrink(void);
void i915_global_active_exit(void);
#endif /* _I915_ACTIVE_H_ */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cc09caf3870e..f16016b330b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1473,9 +1473,6 @@ struct drm_i915_private {
struct kmem_cache *objects;
struct kmem_cache *vmas;
struct kmem_cache *luts;
- struct kmem_cache *requests;
- struct kmem_cache *dependencies;
- struct kmem_cache *priorities;
const struct intel_device_info __info; /* Use INTEL_INFO() to access. */
struct intel_runtime_info __runtime; /* Use RUNTIME_INFO() to access. */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2b261524cfa4..713ed6fbdcc8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -42,6 +42,7 @@
#include "i915_drv.h"
#include "i915_gem_clflush.h"
#include "i915_gemfs.h"
+#include "i915_globals.h"
#include "i915_reset.h"
#include "i915_trace.h"
#include "i915_vgpu.h"
@@ -187,6 +188,8 @@ void i915_gem_unpark(struct drm_i915_private *i915)
if (unlikely(++i915->gt.epoch == 0)) /* keep 0 as invalid */
i915->gt.epoch = 1;
+ i915_globals_unpark();
+
intel_enable_gt_powersave(i915);
i915_update_gfx_val(i915);
if (INTEL_GEN(i915) >= 6)
@@ -2892,12 +2895,11 @@ static void shrink_caches(struct drm_i915_private *i915)
* filled slabs to prioritise allocating from the mostly full slabs,
* with the aim of reducing fragmentation.
*/
-
[Intel-gfx] [PATCH 10/11] drm/i915/execlists: Skip direct submission if only lite-restore
If we resubmitting the active context, simply skip the submission as
performing the submission from the interrupt handler has higher
throughput than continually provoking lite-restores. If however, we find
ourselves with a new client, we check whether or not we can dequeue into
the second port or to resolve preemption.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2268860cca44..3e9f7103f31f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1205,12 +1205,26 @@ static void __submit_queue_imm(struct intel_engine_cs
*engine)
tasklet_hi_schedule(>tasklet);
}
-static void submit_queue(struct intel_engine_cs *engine, int prio)
+static bool inflight(const struct intel_engine_execlists *execlists,
+const struct i915_request *rq)
{
- if (prio > engine->execlists.queue_priority_hint) {
- engine->execlists.queue_priority_hint = prio;
+ const struct i915_request *active = port_request(execlists->port);
+
+ return active && active->hw_context == rq->hw_context;
+}
+
+static void submit_queue(struct intel_engine_cs *engine,
+const struct i915_request *rq)
+{
+ struct intel_engine_execlists *execlists = >execlists;
+
+ if (rq_prio(rq) <= execlists->queue_priority_hint)
+ return;
+
+ execlists->queue_priority_hint = rq_prio(rq);
+
+ if (!inflight(execlists, rq))
__submit_queue_imm(engine);
- }
}
static void execlists_submit_request(struct i915_request *request)
@@ -1226,7 +1240,7 @@ static void execlists_submit_request(struct i915_request
*request)
GEM_BUG_ON(RB_EMPTY_ROOT(>execlists.queue.rb_root));
GEM_BUG_ON(list_empty(>sched.link));
- submit_queue(engine, rq_prio(request));
+ submit_queue(engine, request);
spin_unlock_irqrestore(>timeline.lock, flags);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: remove unused bits from Panel Power Sequence State
On Mon, 25 Feb 2019, Lucas De Marchi wrote:
> On Mon, Feb 25, 2019 at 09:28:06PM +0200, Ville Syrjälä wrote:
>>On Fri, Feb 22, 2019 at 04:34:48PM -0800, Lucas De Marchi wrote:
>>> No change in behavior. Just removing the unused bits since it makes it
>>> easier to compare them on new platforms and one of them was wrong
>>> (PP_SEQUENCE_STATE_ON_S1_0 vs the supposedly correct name
>>> PP_SEQUENCE_STATE_ON_S1_1)
>>>
>>> Cc: Rodrigo Vivi
>>> Signed-off-by: Lucas De Marchi
>>> ---
>>> drivers/gpu/drm/i915/i915_reg.h | 12 +++-
>>> 1 file changed, 3 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>> b/drivers/gpu/drm/i915/i915_reg.h
>>> index 730bb1917fd1..e855dae978db 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -4717,15 +4717,9 @@ enum {
>>> #define PP_SEQUENCE_SHIFT28
>>> #define PP_CYCLE_DELAY_ACTIVE(1 << 27)
>>> #define PP_SEQUENCE_STATE_MASK 0x000f
>>> -#define PP_SEQUENCE_STATE_OFF_IDLE (0x0 << 0)
>>> -#define PP_SEQUENCE_STATE_OFF_S0_1 (0x1 << 0)
>>> -#define PP_SEQUENCE_STATE_OFF_S0_2 (0x2 << 0)
>>> -#define PP_SEQUENCE_STATE_OFF_S0_3 (0x3 << 0)
>>> -#define PP_SEQUENCE_STATE_ON_IDLE(0x8 << 0)
>>> -#define PP_SEQUENCE_STATE_ON_S1_0(0x9 << 0)
>>> -#define PP_SEQUENCE_STATE_ON_S1_2(0xa << 0)
>>> -#define PP_SEQUENCE_STATE_ON_S1_3(0xb << 0)
>>> -#define PP_SEQUENCE_STATE_RESET (0xf << 0)
>>> +#define PP_SEQUENCE_STATE_OFF_IDLE 0x0
>>> +#define PP_SEQUENCE_STATE_ON_IDLE0x8
>>> +#define PP_SEQUENCE_STATE_RESET 0xf
>>
>>But how am I supposed to remember what the register values mean?
>
> We only care for a small subset of those and the name should already be
> enough, no? We don't need to bring in all the possible bits from spec,
> even worse when they are misnamed. If we keep defining what we don't use
> it actually makes our life harder to crosscheck with the spec if
> everything is correct. Makes sense?
Dunno, my guideline has always been to add macros for the entire
register contents if you're adding anything.
BR,
Jani.
>
> Lucas De Marchi
>
>>
>>>
>>> #define _PP_CONTROL0x61204
>>> #define PP_CONTROL(pps_idx)_MMIO_PPS(pps_idx, _PP_CONTROL)
>>> --
>>> 2.20.0
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>>--
>>Ville Syrjälä
>>Intel
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/4] drm/i915/selftests: Exercise resetting during non-user payloads
In selftests/live_hangcheck, we have a lot of tests for resetting simple
spinners, but nothing quite prepared us for how the GPU reacted to
triggering a reset outside of the safe spinner. These two subtests fill
the ring with plain old empty, non-spinning requests, and then triggers
a reset. Without a user-payload to blame, these requests will exercise
the 'non-started' paths and mostly be replayed verbatim.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
.../gpu/drm/i915/selftests/intel_hangcheck.c | 218 ++
1 file changed, 218 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index fa02cf9ce0cf..12e047328ab8 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -415,6 +415,222 @@ static bool wait_for_idle(struct intel_engine_cs *engine)
return wait_for(intel_engine_is_idle(engine), IGT_IDLE_TIMEOUT) == 0;
}
+static int igt_reset_nop(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ unsigned int reset_count, count;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+ struct drm_file *file;
+ IGT_TIMEOUT(end_time);
+ int err = 0;
+
+ /* Check that we can reset during non-user portions of requests */
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(>drm.struct_mutex);
+ ctx = live_context(i915, file);
+ mutex_unlock(>drm.struct_mutex);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
+ goto out;
+ }
+
+ i915_gem_context_clear_bannable(ctx);
+ wakeref = intel_runtime_pm_get(i915);
+ reset_count = i915_reset_count(>gpu_error);
+ count = 0;
+ do {
+ mutex_lock(>drm.struct_mutex);
+ for_each_engine(engine, i915, id) {
+ int i;
+
+ for (i = 0; i < 16; i++) {
+ struct i915_request *rq;
+
+ rq = i915_request_alloc(engine, ctx);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ break;
+ }
+
+ i915_request_add(rq);
+ }
+ }
+ mutex_unlock(>drm.struct_mutex);
+
+ igt_global_reset_lock(i915);
+ i915_reset(i915, ALL_ENGINES, NULL);
+ igt_global_reset_unlock(i915);
+ if (i915_reset_failed(i915)) {
+ err = -EIO;
+ break;
+ }
+
+ if (i915_reset_count(>gpu_error) !=
+ reset_count + ++count) {
+ pr_err("Full GPU reset not recorded!\n");
+ err = -EINVAL;
+ break;
+ }
+
+ if (!i915_reset_flush(i915)) {
+ struct drm_printer p =
+ drm_info_printer(i915->drm.dev);
+
+ pr_err("%s failed to idle after reset\n",
+ engine->name);
+ intel_engine_dump(engine, ,
+ "%s\n", engine->name);
+
+ err = -EIO;
+ break;
+ }
+
+ err = igt_flush_test(i915, 0);
+ if (err)
+ break;
+ } while (time_before(jiffies, end_time));
+ pr_info("%s: %d resets\n", __func__, count);
+
+ mutex_lock(>drm.struct_mutex);
+ err = igt_flush_test(i915, I915_WAIT_LOCKED);
+ mutex_unlock(>drm.struct_mutex);
+
+ intel_runtime_pm_put(i915, wakeref);
+
+out:
+ mock_file_free(i915, file);
+ if (i915_reset_failed(i915))
+ err = -EIO;
+ return err;
+}
+
+static int igt_reset_nop_engine(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+ struct drm_file *file;
+ int err = 0;
+
+ /* Check that we can engine-reset during non-user portions */
+
+ if (!intel_has_reset_engine(i915))
+ return 0;
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(>drm.struct_mutex);
+ ctx = live_context(i915, file);
+ mutex_unlock(>drm.struct_mutex);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
+ goto out;
+ }
+
+ i915_gem_context_clear_bannable(ctx);
+ wakeref = intel_runtime_pm_get(i915);
+
[Intel-gfx] [CI 3/4] drm/i915: Remove i915_request.global_seqno
Having weaned the interrupt handling off using a single global execution
queue, we no longer need to emit a global_seqno. Note that we still have
a few assumptions about execution order along engine timelines, but this
removes the most obvious artefact!
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gpu_error.c | 34 ++---
drivers/gpu/drm/i915/i915_gpu_error.h | 2 -
drivers/gpu/drm/i915/i915_request.c | 34 ++---
drivers/gpu/drm/i915/i915_request.h | 32
drivers/gpu/drm/i915/i915_trace.h | 25 +++---
drivers/gpu/drm/i915/intel_engine_cs.c| 5 +-
drivers/gpu/drm/i915/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 34 ++---
drivers/gpu/drm/i915/intel_ringbuffer.c | 50 +++
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 -
.../gpu/drm/i915/selftests/intel_hangcheck.c | 5 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 1 -
12 files changed, 32 insertions(+), 194 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 061a767e3bed..fa86c60fb56c 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -380,19 +380,16 @@ static void print_error_buffers(struct
drm_i915_error_state_buf *m,
err_printf(m, "%s [%d]:\n", name, count);
while (count--) {
- err_printf(m, "%08x_%08x %8u %02x %02x %02x",
+ err_printf(m, "%08x_%08x %8u %02x %02x",
upper_32_bits(err->gtt_offset),
lower_32_bits(err->gtt_offset),
err->size,
err->read_domains,
- err->write_domain,
- err->wseqno);
+ err->write_domain);
err_puts(m, tiling_flag(err->tiling));
err_puts(m, dirty_flag(err->dirty));
err_puts(m, purgeable_flag(err->purgeable));
err_puts(m, err->userptr ? " userptr" : "");
- err_puts(m, err->engine != -1 ? " " : "");
- err_puts(m, engine_name(m->i915, err->engine));
err_puts(m, i915_cache_level_str(m->i915, err->cache_level));
if (err->name)
@@ -1048,27 +1045,6 @@ i915_error_object_create(struct drm_i915_private *i915,
return dst;
}
-/* The error capture is special as tries to run underneath the normal
- * locking rules - so we use the raw version of the i915_active_request lookup.
- */
-static inline u32
-__active_get_seqno(struct i915_active_request *active)
-{
- struct i915_request *request;
-
- request = __i915_active_request_peek(active);
- return request ? request->global_seqno : 0;
-}
-
-static inline int
-__active_get_engine_id(struct i915_active_request *active)
-{
- struct i915_request *request;
-
- request = __i915_active_request_peek(active);
- return request ? request->engine->id : -1;
-}
-
static void capture_bo(struct drm_i915_error_buffer *err,
struct i915_vma *vma)
{
@@ -1077,9 +1053,6 @@ static void capture_bo(struct drm_i915_error_buffer *err,
err->size = obj->base.size;
err->name = obj->base.name;
- err->wseqno = __active_get_seqno(>frontbuffer_write);
- err->engine = __active_get_engine_id(>frontbuffer_write);
-
err->gtt_offset = vma->node.start;
err->read_domains = obj->read_domains;
err->write_domain = obj->write_domain;
@@ -1284,7 +1257,8 @@ static void record_request(struct i915_request *request,
struct i915_gem_context *ctx = request->gem_context;
erq->flags = request->fence.flags;
- erq->context = ctx->hw_id;
+ erq->context = request->fence.context;
+ erq->seqno = request->fence.seqno;
erq->sched_attr = request->sched.attr;
erq->jiffies = request->emitted_jiffies;
erq->start = i915_ggtt_offset(request->ring->vma);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 19ac102afaff..8c1569c1830d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -164,7 +164,6 @@ struct i915_gpu_state {
struct drm_i915_error_buffer {
u32 size;
u32 name;
- u32 wseqno;
u64 gtt_offset;
u32 read_domains;
u32 write_domain;
@@ -173,7 +172,6 @@ struct i915_gpu_state {
u32 dirty:1;
u32 purgeable:1;
u32 userptr:1;
- s32 engine:4;
u32 cache_level:3;
} *active_bo[I915_NUM_ENGINES], *pinned_bo;
u32 active_bo_count[I915_NUM_ENGINES], pinned_bo_count;
diff --git a/drivers/gpu/drm/i915/i915_request.c
[Intel-gfx] [CI 2/4] drm/i915: Remove access to global seqno in the HWSP
Stop accessing the HWSP to read the global seqno, and stop tracking the
mirror in the engine's execution timeline -- it is unused.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gpu_error.c | 4 --
drivers/gpu/drm/i915/i915_gpu_error.h | 3 --
drivers/gpu/drm/i915/i915_request.c | 27 +
drivers/gpu/drm/i915/i915_reset.c | 1 -
drivers/gpu/drm/i915/intel_engine_cs.c| 14 +--
drivers/gpu/drm/i915/intel_lrc.c | 21 +++---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +---
drivers/gpu/drm/i915/intel_ringbuffer.h | 40 ---
drivers/gpu/drm/i915/selftests/i915_request.c | 3 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 3 --
10 files changed, 19 insertions(+), 104 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 3f6eddb6f6de..061a767e3bed 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -526,8 +526,6 @@ static void error_print_engine(struct
drm_i915_error_state_buf *m,
ee->vm_info.pp_dir_base);
}
}
- err_printf(m, " seqno: 0x%08x\n", ee->seqno);
- err_printf(m, " last_seqno: 0x%08x\n", ee->last_seqno);
err_printf(m, " ring->head: 0x%08x\n", ee->cpu_ring_head);
err_printf(m, " ring->tail: 0x%08x\n", ee->cpu_ring_tail);
err_printf(m, " hangcheck timestamp: %dms (%lu%s)\n",
@@ -1216,8 +1214,6 @@ static void error_record_engine_registers(struct
i915_gpu_state *error,
ee->instpm = I915_READ(RING_INSTPM(engine->mmio_base));
ee->acthd = intel_engine_get_active_head(engine);
- ee->seqno = intel_engine_get_seqno(engine);
- ee->last_seqno = intel_engine_last_submit(engine);
ee->start = I915_READ_START(engine);
ee->head = I915_READ_HEAD(engine);
ee->tail = I915_READ_TAIL(engine);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 94eaf8ab9051..19ac102afaff 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -94,8 +94,6 @@ struct i915_gpu_state {
u32 cpu_ring_head;
u32 cpu_ring_tail;
- u32 last_seqno;
-
/* Register state */
u32 start;
u32 tail;
@@ -108,7 +106,6 @@ struct i915_gpu_state {
u32 bbstate;
u32 instpm;
u32 instps;
- u32 seqno;
u64 bbaddr;
u64 acthd;
u32 fault_reg;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 124b3e279c88..596183f35b78 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -179,12 +179,11 @@ static void free_capture_list(struct i915_request
*request)
static void __retire_engine_request(struct intel_engine_cs *engine,
struct i915_request *rq)
{
- GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d:%d\n",
+ GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d\n",
__func__, engine->name,
rq->fence.context, rq->fence.seqno,
rq->global_seqno,
- hwsp_seqno(rq),
- intel_engine_get_seqno(engine));
+ hwsp_seqno(rq));
GEM_BUG_ON(!i915_request_completed(rq));
@@ -243,12 +242,11 @@ static void i915_request_retire(struct i915_request
*request)
{
struct i915_active_request *active, *next;
- GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
+ GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
request->engine->name,
request->fence.context, request->fence.seqno,
request->global_seqno,
- hwsp_seqno(request),
- intel_engine_get_seqno(request->engine));
+ hwsp_seqno(request));
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
@@ -305,12 +303,11 @@ void i915_request_retire_upto(struct i915_request *rq)
struct intel_ring *ring = rq->ring;
struct i915_request *tmp;
- GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
+ GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
rq->engine->name,
rq->fence.context, rq->fence.seqno,
rq->global_seqno,
- hwsp_seqno(rq),
- intel_engine_get_seqno(rq->engine));
+ hwsp_seqno(rq));
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_request_completed(rq));
@@ -354,12 +351,11 @@ void __i915_request_submit(struct i915_request *request)
[Intel-gfx] [CI 1/4] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno
To determine whether an engine has 'stuck', we simply check whether or
not is still on the same seqno for several seconds. To keep this simple
mechanism intact over the loss of a global seqno, we can simply add a
new global heartbeat seqno instead. As we cannot know the sequence in
which requests will then be completed, we use a primitive random number
generator instead (with a cycle long enough to not matter over an
interval of a few thousand requests between hangcheck samples).
The alternative to using a dedicated seqno on every request is to issue
a heartbeat request and query its progress through the system. Sadly
this requires us to reduce struct_mutex so that we can issue requests
without requiring that bkl.
v2: And without the extra CS_STALL for the hangcheck seqno -- we don't
need strict serialisation with what comes later, we just need to be sure
we don't write the hangcheck seqno before our batch is flushed.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 ++---
drivers/gpu/drm/i915/intel_engine_cs.c | 5 ++--
drivers/gpu/drm/i915/intel_hangcheck.c | 6 ++---
drivers/gpu/drm/i915/intel_lrc.c| 15 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 36 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 19 -
6 files changed, 77 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 37175414ce89..545091a5180b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1295,7 +1295,7 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
with_intel_runtime_pm(dev_priv, wakeref) {
for_each_engine(engine, dev_priv, id) {
acthd[id] = intel_engine_get_active_head(engine);
- seqno[id] = intel_engine_get_seqno(engine);
+ seqno[id] = intel_engine_get_hangcheck_seqno(engine);
}
intel_engine_get_instdone(dev_priv->engine[RCS], );
@@ -1315,8 +1315,9 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
for_each_engine(engine, dev_priv, id) {
seq_printf(m, "%s:\n", engine->name);
seq_printf(m, "\tseqno = %x [current %x, last %x], %dms ago\n",
- engine->hangcheck.seqno, seqno[id],
- intel_engine_last_submit(engine),
+ engine->hangcheck.last_seqno,
+ seqno[id],
+ engine->hangcheck.next_seqno,
jiffies_to_msecs(jiffies -
engine->hangcheck.action_timestamp));
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 81b80f8fd9ea..57bc5c4fb3ff 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1497,10 +1497,11 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_reset_failed(engine->i915))
drm_printf(m, "*** WEDGED ***\n");
- drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms]\n",
+ drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x/%x [%d ms]\n",
intel_engine_get_seqno(engine),
intel_engine_last_submit(engine),
- engine->hangcheck.seqno,
+ engine->hangcheck.last_seqno,
+ engine->hangcheck.next_seqno,
jiffies_to_msecs(jiffies -
engine->hangcheck.action_timestamp));
drm_printf(m, "\tReset count: %d (global %d)\n",
i915_reset_engine_count(error, engine),
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
b/drivers/gpu/drm/i915/intel_hangcheck.c
index 9be033b6f4d2..f1d8dfc58049 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -133,21 +133,21 @@ static void hangcheck_load_sample(struct intel_engine_cs
*engine,
struct hangcheck *hc)
{
hc->acthd = intel_engine_get_active_head(engine);
- hc->seqno = intel_engine_get_seqno(engine);
+ hc->seqno = intel_engine_get_hangcheck_seqno(engine);
}
static void hangcheck_store_sample(struct intel_engine_cs *engine,
const struct hangcheck *hc)
{
engine->hangcheck.acthd = hc->acthd;
- engine->hangcheck.seqno = hc->seqno;
+ engine->hangcheck.last_seqno = hc->seqno;
}
static enum intel_engine_hangcheck_action
hangcheck_get_action(struct intel_engine_cs *engine,
const struct hangcheck *hc)
{
- if (engine->hangcheck.seqno != hc->seqno)
+ if (engine->hangcheck.last_seqno != hc->seqno)
return ENGINE_ACTIVE_SEQNO;
if (intel_engine_is_idle(engine))
diff
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno (rev2)
== Series Details == Series: series starting with [v2] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno (rev2) URL : https://patchwork.freedesktop.org/series/57203/ State : success == Summary == CI Bug Log - changes from CI_DRM_5659 -> Patchwork_12304 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/57203/revisions/2/mbox/ Known issues Here are the changes found in Patchwork_12304 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: PASS -> FAIL [fdo#109485] * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: PASS -> FAIL [fdo#103167] Possible fixes * igt@i915_selftest@live_execlists: - fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 Participating hosts (44 -> 39) -- Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-y Build changes - * Linux: CI_DRM_5659 -> Patchwork_12304 CI_DRM_5659: bffea990c63087245e8501df82fd45f24ce6ad1f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4854: 06b0830fb948b9b632342cd26100342aa01cbc79 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12304: 4263db19d128b52127679a2e19b55c133ba572ff @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4263db19d128 drm/i915/selftests: Exercise resetting during non-user payloads b1b0c52dd2ce drm/i915: Remove i915_request.global_seqno 7858cfe7a809 drm/i915: Remove access to global seqno in the HWSP 212a5ef02a79 drm/i915: Replace global_seqno with a hangcheck heartbeat seqno == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12304/ ___ 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 [v2] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno (rev2)
== Series Details == Series: series starting with [v2] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno (rev2) URL : https://patchwork.freedesktop.org/series/57203/ State : warning == Summary == $ dim checkpatch origin/drm-tip 212a5ef02a79 drm/i915: Replace global_seqno with a hangcheck heartbeat seqno 7858cfe7a809 drm/i915: Remove access to global seqno in the HWSP b1b0c52dd2ce drm/i915: Remove i915_request.global_seqno 4263db19d128 drm/i915/selftests: Exercise resetting during non-user payloads -:35: WARNING:LINE_SPACING: Missing a blank line after declarations #35: FILE: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:427: + struct drm_file *file; + IGT_TIMEOUT(end_time); -:154: WARNING:LINE_SPACING: Missing a blank line after declarations #154: FILE: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:546: + unsigned int count; + IGT_TIMEOUT(end_time); total: 0 errors, 2 warnings, 0 checks, 230 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP2.2 Phase II
== Series Details ==
Series: HDCP2.2 Phase II
URL : https://patchwork.freedesktop.org/series/57232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5659 -> Patchwork_12303
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/57232/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12303:
### IGT changes ###
Possible regressions
* {igt@kms_content_protection@srm} (NEW):
- {fi-icl-y}: NOTRUN -> SKIP
New tests
-
New tests have been introduced between CI_DRM_5659 and Patchwork_12303:
### New IGT tests (1) ###
* igt@kms_content_protection@srm:
- Statuses : 37 skip(s)
- Exec time: [0.0, 0.00] s
Known issues
Here are the changes found in Patchwork_12303 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-n3050: PASS -> SKIP [fdo#109271]
* igt@i915_pm_rpm@basic-rte:
- fi-bsw-n3050: PASS -> FAIL [fdo#108800]
* igt@kms_content_protection@atomic:
- fi-skl-gvtdvm: NOTRUN -> FAIL [fdo#108597] / [fdo#108739] +1
- fi-ivb-3520m: NOTRUN -> SKIP [fdo#109271] +2
- fi-elk-e7500: NOTRUN -> SKIP [fdo#109271] +2
- fi-whl-u: NOTRUN -> SKIP [fdo#109271] +2
- fi-cfl-8700k: NOTRUN -> SKIP [fdo#109271] +2
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +2
- fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] +2
- fi-skl-guc: NOTRUN -> SKIP [fdo#109271] +2
- fi-hsw-peppy: NOTRUN -> SKIP [fdo#109271] +2
- fi-apl-guc: NOTRUN -> FAIL [fdo#108597] / [fdo#108739] +1
* igt@kms_content_protection@legacy:
- fi-cfl-guc: NOTRUN -> SKIP [fdo#109271] +2
- fi-bxt-j4205: NOTRUN -> SKIP [fdo#109271] +2
- fi-kbl-r: NOTRUN -> SKIP [fdo#109271] +2
- fi-cfl-8109u: NOTRUN -> FAIL [fdo#108739] +1
- fi-kbl-guc: NOTRUN -> SKIP [fdo#109271] +2
- fi-bdw-gvtdvm: NOTRUN -> SKIP [fdo#109271] +2
- fi-gdg-551: NOTRUN -> SKIP [fdo#109271] +2
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] +2
- fi-hsw-4770:NOTRUN -> SKIP [fdo#109271] +2
- fi-ivb-3770:NOTRUN -> SKIP [fdo#109271] +2
- fi-kbl-8809g: NOTRUN -> SKIP [fdo#109271] +2
* {igt@kms_content_protection@srm} (NEW):
- fi-ilk-650: NOTRUN -> SKIP [fdo#109271] +2
- fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] +2
- fi-bsw-kefka: NOTRUN -> SKIP [fdo#109271] +2
- fi-hsw-4770r: NOTRUN -> SKIP [fdo#109271] +2
- fi-cfl-8109u: NOTRUN -> SKIP [fdo#109271]
- fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +2
- fi-kbl-7500u: NOTRUN -> SKIP [fdo#109271]
- fi-bdw-5557u: NOTRUN -> SKIP [fdo#109271] +2
- fi-kbl-7567u: NOTRUN -> SKIP [fdo#109271]
- fi-skl-6600u: NOTRUN -> SKIP [fdo#109271] +2
- fi-kbl-7560u: NOTRUN -> SKIP [fdo#109271] +2
- fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] +2
- fi-apl-guc: NOTRUN -> SKIP [fdo#109271]
- fi-byt-n2820: NOTRUN -> SKIP [fdo#109271] +2
- fi-skl-6700k2: NOTRUN -> SKIP [fdo#109271]
- fi-skl-6260u: NOTRUN -> SKIP [fdo#109271]
- fi-skl-gvtdvm: NOTRUN -> SKIP [fdo#109271]
- fi-kbl-x1275: NOTRUN -> SKIP [fdo#109271]
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
- fi-cfl-8109u: PASS -> FAIL [fdo#109495]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108597]: https://bugs.freedesktop.org/show_bug.cgi?id=108597
[fdo#108739]: https://bugs.freedesktop.org/show_bug.cgi?id=108739
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109495]: https://bugs.freedesktop.org/show_bug.cgi?id=109495
[fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
Participating hosts (44 -> 38)
--
Missing(6): fi-ilk-m540 fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-ctg-p8600
fi-icl-u3
Build changes
-
* IGT: IGT_4854 -> IGTPW_2521
* Linux: CI_DRM_5659 -> Patchwork_12303
CI_DRM_5659: bffea990c63087245e8501df82fd45f24ce6ad1f @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_2521: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2521/
IGT_4854: 06b0830fb948b9b632342cd26100342aa01cbc79 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12303: 89073ee51fc9833ef92d07adf075bea255011c7b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
89073ee51fc9 drm/i915:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: extract AUX mask assignment to separate function (rev2)
== Series Details == Series: drm/i915: extract AUX mask assignment to separate function (rev2) URL : https://patchwork.freedesktop.org/series/57119/ State : success == Summary == CI Bug Log - changes from CI_DRM_5659_full -> Patchwork_12302_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12302_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_big: - shard-hsw: PASS -> TIMEOUT [fdo#107937] * igt@gem_mocs_settings@mocs-reset-bsd2: - shard-snb: NOTRUN -> SKIP [fdo#109271] +103 * igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9 * igt@kms_atomic_transition@5x-modeset-transitions-nonblocking: - shard-glk: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_atomic_transition@6x-modeset-transitions-nonblocking-fencing: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-snb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-hsw: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-glk: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-oldfb-render-d: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_cursor_crc@cursor-64x21-random: - shard-apl: PASS -> FAIL [fdo#103232] +4 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: - shard-glk: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-render: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +17 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-onoff: - shard-glk: NOTRUN -> SKIP [fdo#109271] +8 * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-glk: PASS -> FAIL [fdo#108948] +1 * igt@kms_plane@plane-position-covered-pipe-c-planes: - shard-apl: PASS -> FAIL [fdo#103166] +2 * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> FAIL [fdo#109016] * igt@kms_vblank@pipe-a-ts-continuation-modeset-hang: - shard-apl: PASS -> FAIL [fdo#104894] * igt@perf_pmu@busy-hang-vecs0: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@prime_vgem@fence-write-hang: - shard-apl: NOTRUN -> SKIP [fdo#109271] +8 Possible fixes * igt@kms_color@pipe-a-ctm-max: - shard-apl: FAIL [fdo#108147] -> PASS * igt@kms_cursor_crc@cursor-256x85-sliding: - shard-apl: FAIL [fdo#103232] -> PASS +2 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-apl: FAIL [fdo#103167] -> PASS +4 * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-apl: FAIL [fdo#103167] / [fdo#105682] -> PASS * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu: - shard-glk: FAIL [fdo#103167] -> PASS +2 * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: - shard-apl: FAIL [fdo#108948] -> PASS * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-glk: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS * igt@kms_plane@plane-position-covered-pipe-c-planes: - shard-glk: FAIL [fdo#103166] -> PASS +2 * igt@kms_plane@plane-position-hole-dpms-pipe-b-planes: - shard-snb: SKIP [fdo#109271] -> PASS +1 * igt@kms_plane_multiple@atomic-pipe-a-tiling-yf: - shard-apl: FAIL [fdo#103166] -> PASS * igt@kms_rotation_crc@multiplane-rotation: - shard-kbl: INCOMPLETE [fdo#103665] -> PASS * igt@kms_setmode@basic: - shard-kbl: FAIL [fdo#99912] -> PASS * igt@prime_busy@hang-vebox: - shard-hsw: FAIL [fdo#108807] -> PASS [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#104894]: https://bugs.freedesktop.org/show_bug.cgi?id=104894 [fdo#105682]: https://bugs.freedesktop.org/show_bug.cgi?id=105682 [fdo#107937]: https://bugs.freedesktop.org/show_bug.cgi?id=107937 [fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
Re: [Intel-gfx] [PATCH 00/10] HDCP2.2 Phase II
On Tue, Feb 26, 2019 at 8:42 AM Ramalingam C wrote: > > HDCP2.2 phase-II mojorly adds below features: > Addition of three connector properties > CP_Content_Type > CP_SRM Not really clear why this is a connector property. Do we need different SRM for different connectors? My understanding of the spec is that we want one SRM globally (so not even per driver). I think a binary sysfs file in the drm class (in /sys/class/drm, not one of the subdirectories) would fit that. Plus make userspace simpler, since a cat srm_file > /sys/class/drm/cp_srm at boot-up is all we need. Drivers can then just check with drm core for the latest srm file at the start of each hdcp transaction, and update it if there is one. Plus maybe a few functions to do sink filtering on the cpu - I think we need that for hdcp1.x on i915 too. Other properties make sense on the connector I think. Also please spell out CP as content_protection in all the properties/interfaces, I think that would be good, in common lingo (see urban dictionary) cp has a different meaning. -Daniel > CP_Downstream_Info > parsing for HDCP1.4 and 2.2 SRM Blobs > Once HDCP1.4/2.2 authentication is completed gathering the all > downstream topology for userspace > Extending debugfs entry to provide the HDCP2.2 capability too. > > CP_Content_Type: > This property is used to indicate the content type > classification of a stream. Which indicate the HDCP version required > for the rendering of that streams. This conten type is one of the > parameter in the HDCP2.2 authentication flow, as even downstream > repeaters will mandate the HDCP version requirement. > > Two values possible for content type of a stream: > Type 0: Stream can be rendered only on HDCP encrypted link no > restriction on HDCP versions. > Type 1: Stream can be rendered only on HDCP2.2 encrypted link. > > There is a parallel effort in #wayland community to add the support for > HDCP2.2 along with content type support. Patches are under review in > #wayland community. > > CP_SRM: > This blob property is used by the userspace to pass the SRM table > of HDCP1.4 and 2.2. These are nothing but revocated list of receiver IDs > of the HDCP sinks. KMD will use this list to identify the revocated > devices in the HDCP authentication and deny the hdcp encryption to it. > > Work in progress to add the SRM support in the weston HDCP stack. > Yet to publish the patches in the #wayland community. > > CP_Downstream_Info: > This blob property is used by the kernel to pass the downstream topology > of the HDCP encrypted port to the userspace. > > This is used by the userspace to implement the HDCP repeater, which KMD > implementing the HDCP transmitters(downstream ports) and userspace > implementing the upstream port(HDCP receiver). > > Discussion is on going to add the downstream_info support in the > weston HDCP stack. > > Test-with: 1551165805-19130-2-git-send-email-ramalinga...@intel.com > > Ramalingam C (10): > drm: Add CP content type property > drm/i915: Attach content type property > drm: Add CP System Renewability Msg Property > drm/i915: Add HDCP SRM Blob parsing > drm/i915: Add revocation check on HDCP1.4 Ksvs > drm/i915: SRM parsing and revocation check for HDCP2 > drm: Add CP downstream_info property > drm/i915: Populate downstream info for HDCP1.4 > drm/i915: Populate downstream info for HDCP2.2 > drm/i915: debugfs: HDCP2.2 capability read > > drivers/gpu/drm/drm_atomic_uapi.c | 23 +++ > drivers/gpu/drm/drm_connector.c | 204 > drivers/gpu/drm/i915/i915_debugfs.c | 13 +- > drivers/gpu/drm/i915/intel_ddi.c| 23 ++- > drivers/gpu/drm/i915/intel_drv.h| 11 +- > drivers/gpu/drm/i915/intel_hdcp.c | 373 > ++-- > include/drm/drm_connector.h | 40 > include/drm/drm_hdcp.h | 35 > include/uapi/drm/drm_mode.h | 39 > 9 files changed, 737 insertions(+), 24 deletions(-) > > -- > 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
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HDCP2.2 Phase II
== Series Details ==
Series: HDCP2.2 Phase II
URL : https://patchwork.freedesktop.org/series/57232/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d436a49061d8 drm: Add CP content type property
-:123: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#123: FILE: drivers/gpu/drm/drm_connector.c:1601:
+ ARRAY_SIZE(
-:181: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#181: FILE: include/drm/drm_connector.h:1325:
+int drm_connector_attach_cp_content_type_property(
total: 0 errors, 0 warnings, 2 checks, 153 lines checked
9637bf9bd9d9 drm/i915: Attach content type property
112fc8797d7c drm: Add CP System Renewability Msg Property
d3eae4abcd2b drm/i915: Add HDCP SRM Blob parsing
c7cf67c7ec3e drm/i915: Add revocation check on HDCP1.4 Ksvs
1ff0fb1cf24e drm/i915: SRM parsing and revocation check for HDCP2
c1068365cf3a drm: Add CP downstream_info property
-:13: WARNING:TYPO_SPELLING: 'informations' may be misspelled - perhaps
'information'?
#13:
Userspace need this informations to configure this platform as repeater,
-:91: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#91: FILE: drivers/gpu/drm/drm_connector.c:1702:
+int drm_connector_attach_cp_downstream_property(
-:123: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#123: FILE: drivers/gpu/drm/drm_connector.c:1734:
+int drm_mode_connector_update_cp_downstream_property(
-:134: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#134: FILE: drivers/gpu/drm/drm_connector.c:1745:
+ ret = drm_property_replace_global_blob(dev,
+ >cp_downstream_blob_ptr,
-:168: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#168: FILE: include/drm/drm_connector.h:1347:
+int drm_connector_attach_cp_downstream_property(
-:170: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#170: FILE: include/drm/drm_connector.h:1349:
+int drm_mode_connector_update_cp_downstream_property(
total: 0 errors, 1 warnings, 5 checks, 172 lines checked
0e9b016d27ad drm/i915: Populate downstream info for HDCP1.4
-:80: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#80: FILE: drivers/gpu/drm/i915/intel_hdcp.c:796:
+ if (drm_mode_connector_update_cp_downstream_property(
-:92: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#92: FILE: drivers/gpu/drm/i915/intel_hdcp.c:834:
+ if (drm_mode_connector_update_cp_downstream_property(
total: 0 errors, 0 warnings, 2 checks, 104 lines checked
c1f5086d0622 drm/i915: Populate downstream info for HDCP2.2
-:50: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#50: FILE: drivers/gpu/drm/i915/intel_hdcp.c:1665:
+ drm_mode_connector_update_cp_downstream_property(
-:61: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#61: FILE: drivers/gpu/drm/i915/intel_hdcp.c:1676:
+ drm_mode_connector_update_cp_downstream_property(
-:83: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#83: FILE: drivers/gpu/drm/i915/intel_hdcp.c:1700:
+ drm_mode_connector_update_cp_downstream_property(
total: 0 errors, 0 warnings, 3 checks, 75 lines checked
89073ee51fc9 drm/i915: debugfs: HDCP2.2 capability read
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
