[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Implement HDCP2.2 (rev2)
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev2)
URL : https://patchwork.freedesktop.org/series/56453/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5584_full -> Patchwork_12188_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12188_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12188_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12188_full:
### IGT changes ###
Possible regressions
* igt@gem_eio@unwedge-stress:
- shard-snb: PASS -> FAIL
Known issues
Here are the changes found in Patchwork_12188_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@hang:
- shard-snb: PASS -> INCOMPLETE [fdo#105411]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-hsw: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: PASS -> FAIL [fdo#103232] +5
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-kbl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-glk: NOTRUN -> FAIL [fdo#103232]
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-glk: PASS -> FAIL [fdo#103167] +7
* igt@kms_plane@pixel-format-pipe-b-planes-source-clamping:
- shard-apl: PASS -> FAIL [fdo#108948]
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-apl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166] +4
* igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-apl: PASS -> FAIL [fdo#103166] +2
* igt@kms_setmode@basic:
- shard-apl: PASS -> FAIL [fdo#99912]
- shard-kbl: PASS -> FAIL [fdo#99912]
Possible fixes
* igt@gem_exec_flush@basic-wb-rw-before-default:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_atomic_transition@plane-all-transition-fencing:
- shard-hsw: INCOMPLETE [fdo#103540] / [fdo#109225] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-kbl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-apl: FAIL [fdo#103232] -> PASS +5
* igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-kbl: FAIL [fdo#103232] -> PASS +1
* {igt@kms_flip@flip-vs-suspend}:
- shard-kbl: DMESG-WARN [fdo#108566] -> PASS
* igt@kms_flip@plain-flip-fb-recreate-interruptible:
- shard-kbl: FAIL [fdo#100368] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-wc:
- shard-glk: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbc-farfromfence:
- shard-snb: INCOMPLETE [fdo#105411] -> PASS
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: FAIL [fdo#103166] -> PASS +4
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-kbl: FAIL [fdo#103166] -> PASS +2
* igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl: DMESG-FAIL [fdo#105763] -> PASS
* igt@kms_universal_plane@universal-plane-pipe-c-functional:
- shard-glk: FAIL [fdo#103166] -> PASS +6
* igt@pm_rc6_residency@rc6-accuracy:
- shard-snb: {SKIP} [fdo#109271] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=1
[Intel-gfx] ✗ Fi.CI.IGT: failure for Add support for Gen 11 pipe color features (rev7)
== Series Details ==
Series: Add support for Gen 11 pipe color features (rev7)
URL : https://patchwork.freedesktop.org/series/51408/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5584_full -> Patchwork_12189_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12189_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12189_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12189_full:
### IGT changes ###
Possible regressions
* igt@gem_eio@reset-stress:
- shard-snb: PASS -> FAIL
Warnings
* igt@kms_color@pipe-c-degamma:
- shard-glk: {SKIP} [fdo#109271] -> FAIL +4
Known issues
Here are the changes found in Patchwork_12189_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@hang:
- shard-snb: PASS -> INCOMPLETE [fdo#105411]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-hsw: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_flip@flip-vs-expired-vblank:
- shard-glk: PASS -> FAIL [fdo#102887] / [fdo#105363]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk: PASS -> FAIL [fdo#108948]
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-apl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-none:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
* igt@prime_busy@wait-hang-bsd:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
Possible fixes
* igt@gem_exec_flush@basic-wb-rw-before-default:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_atomic_transition@plane-all-transition-fencing:
- shard-hsw: INCOMPLETE [fdo#103540] / [fdo#109225] -> PASS
* igt@kms_color@pipe-b-ctm-green-to-red:
- shard-glk: {SKIP} [fdo#109271] -> PASS +29
* {igt@kms_flip@flip-vs-suspend}:
- shard-kbl: DMESG-WARN [fdo#108566] -> PASS
* igt@kms_flip@plain-flip-fb-recreate-interruptible:
- shard-kbl: FAIL [fdo#100368] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-wc:
- shard-glk: FAIL [fdo#103167] -> PASS
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-apl: FAIL [fdo#103166] -> PASS +2
* igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
- shard-glk: FAIL [fdo#103166] -> PASS +3
* igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl: DMESG-FAIL [fdo#105763] -> PASS
* igt@kms_setmode@basic:
- shard-hsw: FAIL [fdo#99912] -> PASS
Warnings
* igt@kms_color@pipe-a-degamma:
- shard-glk: {SKIP} [fdo#109271] -> FAIL [fdo#108145]
* igt@kms_frontbuffer_tracking@fbc-farfromfence:
- shard-snb: INCOMPLETE [fdo#105411] -> DMESG-FAIL [fdo#107469]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[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#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
[fdo#107469]: https://bugs.freedesktop.org/show_bug.cgi?id=107469
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948
[fdo#109225]: https://bugs.freedesktop.org/show_bug.cgi?id=109225
[fdo#109271]: https://bugs.freedesktop.org
Re: [Intel-gfx] [PATCH v2 2/2] drm/drv: drm_dev_unplug(): Move out drm_dev_put() call
On Fri, Feb 08, 2019 at 03:01:03PM +0100, Noralf Trønnes wrote:
> This makes it possible to use drm_dev_unplug() with the upcoming
> devm_drm_dev_init() which will do drm_dev_put() in its release callback.
>
> Cc: Alex Deucher
> Cc: Christian König
> Cc: David (ChunMing) Zhou
> Cc: Dave Airlie
> Cc: Sean Paul
> Cc: Oleksandr Andrushchenko
> Cc: Daniel Vetter
> Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
> ---
>
> I will take this through drm-misc-next.
>
> Noralf.
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
> drivers/gpu/drm/drm_drv.c | 1 -
> drivers/gpu/drm/udl/udl_drv.c | 1 +
> drivers/gpu/drm/xen/xen_drm_front.c | 1 +
> 4 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index a1bb3773087b..d1f37ba3c118 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -971,6 +971,7 @@ amdgpu_pci_remove(struct pci_dev *pdev)
>
> DRM_ERROR("Device removal is currently not supported outside of
> fbcon\n");
> drm_dev_unplug(dev);
> + drm_dev_put(dev);
> pci_disable_device(pdev);
> pci_set_drvdata(pdev, NULL);
> }
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 05bbc2b622fc..b04982101fcb 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -376,7 +376,6 @@ void drm_dev_unplug(struct drm_device *dev)
> synchronize_srcu(&drm_unplug_srcu);
>
> drm_dev_unregister(dev);
> - drm_dev_put(dev);
> }
> EXPORT_SYMBOL(drm_dev_unplug);
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index 22cd2d13e272..53b7b8c04bc6 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -107,6 +107,7 @@ static void udl_usb_disconnect(struct usb_interface
> *interface)
> udl_fbdev_unplug(dev);
> udl_drop_usb(dev);
> drm_dev_unplug(dev);
> + drm_dev_put(dev);
> }
>
> /*
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
> b/drivers/gpu/drm/xen/xen_drm_front.c
> index 3e78a832d7f9..84aa4d61dc42 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front.c
> @@ -582,6 +582,7 @@ static void xen_drm_drv_fini(struct xen_drm_front_info
> *front_info)
>
> drm_kms_helper_poll_fini(dev);
> drm_dev_unplug(dev);
> + drm_dev_put(dev);
>
> front_info->drm_info = NULL;
>
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 01/38] drm/doc: document recommended component helper usage
On Sat, Feb 09, 2019 at 12:42:30PM +0530, Ramalingam C wrote: > From: Daniel Vetter > > Now that component has docs it's worth spending a few words and > hyperlinks on recommended best practices in drm. > > Cc: Russell King - ARM Linux admin > Signed-off-by: Daniel Vetter Just a quick reminder: When sending out other people's patches, you need to add your own s-o-b line per https://developercertificate.org/ Cheers, Daniel > --- > Documentation/driver-api/component.rst | 2 ++ > Documentation/gpu/drm-internals.rst| 5 + > drivers/gpu/drm/drm_drv.c | 14 ++ > 3 files changed, 21 insertions(+) > > diff --git a/Documentation/driver-api/component.rst > b/Documentation/driver-api/component.rst > index 2da4a8f20607..57e37590733f 100644 > --- a/Documentation/driver-api/component.rst > +++ b/Documentation/driver-api/component.rst > @@ -1,3 +1,5 @@ > +.. _component: > + > == > Component Helper for Aggregate Drivers > == > diff --git a/Documentation/gpu/drm-internals.rst > b/Documentation/gpu/drm-internals.rst > index 3ae23a5454ac..966bd2d9f0cc 100644 > --- a/Documentation/gpu/drm-internals.rst > +++ b/Documentation/gpu/drm-internals.rst > @@ -93,6 +93,11 @@ Device Instance and Driver Handling > Driver Load > --- > > +Component Helper Usage > +~~ > + > +.. kernel-doc:: drivers/gpu/drm/drm_drv.c > + :doc: component helper usage recommendations > > IRQ Helper Library > ~~ > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > index 381581b01d48..aae413003705 100644 > --- a/drivers/gpu/drm/drm_drv.c > +++ b/drivers/gpu/drm/drm_drv.c > @@ -457,6 +457,20 @@ static void drm_fs_inode_free(struct inode *inode) > } > > /** > + * DOC: component helper usage recommendations > + * > + * DRM drivers that drive hardware where a logical device consists of a pile > of > + * independent hardware blocks are recommended to use the :ref:`component > helper > + * library`. The entire device initialization procedure should be > run > + * from the &component_master_ops.master_bind callback, starting with > + * drm_dev_init(), then binding all components with component_bind_all() and > + * finishing with drm_dev_register(). For consistency and easier sharing of > + * components across drivers the opaque pointer passed to all components > through > + * component_bind_all() should point at &struct drm_device of the device > + * instance, not some driver specific private structure. > + */ > + > +/** > * drm_dev_init - Initialise new DRM device > * @dev: DRM device > * @driver: DRM driver > -- > 2.7.4 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t] tests/kms_crtc_background_color: overhaul to match upstream ABI (v4)
Am Donnerstag, 31. Januar 2019, 01:00:34 CET schrieb Matt Roper:
> CRTC background color kernel patches were written about 2.5 years ago
> and floated on the upstream mailing list, but since no opensource
> userspace materialized, we never actually merged them. However the
> corresponding IGT test did get merged and has basically been dead code
> ever since.
>
> A couple years later we finally have an open source userspace
> (ChromeOS), so lets update the IGT test to match the ABI that's actually
> going upstream and to remove some of the cruft from the original test
> that wouldn't actually work.
>
> It's worth noting that we don't seem to be able to test this feature
> with CRC's, at least on Intel gen9. Originally we wanted to draw a
> color into a plane's FB (with Cairo) and then compare the CRC to turning
> off all planes and just setting the CRTC background to the same color.
> However the precision and rounding of the color components causes the
> CRC's to come out differently, even though the end result is visually
> identical. So at the moment this test is mainly useful for visual
> inspection in interactive mode.
>
> v2:
> - Swap red and blue ordering in property value to reflect change
>in v2 of kernel series.
>
> v3:
> - Minor updates to proposed uapi helpers (s/rgba/argb/).
>
> v4:
> - General restructuring into pipe/color subtests.
> - Use RGB2101010 framebuffers for comparison so that we match the bits
>of precision that Intel hardware background color accepts
>
> Cc: igt-...@lists.freedesktop.org
> Signed-off-by: Matt Roper
[...]
> +igt_main
> {
> - igt_display_t *display = &data->display;
> + data_t data = {};
> igt_output_t *output;
> + drmModeModeInfo *mode;
> + int w, h;
> enum pipe pipe;
> - int valid_tests = 0;
> -
> - for_each_pipe_with_valid_output(display, pipe, output) {
> - igt_plane_t *plane;
> -
> - igt_output_set_pipe(output, pipe);
> -
> - plane = igt_output_get_plane_type(output,
> DRM_PLANE_TYPE_PRIMARY);
> - igt_require(igt_pipe_has_prop(display, pipe,
> IGT_CRTC_BACKGROUND));
> -
> - prepare_crtc(data, output, pipe, plane, 1, PURPLE, BLACK64);
> -
> - /* Now set background without using a plane, i.e.,
> - * Disable the plane to let hw background color win blend. */
> - igt_plane_set_fb(plane, NULL);
> - igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND,
> PURPLE64);
> - igt_display_commit2(display, COMMIT_UNIVERSAL);
> -
> - /* Try few other background colors */
> - igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND,
> CYAN64);
> - igt_display_commit2(display, COMMIT_UNIVERSAL);
> -
> - igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND,
> YELLOW64);
> - igt_display_commit2(display, COMMIT_UNIVERSAL);
>
> - igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND,
> RED64);
> - igt_display_commit2(display, COMMIT_UNIVERSAL);
> + igt_fixture {
> + data.gfx_fd = drm_open_driver_master(DRIVER_INTEL);
DRIVER_ANY perhaps like in other tests?
I'm currently looking into implementing your new background-property
in the Rockchip kms driver and I guess this test shouldn't contain any
intel-specifics?
Heiko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 2/5] drm/i915/icl: Add icl pipe degamma and gamma support
Add support for icl pipe degamma and gamma.
v2: Removed a POSTING_READ and corrected the Bit
Definition as per Maarten's comments.
v3: Addressed Matt's review comments. Removed rmw patterns
as suggested by Matt.
v4: Fixed Matt's review comments.
v5: Corrected macro alignment as per Jani Nikula's comments.
Addressed Ville and Matt's review comments.
v6: Merged ICL degamma handling with GLK and dropped ICL
degamma function as per Ville and Matt's comments.
v7: updated gamma_mode state with pre csc gammma and post
gamma enabling in intel_color_check to align with atomic.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h| 12 +++-
drivers/gpu/drm/i915/intel_color.c | 32 ++--
2 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 11bf60d..13a207a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7111,11 +7111,13 @@ enum {
#define _GAMMA_MODE_A 0x4a480
#define _GAMMA_MODE_B 0x4ac80
#define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
-#define GAMMA_MODE_MODE_MASK (3 << 0)
-#define GAMMA_MODE_MODE_8BIT (0 << 0)
-#define GAMMA_MODE_MODE_10BIT (1 << 0)
-#define GAMMA_MODE_MODE_12BIT (2 << 0)
-#define GAMMA_MODE_MODE_SPLIT (3 << 0)
+#define PRE_CSC_GAMMA_ENABLE (1 << 31)
+#define POST_CSC_GAMMA_ENABLE (1 << 30)
+#define GAMMA_MODE_MODE_MASK (3 << 0)
+#define GAMMA_MODE_MODE_8BIT (0 << 0)
+#define GAMMA_MODE_MODE_10BIT (1 << 0)
+#define GAMMA_MODE_MODE_12BIT (2 << 0)
+#define GAMMA_MODE_MODE_SPLIT (3 << 0)
/* DMC/CSR */
#define CSR_PROGRAM(i) _MMIO(0x8 + (i) * 4)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 4e13286..0fcaae4 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -583,6 +583,28 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
}
}
+static void icl_load_luts(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ glk_load_degamma_lut(crtc_state);
+
+ if (crtc_state_is_legacy_gamma(crtc_state)) {
+ i9xx_load_luts(crtc_state);
+ } else {
+ /* ToDo: Add support for multi segment gamma LUT */
+ bdw_load_gamma_lut(crtc_state, 0);
+
+ /*
+* Reset the index, otherwise it prevents the legacy
+* palette to be written properly.
+*/
+ I915_WRITE(PREC_PAL_INDEX(pipe), 0);
+ }
+}
+
static void cherryview_load_luts(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
@@ -772,7 +794,11 @@ int intel_color_check(struct intel_crtc_state *crtc_state)
drm_color_lut_check(gamma_lut, gamma_tests))
return -EINVAL;
- if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ if (INTEL_GEN(dev_priv) >= 11)
+ crtc_state->gamma_mode = GAMMA_MODE_MODE_10BIT |
+PRE_CSC_GAMMA_ENABLE |
+POST_CSC_GAMMA_ENABLE;
+ else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
crtc_state->gamma_mode = GAMMA_MODE_MODE_10BIT;
else if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
crtc_state->gamma_mode = GAMMA_MODE_MODE_SPLIT;
@@ -796,7 +822,9 @@ void intel_color_init(struct intel_crtc *crtc)
dev_priv->display.color_commit = i9xx_color_commit;
} else {
- if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ if (IS_ICELAKE(dev_priv))
+ dev_priv->display.load_luts = icl_load_luts;
+ else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
dev_priv->display.load_luts = glk_load_luts;
else if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
dev_priv->display.load_luts = broadwell_load_luts;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 4/5] drm/i915/icl: Enable pipe output csc
GEN11+ onwards an output csc hardware block has been added.
This is after the pipe gamma block and is in addition to the
legacy pipe CSC block. Primary use case for this block is to
convert RGB to YUV in case sink supports YUV.
This patch adds supports for the same.
v2: This is added after splitting the existing ICL pipe CSC
handling. As per Matt's suggestion, made this to co-exist
with existing pipe CSC, wherein both can be enabled if a
certain usecase arises.
v3: Fixed an issue with co-existence of output csc and normal
pipe csc, spotted by Matt. Put the csc mode flag enabling to
color_check to align with atomic.
v4: Fixed macro alignment and checkpatch complaints wrt line over
100 characters limit.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h| 65
drivers/gpu/drm/i915/intel_color.c | 77 --
drivers/gpu/drm/i915/intel_drv.h | 3 ++
3 files changed, 126 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4cb0013..668e862 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9888,6 +9888,7 @@ enum skl_power_gate {
#define _PIPE_A_CSC_MODE 0x49028
#define ICL_CSC_ENABLE(1 << 31)
+#define ICL_OUTPUT_CSC_ENABLE (1 << 30)
#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
#define CSC_POSITION_BEFORE_GAMMA (1 << 1)
#define CSC_MODE_YUV_TO_RGB (1 << 0)
@@ -9927,6 +9928,70 @@ enum skl_power_gate {
#define PIPE_CSC_POSTOFF_ME(pipe) _MMIO_PIPE(pipe,
_PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
#define PIPE_CSC_POSTOFF_LO(pipe) _MMIO_PIPE(pipe,
_PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
+/* Pipe Output CSC */
+#define _PIPE_A_OUTPUT_CSC_COEFF_RY_GY 0x49050
+#define _PIPE_A_OUTPUT_CSC_COEFF_BY0x49054
+#define _PIPE_A_OUTPUT_CSC_COEFF_RU_GU 0x49058
+#define _PIPE_A_OUTPUT_CSC_COEFF_BU0x4905c
+#define _PIPE_A_OUTPUT_CSC_COEFF_RV_GV 0x49060
+#define _PIPE_A_OUTPUT_CSC_COEFF_BV0x49064
+#define _PIPE_A_OUTPUT_CSC_PREOFF_HI 0x49068
+#define _PIPE_A_OUTPUT_CSC_PREOFF_ME 0x4906c
+#define _PIPE_A_OUTPUT_CSC_PREOFF_LO 0x49070
+#define _PIPE_A_OUTPUT_CSC_POSTOFF_HI 0x49074
+#define _PIPE_A_OUTPUT_CSC_POSTOFF_ME 0x49078
+#define _PIPE_A_OUTPUT_CSC_POSTOFF_LO 0x4907c
+
+#define _PIPE_B_OUTPUT_CSC_COEFF_RY_GY 0x49150
+#define _PIPE_B_OUTPUT_CSC_COEFF_BY0x49154
+#define _PIPE_B_OUTPUT_CSC_COEFF_RU_GU 0x49158
+#define _PIPE_B_OUTPUT_CSC_COEFF_BU0x4915c
+#define _PIPE_B_OUTPUT_CSC_COEFF_RV_GV 0x49160
+#define _PIPE_B_OUTPUT_CSC_COEFF_BV0x49164
+#define _PIPE_B_OUTPUT_CSC_PREOFF_HI 0x49168
+#define _PIPE_B_OUTPUT_CSC_PREOFF_ME 0x4916c
+#define _PIPE_B_OUTPUT_CSC_PREOFF_LO 0x49170
+#define _PIPE_B_OUTPUT_CSC_POSTOFF_HI 0x49174
+#define _PIPE_B_OUTPUT_CSC_POSTOFF_ME 0x49178
+#define _PIPE_B_OUTPUT_CSC_POSTOFF_LO 0x4917c
+
+#define PIPE_CSC_OUTPUT_COEFF_RY_GY(pipe) _MMIO_PIPE(pipe,\
+
_PIPE_A_OUTPUT_CSC_COEFF_RY_GY,\
+
_PIPE_B_OUTPUT_CSC_COEFF_RY_GY)
+#define PIPE_CSC_OUTPUT_COEFF_BY(pipe) _MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_COEFF_BY, \
+
_PIPE_B_OUTPUT_CSC_COEFF_BY)
+#define PIPE_CSC_OUTPUT_COEFF_RU_GU(pipe) _MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_COEFF_RU_GU, \
+
_PIPE_B_OUTPUT_CSC_COEFF_RU_GU)
+#define PIPE_CSC_OUTPUT_COEFF_BU(pipe) _MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_COEFF_BU, \
+
_PIPE_B_OUTPUT_CSC_COEFF_BU)
+#define PIPE_CSC_OUTPUT_COEFF_RV_GV(pipe) _MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_COEFF_RV_GV, \
+
_PIPE_B_OUTPUT_CSC_COEFF_RV_GV)
+#define PIPE_CSC_OUTPUT_COEFF_BV(pipe) _MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_COEFF_BV, \
+
_PIPE_B_OUTPUT_CSC_COEFF_BV)
+#define PIPE_CSC_OUTPUT_PREOFF_HI(pipe)_MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_PREOFF_HI, \
+
_PIPE_B_OUTPUT_CSC_PREOFF_HI)
+#define PIPE_CSC_OUTPUT_PREOFF_ME(pipe)_MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_PREOFF_ME, \
+
_PIPE_B_OUTPUT_CSC_PREOFF_ME)
+#define PIPE_CSC_OUTPUT
[Intel-gfx] [v8 0/5] Add support for Gen 11 pipe color features
This patch series adds support for Gen11 pipe degamma, CSC and gamma hardware blocks. CRC checks are not working for 10bit gamma but works for 8bit pallete modes which seems to be due to some rounding errors in pipe. Also there is a corner case where Lut precision is increased to 3.16, hence its not possible to accurately represent 1.0 which will require 17 bits. Support for extending the ABI is already in discussion in below series: https://patchwork.freedesktop.org/patch/249771/ ToDo: Support for Multi Segmented Gamma will be added later. v2: Addressed Maarten's review comments and re-ordered the patch series. v3: Addressed Matt's review comments. Removed rmw patterns as suggested by Matt. v4: Addressed Matt's review comments. v5: Addressed Matt's, Ville and Jani Nikula's review comments. v6: Addressed Matt and Ville's review comments. Extended GLK degamma function and merged ICL degamma support to that. Handled pipe output csc separately along with regular pipe csc. Dropped gamma_mode removal patch as Ville is using that to refactor the gamma handling. This series may need a rebase on top of Ville's below series: https://patchwork.freedesktop.org/series/55081/. v7: Rebased the series on top of Ville's color management cleanup and state refactoring series. Addressed Matt's review comments and aligned state handling as per atomic design. v8: Fixed macro alignment and some checkpatch warnings. Uma Shankar (5): drm/i915/glk: Fix degamma lut programming drm/i915/icl: Add icl pipe degamma and gamma support drm/i915/icl: Enable ICL Pipe CSC block drm/i915/icl: Enable pipe output csc drm/i915/icl: Add degamma and gamma lut size to gen11 caps drivers/gpu/drm/i915/i915_pci.c| 5 +- drivers/gpu/drm/i915/i915_reg.h| 86 +++--- drivers/gpu/drm/i915/intel_color.c | 141 ++--- drivers/gpu/drm/i915/intel_drv.h | 3 + 4 files changed, 199 insertions(+), 36 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 5/5] drm/i915/icl: Add degamma and gamma lut size to gen11 caps
Add the degamma and gamma lut sizes to gen11 capability
structure.
Note: Currently this doesn't account for the extended range gamma
entries and this will be addressed with new segmented gamma ABI
in a future patch.
v2: Reorder the patch as per Maarten's suggestion.
v3: Rebase
v4: Updated commit message with a note as per Matt's suggestion.
v5: No Change.
Signed-off-by: Uma Shankar
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 2a4d25c..c4d6b8d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -648,7 +648,8 @@
}, \
GEN(11), \
.ddb_size = 2048, \
- .has_logical_ring_elsq = 1
+ .has_logical_ring_elsq = 1, \
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 1/5] drm/i915/glk: Fix degamma lut programming
Fixed the glk degamma lut programming which currently
was hard coding a linear lut all the time, making degamma
block of glk basically a pass through.
Currently degamma lut for glk is assigned as 0 in platform
configuration. Updated the same to 33 as per the hardware
capability. IGT tests for degamma were getting skipped due to
this, spotted by Swati.
ToDo: The current gamma/degamm lut ABI has just 16bit for each
color component. This is not enough for GLK+, since input
precision is increased to 3.16 which will need 19bit entries.
v2: Added Matt's RB.
v3: Changed uint32_t to u32.
Credits-to: Swati Sharma
Signed-off-by: Uma Shankar
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/i915_pci.c| 2 +-
drivers/gpu/drm/i915/intel_color.c | 34 ++
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 66f82f3..2a4d25c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -75,7 +75,7 @@
.gamma_lut_tests = DRM_COLOR_LUT_NON_DECREASING, \
}
#define GLK_COLORS \
- .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024, \
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024, \
.degamma_lut_tests = DRM_COLOR_LUT_NON_DECREASING | \
DRM_COLOR_LUT_EQUAL_CHANNELS, \
}
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index c0e2806..4e13286 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -518,7 +518,7 @@ static void glk_load_degamma_lut(const struct
intel_crtc_state *crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
- const u32 lut_size = 33;
+ const u32 lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
u32 i;
/*
@@ -529,14 +529,32 @@ static void glk_load_degamma_lut(const struct
intel_crtc_state *crtc_state)
I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), 0);
I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), PRE_CSC_GAMC_AUTO_INCREMENT);
- /*
-* FIXME: The pipe degamma table in geminilake doesn't support
-* different values per channel, so this just loads a linear table.
-*/
- for (i = 0; i < lut_size; i++) {
- u32 v = (i * (1 << 16)) / (lut_size - 1);
+ if (crtc_state->base.degamma_lut) {
+ struct drm_color_lut *lut = crtc_state->base.degamma_lut->data;
+
+ for (i = 0; i < lut_size; i++) {
+ /*
+* First 33 entries represent range from 0 to 1.0
+* 34th and 35th entry will represent extended range
+* inputs 3.0 and 7.0 respectively, currently clamped
+* at 1.0. Since the precision is 16bit, the user
+* value can be directly filled to register.
+* The pipe degamma table in GLK+ onwards doesn't
+* support different values per channel, so this just
+* programs green value which will be equal to Red and
+* Blue into the lut registers.
+* ToDo: Extend to max 7.0. Enable 32 bit input value
+* as compared to just 16 to achieve this.
+*/
+ I915_WRITE(PRE_CSC_GAMC_DATA(pipe), lut[i].green);
+ }
+ } else {
+ /* load a linear table. */
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * (1 << 16)) / (lut_size - 1);
- I915_WRITE(PRE_CSC_GAMC_DATA(pipe), v);
+ I915_WRITE(PRE_CSC_GAMC_DATA(pipe), v);
+ }
}
/* Clamp values > 1.0. */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 3/5] drm/i915/icl: Enable ICL Pipe CSC block
Enable ICL pipe csc hardware. CSC block is enabled
in CSC_MODE register instead of PLANE_COLOR_CTL.
ToDO: Extend the ABI to accept 32 bit coefficient values
instead of 16bit for future platforms.
v2: Addressed Maarten's review comments.
v3: Addressed Matt's review comments. Removed rmw patterns
as suggested by Matt.
v4: Addressed Matt's review comments.
v5: Addressed Ville's review comments.
v6: Separated pipe output csc programming from regular csc.
v7: Rebase
Signed-off-by: Uma Shankar
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/i915_reg.h| 9 ++---
drivers/gpu/drm/i915/intel_color.c | 5 -
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 13a207a..4cb0013 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9885,10 +9885,13 @@ enum skl_power_gate {
#define _PIPE_A_CSC_COEFF_BU 0x4901c
#define _PIPE_A_CSC_COEFF_RV_GV0x49020
#define _PIPE_A_CSC_COEFF_BV 0x49024
+
#define _PIPE_A_CSC_MODE 0x49028
-#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
-#define CSC_POSITION_BEFORE_GAMMA(1 << 1)
-#define CSC_MODE_YUV_TO_RGB (1 << 0)
+#define ICL_CSC_ENABLE(1 << 31)
+#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
+#define CSC_POSITION_BEFORE_GAMMA (1 << 1)
+#define CSC_MODE_YUV_TO_RGB (1 << 0)
+
#define _PIPE_A_CSC_PREOFF_HI 0x49030
#define _PIPE_A_CSC_PREOFF_ME 0x49034
#define _PIPE_A_CSC_PREOFF_LO 0x49038
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 0fcaae4..826f8a8 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -243,7 +243,10 @@ static void ilk_load_csc_matrix(const struct
intel_crtc_state *crtc_state)
I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), postoff);
I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), postoff);
- I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+ if (INTEL_GEN(dev_priv) >= 11)
+ I915_WRITE(PIPE_CSC_MODE(pipe), ICL_CSC_ENABLE);
+ else
+ I915_WRITE(PIPE_CSC_MODE(pipe), 0);
} else {
u32 mode = CSC_MODE_YUV_TO_RGB;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [IGT 1/2] tools/intel_gpu_top: Add support for stdout logging
On 08/02/2019 13:58, Eero Tamminen wrote: Hi, On 8.2.2019 14.03, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Two new output modes are added: listing of text data to standard out (-l on the command line), and dumping of JSON formatted records (-J), also to standard out. The first mode is selected automatically when non-interactive standard out is detected. Example of text output: Freq MHz IRQ RC6 Power IMC MiB/s RCS/0 BCS/0 VCS/0 VCS/1 VECS/0 req act /s % W rd wr % se wa % se wa % se wa % se wa % se wa 0 0 0 0 0.00 360 0 0.00 0 0 0.00 0 0 0.00 0 0 0.00 0 0 0.00 0 0 350 350 0 100 0.00 35 2 0.00 0 0 0.00 0 0 0.00 0 0 0.00 0 0 0.00 0 0 350 350 0 100 0.00 34 2 0.00 0 0 0.00 0 0 0.00 0 0 0.00 0 0 0.00 0 0 350 350 0 100 0.00 143 6 0.00 0 0 0.00 0 0 0.00 0 0 0.00 0 0 0.00 0 0 350 350 0 100 0.00 169 7 0.00 0 0 0.00 0 0 0.00 0 0 0.00 0 0 0.00 0 0 350 350 0 100 0.00 169 7 0.00 0 0 0.00 0 0 0.00 0 0 0.00 0 0 0.00 0 0 Looks nice! If you add '#' to the start of the header lines, one could use something like the attached shell script to convert the saved output to SVG graphs with GnuPlot. Before including the script to igt, it would need to be modified to adapt to the number of engines, but maybe intel_gpu_top itself could generate the gnuplot control file when it exits, if given e.g. --gnuplot argument? Hello feature creep! :D I could add gnuplot output mode later, just to keep this stage simpler. In that case I would prefer that this mode outputs a single file (or stdout stream) which could be fed to gnuplot directly. Eg. intel_gpu_top -g -o file.out && gnuplot file.out, or even, intel_gpu_top -g | gnuplot. Quick googling shows it should be possible to embed the data in the "control file", I am only not sure about the output filename in the second example. But anyway, first example should definitely work. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Protect i915_active iterators from the shrinker
On 08/02/2019 13:47, Chris Wilson wrote:
If we allocate while iterating the rbtree of active nodes, we may hit
the shrinker and so retire the i915_active reap the rbtree. Modifying
the rbtree as we iterate is not good behaviour, so acquire the
i915_active first to keep the tree intact whenever we allocate.
Fixes: a42375af0a30 ("drm/i915: Release the active tracker tree upon idling")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_active.c | 36 +-
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 215b6ff8aa73..db7bb5bd5add 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -163,17 +163,25 @@ int i915_active_ref(struct i915_active *ref,
struct i915_request *rq)
{
struct i915_active_request *active;
+ int err = 0;
+
+ /* Prevent reaping in case we malloc/wait while building the tree */
+ i915_active_acquire(ref);
active = active_instance(ref, timeline);
- if (IS_ERR(active))
- return PTR_ERR(active);
+ if (IS_ERR(active)) {
+ err = PTR_ERR(active);
+ goto out;
+ }
if (!i915_active_request_isset(active))
ref->count++;
__i915_active_request_set(active, rq);
GEM_BUG_ON(!ref->count);
- return 0;
+out:
+ i915_active_release(ref);
+ return err;
}
bool i915_active_acquire(struct i915_active *ref)
@@ -223,19 +231,25 @@ int i915_request_await_active_request(struct i915_request
*rq,
int i915_request_await_active(struct i915_request *rq, struct i915_active
*ref)
{
struct active_node *it, *n;
- int ret;
+ int err = 0;
- ret = i915_request_await_active_request(rq, &ref->last);
- if (ret)
- return ret;
+ /* await allocates and so we need to avoid hitting the shrinker */
+ if (i915_active_acquire(ref))
+ goto out; /* was idle */
+
+ err = i915_request_await_active_request(rq, &ref->last);
+ if (err)
+ goto out;
rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node) {
- ret = i915_request_await_active_request(rq, &it->base);
- if (ret)
- return ret;
+ err = i915_request_await_active_request(rq, &it->base);
+ if (err)
+ goto out;
}
- return 0;
+out:
+ i915_active_release(ref);
+ return err;
}
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/46] drm/i915/execlists: Suppress mere WAIT preemption
On 06/02/2019 13:03, Chris Wilson wrote:
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.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c| 12 ++
drivers/gpu/drm/i915/i915_scheduler.h | 2 +
drivers/gpu/drm/i915/intel_lrc.c | 9 +-
drivers/gpu/drm/i915/selftests/intel_lrc.c | 161 +
4 files changed, 183 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index c2a5c48c7541..35acef74b93a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -372,12 +372,24 @@ void __i915_request_submit(struct i915_request *request)
/* We may be recursing from the signal callback of another i915 fence */
spin_lock_nested(&request->lock, SINGLE_DEPTH_NESTING);
+
GEM_BUG_ON(test_bit(I915_FENCE_FLAG_ACTIVE, &request->fence.flags));
set_bit(I915_FENCE_FLAG_ACTIVE, &request->fence.flags);
+
request->global_seqno = seqno;
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &request->fence.flags) &&
!i915_request_enable_breadcrumb(request))
intel_engine_queue_breadcrumbs(engine);
+
+ /*
+* 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;
+
spin_unlock(&request->lock);
engine->emit_fini_breadcrumb(request,
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_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5d5ce91a5dfa..afd05e25f911 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -188,6 +188,12 @@ static inline int rq_prio(const struct i915_request *rq)
return rq->sched.attr.priority;
}
+static int effective_prio(const struct i915_request *rq)
+{
+ /* Restrict mere WAIT boosts from triggering preemption */
+ return rq_prio(rq) | __NO_PREEMPTION;
+}
+
static int queue_prio(const struct intel_engine_execlists *execlists)
{
struct i915_priolist *p;
@@ -208,7 +214,7 @@ static int queue_prio(const struct intel_engine_execlists
*execlists)
static inline bool need_preempt(const struct intel_engine_cs *engine,
const struct i915_request *rq)
{
- const int last_prio = rq_prio(rq);
+ int last_prio;
if (!intel_engine_has_preemption(engine))
return false;
@@ -228,6 +234,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
* preempt. If that hint is stale or we may be trying to preempt
* ourselves, ignore the request.
*/
+ last_prio = effective_prio(rq);
if (!__execlists_need_preempt(engine->execlists.queue_priority_hint,
last_prio))
return false;
diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
b/drivers/gpu/drm/i915/selftests/intel_lrc.c
index 58144e024751..263afd2f1596 100644
--- a/drivers/gpu/drm/i915/selftests/intel_lrc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
@@ -407,6 +407,166 @@ static int live_suppress_self_preempt(void *arg)
goto err_client_b;
}
+static int __i915_sw_fence_call
+dummy_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
+{
+ return NOTIFY_DONE;
+}
+
+static st
Re: [Intel-gfx] [v8 2/5] drm/i915/icl: Add icl pipe degamma and gamma support
Op 11-02-2019 om 10:26 schreef Uma Shankar:
> Add support for icl pipe degamma and gamma.
>
> v2: Removed a POSTING_READ and corrected the Bit
> Definition as per Maarten's comments.
>
> v3: Addressed Matt's review comments. Removed rmw patterns
> as suggested by Matt.
>
> v4: Fixed Matt's review comments.
>
> v5: Corrected macro alignment as per Jani Nikula's comments.
> Addressed Ville and Matt's review comments.
>
> v6: Merged ICL degamma handling with GLK and dropped ICL
> degamma function as per Ville and Matt's comments.
>
> v7: updated gamma_mode state with pre csc gammma and post
> gamma enabling in intel_color_check to align with atomic.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/i915_reg.h| 12 +++-
> drivers/gpu/drm/i915/intel_color.c | 32 ++--
> 2 files changed, 37 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 11bf60d..13a207a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7111,11 +7111,13 @@ enum {
> #define _GAMMA_MODE_A0x4a480
> #define _GAMMA_MODE_B0x4ac80
> #define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
> -#define GAMMA_MODE_MODE_MASK (3 << 0)
> -#define GAMMA_MODE_MODE_8BIT (0 << 0)
> -#define GAMMA_MODE_MODE_10BIT(1 << 0)
> -#define GAMMA_MODE_MODE_12BIT(2 << 0)
> -#define GAMMA_MODE_MODE_SPLIT(3 << 0)
> +#define PRE_CSC_GAMMA_ENABLE(1 << 31)
> +#define POST_CSC_GAMMA_ENABLE (1 << 30)
> +#define GAMMA_MODE_MODE_MASK(3 << 0)
> +#define GAMMA_MODE_MODE_8BIT(0 << 0)
> +#define GAMMA_MODE_MODE_10BIT (1 << 0)
> +#define GAMMA_MODE_MODE_12BIT (2 << 0)
> +#define GAMMA_MODE_MODE_SPLIT (3 << 0)
>
> /* DMC/CSR */
> #define CSR_PROGRAM(i) _MMIO(0x8 + (i) * 4)
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 4e13286..0fcaae4 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -583,6 +583,28 @@ static void glk_load_luts(const struct intel_crtc_state
> *crtc_state)
> }
> }
>
> +static void icl_load_luts(const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> +
> + glk_load_degamma_lut(crtc_state);
> +
> + if (crtc_state_is_legacy_gamma(crtc_state)) {
> + i9xx_load_luts(crtc_state);
> + } else {
> + /* ToDo: Add support for multi segment gamma LUT */
> + bdw_load_gamma_lut(crtc_state, 0);
> +
> + /*
> + * Reset the index, otherwise it prevents the legacy
> + * palette to be written properly.
> + */
> + I915_WRITE(PREC_PAL_INDEX(pipe), 0);
> + }
> +}
> +
Perhaps this write should be moved to bdw_load_gamma_lut() ?
Seems we might also fix the same missing write in glk_load_luts() then..
> static void cherryview_load_luts(const struct intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> @@ -772,7 +794,11 @@ int intel_color_check(struct intel_crtc_state
> *crtc_state)
> drm_color_lut_check(gamma_lut, gamma_tests))
> return -EINVAL;
>
> - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> + if (INTEL_GEN(dev_priv) >= 11)
> + crtc_state->gamma_mode = GAMMA_MODE_MODE_10BIT |
> + PRE_CSC_GAMMA_ENABLE |
> + POST_CSC_GAMMA_ENABLE;
> + else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> crtc_state->gamma_mode = GAMMA_MODE_MODE_10BIT;
> else if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
> crtc_state->gamma_mode = GAMMA_MODE_MODE_SPLIT;
> @@ -796,7 +822,9 @@ void intel_color_init(struct intel_crtc *crtc)
>
> dev_priv->display.color_commit = i9xx_color_commit;
> } else {
> - if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
> + if (IS_ICELAKE(dev_priv))
> + dev_priv->display.load_luts = icl_load_luts;
> + else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
> dev_priv->display.load_luts = glk_load_luts;
> else if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
> dev_priv->display.load_luts = broadwell_load_luts;
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v8 5/5] drm/i915/icl: Add degamma and gamma lut size to gen11 caps
Op 11-02-2019 om 10:26 schreef Uma Shankar:
> Add the degamma and gamma lut sizes to gen11 capability
> structure.
>
> Note: Currently this doesn't account for the extended range gamma
> entries and this will be addressed with new segmented gamma ABI
> in a future patch.
>
> v2: Reorder the patch as per Maarten's suggestion.
>
> v3: Rebase
>
> v4: Updated commit message with a note as per Matt's suggestion.
>
> v5: No Change.
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_pci.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 2a4d25c..c4d6b8d 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -648,7 +648,8 @@
> }, \
> GEN(11), \
> .ddb_size = 2048, \
> - .has_logical_ring_elsq = 1
> + .has_logical_ring_elsq = 1, \
> + .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
>
> static const struct intel_device_info intel_icelake_11_info = {
> GEN11_FEATURES,
For rest of series:
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Add support for Gen 11 pipe color features (rev8)
== Series Details ==
Series: Add support for Gen 11 pipe color features (rev8)
URL : https://patchwork.freedesktop.org/series/51408/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5585_full -> Patchwork_12190_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_12190_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12190_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12190_full:
### IGT changes ###
Warnings
* igt@kms_color@pipe-c-degamma:
- shard-glk: {SKIP} [fdo#109271] -> FAIL +4
Known issues
Here are the changes found in Patchwork_12190_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-write:
- shard-snb: PASS -> INCOMPLETE [fdo#105411]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-glk: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-hsw: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-glk: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-apl: PASS -> FAIL [fdo#103232] +3
* igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-apl: PASS -> FAIL [fdo#109350]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: PASS -> FAIL [fdo#103167] +3
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-glk: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-apl: PASS -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_multiple@atomic-pipe-c-tiling-none:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
Possible fixes
* igt@kms_busy@extended-pageflip-hang-newfb-render-c:
- shard-apl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-glk: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_color@pipe-b-ctm-green-to-red:
- shard-glk: {SKIP} [fdo#109271] -> PASS +29
* igt@kms_color@pipe-c-degamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* {igt@kms_flip@2x-flip-vs-suspend-interruptible}:
- shard-glk: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@kms_flip@modeset-vs-vblank-race-interruptible:
- shard-glk: FAIL [fdo#103060] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render:
- shard-apl: FAIL [fdo#103167] -> PASS +2
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-glk: FAIL [fdo#103166] -> PASS +2
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl: FAIL [fdo#103166] -> PASS +1
Warnings
* igt@i915_suspend@shrink:
- shard-apl: DMESG-WARN [fdo#107886] / [fdo#109244] -> INCOMPLETE
[fdo#103927] / [fdo#106886]
* igt@kms_color@pipe-a-degamma:
- shard-glk: {SKIP} [fdo#109271] -> FAIL [fdo#108145]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
[fdo#107886]: https://bugs.freedesktop.org/show_bug.cgi?id=107886
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedeskto
Re: [Intel-gfx] [PATCH] drm/i915: Skip scanning for signalers if we are already inflight
On 07/02/2019 18:52, Chris Wilson wrote:
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 d01683167c77..71ace2704d89 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));
@@ -294,6 +299,10 @@ static void __i915_schedule(struct i915_request *rq,
list_for_each_entry(dep, &dfs, 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
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/46] drm/i915: Make request allocation caches global
On 06/02/2019 13:03, Chris Wilson wrote:
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 | 105 ++
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 | 48
.../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, 306 insertions(+), 152 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 215b6ff8aa73..9026787ebdf8 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -280,7 +280,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 37230ae7fbe6..a365b1a2ea9a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1459,9 +1459,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 1eb3a5f8654c..d18c4ccff370 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)
@@ -2916,12 +2919,11 @@ static void shrink_caches(struct drm_i915_private *i915)
* filled slabs to prioritise allocating from the mostly full sl
[Intel-gfx] [IGT 1/2] tools/intel_gpu_top: Add support for stdout logging
From: Tvrtko Ursulin
Two new output modes are added: listing of text data to standard out (-l
on the command line), and dumping of JSON formatted records (-J), also to
standard out.
The first mode is selected automatically when non-interactive standard out
is detected.
Example of text output:
Freq MHz IRQ RC6 Power IMC MiB/s RCS/0 BCS/0
VCS/0 VCS/1 VECS/0
req act /s % W rd wr % se wa % se wa
% se wa % se wa % se wa
000 0 0.00360 00.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00 35 20.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00 34 20.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00143 60.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00169 70.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00169 70.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
Example of JSON output:
{
"period": {
"duration": 1002.525224,
"unit": "ms"
},
"frequency": {
"requested": 349.118398,
"actual": 349.118398,
"unit": "MHz"
},
"interrupts": {
"count": 0.00,
"unit": "irq/s"
},
"rc6": {
"value": 99.897752,
"unit": "%"
},
"power": {
"value": 0.00,
"unit": "W"
},
"imc-bandwidth": {
"reads": 149.683843,
"writes": 6.104093,
"unit": "MiB/s"
},
"engines": {
"Render/3D/0": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
},
"Blitter/0": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
},
"Video/0": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
},
"Video/1": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
},
"VideoEnhance/0": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
}
}
}
v2:
* Show example output in commit message.
* Install signal handler to complete output on SIGINT. (Chris Wilson)
v3:
* Use asprintf where possible. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
References: https://bugs.freedesktop.org/show_bug.cgi?id=108689
Cc: Eero Tamminen
Cc: 3.1...@ukr.net
Cc: Chris Wilson
---
man/intel_gpu_top.rst | 9 +-
tools/intel_gpu_top.c | 761 +++---
2 files changed, 644 insertions(+), 126 deletions(-)
diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index 19c712307d28..d5bda093c8e8 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -7,9 +7,9 @@ Display a top-like summary of Intel GPU usage
-
.. include:: defs.rst
:Author: IGT Developers
-:Date: 2018-04-04
+:Date: 2019-02-08
:Version: |PACKAGE_STRING|
-:Copyright: 2009,2011,2012,2016,2018 Intel Corporation
+:Copyright: 2009,2011,2012,2016,2018,2019 Intel Corporation
:Manual section: |MANUAL_SECTION|
:Manual group: |MANUAL_GROUP|
@@ -31,6 +31,11 @@ OPTIONS
-s
Refresh period in milliseconds.
+-l
+List text data to standard out.
+
+-J
+Output JSON formatted data to standard output.
-h
Show help text.
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index b923c3cfbe97..900979eea7a1 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -1,5 +1,5 @@
/*
- * Copyright © 2007-2018 Intel Corporation
+ * Copyright © 2007-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"),
@@ -19,10 +19,6 @@
* 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.
- *
- * Authors:
- *Eric Anholt
- *Eu
[Intel-gfx] [IGT 2/2] tools/intel_gpu_top: Add file output capability
From: Tvrtko Ursulin
A new -o command switch enables logging to a file.
v2:
* Support "-o -" for explicit stdout selection. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
References: https://bugs.freedesktop.org/show_bug.cgi?id=108689
Cc: Eero Tamminen
Cc: 3.1...@ukr.net
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
man/intel_gpu_top.rst | 19 -
tools/intel_gpu_top.c | 63 ---
2 files changed, 53 insertions(+), 29 deletions(-)
diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index d5bda093c8e8..d487baca0c63 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -28,16 +28,21 @@ The tool gathers data using perf performance counters (PMU)
exposed by i915 and
OPTIONS
===
--s
-Refresh period in milliseconds.
+-h
+Show help text.
+
+-J
+Output JSON formatted data.
-l
-List text data to standard out.
+List plain text data.
--J
-Output JSON formatted data to standard output.
--h
-Show help text.
+-o
+Output to the specified file instead of standard output.
+'-' can also be specified to explicitly select standard output.
+
+-s
+Refresh period in milliseconds.
LIMITATIONS
===
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 900979eea7a1..60505a606bfc 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -690,10 +690,11 @@ usage(const char *appname)
"Usage: %s [parameters]\n"
"\n"
"\tThe following parameters are optional:\n\n"
- "\t[-s ] Refresh period in milliseconds (default
%ums).\n"
- "\t[-l]List data to standard out.\n"
- "\t[-J]JSON data to standard out.\n"
"\t[-h]Show this help text.\n"
+ "\t[-J]Output JSON formatted data.\n"
+ "\t[-l]List plain text data.\n"
+ "\t[-o ] Output to specified file or '-' for standard
out.\n"
+ "\t[-s ] Refresh period in milliseconds (default
%ums).\n"
"\n",
appname, DEFAULT_PERIOD_MS);
}
@@ -740,6 +741,8 @@ static const char *json_indent[] = {
static unsigned int json_prev_struct_members;
static unsigned int json_struct_members;
+FILE *out;
+
static void
json_open_struct(const char *name)
{
@@ -749,14 +752,14 @@ json_open_struct(const char *name)
json_struct_members = 0;
if (name)
- printf("%s%s\"%s\": {\n",
- json_prev_struct_members ? ",\n" : "",
- json_indent[json_indent_level],
- name);
+ fprintf(out, "%s%s\"%s\": {\n",
+ json_prev_struct_members ? ",\n" : "",
+ json_indent[json_indent_level],
+ name);
else
- printf("%s\n%s{\n",
- json_prev_struct_members ? "," : "",
- json_indent[json_indent_level]);
+ fprintf(out, "%s\n%s{\n",
+ json_prev_struct_members ? "," : "",
+ json_indent[json_indent_level]);
json_indent_level++;
}
@@ -766,7 +769,7 @@ json_close_struct(void)
{
assert(json_indent_level > 0);
- printf("\n%s}", json_indent[--json_indent_level]);
+ fprintf(out, "\n%s}", json_indent[--json_indent_level]);
if (json_indent_level == 0)
fflush(stdout);
@@ -778,17 +781,17 @@ json_add_member(const struct cnt_group *parent, struct
cnt_item *item,
{
assert(json_indent_level < ARRAY_SIZE(json_indent));
- printf("%s%s\"%s\": ",
+ fprintf(out, "%s%s\"%s\": ",
json_struct_members ? ",\n" : "",
json_indent[json_indent_level], item->name);
json_struct_members++;
if (!strcmp(item->name, "unit"))
- printf("\"%s\"", item->unit);
+ fprintf(out, "\"%s\"", item->unit);
else
- printf("%f",
- pmu_calc(&item->pmu->val, item->d, item->t, item->s));
+ fprintf(out, "%f",
+ pmu_calc(&item->pmu->val, item->d, item->t, item->s));
return 1;
}
@@ -811,8 +814,8 @@ stdout_close_struct(void)
assert(stdout_level > 0);
if (--stdout_level == 0) {
stdout_lines++;
- printf("\n");
- fflush(stdout);
+ fputs("\n", out);
+ fflush(out);
}
}
@@ -844,10 +847,10 @@ stdout_add_member(const struct cnt_group *parent, struct
cnt_item *item,
grp_tot += 1 + it->fmt_d + (it->fmt_dd ? 1 : 0);
}
- printf("%*s ", grp_tot - 1, parent->display_name);
+ fprintf(out, "%*s ", grp_tot - 1, parent->display_name);
return 0;
} else if (headers == 2) {
-
Re: [Intel-gfx] [IGT 1/2] tools/intel_gpu_top: Add support for stdout logging
Quoting Tvrtko Ursulin (2019-02-11 11:45:22)
> +static enum {
> + INTERACTIVE,
> + STDOUT,
> + JSON
> +} output_mode;
> +
> +struct cnt_item {
> + struct pmu_counter *pmu;
/* "%*.*f", fmt_d, fmt_dd, X */
I tried fmt_d == fmt_width and fmt_dd == fmt_decimals
It's called field width and precision in the manpage, so
maybe fmt_width and fmt_precision.
Having figured that out, the use makes sense.
> + unsigned int fmt_d;
> + unsigned int fmt_dd;
> + double d;
> + double t;
> + double s;
> + const char *name;
> + const char *unit;
> +
> + /* Internal fields. */
> + char buf[16];
> +};
> +
> +struct cnt_group {
> + const char *name;
> + const char *display_name;
> + struct cnt_item *items;
> +};
> +
> +static unsigned int json_indent_level;
> +
> +static const char *json_indent[] = {
> + "",
> + "\t",
> + "\t\t",
> + "\t\t\t",
> + "\t\t\t\t",
> + "\t\t\t\t\t",
> +};
> +
> +#define ARRAY_SIZE(arr) (sizeof(arr)/sizeof(arr[0]))
> +
> +static unsigned int json_prev_struct_members;
> +static unsigned int json_struct_members;
> +
> +static void
> +json_open_struct(const char *name)
> +{
> + assert(json_indent_level < ARRAY_SIZE(json_indent));
> +
> + json_prev_struct_members = json_struct_members;
> + json_struct_members = 0;
> +
> + if (name)
> + printf("%s%s\"%s\": {\n",
> + json_prev_struct_members ? ",\n" : "",
> + json_indent[json_indent_level],
"%*s", json_indent_level, "\t\t\t\t\t"
didn't stick?
I could follow the flow, dug into a few of the details, and only have
some nits. One thing, could we feed in a perf record? I was thinking for
testing the various output modes with known data, but may also be useful
for replay.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/46] drm/i915: Compute the global scheduler caps
On 06/02/2019 13:03, Chris Wilson wrote:
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 d18c4ccff370..04fa184fdff5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4728,6 +4728,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 49fa43ff02ba..02ee86159adc 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -614,6 +614,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;
This effectively means that as soon engine->schedule is NULL for one
engine, scheduler caps will be zero. I am thinking if potentially it
would read clearer to just return from the if (engine->schedule) else
branch in that case.
May or may not need to zero i915->caps.scheduler at the beginning of the
function then - depending on whether we think configuration can change
dynamically at runtime.
Regards,
Tvrtko
+}
+
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 da5120283263..59891cca35c1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2341,12 +2341,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 e7d85aaee415..19faa19f2529 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -574,6 +574,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)
{
/*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/46] drm/i915: Compute the global scheduler caps
Quoting Tvrtko Ursulin (2019-02-11 12:24:31)
>
> On 06/02/2019 13:03, Chris Wilson wrote:
> > 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 d18c4ccff370..04fa184fdff5 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4728,6 +4728,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 49fa43ff02ba..02ee86159adc 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -614,6 +614,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;
>
> This effectively means that as soon engine->schedule is NULL for one
> engine, scheduler caps will be zero. I am thinking if potentially it
> would read clearer to just return from the if (engine->schedule) else
> branch in that case.
I thought it was nice to have the same pattern throughout the loop with
the final fixup of making sure that all caps were zero if the global
scheduler was disabled. Whether that fixup actually makes sense? As it
seems a little over protective as we already have an explicit on/off bit
(with the rest showing what you could have won!).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/46] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno
On 06/02/2019 13:03, Chris Wilson wrote:
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).
We couldn't keep the global seqno just for hangcheck puposes? I mean as
long as it is unique, which would be guaranteed by obtaining an
increment on every submission to hw and storing it in atomic_t
i915->hangcheck_global_seqno / rq->hangcheck_global_seqno, hangcheck
does not care about the order of execution, no?
Regards,
Tvrtko
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.
Signed-off-by: Chris Wilson
---
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 af53a2d07f6b..846bd0de3cfa 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], &instdone);
@@ -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 57cfc4c551c9..e1e54b7448b4 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1538,10 +1538,11 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_terminally_wedged(&engine->i915->gpu_error))
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 a219c796e56d..e04b2560369e 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
Re: [Intel-gfx] [PATCH 10/46] drm/i915: Make request allocation caches global
Quoting Tvrtko Ursulin (2019-02-11 11:43:41)
>
> On 06/02/2019 13:03, Chris Wilson wrote:
> > 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 | 105 ++
> > 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 | 48
> > .../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, 306 insertions(+), 152 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 215b6ff8aa73..9026787ebdf8 100644
> > --- a/drivers/gpu/drm/i915/i915_active.c
> > +++ b/drivers/gpu/drm/i915/i915_active.c
> > @@ -280,7 +280,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 37230ae7fbe6..a365b1a2ea9a 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1459,9 +1459,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 1eb3a5f8654c..d18c4ccff370 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_vgp
Re: [Intel-gfx] [PATCH 18/46] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno
Quoting Tvrtko Ursulin (2019-02-11 12:40:07) > > On 06/02/2019 13:03, Chris Wilson wrote: > > 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). > > We couldn't keep the global seqno just for hangcheck puposes? I mean as > long as it is unique, which would be guaranteed by obtaining an > increment on every submission to hw and storing it in atomic_t > i915->hangcheck_global_seqno / rq->hangcheck_global_seqno, hangcheck > does not care about the order of execution, no? s/global_seqno/hangcheck_seqno/ ? (a) the goal is to kill off global_seqno entirely so we are all sure there is no such seqno or ordering anymore (b) this is a temporary patch and we kill off hangcheck_seqno, just as soon as I can submit requests without struct_mutex -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Protect i915_active iterators from the shrinker
Quoting Tvrtko Ursulin (2019-02-11 11:13:12)
>
> On 08/02/2019 13:47, Chris Wilson wrote:
> > If we allocate while iterating the rbtree of active nodes, we may hit
> > the shrinker and so retire the i915_active reap the rbtree. Modifying
> > the rbtree as we iterate is not good behaviour, so acquire the
> > i915_active first to keep the tree intact whenever we allocate.
Bleugh, better grammar included.
> > Fixes: a42375af0a30 ("drm/i915: Release the active tracker tree upon
> > idling")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: Joonas Lahtinen
> Reviewed-by: Tvrtko Ursulin
And pushed, thanks.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v8 2/5] drm/i915/icl: Add icl pipe degamma and gamma support
>-Original Message-
>From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>Sent: Monday, February 11, 2019 4:51 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx] [v8 2/5] drm/i915/icl: Add icl pipe degamma and gamma
>support
>
>Op 11-02-2019 om 10:26 schreef Uma Shankar:
>> Add support for icl pipe degamma and gamma.
>>
>> v2: Removed a POSTING_READ and corrected the Bit Definition as per
>> Maarten's comments.
>>
>> v3: Addressed Matt's review comments. Removed rmw patterns as
>> suggested by Matt.
>>
>> v4: Fixed Matt's review comments.
>>
>> v5: Corrected macro alignment as per Jani Nikula's comments.
>> Addressed Ville and Matt's review comments.
>>
>> v6: Merged ICL degamma handling with GLK and dropped ICL degamma
>> function as per Ville and Matt's comments.
>>
>> v7: updated gamma_mode state with pre csc gammma and post gamma
>> enabling in intel_color_check to align with atomic.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/i915_reg.h| 12 +++-
>> drivers/gpu/drm/i915/intel_color.c | 32
>> ++--
>> 2 files changed, 37 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index 11bf60d..13a207a 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -7111,11 +7111,13 @@ enum {
>> #define _GAMMA_MODE_A 0x4a480
>> #define _GAMMA_MODE_B 0x4ac80
>> #define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A,
>_GAMMA_MODE_B)
>> -#define GAMMA_MODE_MODE_MASK(3 << 0)
>> -#define GAMMA_MODE_MODE_8BIT(0 << 0)
>> -#define GAMMA_MODE_MODE_10BIT (1 << 0)
>> -#define GAMMA_MODE_MODE_12BIT (2 << 0)
>> -#define GAMMA_MODE_MODE_SPLIT (3 << 0)
>> +#define PRE_CSC_GAMMA_ENABLE (1 << 31)
>> +#define POST_CSC_GAMMA_ENABLE (1 << 30)
>> +#define GAMMA_MODE_MODE_MASK (3 << 0)
>> +#define GAMMA_MODE_MODE_8BIT (0 << 0)
>> +#define GAMMA_MODE_MODE_10BIT (1 << 0)
>> +#define GAMMA_MODE_MODE_12BIT (2 << 0)
>> +#define GAMMA_MODE_MODE_SPLIT (3 << 0)
>>
>> /* DMC/CSR */
>> #define CSR_PROGRAM(i) _MMIO(0x8 + (i) * 4)
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index 4e13286..0fcaae4 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -583,6 +583,28 @@ static void glk_load_luts(const struct intel_crtc_state
>*crtc_state)
>> }
>> }
>>
>> +static void icl_load_luts(const struct intel_crtc_state *crtc_state)
>> +{
>> +struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>> +struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> +enum pipe pipe = crtc->pipe;
>> +
>> +glk_load_degamma_lut(crtc_state);
>> +
>> +if (crtc_state_is_legacy_gamma(crtc_state)) {
>> +i9xx_load_luts(crtc_state);
>> +} else {
>> +/* ToDo: Add support for multi segment gamma LUT */
>> +bdw_load_gamma_lut(crtc_state, 0);
>> +
>> +/*
>> + * Reset the index, otherwise it prevents the legacy
>> + * palette to be written properly.
>> + */
>> +I915_WRITE(PREC_PAL_INDEX(pipe), 0);
>> +}
>> +}
>> +
>
>Perhaps this write should be moved to bdw_load_gamma_lut() ?
>
>Seems we might also fix the same missing write in glk_load_luts() then..
Thanks Maarten for reviewing this series.
Ok Sure, will move this to bdw_load_gamma_lut(). Can I add your RB on this
patch also with this fix ?
Will send out the next version once you confirm.
Regards,
Uma Shankar
>
>> static void cherryview_load_luts(const struct intel_crtc_state
>> *crtc_state) {
>> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>> @@ -772,7 +794,11 @@ int intel_color_check(struct intel_crtc_state
>> *crtc_state)
>> drm_color_lut_check(gamma_lut, gamma_tests))
>> return -EINVAL;
>>
>> -if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
>> +if (INTEL_GEN(dev_priv) >= 11)
>> +crtc_state->gamma_mode = GAMMA_MODE_MODE_10BIT |
>> + PRE_CSC_GAMMA_ENABLE |
>> + POST_CSC_GAMMA_ENABLE;
>> +else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
>> crtc_state->gamma_mode = GAMMA_MODE_MODE_10BIT;
>> else if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
>> crtc_state->gamma_mode = GAMMA_MODE_MODE_SPLIT; @@ -
>796,7 +822,9 @@
>> void intel_color_init(struct intel_crtc *crtc)
>>
>> dev_priv->display.color_commit = i9xx_color_commit;
>> } else {
>> -if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
>> +if (IS_ICELAKE(dev_priv))
>> +dev_priv->displ
[Intel-gfx] [PATCH] drm/i915: Include the current timeline seqno for debugging execlists
While this is mainly only useful for ELSP[0], it is definitely useful to
know the current timeline seqno wrt to the queued set of requests for
that port, as this carries additional information above and beyond the
near-defunct global_seqno and global HWSP.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 49fa43ff02ba..2547e2e51db8 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1425,10 +1425,11 @@ static void intel_engine_print_registers(const struct
intel_engine_cs *engine,
char hdr[80];
snprintf(hdr, sizeof(hdr),
-"\t\tELSP[%d] count=%d,
ring:{start:%08x, hwsp:%08x}, rq: ",
+"\t\tELSP[%d] count=%d,
ring:{start:%08x, hwsp:%08x, seqno:%08x}, rq: ",
idx, count,
i915_ggtt_offset(rq->ring->vma),
-rq->timeline->hwsp_offset);
+rq->timeline->hwsp_offset,
+hwsp_seqno(rq));
print_request(m, rq, hdr);
} else {
drm_printf(m, "\t\tELSP[%d] idle\n", idx);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v8 2/5] drm/i915/icl: Add icl pipe degamma and gamma support
Op 11-02-2019 om 14:01 schreef Shankar, Uma:
>
>> -Original Message-
>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>> Sent: Monday, February 11, 2019 4:51 PM
>> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
>> Cc: Syrjala, Ville ; Lankhorst, Maarten
>>
>> Subject: Re: [Intel-gfx] [v8 2/5] drm/i915/icl: Add icl pipe degamma and
>> gamma
>> support
>>
>> Op 11-02-2019 om 10:26 schreef Uma Shankar:
>>> Add support for icl pipe degamma and gamma.
>>>
>>> v2: Removed a POSTING_READ and corrected the Bit Definition as per
>>> Maarten's comments.
>>>
>>> v3: Addressed Matt's review comments. Removed rmw patterns as
>>> suggested by Matt.
>>>
>>> v4: Fixed Matt's review comments.
>>>
>>> v5: Corrected macro alignment as per Jani Nikula's comments.
>>> Addressed Ville and Matt's review comments.
>>>
>>> v6: Merged ICL degamma handling with GLK and dropped ICL degamma
>>> function as per Ville and Matt's comments.
>>>
>>> v7: updated gamma_mode state with pre csc gammma and post gamma
>>> enabling in intel_color_check to align with atomic.
>>>
>>> Signed-off-by: Uma Shankar
>>> ---
>>> drivers/gpu/drm/i915/i915_reg.h| 12 +++-
>>> drivers/gpu/drm/i915/intel_color.c | 32
>>> ++--
>>> 2 files changed, 37 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>> b/drivers/gpu/drm/i915/i915_reg.h index 11bf60d..13a207a 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -7111,11 +7111,13 @@ enum {
>>> #define _GAMMA_MODE_A 0x4a480
>>> #define _GAMMA_MODE_B 0x4ac80
>>> #define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A,
>> _GAMMA_MODE_B)
>>> -#define GAMMA_MODE_MODE_MASK (3 << 0)
>>> -#define GAMMA_MODE_MODE_8BIT (0 << 0)
>>> -#define GAMMA_MODE_MODE_10BIT (1 << 0)
>>> -#define GAMMA_MODE_MODE_12BIT (2 << 0)
>>> -#define GAMMA_MODE_MODE_SPLIT (3 << 0)
>>> +#define PRE_CSC_GAMMA_ENABLE (1 << 31)
>>> +#define POST_CSC_GAMMA_ENABLE (1 << 30)
>>> +#define GAMMA_MODE_MODE_MASK (3 << 0)
>>> +#define GAMMA_MODE_MODE_8BIT (0 << 0)
>>> +#define GAMMA_MODE_MODE_10BIT (1 << 0)
>>> +#define GAMMA_MODE_MODE_12BIT (2 << 0)
>>> +#define GAMMA_MODE_MODE_SPLIT (3 << 0)
>>>
>>> /* DMC/CSR */
>>> #define CSR_PROGRAM(i) _MMIO(0x8 + (i) * 4)
>>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>>> b/drivers/gpu/drm/i915/intel_color.c
>>> index 4e13286..0fcaae4 100644
>>> --- a/drivers/gpu/drm/i915/intel_color.c
>>> +++ b/drivers/gpu/drm/i915/intel_color.c
>>> @@ -583,6 +583,28 @@ static void glk_load_luts(const struct intel_crtc_state
>> *crtc_state)
>>> }
>>> }
>>>
>>> +static void icl_load_luts(const struct intel_crtc_state *crtc_state)
>>> +{
>>> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>>> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>>> + enum pipe pipe = crtc->pipe;
>>> +
>>> + glk_load_degamma_lut(crtc_state);
>>> +
>>> + if (crtc_state_is_legacy_gamma(crtc_state)) {
>>> + i9xx_load_luts(crtc_state);
>>> + } else {
>>> + /* ToDo: Add support for multi segment gamma LUT */
>>> + bdw_load_gamma_lut(crtc_state, 0);
>>> +
>>> + /*
>>> +* Reset the index, otherwise it prevents the legacy
>>> +* palette to be written properly.
>>> +*/
>>> + I915_WRITE(PREC_PAL_INDEX(pipe), 0);
>>> + }
>>> +}
>>> +
>> Perhaps this write should be moved to bdw_load_gamma_lut() ?
>>
>> Seems we might also fix the same missing write in glk_load_luts() then..
> Thanks Maarten for reviewing this series.
>
> Ok Sure, will move this to bdw_load_gamma_lut(). Can I add your RB on this
> patch also with this fix ?
>
> Will send out the next version once you confirm.
Yes. :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v9 4/5] drm/i915/icl: Enable pipe output csc
GEN11+ onwards an output csc hardware block has been added.
This is after the pipe gamma block and is in addition to the
legacy pipe CSC block. Primary use case for this block is to
convert RGB to YUV in case sink supports YUV.
This patch adds supports for the same.
v2: This is added after splitting the existing ICL pipe CSC
handling. As per Matt's suggestion, made this to co-exist
with existing pipe CSC, wherein both can be enabled if a
certain usecase arises.
v3: Fixed an issue with co-existence of output csc and normal
pipe csc, spotted by Matt. Put the csc mode flag enabling to
color_check to align with atomic.
v4: Fixed macro alignment and checkpatch complaints wrt line over
100 characters limit.
Signed-off-by: Uma Shankar
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_reg.h| 65
drivers/gpu/drm/i915/intel_color.c | 77 --
drivers/gpu/drm/i915/intel_drv.h | 3 ++
3 files changed, 126 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4cb0013..668e862 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9888,6 +9888,7 @@ enum skl_power_gate {
#define _PIPE_A_CSC_MODE 0x49028
#define ICL_CSC_ENABLE(1 << 31)
+#define ICL_OUTPUT_CSC_ENABLE (1 << 30)
#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
#define CSC_POSITION_BEFORE_GAMMA (1 << 1)
#define CSC_MODE_YUV_TO_RGB (1 << 0)
@@ -9927,6 +9928,70 @@ enum skl_power_gate {
#define PIPE_CSC_POSTOFF_ME(pipe) _MMIO_PIPE(pipe,
_PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
#define PIPE_CSC_POSTOFF_LO(pipe) _MMIO_PIPE(pipe,
_PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
+/* Pipe Output CSC */
+#define _PIPE_A_OUTPUT_CSC_COEFF_RY_GY 0x49050
+#define _PIPE_A_OUTPUT_CSC_COEFF_BY0x49054
+#define _PIPE_A_OUTPUT_CSC_COEFF_RU_GU 0x49058
+#define _PIPE_A_OUTPUT_CSC_COEFF_BU0x4905c
+#define _PIPE_A_OUTPUT_CSC_COEFF_RV_GV 0x49060
+#define _PIPE_A_OUTPUT_CSC_COEFF_BV0x49064
+#define _PIPE_A_OUTPUT_CSC_PREOFF_HI 0x49068
+#define _PIPE_A_OUTPUT_CSC_PREOFF_ME 0x4906c
+#define _PIPE_A_OUTPUT_CSC_PREOFF_LO 0x49070
+#define _PIPE_A_OUTPUT_CSC_POSTOFF_HI 0x49074
+#define _PIPE_A_OUTPUT_CSC_POSTOFF_ME 0x49078
+#define _PIPE_A_OUTPUT_CSC_POSTOFF_LO 0x4907c
+
+#define _PIPE_B_OUTPUT_CSC_COEFF_RY_GY 0x49150
+#define _PIPE_B_OUTPUT_CSC_COEFF_BY0x49154
+#define _PIPE_B_OUTPUT_CSC_COEFF_RU_GU 0x49158
+#define _PIPE_B_OUTPUT_CSC_COEFF_BU0x4915c
+#define _PIPE_B_OUTPUT_CSC_COEFF_RV_GV 0x49160
+#define _PIPE_B_OUTPUT_CSC_COEFF_BV0x49164
+#define _PIPE_B_OUTPUT_CSC_PREOFF_HI 0x49168
+#define _PIPE_B_OUTPUT_CSC_PREOFF_ME 0x4916c
+#define _PIPE_B_OUTPUT_CSC_PREOFF_LO 0x49170
+#define _PIPE_B_OUTPUT_CSC_POSTOFF_HI 0x49174
+#define _PIPE_B_OUTPUT_CSC_POSTOFF_ME 0x49178
+#define _PIPE_B_OUTPUT_CSC_POSTOFF_LO 0x4917c
+
+#define PIPE_CSC_OUTPUT_COEFF_RY_GY(pipe) _MMIO_PIPE(pipe,\
+
_PIPE_A_OUTPUT_CSC_COEFF_RY_GY,\
+
_PIPE_B_OUTPUT_CSC_COEFF_RY_GY)
+#define PIPE_CSC_OUTPUT_COEFF_BY(pipe) _MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_COEFF_BY, \
+
_PIPE_B_OUTPUT_CSC_COEFF_BY)
+#define PIPE_CSC_OUTPUT_COEFF_RU_GU(pipe) _MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_COEFF_RU_GU, \
+
_PIPE_B_OUTPUT_CSC_COEFF_RU_GU)
+#define PIPE_CSC_OUTPUT_COEFF_BU(pipe) _MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_COEFF_BU, \
+
_PIPE_B_OUTPUT_CSC_COEFF_BU)
+#define PIPE_CSC_OUTPUT_COEFF_RV_GV(pipe) _MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_COEFF_RV_GV, \
+
_PIPE_B_OUTPUT_CSC_COEFF_RV_GV)
+#define PIPE_CSC_OUTPUT_COEFF_BV(pipe) _MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_COEFF_BV, \
+
_PIPE_B_OUTPUT_CSC_COEFF_BV)
+#define PIPE_CSC_OUTPUT_PREOFF_HI(pipe)_MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_PREOFF_HI, \
+
_PIPE_B_OUTPUT_CSC_PREOFF_HI)
+#define PIPE_CSC_OUTPUT_PREOFF_ME(pipe)_MMIO_PIPE(pipe, \
+
_PIPE_A_OUTPUT_CSC_PREOFF_ME, \
+
_PIPE_B_OUTPUT_CSC_PRE
[Intel-gfx] [v9 2/5] drm/i915/icl: Add icl pipe degamma and gamma support
Add support for icl pipe degamma and gamma.
v2: Removed a POSTING_READ and corrected the Bit
Definition as per Maarten's comments.
v3: Addressed Matt's review comments. Removed rmw patterns
as suggested by Matt.
v4: Fixed Matt's review comments.
v5: Corrected macro alignment as per Jani Nikula's comments.
Addressed Ville and Matt's review comments.
v6: Merged ICL degamma handling with GLK and dropped ICL
degamma function as per Ville and Matt's comments.
v7: updated gamma_mode state with pre csc gammma and post
gamma enabling in intel_color_check to align with atomic.
v8: Addressed Maarten's review comments.
Signed-off-by: Uma Shankar
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_reg.h| 12 +++-
drivers/gpu/drm/i915/intel_color.c | 21 +++--
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 11bf60d..13a207a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7111,11 +7111,13 @@ enum {
#define _GAMMA_MODE_A 0x4a480
#define _GAMMA_MODE_B 0x4ac80
#define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
-#define GAMMA_MODE_MODE_MASK (3 << 0)
-#define GAMMA_MODE_MODE_8BIT (0 << 0)
-#define GAMMA_MODE_MODE_10BIT (1 << 0)
-#define GAMMA_MODE_MODE_12BIT (2 << 0)
-#define GAMMA_MODE_MODE_SPLIT (3 << 0)
+#define PRE_CSC_GAMMA_ENABLE (1 << 31)
+#define POST_CSC_GAMMA_ENABLE (1 << 30)
+#define GAMMA_MODE_MODE_MASK (3 << 0)
+#define GAMMA_MODE_MODE_8BIT (0 << 0)
+#define GAMMA_MODE_MODE_10BIT (1 << 0)
+#define GAMMA_MODE_MODE_12BIT (2 << 0)
+#define GAMMA_MODE_MODE_SPLIT (3 << 0)
/* DMC/CSR */
#define CSR_PROGRAM(i) _MMIO(0x8 + (i) * 4)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index e391899..c5bd0f9 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -571,6 +571,17 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
bdw_load_gamma_lut(crtc_state, 0);
}
+static void icl_load_luts(const struct intel_crtc_state *crtc_state)
+{
+ glk_load_degamma_lut(crtc_state);
+
+ if (crtc_state_is_legacy_gamma(crtc_state))
+ i9xx_load_luts(crtc_state);
+ else
+ /* ToDo: Add support for multi segment gamma LUT */
+ bdw_load_gamma_lut(crtc_state, 0);
+}
+
static void cherryview_load_luts(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
@@ -760,7 +771,11 @@ int intel_color_check(struct intel_crtc_state *crtc_state)
drm_color_lut_check(gamma_lut, gamma_tests))
return -EINVAL;
- if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ if (INTEL_GEN(dev_priv) >= 11)
+ crtc_state->gamma_mode = GAMMA_MODE_MODE_10BIT |
+PRE_CSC_GAMMA_ENABLE |
+POST_CSC_GAMMA_ENABLE;
+ else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
crtc_state->gamma_mode = GAMMA_MODE_MODE_10BIT;
else if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
crtc_state->gamma_mode = GAMMA_MODE_MODE_SPLIT;
@@ -784,7 +799,9 @@ void intel_color_init(struct intel_crtc *crtc)
dev_priv->display.color_commit = i9xx_color_commit;
} else {
- if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ if (IS_ICELAKE(dev_priv))
+ dev_priv->display.load_luts = icl_load_luts;
+ else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
dev_priv->display.load_luts = glk_load_luts;
else if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
dev_priv->display.load_luts = broadwell_load_luts;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v9 5/5] drm/i915/icl: Add degamma and gamma lut size to gen11 caps
Add the degamma and gamma lut sizes to gen11 capability
structure.
Note: Currently this doesn't account for the extended range gamma
entries and this will be addressed with new segmented gamma ABI
in a future patch.
v2: Reorder the patch as per Maarten's suggestion.
v3: Rebase
v4: Updated commit message with a note as per Matt's suggestion.
v5: No Change.
Signed-off-by: Uma Shankar
Reviewed-by: Matt Roper
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 2a4d25c..c4d6b8d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -648,7 +648,8 @@
}, \
GEN(11), \
.ddb_size = 2048, \
- .has_logical_ring_elsq = 1
+ .has_logical_ring_elsq = 1, \
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v9 3/5] drm/i915/icl: Enable ICL Pipe CSC block
Enable ICL pipe csc hardware. CSC block is enabled
in CSC_MODE register instead of PLANE_COLOR_CTL.
ToDO: Extend the ABI to accept 32 bit coefficient values
instead of 16bit for future platforms.
v2: Addressed Maarten's review comments.
v3: Addressed Matt's review comments. Removed rmw patterns
as suggested by Matt.
v4: Addressed Matt's review comments.
v5: Addressed Ville's review comments.
v6: Separated pipe output csc programming from regular csc.
v7: Rebase
Signed-off-by: Uma Shankar
Reviewed-by: Matt Roper
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_reg.h| 9 ++---
drivers/gpu/drm/i915/intel_color.c | 5 -
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 13a207a..4cb0013 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9885,10 +9885,13 @@ enum skl_power_gate {
#define _PIPE_A_CSC_COEFF_BU 0x4901c
#define _PIPE_A_CSC_COEFF_RV_GV0x49020
#define _PIPE_A_CSC_COEFF_BV 0x49024
+
#define _PIPE_A_CSC_MODE 0x49028
-#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
-#define CSC_POSITION_BEFORE_GAMMA(1 << 1)
-#define CSC_MODE_YUV_TO_RGB (1 << 0)
+#define ICL_CSC_ENABLE(1 << 31)
+#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
+#define CSC_POSITION_BEFORE_GAMMA (1 << 1)
+#define CSC_MODE_YUV_TO_RGB (1 << 0)
+
#define _PIPE_A_CSC_PREOFF_HI 0x49030
#define _PIPE_A_CSC_PREOFF_ME 0x49034
#define _PIPE_A_CSC_PREOFF_LO 0x49038
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index c5bd0f9..395b475 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -243,7 +243,10 @@ static void ilk_load_csc_matrix(const struct
intel_crtc_state *crtc_state)
I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), postoff);
I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), postoff);
- I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+ if (INTEL_GEN(dev_priv) >= 11)
+ I915_WRITE(PIPE_CSC_MODE(pipe), ICL_CSC_ENABLE);
+ else
+ I915_WRITE(PIPE_CSC_MODE(pipe), 0);
} else {
u32 mode = CSC_MODE_YUV_TO_RGB;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v9 1/5] drm/i915/glk: Fix degamma lut programming
Fixed the glk degamma lut programming which currently
was hard coding a linear lut all the time, making degamma
block of glk basically a pass through.
Currently degamma lut for glk is assigned as 0 in platform
configuration. Updated the same to 33 as per the hardware
capability. IGT tests for degamma were getting skipped due to
this, spotted by Swati.
ToDo: The current gamma/degamm lut ABI has just 16bit for each
color component. This is not enough for GLK+, since input
precision is increased to 3.16 which will need 19bit entries.
v2: Added Matt's RB.
v3: Changed uint32_t to u32.
v4: Fixed Maarten's review comment
Credits-to: Swati Sharma
Signed-off-by: Uma Shankar
Reviewed-by: Matt Roper
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_pci.c| 2 +-
drivers/gpu/drm/i915/intel_color.c | 62 +-
2 files changed, 35 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 66f82f3..2a4d25c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -75,7 +75,7 @@
.gamma_lut_tests = DRM_COLOR_LUT_NON_DECREASING, \
}
#define GLK_COLORS \
- .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024, \
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024, \
.degamma_lut_tests = DRM_COLOR_LUT_NON_DECREASING | \
DRM_COLOR_LUT_EQUAL_CHANNELS, \
}
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index c0e2806..e391899 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -489,6 +489,12 @@ static void bdw_load_gamma_lut(const struct
intel_crtc_state *crtc_state, u32 of
I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), (1 << 16) - 1);
I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), (1 << 16) - 1);
}
+
+ /*
+* Reset the index, otherwise it prevents the legacy palette to be
+* written properly.
+*/
+ I915_WRITE(PREC_PAL_INDEX(pipe), 0);
}
/* Loads the palette/gamma unit for the CRTC on Broadwell+. */
@@ -496,7 +502,6 @@ static void broadwell_load_luts(const struct
intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum pipe pipe = crtc->pipe;
if (crtc_state_is_legacy_gamma(crtc_state)) {
i9xx_load_luts(crtc_state);
@@ -504,12 +509,6 @@ static void broadwell_load_luts(const struct
intel_crtc_state *crtc_state)
bdw_load_degamma_lut(crtc_state);
bdw_load_gamma_lut(crtc_state,
INTEL_INFO(dev_priv)->color.degamma_lut_size);
-
- /*
-* Reset the index, otherwise it prevents the legacy palette to
be
-* written properly.
-*/
- I915_WRITE(PREC_PAL_INDEX(pipe), 0);
}
}
@@ -518,7 +517,7 @@ static void glk_load_degamma_lut(const struct
intel_crtc_state *crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
- const u32 lut_size = 33;
+ const u32 lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
u32 i;
/*
@@ -529,14 +528,32 @@ static void glk_load_degamma_lut(const struct
intel_crtc_state *crtc_state)
I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), 0);
I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), PRE_CSC_GAMC_AUTO_INCREMENT);
- /*
-* FIXME: The pipe degamma table in geminilake doesn't support
-* different values per channel, so this just loads a linear table.
-*/
- for (i = 0; i < lut_size; i++) {
- u32 v = (i * (1 << 16)) / (lut_size - 1);
+ if (crtc_state->base.degamma_lut) {
+ struct drm_color_lut *lut = crtc_state->base.degamma_lut->data;
+
+ for (i = 0; i < lut_size; i++) {
+ /*
+* First 33 entries represent range from 0 to 1.0
+* 34th and 35th entry will represent extended range
+* inputs 3.0 and 7.0 respectively, currently clamped
+* at 1.0. Since the precision is 16bit, the user
+* value can be directly filled to register.
+* The pipe degamma table in GLK+ onwards doesn't
+* support different values per channel, so this just
+* programs green value which will be equal to Red and
+* Blue into the lut registers.
+* ToDo: Extend to max 7.0. Enable 32 bit input value
+* as compared to just 16 to achieve
[Intel-gfx] [v9 0/5] Add support for Gen 11 pipe color features
This patch series adds support for Gen11 pipe degamma, CSC and gamma hardware blocks. CRC checks are not working for 10bit gamma but works for 8bit pallete modes which seems to be due to some rounding errors in pipe. Also there is a corner case where Lut precision is increased to 3.16, hence its not possible to accurately represent 1.0 which will require 17 bits. Support for extending the ABI is already in discussion in below series: https://patchwork.freedesktop.org/patch/249771/ ToDo: Support for Multi Segmented Gamma will be added later. v2: Addressed Maarten's review comments and re-ordered the patch series. v3: Addressed Matt's review comments. Removed rmw patterns as suggested by Matt. v4: Addressed Matt's review comments. v5: Addressed Matt's, Ville and Jani Nikula's review comments. v6: Addressed Matt and Ville's review comments. Extended GLK degamma function and merged ICL degamma support to that. Handled pipe output csc separately along with regular pipe csc. Dropped gamma_mode removal patch as Ville is using that to refactor the gamma handling. This series may need a rebase on top of Ville's below series: https://patchwork.freedesktop.org/series/55081/. v7: Rebased the series on top of Ville's color management cleanup and state refactoring series. Addressed Matt's review comments and aligned state handling as per atomic design. v8: Fixed macro alignment and some checkpatch warnings. v9: Fix Maarten's review comments and added his RB tag. Uma Shankar (5): drm/i915/glk: Fix degamma lut programming drm/i915/icl: Add icl pipe degamma and gamma support drm/i915/icl: Enable ICL Pipe CSC block drm/i915/icl: Enable pipe output csc drm/i915/icl: Add degamma and gamma lut size to gen11 caps drivers/gpu/drm/i915/i915_pci.c| 5 +- drivers/gpu/drm/i915/i915_reg.h| 86 ++-- drivers/gpu/drm/i915/intel_color.c | 155 ++--- drivers/gpu/drm/i915/intel_drv.h | 3 + 4 files changed, 194 insertions(+), 55 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v8 2/5] drm/i915/icl: Add icl pipe degamma and gamma support
>-Original Message-
>From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>Sent: Monday, February 11, 2019 6:54 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx] [v8 2/5] drm/i915/icl: Add icl pipe degamma and gamma
>support
>
>Op 11-02-2019 om 14:01 schreef Shankar, Uma:
>>
>>> -Original Message-
>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>>> Sent: Monday, February 11, 2019 4:51 PM
>>> To: Shankar, Uma ;
>>> intel-gfx@lists.freedesktop.org
>>> Cc: Syrjala, Ville ; Lankhorst, Maarten
>>>
>>> Subject: Re: [Intel-gfx] [v8 2/5] drm/i915/icl: Add icl pipe degamma
>>> and gamma support
>>>
>>> Op 11-02-2019 om 10:26 schreef Uma Shankar:
Add support for icl pipe degamma and gamma.
v2: Removed a POSTING_READ and corrected the Bit Definition as per
Maarten's comments.
v3: Addressed Matt's review comments. Removed rmw patterns as
suggested by Matt.
v4: Fixed Matt's review comments.
v5: Corrected macro alignment as per Jani Nikula's comments.
Addressed Ville and Matt's review comments.
v6: Merged ICL degamma handling with GLK and dropped ICL degamma
function as per Ville and Matt's comments.
v7: updated gamma_mode state with pre csc gammma and post gamma
enabling in intel_color_check to align with atomic.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h| 12 +++-
drivers/gpu/drm/i915/intel_color.c | 32
++--
2 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h index 11bf60d..13a207a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7111,11 +7111,13 @@ enum {
#define _GAMMA_MODE_A 0x4a480
#define _GAMMA_MODE_B 0x4ac80
#define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A,
>>> _GAMMA_MODE_B)
-#define GAMMA_MODE_MODE_MASK (3 << 0)
-#define GAMMA_MODE_MODE_8BIT (0 << 0)
-#define GAMMA_MODE_MODE_10BIT (1 << 0)
-#define GAMMA_MODE_MODE_12BIT (2 << 0)
-#define GAMMA_MODE_MODE_SPLIT (3 << 0)
+#define PRE_CSC_GAMMA_ENABLE (1 << 31)
+#define POST_CSC_GAMMA_ENABLE(1 << 30)
+#define GAMMA_MODE_MODE_MASK (3 << 0)
+#define GAMMA_MODE_MODE_8BIT (0 << 0)
+#define GAMMA_MODE_MODE_10BIT(1 << 0)
+#define GAMMA_MODE_MODE_12BIT(2 << 0)
+#define GAMMA_MODE_MODE_SPLIT(3 << 0)
/* DMC/CSR */
#define CSR_PROGRAM(i)_MMIO(0x8 + (i) * 4)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 4e13286..0fcaae4 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -583,6 +583,28 @@ static void glk_load_luts(const struct
intel_crtc_state
>>> *crtc_state)
}
}
+static void icl_load_luts(const struct intel_crtc_state
+*crtc_state) {
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ glk_load_degamma_lut(crtc_state);
+
+ if (crtc_state_is_legacy_gamma(crtc_state)) {
+ i9xx_load_luts(crtc_state);
+ } else {
+ /* ToDo: Add support for multi segment gamma LUT */
+ bdw_load_gamma_lut(crtc_state, 0);
+
+ /*
+ * Reset the index, otherwise it prevents the legacy
+ * palette to be written properly.
+ */
+ I915_WRITE(PREC_PAL_INDEX(pipe), 0);
+ }
+}
+
>>> Perhaps this write should be moved to bdw_load_gamma_lut() ?
>>>
>>> Seems we might also fix the same missing write in glk_load_luts() then..
>> Thanks Maarten for reviewing this series.
>>
>> Ok Sure, will move this to bdw_load_gamma_lut(). Can I add your RB on this
>> patch
>also with this fix ?
>>
>> Will send out the next version once you confirm.
>Yes. :)
Thanks Maarten, sent the latest.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
We need to flush our srcu protecting resources about to be clobbered
by the reset, inside of our timer failsafe but outside of the
error->wedge_mutex, so that the failsafe can run in case the
synchronize_srcu() takes too long (hits a shrinker deadlock?).
Fixes: 72eb16df010a ("drm/i915: Serialise resets with wedging")
References: https://bugs.freedesktop.org/show_bug.cgi?id=109605
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 9494b015185a..c2b7570730c2 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -941,9 +941,6 @@ static int do_reset(struct drm_i915_private *i915, unsigned
int stalled_mask)
{
int err, i;
- /* Flush everyone currently using a resource about to be clobbered */
- synchronize_srcu(&i915->gpu_error.reset_backoff_srcu);
-
err = intel_gpu_reset(i915, ALL_ENGINES);
for (i = 0; err && i < RESET_MAX_RETRIES; i++) {
msleep(10 * (i + 1));
@@ -1140,6 +1137,9 @@ static void i915_reset_device(struct drm_i915_private
*i915,
i915_wedge_on_timeout(&w, i915, 5 * HZ) {
intel_prepare_reset(i915);
+ /* Flush everyone using a resource about to be clobbered */
+ synchronize_srcu(&error->reset_backoff_srcu);
+
mutex_lock(&error->wedge_mutex);
i915_reset(i915, engine_mask, reason);
mutex_unlock(&error->wedge_mutex);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
We need to flush our srcu protecting resources about to be clobbered
by the reset, inside of our timer failsafe but outside of the
error->wedge_mutex, so that the failsafe can run in case the
synchronize_srcu() takes too long (hits a shrinker deadlock?).
Fixes: 72eb16df010a ("drm/i915: Serialise resets with wedging")
References: https://bugs.freedesktop.org/show_bug.cgi?id=109605
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 9494b015185a..c2b7570730c2 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -941,9 +941,6 @@ static int do_reset(struct drm_i915_private *i915, unsigned
int stalled_mask)
{
int err, i;
- /* Flush everyone currently using a resource about to be clobbered */
- synchronize_srcu(&i915->gpu_error.reset_backoff_srcu);
-
err = intel_gpu_reset(i915, ALL_ENGINES);
for (i = 0; err && i < RESET_MAX_RETRIES; i++) {
msleep(10 * (i + 1));
@@ -1140,6 +1137,9 @@ static void i915_reset_device(struct drm_i915_private
*i915,
i915_wedge_on_timeout(&w, i915, 5 * HZ) {
intel_prepare_reset(i915);
+ /* Flush everyone using a resource about to be clobbered */
+ synchronize_srcu(&error->reset_backoff_srcu);
+
mutex_lock(&error->wedge_mutex);
i915_reset(i915, engine_mask, reason);
mutex_unlock(&error->wedge_mutex);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Use synchronize_srcu_expedited() for resets
We impose upon ourselves a strict timeout for resets (to ensure forward progress by use of a failsafe). Prefer to use the expedited synchronisation function in this case to reduce the likelihood of a spurious delay being treated as a deadlock. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_reset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c index c2b7570730c2..c1b53533ada6 100644 --- a/drivers/gpu/drm/i915/i915_reset.c +++ b/drivers/gpu/drm/i915/i915_reset.c @@ -1138,7 +1138,7 @@ static void i915_reset_device(struct drm_i915_private *i915, intel_prepare_reset(i915); /* Flush everyone using a resource about to be clobbered */ - synchronize_srcu(&error->reset_backoff_srcu); + synchronize_srcu_expedited(&error->reset_backoff_srcu); mutex_lock(&error->wedge_mutex); i915_reset(i915, engine_mask, reason); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Include the current timeline seqno for debugging execlists
== Series Details ==
Series: drm/i915: Include the current timeline seqno for debugging execlists
URL : https://patchwork.freedesktop.org/series/56493/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5588 -> Patchwork_12191
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56493/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12191:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_parallel@basic:
- {fi-icl-y}: PASS -> INCOMPLETE
Known issues
Here are the changes found in Patchwork_12191 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-skl-6700hq: PASS -> INCOMPLETE [fdo#108744]
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: PASS -> FAIL [fdo#108800]
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: PASS -> FAIL [fdo#108511]
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u3}:FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Participating hosts (48 -> 42)
--
Additional (1): fi-glk-j4005
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5588 -> Patchwork_12191
CI_DRM_5588: 133ed6b29f62713f2edd95eac6ccc2ae1d6e4d6e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4816: f62577c85c9ef0539d468d6fad105b706a15139c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12191: ff6ebd3562f7c2f8f21a92d217d2bd3bdccb0753 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ff6ebd3562f7 drm/i915: Include the current timeline seqno for debugging
execlists
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12191/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_parse: Switch to a fixed timeout for basic-allocations
basic-allocations was written to demonstrate a flaw in our continual
reallocation of cmdparser shadow bo, largely fixed by keeping a small
cache of bo of different lengths (to speed up the search for the correct
sized bo). We only care enough to exercise the slowdown by submitting
lots of execbufs, and can see the effect of bo caching on the rate, so
replace the fixed number of iterations with a timeout and count how many
batches we could submit instead.
Similarly, we now do not need to wait for all of our queue to complete
as we can tell the kernel to drop the queue instead.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107936
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_parse.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/tests/i915/gem_exec_parse.c b/tests/i915/gem_exec_parse.c
index b653b1bdc..62e8d0a51 100644
--- a/tests/i915/gem_exec_parse.c
+++ b/tests/i915/gem_exec_parse.c
@@ -303,15 +303,15 @@ test_lri(int fd, uint32_t handle, struct test_lri *test)
static void test_allocations(int fd)
{
- uint32_t bbe = MI_BATCH_BUFFER_END;
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 obj[17];
- int i, j;
+ unsigned long count;
intel_require_memory(2, 1ull<<(12 + ARRAY_SIZE(obj)), CHECK_RAM);
memset(obj, 0, sizeof(obj));
- for (i = 0; i < ARRAY_SIZE(obj); i++) {
+ for (int i = 0; i < ARRAY_SIZE(obj); i++) {
uint64_t size = 1ull << (12 + i);
obj[i].handle = gem_create(fd, size);
@@ -322,17 +322,21 @@ static void test_allocations(int fd)
memset(&execbuf, 0, sizeof(execbuf));
execbuf.buffer_count = 1;
- for (j = 0; j < 16384; j++) {
- igt_progress("allocations ", j, 16384);
- i = rand() % ARRAY_SIZE(obj);
+
+ count = 0;
+ igt_until_timeout(20) {
+ int i = rand() % ARRAY_SIZE(obj);
execbuf.buffers_ptr = to_user_pointer(&obj[i]);
execbuf.batch_start_offset = (rand() % (1ull
Re: [Intel-gfx] [PATCH] drm/i915: permit zero valued dmap in for_each_sgt_dma
On Wed, 30 Jan 2019 at 20:03, Chris Wilson wrote:
>
> Quoting Matthew Auld (2019-01-30 19:18:25)
> > Break on NULL iter.sgp, rather than dmap == 0, on the off chance that we
> > have some hypothetical selftest or similar in the future that considers
> > dmap = 0 to be perfectly valid.
>
> 0 == DMA_MAPPING_ERROR
Ah, I have DMA_MAPPING_ERROR (~(dma_addr_t)0), and I guess zero is
also invalid...
>
> It wouldn't be a dma iterator at that point.
>
> for_each_sgt_device_addr, _daddr?
Do you mean just rename it to say for_each_sgt_device_addr, or
introduce a new helper with that name?
So say in ggtt_insert_entries:
if (something)
for_each_sgt_device_addr() {}
else
for_each_sgt_dma() {}
?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for Gen 11 pipe color features (rev9)
== Series Details ==
Series: Add support for Gen 11 pipe color features (rev9)
URL : https://patchwork.freedesktop.org/series/51408/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5588 -> Patchwork_12192
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/51408/revisions/9/mbox/
Known issues
Here are the changes found in Patchwork_12192 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: PASS -> FAIL [fdo#108800]
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109567]: https://bugs.freedesktop.org/show_bug.cgi?id=109567
Participating hosts (48 -> 42)
--
Additional (1): fi-glk-j4005
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5588 -> Patchwork_12192
CI_DRM_5588: 133ed6b29f62713f2edd95eac6ccc2ae1d6e4d6e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4816: f62577c85c9ef0539d468d6fad105b706a15139c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12192: a781ee195597d269666195f2709e7bb404446d55 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a781ee195597 drm/i915/icl: Add degamma and gamma lut size to gen11 caps
36f26128dafc drm/i915/icl: Enable pipe output csc
843b26b1c649 drm/i915/icl: Enable ICL Pipe CSC block
1b7082b9015e drm/i915/icl: Add icl pipe degamma and gamma support
4656551a2aca drm/i915/glk: Fix degamma lut programming
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12192/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: permit zero valued dmap in for_each_sgt_dma
Quoting Matthew Auld (2019-02-11 14:39:38)
> On Wed, 30 Jan 2019 at 20:03, Chris Wilson wrote:
> >
> > Quoting Matthew Auld (2019-01-30 19:18:25)
> > > Break on NULL iter.sgp, rather than dmap == 0, on the off chance that we
> > > have some hypothetical selftest or similar in the future that considers
> > > dmap = 0 to be perfectly valid.
> >
> > 0 == DMA_MAPPING_ERROR
>
> Ah, I have DMA_MAPPING_ERROR (~(dma_addr_t)0), and I guess zero is
> also invalid...
>
> >
> > It wouldn't be a dma iterator at that point.
> >
> > for_each_sgt_device_addr, _daddr?
>
> Do you mean just rename it to say for_each_sgt_device_addr, or
> introduce a new helper with that name?
>
> So say in ggtt_insert_entries:
>
> if (something)
> for_each_sgt_device_addr() {}
> else
> for_each_sgt_dma() {}
If our vfuncs naturally split down into different semantics then keeping
both around can prove useful. If not, let's just call it device_addr and
move on.
I hope it's the former, as we may need to review some contention over
dma-mapping apis and so knowing what semantics apply will be useful.
(Perhaps an alternative would be to start ring-fencing x86-only code so
that we have some excuse to our abuses.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Pull sync_scru for device reset outside of wedge_mutex
== Series Details ==
Series: drm/i915: Pull sync_scru for device reset outside of wedge_mutex
URL : https://patchwork.freedesktop.org/series/56495/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5588 -> Patchwork_12193
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56495/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12193 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-skl-gvtdvm: PASS -> INCOMPLETE [fdo#105600] / [fdo#108744]
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: PASS -> DMESG-FAIL [fdo#103182]
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u3}:FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#105600]: https://bugs.freedesktop.org/show_bug.cgi?id=105600
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#109226]: https://bugs.freedesktop.org/show_bug.cgi?id=109226
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Participating hosts (48 -> 41)
--
Additional (1): fi-glk-j4005
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-blb-e6850 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5588 -> Patchwork_12193
CI_DRM_5588: 133ed6b29f62713f2edd95eac6ccc2ae1d6e4d6e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4816: f62577c85c9ef0539d468d6fad105b706a15139c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12193: ab4aa6cb2bbc133d070fd850e292ab4670011508 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ab4aa6cb2bbc drm/i915: Pull sync_scru for device reset outside of wedge_mutex
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12193/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reacquire priolist cache after dropping the engine lock
Quoting Chris Wilson (2019-02-11 15:45:30)
> If we drop the engine lock, we may run execlists_dequeue which may free
> the priolist. Therefore if we ever drop the execution lock on the
> engine, we have to discard our cache and refetch the priolist to ensure
> we do not use a stale pointer.
>
> [ 506.418935] [IGT] gem_exec_whisper: starting subtest contexts-priority
> [ 593.240825] general protection fault: [#1] SMP
> [ 593.240863] CPU: 1 PID: 494 Comm: gem_exec_whispe Tainted: G U
>5.0.0-rc6+ #100
> [ 593.240879] Hardware name: /NUC6CAYB, BIOS
> AYAPLCEL.86A.0029.2016.1124.1625 11/24/2016
> [ 593.240965] RIP: 0010:__i915_schedule+0x1fe/0x320 [i915]
> [ 593.240981] Code: 48 8b 0c 24 48 89 c3 49 8b 45 28 49 8b 75 20 4c 89 3c 24
> 48 89 46 08 48 89 30 48 8b 43 08 48 89 4b 08 49 89 5d 20 49 89 45 28 <48> 89
> 08 45 39 a7 b8 03 00 00 7d 44 45 89 a7 b8 03 00 00 49 8b 85
> [ 593.240999] RSP: 0018:c9057a60 EFLAGS: 00010046
> [ 593.241013] RAX: 6b6b6b6b6b6b6b6b RBX: 8882582d7870 RCX:
> 88826baba6f0
> [ 593.241026] RDX: RSI: 8882582d6e70 RDI:
> 888273482194
> [ 593.241049] RBP: c9057a68 R08: 8882582d7680 R09:
> 8882582d7840
> [ 593.241068] R10: R11: ea00095ebe08 R12:
> 0728
> [ 593.241105] R13: 88826baba6d0 R14: c9057a40 R15:
> 888273482158
> [ 593.241120] FS: 7f4613fb3900() GS:888277a8()
> knlGS:
> [ 593.241133] CS: 0010 DS: ES: CR0: 80050033
> [ 593.241146] CR2: 7f57d3c66a84 CR3: 00026e2b6000 CR4:
> 001406e0
> [ 593.241158] Call Trace:
> [ 593.241233] i915_schedule+0x1f/0x30 [i915]
> [ 593.241326] i915_request_add+0x1a9/0x290 [i915]
> [ 593.241393] i915_gem_do_execbuffer+0x45f/0x1150 [i915]
> [ 593.241411] ? init_object+0x49/0x80
> [ 593.241425] ? ___slab_alloc.constprop.91+0x4b8/0x4e0
> [ 593.241491] ? i915_gem_execbuffer2_ioctl+0x99/0x380 [i915]
> [ 593.241563] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
> [ 593.241629] i915_gem_execbuffer2_ioctl+0x1bb/0x380 [i915]
> [ 593.241705] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
> [ 593.241724] drm_ioctl_kernel+0x81/0xd0
> [ 593.241738] drm_ioctl+0x1a7/0x310
> [ 593.241803] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
> [ 593.241819] ? __update_load_avg_se+0x1c9/0x240
> [ 593.241834] ? pick_next_entity+0x7e/0x120
> [ 593.241851] do_vfs_ioctl+0x88/0x5d0
> [ 593.241880] ksys_ioctl+0x35/0x70
> [ 593.241894] __x64_sys_ioctl+0x11/0x20
> [ 593.241907] do_syscall_64+0x44/0xf0
> [ 593.241924] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 593.241940] RIP: 0033:0x7f4615ffe757
> [ 593.241952] Code: 00 00 90 48 8b 05 39 a7 0c 00 64 c7 00 26 00 00 00 48 c7
> c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 8b 0d 09 a7 0c 00 f7 d8 64 89 01 48
> [ 593.241970] RSP: 002b:7ffc1030ddf8 EFLAGS: 0246 ORIG_RAX:
> 0010
> [ 593.241984] RAX: ffda RBX: 7ffc10324420 RCX:
> 7f4615ffe757
> [ 593.241997] RDX: 7ffc1030e220 RSI: 40406469 RDI:
> 0003
> [ 593.242010] RBP: 7ffc1030e220 R08: 7f46160c9208 R09:
> 7f46160c9240
> [ 593.242022] R10: R11: 0246 R12:
> 40406469
> [ 593.242038] R13: 0003 R14: R15:
>
> [ 593.242058] Modules linked in: i915 intel_gtt drm_kms_helper prime_numbers
>
> Fixes: a02eb975be78 ("drm/i915/execlists: Cache the priolist when
> rescheduling")
> Testcase: igt/gem_exec_whisper/contexts-priority # rare!
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> Cc: Michał Winiarski
> ---
> drivers/gpu/drm/i915/i915_scheduler.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index d01683167c77..177505b9c509 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -340,6 +340,8 @@ static void __i915_schedule(struct i915_request *rq,
>
> engine = sched_lock_engine(node, engine);
> lockdep_assert_held(&engine->timeline.lock);
> + if (last != engine) /* if we drop the lock, refetch priolist
> */
> + last = NULL;
Alternatively (or perhaps future tweaking) would be to pass in a
cache_struct that we memset inside sched_lock_engine(0.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Reacquire priolist cache after dropping the engine lock
If we drop the engine lock, we may run execlists_dequeue which may free
the priolist. Therefore if we ever drop the execution lock on the
engine, we have to discard our cache and refetch the priolist to ensure
we do not use a stale pointer.
[ 506.418935] [IGT] gem_exec_whisper: starting subtest contexts-priority
[ 593.240825] general protection fault: [#1] SMP
[ 593.240863] CPU: 1 PID: 494 Comm: gem_exec_whispe Tainted: G U
5.0.0-rc6+ #100
[ 593.240879] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0029.2016.1124.1625
11/24/2016
[ 593.240965] RIP: 0010:__i915_schedule+0x1fe/0x320 [i915]
[ 593.240981] Code: 48 8b 0c 24 48 89 c3 49 8b 45 28 49 8b 75 20 4c 89 3c 24
48 89 46 08 48 89 30 48 8b 43 08 48 89 4b 08 49 89 5d 20 49 89 45 28 <48> 89 08
45 39 a7 b8 03 00 00 7d 44 45 89 a7 b8 03 00 00 49 8b 85
[ 593.240999] RSP: 0018:c9057a60 EFLAGS: 00010046
[ 593.241013] RAX: 6b6b6b6b6b6b6b6b RBX: 8882582d7870 RCX: 88826baba6f0
[ 593.241026] RDX: RSI: 8882582d6e70 RDI: 888273482194
[ 593.241049] RBP: c9057a68 R08: 8882582d7680 R09: 8882582d7840
[ 593.241068] R10: R11: ea00095ebe08 R12: 0728
[ 593.241105] R13: 88826baba6d0 R14: c9057a40 R15: 888273482158
[ 593.241120] FS: 7f4613fb3900() GS:888277a8()
knlGS:
[ 593.241133] CS: 0010 DS: ES: CR0: 80050033
[ 593.241146] CR2: 7f57d3c66a84 CR3: 00026e2b6000 CR4: 001406e0
[ 593.241158] Call Trace:
[ 593.241233] i915_schedule+0x1f/0x30 [i915]
[ 593.241326] i915_request_add+0x1a9/0x290 [i915]
[ 593.241393] i915_gem_do_execbuffer+0x45f/0x1150 [i915]
[ 593.241411] ? init_object+0x49/0x80
[ 593.241425] ? ___slab_alloc.constprop.91+0x4b8/0x4e0
[ 593.241491] ? i915_gem_execbuffer2_ioctl+0x99/0x380 [i915]
[ 593.241563] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
[ 593.241629] i915_gem_execbuffer2_ioctl+0x1bb/0x380 [i915]
[ 593.241705] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
[ 593.241724] drm_ioctl_kernel+0x81/0xd0
[ 593.241738] drm_ioctl+0x1a7/0x310
[ 593.241803] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
[ 593.241819] ? __update_load_avg_se+0x1c9/0x240
[ 593.241834] ? pick_next_entity+0x7e/0x120
[ 593.241851] do_vfs_ioctl+0x88/0x5d0
[ 593.241880] ksys_ioctl+0x35/0x70
[ 593.241894] __x64_sys_ioctl+0x11/0x20
[ 593.241907] do_syscall_64+0x44/0xf0
[ 593.241924] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 593.241940] RIP: 0033:0x7f4615ffe757
[ 593.241952] Code: 00 00 90 48 8b 05 39 a7 0c 00 64 c7 00 26 00 00 00 48 c7
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 09 a7 0c 00 f7 d8 64 89 01 48
[ 593.241970] RSP: 002b:7ffc1030ddf8 EFLAGS: 0246 ORIG_RAX:
0010
[ 593.241984] RAX: ffda RBX: 7ffc10324420 RCX: 7f4615ffe757
[ 593.241997] RDX: 7ffc1030e220 RSI: 40406469 RDI: 0003
[ 593.242010] RBP: 7ffc1030e220 R08: 7f46160c9208 R09: 7f46160c9240
[ 593.242022] R10: R11: 0246 R12: 40406469
[ 593.242038] R13: 0003 R14: R15:
[ 593.242058] Modules linked in: i915 intel_gtt drm_kms_helper prime_numbers
v2: Track the local engine cache and explicitly clear it when switching
engine locks.
Fixes: a02eb975be78 ("drm/i915/execlists: Cache the priolist when rescheduling")
Testcase: igt/gem_exec_whisper/contexts-priority # rare!
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_scheduler.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index d01683167c77..8bc042551692 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -223,8 +223,14 @@ i915_sched_lookup_priolist(struct intel_engine_cs *engine,
int prio)
return &p->requests[idx];
}
+struct sched_cache {
+ struct list_head *priolist;
+};
+
static struct intel_engine_cs *
-sched_lock_engine(struct i915_sched_node *node, struct intel_engine_cs *locked)
+sched_lock_engine(const struct i915_sched_node *node,
+ struct intel_engine_cs *locked,
+ struct sched_cache *cache)
{
struct intel_engine_cs *engine = node_to_request(node)->engine;
@@ -232,6 +238,7 @@ sched_lock_engine(struct i915_sched_node *node, struct
intel_engine_cs *locked)
if (engine != locked) {
spin_unlock(&locked->timeline.lock);
+ memset(cache, 0, sizeof(*cache));
spin_lock(&engine->timeline.lock);
}
@@ -253,11 +260,11 @@ static bool inflight(const struct i915_request *rq,
static void __i915_schedule(struct i915_request *rq,
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
== Series Details ==
Series: series starting with [1/2] drm/i915: Pull sync_scru for device reset
outside of wedge_mutex
URL : https://patchwork.freedesktop.org/series/56496/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5588 -> Patchwork_12194
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56496/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12194 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#109485]
* igt@kms_flip@basic-flip-vs-modeset:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u3}:FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#109567]: https://bugs.freedesktop.org/show_bug.cgi?id=109567
Participating hosts (48 -> 42)
--
Additional (1): fi-glk-j4005
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5588 -> Patchwork_12194
CI_DRM_5588: 133ed6b29f62713f2edd95eac6ccc2ae1d6e4d6e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4816: f62577c85c9ef0539d468d6fad105b706a15139c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12194: 956ea687c738a4d9a9facc967f137a305c41a00f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
956ea687c738 drm/i915: Use synchronize_srcu_expedited() for resets
f2d7e66b651f drm/i915: Pull sync_scru for device reset outside of wedge_mutex
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12194/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Reacquire priolist cache after dropping the engine lock
If we drop the engine lock, we may run execlists_dequeue which may free
the priolist. Therefore if we ever drop the execution lock on the
engine, we have to discard our cache and refetch the priolist to ensure
we do not use a stale pointer.
[ 506.418935] [IGT] gem_exec_whisper: starting subtest contexts-priority
[ 593.240825] general protection fault: [#1] SMP
[ 593.240863] CPU: 1 PID: 494 Comm: gem_exec_whispe Tainted: G U
5.0.0-rc6+ #100
[ 593.240879] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0029.2016.1124.1625
11/24/2016
[ 593.240965] RIP: 0010:__i915_schedule+0x1fe/0x320 [i915]
[ 593.240981] Code: 48 8b 0c 24 48 89 c3 49 8b 45 28 49 8b 75 20 4c 89 3c 24
48 89 46 08 48 89 30 48 8b 43 08 48 89 4b 08 49 89 5d 20 49 89 45 28 <48> 89 08
45 39 a7 b8 03 00 00 7d 44 45 89 a7 b8 03 00 00 49 8b 85
[ 593.240999] RSP: 0018:c9057a60 EFLAGS: 00010046
[ 593.241013] RAX: 6b6b6b6b6b6b6b6b RBX: 8882582d7870 RCX: 88826baba6f0
[ 593.241026] RDX: RSI: 8882582d6e70 RDI: 888273482194
[ 593.241049] RBP: c9057a68 R08: 8882582d7680 R09: 8882582d7840
[ 593.241068] R10: R11: ea00095ebe08 R12: 0728
[ 593.241105] R13: 88826baba6d0 R14: c9057a40 R15: 888273482158
[ 593.241120] FS: 7f4613fb3900() GS:888277a8()
knlGS:
[ 593.241133] CS: 0010 DS: ES: CR0: 80050033
[ 593.241146] CR2: 7f57d3c66a84 CR3: 00026e2b6000 CR4: 001406e0
[ 593.241158] Call Trace:
[ 593.241233] i915_schedule+0x1f/0x30 [i915]
[ 593.241326] i915_request_add+0x1a9/0x290 [i915]
[ 593.241393] i915_gem_do_execbuffer+0x45f/0x1150 [i915]
[ 593.241411] ? init_object+0x49/0x80
[ 593.241425] ? ___slab_alloc.constprop.91+0x4b8/0x4e0
[ 593.241491] ? i915_gem_execbuffer2_ioctl+0x99/0x380 [i915]
[ 593.241563] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
[ 593.241629] i915_gem_execbuffer2_ioctl+0x1bb/0x380 [i915]
[ 593.241705] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
[ 593.241724] drm_ioctl_kernel+0x81/0xd0
[ 593.241738] drm_ioctl+0x1a7/0x310
[ 593.241803] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
[ 593.241819] ? __update_load_avg_se+0x1c9/0x240
[ 593.241834] ? pick_next_entity+0x7e/0x120
[ 593.241851] do_vfs_ioctl+0x88/0x5d0
[ 593.241880] ksys_ioctl+0x35/0x70
[ 593.241894] __x64_sys_ioctl+0x11/0x20
[ 593.241907] do_syscall_64+0x44/0xf0
[ 593.241924] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 593.241940] RIP: 0033:0x7f4615ffe757
[ 593.241952] Code: 00 00 90 48 8b 05 39 a7 0c 00 64 c7 00 26 00 00 00 48 c7
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 09 a7 0c 00 f7 d8 64 89 01 48
[ 593.241970] RSP: 002b:7ffc1030ddf8 EFLAGS: 0246 ORIG_RAX:
0010
[ 593.241984] RAX: ffda RBX: 7ffc10324420 RCX: 7f4615ffe757
[ 593.241997] RDX: 7ffc1030e220 RSI: 40406469 RDI: 0003
[ 593.242010] RBP: 7ffc1030e220 R08: 7f46160c9208 R09: 7f46160c9240
[ 593.242022] R10: R11: 0246 R12: 40406469
[ 593.242038] R13: 0003 R14: R15:
[ 593.242058] Modules linked in: i915 intel_gtt drm_kms_helper prime_numbers
Fixes: a02eb975be78 ("drm/i915/execlists: Cache the priolist when rescheduling")
Testcase: igt/gem_exec_whisper/contexts-priority # rare!
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_scheduler.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index d01683167c77..177505b9c509 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -340,6 +340,8 @@ static void __i915_schedule(struct i915_request *rq,
engine = sched_lock_engine(node, engine);
lockdep_assert_held(&engine->timeline.lock);
+ if (last != engine) /* if we drop the lock, refetch priolist */
+ last = NULL;
/* Recheck after acquiring the engine->timeline.lock */
if (prio <= node->attr.priority || node_signaled(node))
--
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: Pull sync_scru for device reset outside of wedge_mutex
Chris Wilson writes:
> We need to flush our srcu protecting resources about to be clobbered
> by the reset, inside of our timer failsafe but outside of the
> error->wedge_mutex, so that the failsafe can run in case the
> synchronize_srcu() takes too long (hits a shrinker deadlock?).
>
> Fixes: 72eb16df010a ("drm/i915: Serialise resets with wedging")
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109605
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reset.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reset.c
> b/drivers/gpu/drm/i915/i915_reset.c
> index 9494b015185a..c2b7570730c2 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -941,9 +941,6 @@ static int do_reset(struct drm_i915_private *i915,
> unsigned int stalled_mask)
> {
> int err, i;
>
> - /* Flush everyone currently using a resource about to be clobbered */
> - synchronize_srcu(&i915->gpu_error.reset_backoff_srcu);
> -
> err = intel_gpu_reset(i915, ALL_ENGINES);
> for (i = 0; err && i < RESET_MAX_RETRIES; i++) {
> msleep(10 * (i + 1));
> @@ -1140,6 +1137,9 @@ static void i915_reset_device(struct drm_i915_private
> *i915,
> i915_wedge_on_timeout(&w, i915, 5 * HZ) {
> intel_prepare_reset(i915);
>
> + /* Flush everyone using a resource about to be clobbered */
> + synchronize_srcu(&error->reset_backoff_srcu);
> +
Do we easily see which one it will be? This one or
the block below to timeout on wedge?
Reviewed-by: Mika Kuoppala
> mutex_lock(&error->wedge_mutex);
> i915_reset(i915, engine_mask, reason);
> mutex_unlock(&error->wedge_mutex);
> --
> 2.20.1
>
> ___
> 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 18/46] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno
On 11/02/2019 12:44, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-02-11 12:40:07) On 06/02/2019 13:03, Chris Wilson wrote: 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). We couldn't keep the global seqno just for hangcheck puposes? I mean as long as it is unique, which would be guaranteed by obtaining an increment on every submission to hw and storing it in atomic_t i915->hangcheck_global_seqno / rq->hangcheck_global_seqno, hangcheck does not care about the order of execution, no? s/global_seqno/hangcheck_seqno/ ? Yes sure, I was just trying to express the idea that a "globally" unique number is all that I thought we need. Like: rq->hangcheck_seqno = atomic_inc_return(&i915->hangcheck_seqno); Did I get that right then? That we don't really need the pseudo random number solution? We could even avoid calling it a seqno if desired. rq->unique, wait.. we possibly had this name for something in the past.. (a) the goal is to kill off global_seqno entirely so we are all sure there is no such seqno or ordering anymore (b) this is a temporary patch and we kill off hangcheck_seqno, just as soon as I can submit requests without struct_mutex The heartbeat request solution? Is that better than the hangcheck seqno? Regards, Tvrtko ___ 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: Use synchronize_srcu_expedited() for resets
Chris Wilson writes: > We impose upon ourselves a strict timeout for resets (to ensure forward > progress by use of a failsafe). Prefer to use the expedited > synchronisation function in this case to reduce the likelihood of a > spurious delay being treated as a deadlock. 5 seconds of spurious delay? Well, better to rule this one out, Reviewed-by: Mika Kuoppala > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_reset.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_reset.c > b/drivers/gpu/drm/i915/i915_reset.c > index c2b7570730c2..c1b53533ada6 100644 > --- a/drivers/gpu/drm/i915/i915_reset.c > +++ b/drivers/gpu/drm/i915/i915_reset.c > @@ -1138,7 +1138,7 @@ static void i915_reset_device(struct drm_i915_private > *i915, > intel_prepare_reset(i915); > > /* Flush everyone using a resource about to be clobbered */ > - synchronize_srcu(&error->reset_backoff_srcu); > + synchronize_srcu_expedited(&error->reset_backoff_srcu); > > mutex_lock(&error->wedge_mutex); > i915_reset(i915, engine_mask, reason); > -- > 2.20.1 > > ___ > 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
[Intel-gfx] [PULL] topic/component-typed
Hi all, Here's the typed component topic branch. drm-intel maintainers: Please pull, I need this for the mei hdcp work from Ram. drm-misc maintainers: Please pull, there's a drm doc patch follow-up that I want to stuff into drm-misc-next. Greg: The drm side missed our feature cutoff, so will only land in 5.2. Probably good if you pull this into drivers-core so it lands a bit quicker. You&Arnd will also get a topic pull later on with the MEI bits for char-misc tree, which needs to be based on top of this tree here. Takashi: Since the drm side only lands in 5.2 might be good if you pull this in too to avoid conflicts. Cheers, Daniel topic/component-typed-2019-02-11: typed componented support + i915/snd-hda changes This is needed by the new MEI-HDCP support in i915, so will need to go in through drm and drivers-misc trees at least. Cheers, Daniel The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5: Linux 5.0-rc5 (2019-02-03 13:48:04 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/topic/component-typed-2019-02-11 for you to fetch changes up to 8857c7d065e900a0b3829c97634c99501b606541: i915/snd_hdac: I915 subcomponent for the snd_hdac (2019-02-08 16:58:59 +0100) typed componented support + i915/snd-hda changes This is needed by the new MEI-HDCP support in i915, so will need to go in through drm and drivers-misc trees at least. Daniel Vetter (3): component: Add documentation components: multiple components for a device i915/snd_hdac: I915 subcomponent for the snd_hdac Documentation/driver-api/component.rst | 17 +++ Documentation/driver-api/device_link.rst | 3 + Documentation/driver-api/index.rst | 1 + drivers/base/component.c | 206 +-- drivers/gpu/drm/i915/intel_audio.c | 4 +- include/drm/i915_component.h | 4 + include/linux/component.h| 76 include/sound/hda_component.h| 5 +- sound/hda/hdac_component.c | 4 +- sound/hda/hdac_i915.c| 6 +- 10 files changed, 308 insertions(+), 18 deletions(-) create mode 100644 Documentation/driver-api/component.rst -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [IGT 1/2] tools/intel_gpu_top: Add support for stdout logging
On 11/02/2019 12:21, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-02-11 11:45:22)
+static enum {
+ INTERACTIVE,
+ STDOUT,
+ JSON
+} output_mode;
+
+struct cnt_item {
+ struct pmu_counter *pmu;
/* "%*.*f", fmt_d, fmt_dd, X */
I tried fmt_d == fmt_width and fmt_dd == fmt_decimals
It's called field width and precision in the manpage, so
maybe fmt_width and fmt_precision.
Makes sense indeed.
Having figured that out, the use makes sense.
+ unsigned int fmt_d;
+ unsigned int fmt_dd;
+ double d;
+ double t;
+ double s;
+ const char *name;
+ const char *unit;
+
+ /* Internal fields. */
+ char buf[16];
+};
+
+struct cnt_group {
+ const char *name;
+ const char *display_name;
+ struct cnt_item *items;
+};
+
+static unsigned int json_indent_level;
+
+static const char *json_indent[] = {
+ "",
+ "\t",
+ "\t\t",
+ "\t\t\t",
+ "\t\t\t\t",
+ "\t\t\t\t\t",
+};
+
+#define ARRAY_SIZE(arr) (sizeof(arr)/sizeof(arr[0]))
+
+static unsigned int json_prev_struct_members;
+static unsigned int json_struct_members;
+
+static void
+json_open_struct(const char *name)
+{
+ assert(json_indent_level < ARRAY_SIZE(json_indent));
+
+ json_prev_struct_members = json_struct_members;
+ json_struct_members = 0;
+
+ if (name)
+ printf("%s%s\"%s\": {\n",
+ json_prev_struct_members ? ",\n" : "",
+ json_indent[json_indent_level],
"%*s", json_indent_level, "\t\t\t\t\t"
didn't stick?
No, I lost patience trying to make it do what I want. AFAIR it insisted
on right justifying and the negative count also did not work.
I could follow the flow, dug into a few of the details, and only have
some nits. One thing, could we feed in a perf record? I was thinking for
testing the various output modes with known data, but may also be useful
for replay.
Could do, should be too hard. Writing tests for tool output though
sounds like something I won't have time to do in the near future.
Reviewed-by: Chris Wilson
Thanks, I'll keep it when I fix the asprintf return value inspection
which I butchered in a hasty copy and paste work.
Regards,
Tvrtko
___
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: Pull sync_scru for device reset outside of wedge_mutex
Quoting Mika Kuoppala (2019-02-11 15:09:48)
> Chris Wilson writes:
>
> > We need to flush our srcu protecting resources about to be clobbered
> > by the reset, inside of our timer failsafe but outside of the
> > error->wedge_mutex, so that the failsafe can run in case the
> > synchronize_srcu() takes too long (hits a shrinker deadlock?).
> >
> > Fixes: 72eb16df010a ("drm/i915: Serialise resets with wedging")
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=109605
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_reset.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reset.c
> > b/drivers/gpu/drm/i915/i915_reset.c
> > index 9494b015185a..c2b7570730c2 100644
> > --- a/drivers/gpu/drm/i915/i915_reset.c
> > +++ b/drivers/gpu/drm/i915/i915_reset.c
> > @@ -941,9 +941,6 @@ static int do_reset(struct drm_i915_private *i915,
> > unsigned int stalled_mask)
> > {
> > int err, i;
> >
> > - /* Flush everyone currently using a resource about to be clobbered */
> > - synchronize_srcu(&i915->gpu_error.reset_backoff_srcu);
> > -
> > err = intel_gpu_reset(i915, ALL_ENGINES);
> > for (i = 0; err && i < RESET_MAX_RETRIES; i++) {
> > msleep(10 * (i + 1));
> > @@ -1140,6 +1137,9 @@ static void i915_reset_device(struct drm_i915_private
> > *i915,
> > i915_wedge_on_timeout(&w, i915, 5 * HZ) {
> > intel_prepare_reset(i915);
> >
> > + /* Flush everyone using a resource about to be clobbered */
> > + synchronize_srcu(&error->reset_backoff_srcu);
> > +
>
> Do we easily see which one it will be? This one or
> the block below to timeout on wedge?
It would be easy to reconstruct if we have all the stack traces so we
can switch which process is stuck where, but we do not. Failing that my
hunch is that it's sync_srcu taking too long, and by design we know it
can deadlock around an unfortunate shrinker interaction :( But I'm not
entirely convinced we're hitting that.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/46] drm/i915: Make request allocation caches global
On 11/02/2019 12:40, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-02-11 11:43:41)
On 06/02/2019 13:03, Chris Wilson wrote:
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 | 105 ++
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 | 48
.../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, 306 insertions(+), 152 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 215b6ff8aa73..9026787ebdf8 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -280,7 +280,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 37230ae7fbe6..a365b1a2ea9a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1459,9 +1459,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 1eb3a5f8654c..d18c4ccff370 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)
@@ -2916,12 +2919,11 @@ static void shrink
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/opregion: rvda is relative from opregion base in opregion 2.1+
On Fri, 08 Feb 2019, Ville Syrjälä wrote:
> On Fri, Feb 08, 2019 at 09:00:59PM +0200, Jani Nikula wrote:
>> On Fri, 08 Feb 2019, Ville Syrjälä wrote:
>> > On Fri, Feb 08, 2019 at 08:42:53PM +0200, Jani Nikula wrote:
>> >> Starting from opregion version 2.1 (roughly corresponding to ICL+) the
>> >> RVDA field is relative from the beginning of opregion, not absolute
>> >> address.
>> >>
>> >> Fix the error path while at it.
>> >>
>> >> v2: Make relative vs. absolute conditional on the opregion version,
>> >> bumped for the purpose. Turned out there are machines relying on
>> >> absolute RVDA in the wild.
>> >>
>> >> v3: Fix the version checks
>> >>
>> >> Fixes: 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6
>> >> KB")
>> >> Cc: Ville Syrjälä
>> >> Cc: Imre Deak
>> >> Signed-off-by: Jani Nikula
>> >> ---
>> >> drivers/gpu/drm/i915/intel_opregion.c | 24 +---
>> >> 1 file changed, 21 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
>> >> b/drivers/gpu/drm/i915/intel_opregion.c
>> >> index f1b841580521..5e00ee9270b5 100644
>> >> --- a/drivers/gpu/drm/i915/intel_opregion.c
>> >> +++ b/drivers/gpu/drm/i915/intel_opregion.c
>> >> @@ -123,7 +123,8 @@ struct opregion_asle {
>> >> u64 fdss;
>> >> u32 fdsp;
>> >> u32 stat;
>> >> - u64 rvda; /* Physical address of raw vbt data */
>> >> + u64 rvda; /* Physical (2.0) or relative from opregion (2.1+)
>> >> + * address of raw VBT data. */
>> >> u32 rvds; /* Size of raw vbt data */
>> >> u8 rsvd[58];
>> >> } __packed;
>> >> @@ -964,9 +965,24 @@ int intel_opregion_setup(struct drm_i915_private
>> >> *dev_priv)
>> >>
>> >> if (opregion->header->over.major >= 2 && opregion->asle &&
>>
>> Push this line to short term memory.
>
> Stack overflow.
>
> Series is
> Reviewed-by: Ville Syrjälä
Thanks, pushed patches 1&2 to dinq.
BR,
Jani.
>
>>
>> >> opregion->asle->rvda && opregion->asle->rvds) {
>> >> - opregion->rvda = memremap(opregion->asle->rvda,
>> >> - opregion->asle->rvds,
>> >> + resource_size_t rvda = opregion->asle->rvda;
>> >> +
>> >> + /*
>> >> + * opregion 2.0: rvda is the physical VBT address.
>> >> + *
>> >> + * opregion 2.1+: rvda is unsigned, relative offset from
>> >> + * opregion base, and should never point within opregion.
>> >> + */
>> >> + if (opregion->header->over.major > 2 ||
>> >> + opregion->header->over.minor >= 1) {
>> >
>> > What happens with version 1.1?
>>
>> Pop. ;)
>>
>> BR,
>> Jani.
>>
>> >
>> >> + WARN_ON(rvda < OPREGION_SIZE);
>> >> +
>> >> + rvda += asls;
>> >> + }
>> >> +
>> >> + opregion->rvda = memremap(rvda, opregion->asle->rvds,
>> >> MEMREMAP_WB);
>> >> +
>> >> vbt = opregion->rvda;
>> >> vbt_size = opregion->asle->rvds;
>> >> if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
>> >> @@ -976,6 +992,8 @@ int intel_opregion_setup(struct drm_i915_private
>> >> *dev_priv)
>> >> goto out;
>> >> } else {
>> >> DRM_DEBUG_KMS("Invalid VBT in ACPI OpRegion (RVDA)\n");
>> >> + memunmap(opregion->rvda);
>> >> + opregion->rvda = NULL;
>> >> }
>> >> }
>> >>
>> >> --
>> >> 2.20.1
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
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 2/2] drm/i915: Use synchronize_srcu_expedited() for resets
Quoting Mika Kuoppala (2019-02-11 15:13:19) > Chris Wilson writes: > > > We impose upon ourselves a strict timeout for resets (to ensure forward > > progress by use of a failsafe). Prefer to use the expedited > > synchronisation function in this case to reduce the likelihood of a > > spurious delay being treated as a deadlock. > > 5 seconds of spurious delay? Past experience with rcu says over 30s is not unheard of; though it does start to complain if the system skips over 120s without an rcu grace period. > Well, better to rule this one out, Ulterior motive is that we still want fast resets :) We shouldn't upset the RT crowd too much as we are only using this sparingly. -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_exec_parse: Switch to a fixed timeout for basic-allocations
On 11/02/2019 14:35, Chris Wilson wrote:
basic-allocations was written to demonstrate a flaw in our continual
reallocation of cmdparser shadow bo, largely fixed by keeping a small
cache of bo of different lengths (to speed up the search for the correct
sized bo). We only care enough to exercise the slowdown by submitting
lots of execbufs, and can see the effect of bo caching on the rate, so
replace the fixed number of iterations with a timeout and count how many
batches we could submit instead.
Similarly, we now do not need to wait for all of our queue to complete
as we can tell the kernel to drop the queue instead.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107936
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_parse.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/tests/i915/gem_exec_parse.c b/tests/i915/gem_exec_parse.c
index b653b1bdc..62e8d0a51 100644
--- a/tests/i915/gem_exec_parse.c
+++ b/tests/i915/gem_exec_parse.c
@@ -303,15 +303,15 @@ test_lri(int fd, uint32_t handle, struct test_lri *test)
static void test_allocations(int fd)
{
- uint32_t bbe = MI_BATCH_BUFFER_END;
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 obj[17];
- int i, j;
+ unsigned long count;
intel_require_memory(2, 1ull<<(12 + ARRAY_SIZE(obj)), CHECK_RAM);
memset(obj, 0, sizeof(obj));
- for (i = 0; i < ARRAY_SIZE(obj); i++) {
+ for (int i = 0; i < ARRAY_SIZE(obj); i++) {
uint64_t size = 1ull << (12 + i);
obj[i].handle = gem_create(fd, size);
@@ -322,17 +322,21 @@ static void test_allocations(int fd)
memset(&execbuf, 0, sizeof(execbuf));
execbuf.buffer_count = 1;
- for (j = 0; j < 16384; j++) {
- igt_progress("allocations ", j, 16384);
- i = rand() % ARRAY_SIZE(obj);
+
+ count = 0;
+ igt_until_timeout(20) {
+ int i = rand() % ARRAY_SIZE(obj);
execbuf.buffers_ptr = to_user_pointer(&obj[i]);
execbuf.batch_start_offset = (rand() % (1ull<
Downside here is that tests start to exercise a lot more driver paths.
Or is that an upside? It's confusing these days.
I'd prefer if we just let it run and don't involve wedge/unwedge. Well
actually... we could modify the submit loop to sync a bit rather than
build a queue for 20 seconds? Would sync after each execbuf be
detrimental to test goals? Alternatively submit maybe ARRAY_SIZE worth
and then sync?
Regards,
Tvrtko
- for (i = 0; i < ARRAY_SIZE(obj); i++) {
+ for (int i = 0; i < ARRAY_SIZE(obj); i++) {
gem_sync(fd, obj[i].handle);
gem_close(fd, obj[i].handle);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Include the current timeline seqno for debugging execlists
On 11/02/2019 13:10, Chris Wilson wrote:
While this is mainly only useful for ELSP[0], it is definitely useful to
know the current timeline seqno wrt to the queued set of requests for
that port, as this carries additional information above and beyond the
near-defunct global_seqno and global HWSP.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 49fa43ff02ba..2547e2e51db8 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1425,10 +1425,11 @@ static void intel_engine_print_registers(const struct
intel_engine_cs *engine,
char hdr[80];
snprintf(hdr, sizeof(hdr),
-"\t\tELSP[%d] count=%d, ring:{start:%08x,
hwsp:%08x}, rq: ",
+"\t\tELSP[%d] count=%d, ring:{start:%08x,
hwsp:%08x, seqno:%08x}, rq: ",
idx, count,
i915_ggtt_offset(rq->ring->vma),
-rq->timeline->hwsp_offset);
+rq->timeline->hwsp_offset,
+hwsp_seqno(rq));
print_request(m, rq, hdr);
} else {
drm_printf(m, "\t\tELSP[%d] idle\n", idx);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Include the current timeline seqno for debugging execlists
== Series Details ==
Series: drm/i915: Include the current timeline seqno for debugging execlists
URL : https://patchwork.freedesktop.org/series/56493/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5588_full -> Patchwork_12191_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12191_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@hang:
- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [fdo#109605 ] /
[k.org#198133]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-hsw: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-c-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-apl: PASS -> FAIL [fdo#103167] +3
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-apl: PASS -> FAIL [fdo#103166] +3
Possible fixes
* igt@gem_eio@unwedge-stress:
- shard-snb: FAIL [fdo#107799] -> PASS
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk: FAIL [fdo#108145] -> PASS +1
* igt@kms_cursor_legacy@all-pipes-torture-move:
- shard-hsw: DMESG-WARN [fdo#107122] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-glk: FAIL [fdo#103167] -> PASS +2
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS +1
- shard-glk: FAIL [fdo#103166] -> PASS +2
* igt@kms_setmode@basic:
- shard-apl: FAIL [fdo#99912] -> PASS
Warnings
* igt@i915_suspend@shrink:
- shard-glk: INCOMPLETE [fdo#103359] / [fdo#106886] /
[k.org#198133] -> DMESG-WARN [fdo#109244]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
[fdo#107122]: https://bugs.freedesktop.org/show_bug.cgi?id=107122
[fdo#107799]: https://bugs.freedesktop.org/show_bug.cgi?id=107799
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#109244]: https://bugs.freedesktop.org/show_bug.cgi?id=109244
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109605 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109605
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5588 -> Patchwork_12191
CI_DRM_5588: 133ed6b29f62713f2edd95eac6ccc2ae1d6e4d6e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4816: f62577c85c9ef0539d468d6fad105b706a15139c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12191: ff6ebd3562f7c2f8f21a92d217d2bd3bdccb0753 @
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_12191/
___
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_exec_parse: Switch to a fixed timeout for basic-allocations
Quoting Tvrtko Ursulin (2019-02-11 17:18:02)
>
> On 11/02/2019 14:35, Chris Wilson wrote:
> > basic-allocations was written to demonstrate a flaw in our continual
> > reallocation of cmdparser shadow bo, largely fixed by keeping a small
> > cache of bo of different lengths (to speed up the search for the correct
> > sized bo). We only care enough to exercise the slowdown by submitting
> > lots of execbufs, and can see the effect of bo caching on the rate, so
> > replace the fixed number of iterations with a timeout and count how many
> > batches we could submit instead.
> >
> > Similarly, we now do not need to wait for all of our queue to complete
> > as we can tell the kernel to drop the queue instead.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=107936
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > tests/i915/gem_exec_parse.c | 18 +++---
> > 1 file changed, 11 insertions(+), 7 deletions(-)
> >
> > diff --git a/tests/i915/gem_exec_parse.c b/tests/i915/gem_exec_parse.c
> > index b653b1bdc..62e8d0a51 100644
> > --- a/tests/i915/gem_exec_parse.c
> > +++ b/tests/i915/gem_exec_parse.c
> > @@ -303,15 +303,15 @@ test_lri(int fd, uint32_t handle, struct test_lri
> > *test)
> >
> > static void test_allocations(int fd)
> > {
> > - uint32_t bbe = MI_BATCH_BUFFER_END;
> > + const uint32_t bbe = MI_BATCH_BUFFER_END;
> > struct drm_i915_gem_execbuffer2 execbuf;
> > struct drm_i915_gem_exec_object2 obj[17];
> > - int i, j;
> > + unsigned long count;
> >
> > intel_require_memory(2, 1ull<<(12 + ARRAY_SIZE(obj)), CHECK_RAM);
> >
> > memset(obj, 0, sizeof(obj));
> > - for (i = 0; i < ARRAY_SIZE(obj); i++) {
> > + for (int i = 0; i < ARRAY_SIZE(obj); i++) {
> > uint64_t size = 1ull << (12 + i);
> >
> > obj[i].handle = gem_create(fd, size);
> > @@ -322,17 +322,21 @@ static void test_allocations(int fd)
> >
> > memset(&execbuf, 0, sizeof(execbuf));
> > execbuf.buffer_count = 1;
> > - for (j = 0; j < 16384; j++) {
> > - igt_progress("allocations ", j, 16384);
> > - i = rand() % ARRAY_SIZE(obj);
> > +
> > + count = 0;
> > + igt_until_timeout(20) {
> > + int i = rand() % ARRAY_SIZE(obj);
> > execbuf.buffers_ptr = to_user_pointer(&obj[i]);
> > execbuf.batch_start_offset = (rand() % (1ull< > execbuf.batch_start_offset += 64 * (rand() % 64);
> > execbuf.batch_len = (1ull<<(12+i)) -
> > execbuf.batch_start_offset;
> > gem_execbuf(fd, &execbuf);
> > + count++;
> > }
> > + igt_info("Submitted %lu execbufs\n", count);
> > + igt_drop_caches_set(fd, DROP_RESET_ACTIVE); /* Cancel the queued work
> > */
>
> Downside here is that tests start to exercise a lot more driver paths.
> Or is that an upside? It's confusing these days.
>
> I'd prefer if we just let it run and don't involve wedge/unwedge. Well
> actually... we could modify the submit loop to sync a bit rather than
> build a queue for 20 seconds? Would sync after each execbuf be
> detrimental to test goals? Alternatively submit maybe ARRAY_SIZE worth
> and then sync?
Yes, syncing affects i915_gem_batch_pool.c. The length of the cache
lists is largely determined by the number of batches in flight.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Reacquire priolist cache after dropping the engine lock
On 11/02/2019 16:09, Chris Wilson wrote:
> If we drop the engine lock, we may run execlists_dequeue which may free
> the priolist. Therefore if we ever drop the execution lock on the
> engine, we have to discard our cache and refetch the priolist to ensure
> we do not use a stale pointer.
On first look one would observe current code is trying to re-acquire the prio
list on changing the engine, so I guess the problem is this check is hidden
under an additional conditional.
So a simpler approach of:
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index d01683167c77..74896e7dbfa7 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -341,16 +341,17 @@ static void __i915_schedule(struct i915_request *rq,
engine = sched_lock_engine(node, engine);
lockdep_assert_held(&engine->timeline.lock);
+ if (last != engine) {
+ pl = i915_sched_lookup_priolist(engine, prio);
+ last = engine;
+ }
+
/* Recheck after acquiring the engine->timeline.lock */
if (prio <= node->attr.priority || node_signaled(node))
continue;
node->attr.priority = prio;
if (!list_empty(&node->link)) {
- if (last != engine) {
- pl = i915_sched_lookup_priolist(engine, prio);
- last = engine;
- }
list_move_tail(&node->link, pl);
} else {
/*
Would not be acceptable?
>
> [ 506.418935] [IGT] gem_exec_whisper: starting subtest contexts-priority
> [ 593.240825] general protection fault: [#1] SMP
> [ 593.240863] CPU: 1 PID: 494 Comm: gem_exec_whispe Tainted: G U
>5.0.0-rc6+ #100
> [ 593.240879] Hardware name: /NUC6CAYB, BIOS
> AYAPLCEL.86A.0029.2016.1124.1625 11/24/2016
> [ 593.240965] RIP: 0010:__i915_schedule+0x1fe/0x320 [i915]
> [ 593.240981] Code: 48 8b 0c 24 48 89 c3 49 8b 45 28 49 8b 75 20 4c 89 3c 24
> 48 89 46 08 48 89 30 48 8b 43 08 48 89 4b 08 49 89 5d 20 49 89 45 28 <48> 89
> 08 45 39 a7 b8 03 00 00 7d 44 45 89 a7 b8 03 00 00 49 8b 85
> [ 593.240999] RSP: 0018:c9057a60 EFLAGS: 00010046
> [ 593.241013] RAX: 6b6b6b6b6b6b6b6b RBX: 8882582d7870 RCX:
> 88826baba6f0
> [ 593.241026] RDX: RSI: 8882582d6e70 RDI:
> 888273482194
> [ 593.241049] RBP: c9057a68 R08: 8882582d7680 R09:
> 8882582d7840
> [ 593.241068] R10: R11: ea00095ebe08 R12:
> 0728
> [ 593.241105] R13: 88826baba6d0 R14: c9057a40 R15:
> 888273482158
> [ 593.241120] FS: 7f4613fb3900() GS:888277a8()
> knlGS:
> [ 593.241133] CS: 0010 DS: ES: CR0: 80050033
> [ 593.241146] CR2: 7f57d3c66a84 CR3: 00026e2b6000 CR4:
> 001406e0
> [ 593.241158] Call Trace:
> [ 593.241233] i915_schedule+0x1f/0x30 [i915]
> [ 593.241326] i915_request_add+0x1a9/0x290 [i915]
> [ 593.241393] i915_gem_do_execbuffer+0x45f/0x1150 [i915]
> [ 593.241411] ? init_object+0x49/0x80
> [ 593.241425] ? ___slab_alloc.constprop.91+0x4b8/0x4e0
> [ 593.241491] ? i915_gem_execbuffer2_ioctl+0x99/0x380 [i915]
> [ 593.241563] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
> [ 593.241629] i915_gem_execbuffer2_ioctl+0x1bb/0x380 [i915]
> [ 593.241705] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
> [ 593.241724] drm_ioctl_kernel+0x81/0xd0
> [ 593.241738] drm_ioctl+0x1a7/0x310
> [ 593.241803] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
> [ 593.241819] ? __update_load_avg_se+0x1c9/0x240
> [ 593.241834] ? pick_next_entity+0x7e/0x120
> [ 593.241851] do_vfs_ioctl+0x88/0x5d0
> [ 593.241880] ksys_ioctl+0x35/0x70
> [ 593.241894] __x64_sys_ioctl+0x11/0x20
> [ 593.241907] do_syscall_64+0x44/0xf0
> [ 593.241924] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 593.241940] RIP: 0033:0x7f4615ffe757
> [ 593.241952] Code: 00 00 90 48 8b 05 39 a7 0c 00 64 c7 00 26 00 00 00 48 c7
> c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 8b 0d 09 a7 0c 00 f7 d8 64 89 01 48
> [ 593.241970] RSP: 002b:7ffc1030ddf8 EFLAGS: 0246 ORIG_RAX:
> 0010
> [ 593.241984] RAX: ffda RBX: 7ffc10324420 RCX:
> 7f4615ffe757
> [ 593.241997] RDX: 7ffc1030e220 RSI: 40406469 RDI:
> 0003
> [ 593.242010] RBP: 7ffc1030e220 R08: 7f46160c9208 R09:
> 7f46160c9240
> [ 593.242022] R10: R11: 0246 R12:
> 40406469
> [ 593.242038] R13: 0003 R14: R15:
>
> [ 593.242058] Modules linked in: i915 intel_gtt drm_kms_helper prime_numbers
>
> v2: Track the local engine cache and exp
[Intel-gfx] [PATCH v3] drm/i915/query: Split out query item checks
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
---
drivers/gpu/drm/i915/i915_query.c | 39 ---
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index cbcb957b7141..782183b78f49 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -10,12 +10,34 @@
#include "i915_query.h"
#include
+static int copy_query_item(void *query_hdr, size_t query_sz,
+ u32 total_length,
+ struct drm_i915_query_item *query_item)
+{
+ if (query_item->length == 0)
+ return total_length;
+
+ if (query_item->length < total_length)
+ return -EINVAL;
+
+ if (copy_from_user(query_hdr, u64_to_user_ptr(query_item->data_ptr),
+ query_sz))
+ return -EFAULT;
+
+ if (!access_ok(u64_to_user_ptr(query_item->data_ptr),
+ total_length))
+ return -EFAULT;
+
+ return 0;
+}
+
static int query_topology_info(struct drm_i915_private *dev_priv,
struct drm_i915_query_item *query_item)
{
const struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)->sseu;
struct drm_i915_query_topology_info topo;
u32 slice_length, subslice_length, eu_length, total_length;
+ int ret;
if (query_item->flags != 0)
return -EINVAL;
@@ -33,23 +55,14 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
total_length = sizeof(topo) + slice_length + subslice_length +
eu_length;
- if (query_item->length == 0)
- return total_length;
-
- if (query_item->length < total_length)
- return -EINVAL;
-
- if (copy_from_user(&topo, u64_to_user_ptr(query_item->data_ptr),
- sizeof(topo)))
- return -EFAULT;
+ ret = copy_query_item(&topo, sizeof(topo), total_length,
+ query_item);
+ if (ret != 0)
+ return ret;
if (topo.flags != 0)
return -EINVAL;
- if (!access_ok(u64_to_user_ptr(query_item->data_ptr),
- total_length))
- return -EFAULT;
-
memset(&topo, 0, sizeof(topo));
topo.max_slices = sseu->max_slices;
topo.max_subslices = sseu->max_subslices;
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Reacquire priolist cache after dropping the engine lock
Quoting Tvrtko Ursulin (2019-02-11 17:33:37)
>
> On 11/02/2019 16:09, Chris Wilson wrote:
> > If we drop the engine lock, we may run execlists_dequeue which may free
> > the priolist. Therefore if we ever drop the execution lock on the
> > engine, we have to discard our cache and refetch the priolist to ensure
> > we do not use a stale pointer.
>
> On first look one would observe current code is trying to re-acquire the prio
> list on changing the engine, so I guess the problem is this check is hidden
> under an additional conditional.
>
> So a simpler approach of:
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index d01683167c77..74896e7dbfa7 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -341,16 +341,17 @@ static void __i915_schedule(struct i915_request *rq,
> engine = sched_lock_engine(node, engine);
> lockdep_assert_held(&engine->timeline.lock);
>
> + if (last != engine) {
> + pl = i915_sched_lookup_priolist(engine, prio);
> + last = engine;
> + }
> +
> /* Recheck after acquiring the engine->timeline.lock */
> if (prio <= node->attr.priority || node_signaled(node))
> continue;
>
> node->attr.priority = prio;
> if (!list_empty(&node->link)) {
> - if (last != engine) {
> - pl = i915_sched_lookup_priolist(engine, prio);
> - last = engine;
> - }
> list_move_tail(&node->link, pl);
> } else {
> /*
> Would not be acceptable?
It marks the priolist as used even though we may not populate it. That
extra conditional biting again, and it defeats the purpose of not having
to look up the priolist as often (for engines where we don't need to
touch the priority queue itself).
> > [ 506.418935] [IGT] gem_exec_whisper: starting subtest contexts-priority
> > [ 593.240825] general protection fault: [#1] SMP
> > [ 593.240863] CPU: 1 PID: 494 Comm: gem_exec_whispe Tainted: G U
> > 5.0.0-rc6+ #100
> > [ 593.240879] Hardware name: /NUC6CAYB, BIOS
> > AYAPLCEL.86A.0029.2016.1124.1625 11/24/2016
> > [ 593.240965] RIP: 0010:__i915_schedule+0x1fe/0x320 [i915]
> > [ 593.240981] Code: 48 8b 0c 24 48 89 c3 49 8b 45 28 49 8b 75 20 4c 89 3c
> > 24 48 89 46 08 48 89 30 48 8b 43 08 48 89 4b 08 49 89 5d 20 49 89 45 28
> > <48> 89 08 45 39 a7 b8 03 00 00 7d 44 45 89 a7 b8 03 00 00 49 8b 85
> > [ 593.240999] RSP: 0018:c9057a60 EFLAGS: 00010046
> > [ 593.241013] RAX: 6b6b6b6b6b6b6b6b RBX: 8882582d7870 RCX:
> > 88826baba6f0
> > [ 593.241026] RDX: RSI: 8882582d6e70 RDI:
> > 888273482194
> > [ 593.241049] RBP: c9057a68 R08: 8882582d7680 R09:
> > 8882582d7840
> > [ 593.241068] R10: R11: ea00095ebe08 R12:
> > 0728
> > [ 593.241105] R13: 88826baba6d0 R14: c9057a40 R15:
> > 888273482158
> > [ 593.241120] FS: 7f4613fb3900() GS:888277a8()
> > knlGS:
> > [ 593.241133] CS: 0010 DS: ES: CR0: 80050033
> > [ 593.241146] CR2: 7f57d3c66a84 CR3: 00026e2b6000 CR4:
> > 001406e0
> > [ 593.241158] Call Trace:
> > [ 593.241233] i915_schedule+0x1f/0x30 [i915]
> > [ 593.241326] i915_request_add+0x1a9/0x290 [i915]
> > [ 593.241393] i915_gem_do_execbuffer+0x45f/0x1150 [i915]
> > [ 593.241411] ? init_object+0x49/0x80
> > [ 593.241425] ? ___slab_alloc.constprop.91+0x4b8/0x4e0
> > [ 593.241491] ? i915_gem_execbuffer2_ioctl+0x99/0x380 [i915]
> > [ 593.241563] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
> > [ 593.241629] i915_gem_execbuffer2_ioctl+0x1bb/0x380 [i915]
> > [ 593.241705] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
> > [ 593.241724] drm_ioctl_kernel+0x81/0xd0
> > [ 593.241738] drm_ioctl+0x1a7/0x310
> > [ 593.241803] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
> > [ 593.241819] ? __update_load_avg_se+0x1c9/0x240
> > [ 593.241834] ? pick_next_entity+0x7e/0x120
> > [ 593.241851] do_vfs_ioctl+0x88/0x5d0
> > [ 593.241880] ksys_ioctl+0x35/0x70
> > [ 593.241894] __x64_sys_ioctl+0x11/0x20
> > [ 593.241907] do_syscall_64+0x44/0xf0
> > [ 593.241924] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [ 593.241940] RIP: 0033:0x7f4615ffe757
> > [ 593.241952] Code: 00 00 90 48 8b 05 39 a7 0c 00 64 c7 00 26 00 00 00 48
> > c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05
> > <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 a7 0c 00 f7 d8 64 89 01 48
> > [ 593.241970] RSP: 002b:7ffc1030ddf8 EFLAGS: 0246 ORIG_RAX:
> > 0010
> > [ 593.241984] RAX: ffda RBX: 7ffc10324420 RCX:
> > 7f
[Intel-gfx] ✓ Fi.CI.IGT: success for Add support for Gen 11 pipe color features (rev9)
== Series Details ==
Series: Add support for Gen 11 pipe color features (rev9)
URL : https://patchwork.freedesktop.org/series/51408/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5588_full -> Patchwork_12192_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_12192_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12192_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12192_full:
### IGT changes ###
Warnings
* igt@kms_color@pipe-c-degamma:
- shard-glk: {SKIP} [fdo#109271] -> FAIL +4
Known issues
Here are the changes found in Patchwork_12192_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-hsw: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-c-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-hsw: PASS -> INCOMPLETE [fdo#103540]
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane@pixel-format-pipe-b-planes-source-clamping:
- shard-apl: PASS -> FAIL [fdo#108948]
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
Possible fixes
* igt@gem_eio@unwedge-stress:
- shard-snb: FAIL [fdo#107799] -> PASS
* igt@i915_suspend@fence-restore-untiled:
- shard-snb: INCOMPLETE [fdo#105411] -> PASS
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_color@pipe-b-ctm-green-to-red:
- shard-glk: {SKIP} [fdo#109271] -> PASS +29
* igt@kms_cursor_legacy@all-pipes-torture-move:
- shard-hsw: DMESG-WARN [fdo#107122] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS +2
Warnings
* igt@i915_suspend@shrink:
- shard-apl: DMESG-WARN [fdo#107886] / [fdo#109244] -> INCOMPLETE
[fdo#103927] / [fdo#106886]
- shard-glk: INCOMPLETE [fdo#103359] / [fdo#106886] /
[k.org#198133] -> DMESG-WARN [fdo#109244]
* igt@kms_color@pipe-a-degamma:
- shard-glk: {SKIP} [fdo#109271] -> FAIL [fdo#108145]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[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#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
[fdo#107122]: https://bugs.freedesktop.org/show_bug.cgi?id=107122
[fdo#107799]: https://bugs.freedesktop.org/show_bug.cgi?id=107799
[fdo#107886]: https://bugs.freedesktop.org/show_bug.cgi?id=107886
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948
[fdo#109244]: https://bugs.freedesktop.org/show_bug.cgi?id=109244
[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
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5588 -> Patchwork_12192
CI_DRM_5588: 133ed6b29f62713f2edd95eac6ccc2ae1d6e4d6e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4816: f62577c85c9ef0539d468d6fad105b706a1513
Re: [Intel-gfx] [PATCH v3] drm/i915/query: Split out query item checks
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
---
drivers/gpu/drm/i915/i915_query.c | 39 ---
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index cbcb957b7141..782183b78f49 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -10,12 +10,34 @@
#include "i915_query.h"
#include
+static int copy_query_item(void *query_hdr, size_t query_sz,
+ u32 total_length,
+ struct drm_i915_query_item *query_item)
+{
+ if (query_item->length == 0)
+ return total_length;
+
+ if (query_item->length < total_length)
+ return -EINVAL;
+
+ if (copy_from_user(query_hdr, u64_to_user_ptr(query_item->data_ptr),
+ query_sz))
+ return -EFAULT;
+
+ if (!access_ok(u64_to_user_ptr(query_item->data_ptr),
+ total_length))
+ return -EFAULT;
+
+ return 0;
+}
+
static int query_topology_info(struct drm_i915_private *dev_priv,
struct drm_i915_query_item *query_item)
{
const struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)->sseu;
struct drm_i915_query_topology_info topo;
u32 slice_length, subslice_length, eu_length, total_length;
+ int ret;
if (query_item->flags != 0)
return -EINVAL;
@@ -33,23 +55,14 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
total_length = sizeof(topo) + slice_length + subslice_length + eu_length;
- if (query_item->length == 0)
- return total_length;
-
- if (query_item->length < total_length)
- return -EINVAL;
-
- if (copy_from_user(&topo, u64_to_user_ptr(query_item->data_ptr),
- sizeof(topo)))
- return -EFAULT;
+ ret = copy_query_item(&topo, sizeof(topo), total_length,
+ query_item);
+ if (ret != 0)
+ return ret;
if (topo.flags != 0)
return -EINVAL;
- if (!access_ok(u64_to_user_ptr(query_item->data_ptr),
- total_length))
- return -EFAULT;
-
memset(&topo, 0, sizeof(topo));
topo.max_slices = sseu->max_slices;
topo.max_subslices = sseu->max_subslices;
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_reuse: stop the hang detector afterwards
Take responsibility for the state we create, and in particular remember
to kill our child process (the hang detector) before exiting.
Reported-by: Daniel Vetter
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
tests/i915/gem_exec_reuse.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_reuse.c b/tests/i915/gem_exec_reuse.c
index df220be7b..44946528f 100644
--- a/tests/i915/gem_exec_reuse.c
+++ b/tests/i915/gem_exec_reuse.c
@@ -116,7 +116,7 @@ static unsigned int max_nfd(void)
igt_main
{
- struct noop no;
+ struct noop no = { .fd = -1 };
unsigned engines[16];
unsigned nengine;
unsigned n;
@@ -213,4 +213,7 @@ igt_main
for (n = 0; n < ncontexts; n++)
gem_context_destroy(no.fd, contexts[n]);
}
+
+ igt_fixture
+ igt_stop_hang_detector(no.fd);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Reacquire priolist cache after dropping the engine lock
On 11/02/2019 17:44, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-02-11 17:33:37)
On 11/02/2019 16:09, Chris Wilson wrote:
If we drop the engine lock, we may run execlists_dequeue which may free
the priolist. Therefore if we ever drop the execution lock on the
engine, we have to discard our cache and refetch the priolist to ensure
we do not use a stale pointer.
On first look one would observe current code is trying to re-acquire the prio
list on changing the engine, so I guess the problem is this check is hidden
under an additional conditional.
So a simpler approach of:
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index d01683167c77..74896e7dbfa7 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -341,16 +341,17 @@ static void __i915_schedule(struct i915_request *rq,
engine = sched_lock_engine(node, engine);
lockdep_assert_held(&engine->timeline.lock);
+ if (last != engine) {
+ pl = i915_sched_lookup_priolist(engine, prio);
+ last = engine;
+ }
+
/* Recheck after acquiring the engine->timeline.lock */
if (prio <= node->attr.priority || node_signaled(node))
continue;
node->attr.priority = prio;
if (!list_empty(&node->link)) {
- if (last != engine) {
- pl = i915_sched_lookup_priolist(engine, prio);
- last = engine;
- }
list_move_tail(&node->link, pl);
} else {
/*
Would not be acceptable?
It marks the priolist as used even though we may not populate it. That
extra conditional biting again, and it defeats the purpose of not having
to look up the priolist as often (for engines where we don't need to
touch the priority queue itself).
Yep, my bad.
[ 506.418935] [IGT] gem_exec_whisper: starting subtest contexts-priority
[ 593.240825] general protection fault: [#1] SMP
[ 593.240863] CPU: 1 PID: 494 Comm: gem_exec_whispe Tainted: G U
5.0.0-rc6+ #100
[ 593.240879] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0029.2016.1124.1625
11/24/2016
[ 593.240965] RIP: 0010:__i915_schedule+0x1fe/0x320 [i915]
[ 593.240981] Code: 48 8b 0c 24 48 89 c3 49 8b 45 28 49 8b 75 20 4c 89 3c 24 48 89
46 08 48 89 30 48 8b 43 08 48 89 4b 08 49 89 5d 20 49 89 45 28 <48> 89 08 45 39
a7 b8 03 00 00 7d 44 45 89 a7 b8 03 00 00 49 8b 85
[ 593.240999] RSP: 0018:c9057a60 EFLAGS: 00010046
[ 593.241013] RAX: 6b6b6b6b6b6b6b6b RBX: 8882582d7870 RCX: 88826baba6f0
[ 593.241026] RDX: RSI: 8882582d6e70 RDI: 888273482194
[ 593.241049] RBP: c9057a68 R08: 8882582d7680 R09: 8882582d7840
[ 593.241068] R10: R11: ea00095ebe08 R12: 0728
[ 593.241105] R13: 88826baba6d0 R14: c9057a40 R15: 888273482158
[ 593.241120] FS: 7f4613fb3900() GS:888277a8()
knlGS:
[ 593.241133] CS: 0010 DS: ES: CR0: 80050033
[ 593.241146] CR2: 7f57d3c66a84 CR3: 00026e2b6000 CR4: 001406e0
[ 593.241158] Call Trace:
[ 593.241233] i915_schedule+0x1f/0x30 [i915]
[ 593.241326] i915_request_add+0x1a9/0x290 [i915]
[ 593.241393] i915_gem_do_execbuffer+0x45f/0x1150 [i915]
[ 593.241411] ? init_object+0x49/0x80
[ 593.241425] ? ___slab_alloc.constprop.91+0x4b8/0x4e0
[ 593.241491] ? i915_gem_execbuffer2_ioctl+0x99/0x380 [i915]
[ 593.241563] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
[ 593.241629] i915_gem_execbuffer2_ioctl+0x1bb/0x380 [i915]
[ 593.241705] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
[ 593.241724] drm_ioctl_kernel+0x81/0xd0
[ 593.241738] drm_ioctl+0x1a7/0x310
[ 593.241803] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
[ 593.241819] ? __update_load_avg_se+0x1c9/0x240
[ 593.241834] ? pick_next_entity+0x7e/0x120
[ 593.241851] do_vfs_ioctl+0x88/0x5d0
[ 593.241880] ksys_ioctl+0x35/0x70
[ 593.241894] __x64_sys_ioctl+0x11/0x20
[ 593.241907] do_syscall_64+0x44/0xf0
[ 593.241924] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 593.241940] RIP: 0033:0x7f4615ffe757
[ 593.241952] Code: 00 00 90 48 8b 05 39 a7 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff
ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 73 01 c3 48 8b 0d 09 a7 0c 00 f7 d8 64 89 01 48
[ 593.241970] RSP: 002b:7ffc1030ddf8 EFLAGS: 0246 ORIG_RAX:
0010
[ 593.241984] RAX: ffda RBX: 7ffc10324420 RCX: 7f4615ffe757
[ 593.241997] RDX: 7ffc1030e220 RSI: 40406469 RDI: 0003
[ 593.242010] RBP: 7ffc1030e220 R08: 7f46160c9208 R09: 7f46160c9240
[ 593.242022] R10: R11: 0246 R12
Re: [Intel-gfx] [PATCH 17/46] drm/i915: Apply rps waitboosting for dma_fence_wait_timeout()
On 06/02/2019 13:03, Chris Wilson wrote:
As time goes by, usage of generic ioctls such as drm_syncobj and
sync_file are on the increase bypassing i915-specific ioctls like
GEM_WAIT. Currently, we only apply waitboosting to our driver ioctls as
we track the file/client and account the waitboosting to them. However,
since commit 7b92c1bd0540 ("drm/i915: Avoid keeping waitboost active for
signaling threads"), we no longer have been applying the client
ratelimiting on waitboosts and so that information has only been used
for debug tracking.
Push the application of waitboosting down to the common
i915_request_wait, and apply it to all foreign fence waits as well.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Eero Tamminen
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 +-
drivers/gpu/drm/i915/i915_drv.h | 7 +--
drivers/gpu/drm/i915/i915_gem.c | 86 ++--
drivers/gpu/drm/i915/i915_request.c | 21 ++-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 5 +-
7 files changed, 44 insertions(+), 98 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8a488ffc8b7d..af53a2d07f6b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2020,11 +2020,9 @@ static const char *rps_power_to_str(unsigned int power)
static int i915_rps_boost_info(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
- struct drm_device *dev = &dev_priv->drm;
struct intel_rps *rps = &dev_priv->gt_pm.rps;
u32 act_freq = rps->cur_freq;
intel_wakeref_t wakeref;
- struct drm_file *file;
with_intel_runtime_pm_if_in_use(dev_priv, wakeref) {
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
@@ -2058,22 +2056,7 @@ static int i915_rps_boost_info(struct seq_file *m, void
*data)
intel_gpu_freq(dev_priv, rps->efficient_freq),
intel_gpu_freq(dev_priv, rps->boost_freq));
- mutex_lock(&dev->filelist_mutex);
- list_for_each_entry_reverse(file, &dev->filelist, lhead) {
- struct drm_i915_file_private *file_priv = file->driver_priv;
- struct task_struct *task;
-
- rcu_read_lock();
- task = pid_task(file->pid, PIDTYPE_PID);
- seq_printf(m, "%s [%d]: %d boosts\n",
- task ? task->comm : "",
- task ? task->pid : -1,
- atomic_read(&file_priv->rps_client.boosts));
- rcu_read_unlock();
- }
- seq_printf(m, "Kernel (anonymous) boosts: %d\n",
- atomic_read(&rps->boosts));
- mutex_unlock(&dev->filelist_mutex);
+ seq_printf(m, "Wait boosts: %d\n", atomic_read(&rps->boosts));
if (INTEL_GEN(dev_priv) >= 6 &&
rps->enabled &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a365b1a2ea9a..4d697b1002af 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -217,10 +217,6 @@ struct drm_i915_file_private {
} mm;
struct idr context_idr;
- struct intel_rps_client {
- atomic_t boosts;
- } rps_client;
-
unsigned int bsd_engine;
/*
@@ -3041,8 +3037,7 @@ void i915_gem_resume(struct drm_i915_private *dev_priv);
vm_fault_t i915_gem_fault(struct vm_fault *vmf);
int i915_gem_object_wait(struct drm_i915_gem_object *obj,
unsigned int flags,
-long timeout,
-struct intel_rps_client *rps);
+long timeout);
int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
unsigned int flags,
const struct i915_sched_attr *attr);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 04fa184fdff5..78b9aa57932d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -421,8 +421,7 @@ int i915_gem_object_unbind(struct drm_i915_gem_object *obj)
static long
i915_gem_object_wait_fence(struct dma_fence *fence,
unsigned int flags,
- long timeout,
- struct intel_rps_client *rps_client)
+ long timeout)
{
struct i915_request *rq;
@@ -440,27 +439,6 @@ i915_gem_object_wait_fence(struct dma_fence *fence,
if (i915_request_completed(rq))
goto out;
- /*
-* This client is about to stall waiting for the GPU. In many cases
-* this is undesirable and limits the throughput of the system, as
-* many clients cannot continue processing user input/output whilst
-* blocked. RPS autotuning
Re: [Intel-gfx] [PATCH v12 32/38] misc/mei/hdcp: Verify M_prime
>
> Request to ME to verify the M_Prime received from the HDCP sink.
>
> ME FW will calculate the M and compare with M_prime received as part of
> RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg.
>
> On successful completion of this stage, downstream propagation of the stream
> management info is completed.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
> v4:
> %zd for ssize_t [Alexander]
> %s/return -1/return -EIO [Alexander]
> endianness conversion func is moved to drm_hdcp.h [Uma]
> v5: Rebased.
> v6:
> Collected the Rb-ed by.
> Rebasing.
> v7:
> Adjust to the new mei interface.
> Fix for Kdoc.
> v8:
> K-Doc addition. [Tomas]
> drm_hdcp2_u32_to_seq_num() is used for u32 to seq_num.
> v9:
> renamed func as mei_hdcp_* [Tomas]
> Inline function is defined for DDI index [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 67
> +++-
> 1 file changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 6cd76b3bcaea..7d0562c2a773 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -535,6 +535,71 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct
> device *dev,
> return 0;
> }
>
> +/**
> + * mei_hdcp_verify_mprime() - Verify mprime.
> + * @dev: device corresponding to the mei_cl_device
> + * @hdcp_data: Intel HW specific hdcp data
This should be @data across all the functions.
> + * @stream_ready: RepeaterAuth_Stream_Ready msg for ME FW verification.
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int mei_hdcp_verify_mprime(struct device *dev,
> + struct hdcp_port_data *data,
> + struct hdcp2_rep_stream_ready
> *stream_ready) {
> + struct wired_cmd_repeater_auth_stream_req_in
> + verify_mprime_in = { { 0 } };
> + struct wired_cmd_repeater_auth_stream_req_out
> + verify_mprime_out = { { 0 } };
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !stream_ready || !data)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(dev);
> +
> + verify_mprime_in.header.api_version = HDCP_API_VERSION;
> + verify_mprime_in.header.command_id =
> WIRED_REPEATER_AUTH_STREAM_REQ;
> + verify_mprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
> + verify_mprime_in.header.buffer_len =
> +
> WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN;
> +
> + verify_mprime_in.port.integrated_port_type = data->port_type;
> + verify_mprime_in.port.physical_port = mei_get_ddi_index(data->port);
> +
> + memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
> +HDCP_2_2_MPRIME_LEN);
> + drm_hdcp2_u32_to_seq_num(verify_mprime_in.seq_num_m, data-
> >seq_num_m);
> + memcpy(verify_mprime_in.streams, data->streams,
> +(data->k * sizeof(struct hdcp2_streamid_type)));
> +
> + verify_mprime_in.k = __swab16(data->k);
> +
> + byte = mei_cldev_send(cldev, (u8 *)&verify_mprime_in,
> + sizeof(verify_mprime_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
> + return byte;
> + }
> +
> + byte = mei_cldev_recv(cldev, (u8 *)&verify_mprime_out,
> + sizeof(verify_mprime_out));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
> + return byte;
> + }
> +
> + if (verify_mprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
> + dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
> + WIRED_REPEATER_AUTH_STREAM_REQ,
> + verify_mprime_out.header.status);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> static __attribute__((unused))
> struct i915_hdcp_component_ops mei_hdcp_ops = {
> .owner = THIS_MODULE,
> @@ -548,7 +613,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .get_session_key = mei_hdcp_get_session_key,
> .repeater_check_flow_prepare_ack =
> mei_hdcp_repeater_check_flow_prepare_ack,
> - .verify_mprime = NULL,
> + .verify_mprime = mei_hdcp_verify_mprime,
> .enable_hdcp_authentication = NULL,
> .close_hdcp_session = NULL,
> };
> --
> 2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/46] drm/i915/pmu: Always sample an active ringbuffer
On 06/02/2019 13:03, Chris Wilson wrote:
As we no longer have a precise indication of requests queued to an
engine, make no presumptions and just sample the ring registers to see
if the engine is busy.
v2: Report busy while the ring is idling on a semaphore/event.
I was planning to take care of this detail but cool, no complaints. :)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_pmu.c | 55 +
1 file changed, 21 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 13d70b90dd0f..157cbfa155d9 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -101,7 +101,7 @@ static bool pmu_needs_timer(struct drm_i915_private *i915,
bool gpu_active)
*
* Use RCS as proxy for all engines.
*/
- else if (intel_engine_supports_stats(i915->engine[RCS]))
+ else if (i915->caps.scheduler & I915_SCHEDULER_CAP_PMU)
Need to nuke the comment as well.
But my problem is I still think I915_SCHEDULER_CAP_PMU is wrong name and
level. It is neither a scheduler feature, nor the whole PMU. Maybe
I915_SCHEDULER_CAP_ENGINE_STATS removes one contention point, but still
I am wondering if I could refactor how the PMU tracks the need for
having the sampling timer and so remove the need for proxying from RCS
via that route.
enable &= ~BIT(I915_SAMPLE_BUSY);
/*
@@ -148,14 +148,6 @@ void i915_pmu_gt_unparked(struct drm_i915_private *i915)
spin_unlock_irq(&i915->pmu.lock);
}
-static bool grab_forcewake(struct drm_i915_private *i915, bool fw)
-{
- if (!fw)
- intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
-
- return true;
-}
-
static void
add_sample(struct i915_pmu_sample *sample, u32 val)
{
@@ -168,7 +160,6 @@ engines_sample(struct drm_i915_private *dev_priv, unsigned
int period_ns)
struct intel_engine_cs *engine;
enum intel_engine_id id;
intel_wakeref_t wakeref;
- bool fw = false;
if ((dev_priv->pmu.enable & ENGINE_SAMPLE_MASK) == 0)
return;
@@ -181,36 +172,32 @@ engines_sample(struct drm_i915_private *dev_priv,
unsigned int period_ns)
return;
for_each_engine(engine, dev_priv, id) {
- u32 current_seqno = intel_engine_get_seqno(engine);
- u32 last_seqno = intel_engine_last_submit(engine);
+ typeof(engine->pmu) *pmu = &engine->pmu;
I would also prefer we did not start introducing the idiom of declaring
locals outside macros with typeof.
+ bool busy;
u32 val;
- val = !i915_seqno_passed(current_seqno, last_seqno);
-
- if (val)
- add_sample(&engine->pmu.sample[I915_SAMPLE_BUSY],
- period_ns);
-
- if (val && (engine->pmu.enable &
- (BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
- fw = grab_forcewake(dev_priv, fw);
-
- val = I915_READ_FW(RING_CTL(engine->mmio_base));
- } else {
- val = 0;
- }
+ val = I915_READ_FW(RING_CTL(engine->mmio_base));
+ if (val == 0 || val == ~0u) /* outside of powerwell */
+ continue;
Would /* Powerwell not awake. */ be clearer?
So the claim is we can rely on register being either all zeros or all
ones when powered down? Absolutely 100%? Is this documented somewhere?
But still need the runtime pm ref?
Regards,
Tvrtko
if (val & RING_WAIT)
- add_sample(&engine->pmu.sample[I915_SAMPLE_WAIT],
- period_ns);
-
+ add_sample(&pmu->sample[I915_SAMPLE_WAIT], period_ns);
if (val & RING_WAIT_SEMAPHORE)
- add_sample(&engine->pmu.sample[I915_SAMPLE_SEMA],
- period_ns);
- }
+ add_sample(&pmu->sample[I915_SAMPLE_SEMA], period_ns);
- if (fw)
- intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+ /*
+* MI_MODE reports IDLE if the ring is waiting, but we regard
+* this as being busy instead, as the engine is busy with the
+* user request.
+*/
+ busy = val & (RING_WAIT_SEMAPHORE | RING_WAIT);
+ if (!busy) {
+ val = I915_READ_FW(RING_MI_MODE(engine->mmio_base));
+ busy = !(val & MODE_IDLE);
+ }
+ if (busy)
+ add_sample(&pmu->sample[I915_SAMPLE_BUSY], period_ns);
+ }
intel_runtime_pm_put(dev_priv, wakeref);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-
Re: [Intel-gfx] [PATCH 20/46] drm/i915: Remove access to global seqno in the HWSP
On 06/02/2019 13:03, Chris Wilson wrote:
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
---
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 | 2 -
10 files changed, 19 insertions(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9a65341fec09..a674c78ca1f8 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -533,8 +533,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",
@@ -1227,8 +1225,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 d5c58e82508b..4dbbd0f02edb 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 eed66d3606d9..85cf5cfbc7ed 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -192,12 +192,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));
@@ -256,12 +255,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(&request->i915->drm.struct_mutex);
GEM_BUG_ON(!i915_sw_fence_signaled(&request->submit));
@@ -320,12 +318,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(&rq->i915->drm.struct_mutex);
GEM_BUG_ON(!i915_request_completed(rq));
@@ -427,12 +424,11 @@ void __i915_request_submit(struct i915_request *requ
Re: [Intel-gfx] [PULL] topic/component-typed
Hi Daniel. On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote: > Hi all, > > Here's the typed component topic branch. > > drm-intel maintainers: Please pull, I need this for the mei hdcp work from > Ram. > > drm-misc maintainers: Please pull, there's a drm doc patch follow-up > that I want to stuff into drm-misc-next. > > Greg: The drm side missed our feature cutoff, so will only land in 5.2. With all the dependencies why not bend the rule a little and get this in now? It is not like this is a huge patchset. Sam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Reacquire priolist cache after dropping the engine lock (rev2)
== Series Details == Series: drm/i915: Reacquire priolist cache after dropping the engine lock (rev2) URL : https://patchwork.freedesktop.org/series/56501/ State : failure == Summary == Applying: drm/i915: Reacquire priolist cache after dropping the engine lock error: patch failed: drivers/gpu/drm/i915/i915_scheduler.c:341 error: drivers/gpu/drm/i915/i915_scheduler.c: patch does not apply error: Did you hand edit your patch? It does not apply to blobs recorded in its index. hint: Use 'git am --show-current-patch' to see the failed patch Using index info to reconstruct a base tree... Patch failed at 0001 drm/i915: Reacquire priolist cache after dropping the engine lock 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] [igt-dev] [PATCH i-g-t] i915/gem_exec_reuse: stop the hang detector afterwards
On 11/02/19 09:52, Chris Wilson wrote:
Take responsibility for the state we create, and in particular remember
to kill our child process (the hang detector) before exiting.
Reported-by: Daniel Vetter
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
tests/i915/gem_exec_reuse.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_reuse.c b/tests/i915/gem_exec_reuse.c
index df220be7b..44946528f 100644
--- a/tests/i915/gem_exec_reuse.c
+++ b/tests/i915/gem_exec_reuse.c
@@ -116,7 +116,7 @@ static unsigned int max_nfd(void)
igt_main
{
- struct noop no;
+ struct noop no = { .fd = -1 };
unsigned engines[16];
unsigned nengine;
unsigned n;
@@ -213,4 +213,7 @@ igt_main
for (n = 0; n < ncontexts; n++)
gem_context_destroy(no.fd, contexts[n]);
}
+
+ igt_fixture
+ igt_stop_hang_detector(no.fd);
This doesn't take an fd... incoming changes to the lib?
Still makes sense, with fix,
Reviewed-by: Antonio Argenziano
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/46] drm/i915: Remove i915_request.global_seqno
On 06/02/2019 13:03, Chris Wilson wrote:
Having weaned the interrupt handling off using a single global execution
queue, we no longer need to emit a global_seqno.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 35 ++---
drivers/gpu/drm/i915/i915_gpu_error.h | 2 -
drivers/gpu/drm/i915/i915_request.c | 31 ++--
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, 31 insertions(+), 193 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index a674c78ca1f8..8792ad12373d 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));
Why remove this information?
err_puts(m, i915_cache_level_str(m->i915, err->cache_level));
if (err->name)
@@ -1059,27 +1056,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)
{
@@ -1088,9 +1064,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(&obj->frontbuffer_write);
- err->engine = __active_get_engine_id(&obj->frontbuffer_write);
-
err->gtt_offset = vma->node.start;
err->read_domains = obj->read_domains;
err->write_domain = obj->write_domain;
@@ -1295,10 +1268,10 @@ 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->ban_score = atomic_read(&ctx->ban_score);
- erq->seqno = request->global_seqno;
erq->jiffies = request->emitted_jiffies;
erq->start = i915_ggtt_offset(request->ring->vma);
erq->head = request->head;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 4dbbd0f02edb..34fec5f00ef2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -167,7 +167,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;
@@ -176,7 +175,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
Re: [Intel-gfx] [PULL] topic/component-typed
On Mon, Feb 11, 2019 at 7:25 PM Sam Ravnborg wrote: > > Hi Daniel. > > On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote: > > Hi all, > > > > Here's the typed component topic branch. > > > > drm-intel maintainers: Please pull, I need this for the mei hdcp work from > > Ram. > > > > drm-misc maintainers: Please pull, there's a drm doc patch follow-up > > that I want to stuff into drm-misc-next. > > > > Greg: The drm side missed our feature cutoff, so will only land in 5.2. > > With all the dependencies why not bend the rule a little and get this in now? > It is not like this is a huge patchset. The feature that depends upon this is almost 40 patches. That's a bit much for bending :-) Hence why I'm asking Greg to pull this, so it's not stuck out of tree for 3 months for no good reason. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/46] drm/i915: Store the BIT(engine->id) as the engine's mask
On 06/02/2019 13:03, Chris Wilson wrote:
In the next patch, we are introducing a broad virtual engine to encompass
multiple physical engines, losing the 1:1 nature of BIT(engine->id). To
reflect the broader set of engines implied by the virtual instance, lets
store the full bitmask.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c| 4 ++--
drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
drivers/gpu/drm/i915/intel_hangcheck.c | 8
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +--
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 2 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 1 +
7 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 7051c0a43941..78c9689629a0 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -1053,7 +1053,7 @@ void i915_reset(struct drm_i915_private *i915,
static inline int intel_gt_reset_engine(struct drm_i915_private *i915,
struct intel_engine_cs *engine)
{
- return intel_gpu_reset(i915, intel_engine_flag(engine));
+ return intel_gpu_reset(i915, engine->mask);
}
/**
@@ -1253,7 +1253,7 @@ void i915_handle_error(struct drm_i915_private *i915,
continue;
if (i915_reset_engine(engine, msg) == 0)
- engine_mask &= ~intel_engine_flag(engine);
+ engine_mask &= ~engine->mask;
clear_bit(I915_RESET_ENGINE + engine->id,
&error->flags);
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index ce7c19f2ae49..45e38877ab17 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -313,7 +313,10 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
if (!engine)
return -ENOMEM;
+ BUILD_BUG_ON(BITS_PER_TYPE(engine->mask) < I915_NUM_ENGINES);
+
engine->id = id;
+ engine->mask = BIT(id);
engine->i915 = dev_priv;
__sprint_engine_name(engine->name, info);
engine->hw_id = engine->guc_id = info->hw_id;
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
b/drivers/gpu/drm/i915/intel_hangcheck.c
index e04b2560369e..58b6ff8453dc 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -120,7 +120,7 @@ engine_stuck(struct intel_engine_cs *engine, u64 acthd)
*/
tmp = I915_READ_CTL(engine);
if (tmp & RING_WAIT) {
- i915_handle_error(dev_priv, BIT(engine->id), 0,
+ i915_handle_error(dev_priv, engine->mask, 0,
"stuck wait on %s", engine->name);
I915_WRITE_CTL(engine, tmp);
return ENGINE_WAIT_KICK;
@@ -282,13 +282,13 @@ static void i915_hangcheck_elapsed(struct work_struct
*work)
hangcheck_store_sample(engine, &hc);
if (hc.stalled) {
- hung |= intel_engine_flag(engine);
+ hung |= engine->mask;
if (hc.action != ENGINE_DEAD)
- stuck |= intel_engine_flag(engine);
+ stuck |= engine->mask;
}
if (hc.wedged)
- wedged |= intel_engine_flag(engine);
+ wedged |= engine->mask;
}
if (GEM_SHOW_DEBUG() && (hung | stuck)) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1b96b0960adc..91c49f644898 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1859,8 +1859,8 @@ static int switch_context(struct i915_request *rq)
goto err;
} while (--loops);
- if (intel_engine_flag(engine) & ppgtt->pd_dirty_rings) {
- unwind_mm = intel_engine_flag(engine);
+ if (ppgtt->pd_dirty_rings & engine->mask) {
+ unwind_mm = engine->mask;
ppgtt->pd_dirty_rings &= ~unwind_mm;
hw_flags = MI_FORCE_RESTORE;
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 39a9ee7b61e2..d46784f9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -334,6 +334,7 @@ struct intel_engine_cs {
enum intel_engine_id id;
unsigned int hw_id;
unsigned int guc_id;
+ unsigned long mask;
Could use intel_ring_mask_t - if we renamed it to intel_engine_mask_t -
which is already checked with a BUILD_BUG_ON.
u8 uabi_id;
u8 uabi_class;
@@ -668,12
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/query: Split out query item checks (rev3)
== Series Details ==
Series: drm/i915/query: Split out query item checks (rev3)
URL : https://patchwork.freedesktop.org/series/54917/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5589 -> Patchwork_12197
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54917/revisions/3/mbox/
Known issues
Here are the changes found in Patchwork_12197 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: PASS -> DMESG-FAIL [fdo#103182]
{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#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109226]: https://bugs.freedesktop.org/show_bug.cgi?id=109226
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (47 -> 41)
--
Additional (2): fi-byt-j1900 fi-pnv-d510
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-glk-j4005 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5589 -> Patchwork_12197
CI_DRM_5589: 7a1e565f0c6d003c5990380c6e3da8719ac33eec @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4816: f62577c85c9ef0539d468d6fad105b706a15139c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12197: 5b66ad7580875a872e689cbe0326c3bb47727133 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5b66ad758087 drm/i915/query: Split out query item checks
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12197/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/component-typed
On Mon, 11 Feb 2019 19:25:12 +0100, Sam Ravnborg wrote: > > Hi Daniel. > > On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote: > > Hi all, > > > > Here's the typed component topic branch. > > > > drm-intel maintainers: Please pull, I need this for the mei hdcp work from > > Ram. > > > > drm-misc maintainers: Please pull, there's a drm doc patch follow-up > > that I want to stuff into drm-misc-next. > > > > Greg: The drm side missed our feature cutoff, so will only land in 5.2. > > With all the dependencies why not bend the rule a little and get this in now? > It is not like this is a huge patchset. Yeah, that's likely the most straightforward way. BTW, I tried to pull onto sound git tree for-next branch, and it worked without conflicts. So I don't think it needs to be pulled onto mine. thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Pull sync_scru for device reset outside of wedge_mutex
== Series Details ==
Series: drm/i915: Pull sync_scru for device reset outside of wedge_mutex
URL : https://patchwork.freedesktop.org/series/56495/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5588_full -> Patchwork_12193_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12193_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@basic-all-heavy:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@gem_eio@reset-stress:
- shard-snb: PASS -> FAIL [fdo#107799]
* igt@gem_exec_big:
- shard-hsw: PASS -> TIMEOUT [fdo#107937]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-hsw: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-256x256-random:
- shard-apl: PASS -> FAIL [fdo#103232] +2
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
- shard-glk: PASS -> FAIL [fdo#103167] +4
* igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-glk: PASS -> FAIL [fdo#103166] +4
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-apl: PASS -> FAIL [fdo#103166] +2
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
Possible fixes
* igt@i915_suspend@fence-restore-untiled:
- shard-snb: INCOMPLETE [fdo#105411] -> PASS
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_cursor_crc@cursor-256x256-onscreen:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_legacy@all-pipes-torture-move:
- shard-hsw: DMESG-WARN [fdo#107122] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS +2
- shard-glk: FAIL [fdo#103166] -> PASS +2
* igt@kms_setmode@basic:
- shard-hsw: FAIL [fdo#99912] -> PASS
* igt@pm_rc6_residency@rc6-accuracy:
- shard-kbl: {SKIP} [fdo#109271] -> PASS
Warnings
* igt@i915_suspend@shrink:
- shard-glk: INCOMPLETE [fdo#103359] / [fdo#106886] /
[k.org#198133] -> DMESG-WARN [fdo#109244]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[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#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
[fdo#107122]: https://bugs.freedesktop.org/show_bug.cgi?id=107122
[fdo#107799]: https://bugs.freedesktop.org/show_bug.cgi?id=107799
[fdo#107937]: https://bugs.freedesktop.org/show_bug.cgi?id=107937
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109244]: https://bugs.freedesktop.org/show_bug.cgi?id=109244
[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
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5588 -> Patchwork_12193
CI_DRM_5588: 133ed6b29f62713f2edd95eac6ccc2ae1d6e4d6e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4816: f62577c85c9ef0539d468d6fad105b706a15139c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12193: ab4aa6cb2bbc133d070fd850e292ab4670011508 @
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_12193/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/46] drm/i915: Introduce the i915_user_extension_method
On 06/02/2019 13:03, Chris Wilson wrote:
An idea for extending uABI inspired by Vulkan's extension chains.
Instead of expanding the data struct for each ioctl every time we need
to add a new feature, define an extension chain instead. As we add
optional interfaces to control the ioctl, we define a new extension
struct that can be linked into the ioctl data only when required by the
user. The key advantage being able to ignore large control structs for
optional interfaces/extensions, while being able to process them in a
consistent manner.
In comparison to other extensible ioctls, the key difference is the
use of a linked chain of extension structs vs an array of tagged
pointers. For example,
struct drm_amdgpu_cs_chunk {
__u32 chunk_id;
__u32 length_dw;
__u64 chunk_data;
};
struct drm_amdgpu_cs_in {
__u32 ctx_id;
__u32 bo_list_handle;
__u32 num_chunks;
__u32 _pad;
__u64 chunks;
};
allows userspace to pass in array of pointers to extension structs, but
must therefore keep constructing that array along side the command stream.
In dynamic situations like that, a linked list is preferred and does not
similar from extra cache line misses as the extension structs themselves
must still be loaded separate to the chunks array.
v2: Apply the tail call optimisation directly to nip the worry of stack
overflow in the bud.
v3: Defend against recursion.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_user_extensions.c | 43 +
drivers/gpu/drm/i915/i915_user_extensions.h | 20 ++
drivers/gpu/drm/i915/i915_utils.h | 7
include/uapi/drm/i915_drm.h | 20 ++
5 files changed, 91 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_user_extensions.c
create mode 100644 drivers/gpu/drm/i915/i915_user_extensions.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a1d834068765..89105b1aaf12 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -46,6 +46,7 @@ i915-y := i915_drv.o \
i915_sw_fence.o \
i915_syncmap.o \
i915_sysfs.o \
+ i915_user_extensions.o \
intel_csr.o \
intel_device_info.o \
intel_pm.o \
diff --git a/drivers/gpu/drm/i915/i915_user_extensions.c
b/drivers/gpu/drm/i915/i915_user_extensions.c
new file mode 100644
index ..879b4094b2d7
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_user_extensions.c
@@ -0,0 +1,43 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_user_extensions.h"
+
+int i915_user_extensions(struct i915_user_extension __user *ext,
+const i915_user_extension_fn *tbl,
+unsigned long count,
+void *data)
+{
+ unsigned int stackdepth = 512;
+
+ while (ext) {
+ int err;
+ u64 x;
+
+ if (!stackdepth--) /* recursion vs useful flexibility */
+ return -EINVAL;
I don't get this - which recursion? Variable is also a local automatic.
+
+ if (get_user(x, &ext->name))
+ return -EFAULT;
+
+ err = -EINVAL;
+ if (x < count && tbl[x])
+ err = tbl[x](ext, data);
+ if (err)
+ return err;
Do you plan to add the unwind as previously discussed? Or we define the
interface as having undefined state if one extension failed? I would be
a bit suboptimal for userspace since it would mean having to throw away
and recreate the object in use cases for user extensions capable ioctl
is executed post creation of some object.
Regards,
Tvrtko
+
+ if (get_user(x, &ext->next_extension))
+ return -EFAULT;
+
+ ext = u64_to_user_ptr(x);
+ }
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/i915_user_extensions.h
b/drivers/gpu/drm/i915/i915_user_extensions.h
new file mode 100644
index ..313a510b068a
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_user_extensions.h
@@ -0,0 +1,20 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef I915_USER_EXTENSIONS_H
+#define I915_USER_EXTENSIONS_H
+
+struct i915_user_extension;
+
+typedef int (*i915_user_extension_fn)(struct i915_user_extension __user *ext,
+ void *data);
+
+int i915_user_extensions(struct i915_user_extension __user *ext,
+const i915_user_extension_fn *tbl,
+unsigned long count,
+void *data);
+
+#endif /* I915_USER_EXTENSIONS_H */
diff --git a/drivers/gpu/drm/i915
Re: [Intel-gfx] [PATCH 30/46] drm/i915: Track active engines within a context
On 06/02/2019 13:03, Chris Wilson wrote:
For use in the next patch, if we track which engines have been used by
the HW, we can reduce the work required to flush our state off the HW to
those engines.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 3 +++
drivers/gpu/drm/i915/i915_gem_context.h | 4
drivers/gpu/drm/i915/intel_lrc.c | 2 ++
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
drivers/gpu/drm/i915/selftests/mock_context.c | 1 +
drivers/gpu/drm/i915/selftests/mock_engine.c | 2 ++
6 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 582a7015e6a4..91037ca96be1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -210,6 +210,7 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
lockdep_assert_held(&ctx->i915->drm.struct_mutex);
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
+ GEM_BUG_ON(!list_empty(&ctx->active_engines));
release_hw_id(ctx);
i915_ppgtt_put(ctx->ppgtt);
@@ -337,6 +338,7 @@ intel_context_init(struct intel_context *ce,
struct intel_engine_cs *engine)
{
ce->gem_context = ctx;
+ ce->engine = engine;
INIT_LIST_HEAD(&ce->signal_link);
INIT_LIST_HEAD(&ce->signals);
@@ -364,6 +366,7 @@ __create_hw_context(struct drm_i915_private *dev_priv,
list_add_tail(&ctx->link, &dev_priv->contexts.list);
ctx->i915 = dev_priv;
ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
+ INIT_LIST_HEAD(&ctx->active_engines);
for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++)
intel_context_init(&ctx->__engine[n], ctx, dev_priv->engine[n]);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 651f2e4badb6..ab89c7501408 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -161,6 +161,8 @@ struct i915_gem_context {
atomic_t hw_id_pin_count;
struct list_head hw_id_link;
+ struct list_head active_engines;
+
/**
* @user_handle: userspace identifier
*
@@ -174,7 +176,9 @@ struct i915_gem_context {
/** engine: per-engine logical HW state */
struct intel_context {
struct i915_gem_context *gem_context;
+ struct intel_engine_cs *engine;
struct intel_engine_cs *active;
+ struct list_head active_link;
struct list_head signal_link;
struct list_head signals;
struct i915_vma *state;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2424eb2b1fc6..b3555b1b0e07 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1276,6 +1276,7 @@ static void execlists_context_unpin(struct intel_context
*ce)
i915_gem_object_unpin_map(ce->state->obj);
i915_vma_unpin(ce->state);
+ list_del(&ce->active_link);
i915_gem_context_put(ce->gem_context);
}
@@ -1361,6 +1362,7 @@ __execlists_context_pin(struct intel_engine_cs *engine,
ce->state->obj->pin_global++;
i915_gem_context_get(ctx);
+ list_add(&ce->active_link, &ctx->active_engines);
Why is it called active_engines if it lists active_contexts? :)
return ce;
unpin_ring:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 91c49f644898..4557f715663d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1430,6 +1430,7 @@ static void intel_ring_context_unpin(struct intel_context
*ce)
__context_unpin_ppgtt(ce->gem_context);
__context_unpin(ce);
+ list_del(&ce->active_link);
i915_gem_context_put(ce->gem_context);
}
@@ -1530,6 +1531,7 @@ __ring_context_pin(struct intel_engine_cs *engine,
goto err_unpin;
i915_gem_context_get(ctx);
+ list_add(&ce->active_link, &ctx->active_engines);
/* One ringbuffer to rule them all */
GEM_BUG_ON(!engine->buffer);
diff --git a/drivers/gpu/drm/i915/selftests/mock_context.c
b/drivers/gpu/drm/i915/selftests/mock_context.c
index b646cdcdd602..1b5073a362eb 100644
--- a/drivers/gpu/drm/i915/selftests/mock_context.c
+++ b/drivers/gpu/drm/i915/selftests/mock_context.c
@@ -44,6 +44,7 @@ mock_context(struct drm_i915_private *i915,
INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
INIT_LIST_HEAD(&ctx->handles_list);
INIT_LIST_HEAD(&ctx->hw_id_link);
+ INIT_LIST_HEAD(&ctx->active_engines);
for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++)
intel_context_init(&ctx->__engine[n], ctx, i915->engine[n]);
diff --git a/drivers/gpu/drm/i915/selftests/mock_engine.c
b/drivers/gpu/drm/i915/selftests/mock_eng
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_parse: Switch to a fixed timeout for basic-allocations
Quoting Chris Wilson (2019-02-11 17:23:57) > Quoting Tvrtko Ursulin (2019-02-11 17:18:02) > > I'd prefer if we just let it run and don't involve wedge/unwedge. Well > > actually... we could modify the submit loop to sync a bit rather than > > build a queue for 20 seconds? Would sync after each execbuf be > > detrimental to test goals? Alternatively submit maybe ARRAY_SIZE worth > > and then sync? > > Yes, syncing affects i915_gem_batch_pool.c. The length of the cache > lists is largely determined by the number of batches in flight. Along those lines, it's probably worthwhile to stress fixed object sizes as well, and make those batches long last, yet still quick to parse. It's worth bearing in mind that another user of i915_gem_batch_pool are GPU relocs, so this issue isn't just limited to gen7-cmdparser. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump skl+ watermark changes
Reviewed-by: Clint Taylor
-Clint
On 2/8/19 12:05, Ville Syrjala wrote:
From: Ville Syrjälä
Currently we're only dumping out the ddb allocation changes, let's do
the same for the watermarks. This should help with debugging underruns
and whatnot.
First I tried one line per plane per wm level, but that resulted in
an obnoxious amount of lines printed. So as a compromise I settled
on a four line format, each line containing a single watermark related
value (enable,lines,blocks,min_ddb_alloc) for all 8 levels (+trans wm).
It still produces quite a lot of output but I can't really see a way
around that because we simply have a lot of data to dump.
Let's also pimp the ddb debug to print the size of the allocations
too, not just their bounds. Makes it a bit easier to compare against
the watermarks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 86 +++--
1 file changed, 83 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 54307f1df6cf..454581b044ad 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5269,6 +5269,11 @@ skl_compute_ddb(struct intel_atomic_state *state)
return 0;
}
+static char enast(bool enable)
+{
+ return enable ? '*' : ' ';
+}
+
static void
skl_print_wm_changes(struct intel_atomic_state *state)
{
@@ -5279,8 +5284,16 @@ skl_print_wm_changes(struct intel_atomic_state *state)
struct intel_crtc *crtc;
int i;
+ if ((drm_debug & DRM_UT_KMS) == 0)
+ return;
+
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ const struct skl_pipe_wm *old_pipe_wm, *new_pipe_wm;
+
+ old_pipe_wm = &old_crtc_state->wm.skl.optimal;
+ new_pipe_wm = &new_crtc_state->wm.skl.optimal;
+
for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
enum plane_id plane_id = plane->id;
const struct skl_ddb_entry *old, *new;
@@ -5291,10 +5304,77 @@ skl_print_wm_changes(struct intel_atomic_state *state)
if (skl_ddb_entry_equal(old, new))
continue;
- DRM_DEBUG_KMS("[PLANE:%d:%s] ddb (%d - %d) -> (%d - %d)\n",
+ DRM_DEBUG_KMS("[PLANE:%d:%s] ddb (%4d - %4d) -> (%4d - %4d),
size %4d -> %4d\n",
+ plane->base.base.id, plane->base.name,
+ old->start, old->end, new->start,
new->end,
+ skl_ddb_entry_size(old),
skl_ddb_entry_size(new));
+ }
+
+ for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
+ enum plane_id plane_id = plane->id;
+ const struct skl_plane_wm *old_wm, *new_wm;
+
+ old_wm = &old_pipe_wm->planes[plane_id];
+ new_wm = &new_pipe_wm->planes[plane_id];
+
+ if (skl_plane_wm_equals(dev_priv, old_wm, new_wm))
+ continue;
+
+ DRM_DEBUG_KMS("[PLANE:%d:%s] level
%cwm0,%cwm1,%cwm2,%cwm3,%cwm4,%cwm5,%cwm6,%cwm7,%ctwm"
+ " ->
%cwm0,%cwm1,%cwm2,%cwm3,%cwm4,%cwm5,%cwm6,%cwm7,%ctwm\n",
+ plane->base.base.id, plane->base.name,
+ enast(old_wm->wm[0].plane_en),
enast(old_wm->wm[1].plane_en),
+ enast(old_wm->wm[2].plane_en),
enast(old_wm->wm[3].plane_en),
+ enast(old_wm->wm[4].plane_en),
enast(old_wm->wm[5].plane_en),
+ enast(old_wm->wm[6].plane_en),
enast(old_wm->wm[7].plane_en),
+ enast(old_wm->trans_wm.plane_en),
+ enast(new_wm->wm[0].plane_en),
enast(new_wm->wm[1].plane_en),
+ enast(new_wm->wm[2].plane_en),
enast(new_wm->wm[3].plane_en),
+ enast(new_wm->wm[4].plane_en),
enast(new_wm->wm[5].plane_en),
+ enast(new_wm->wm[6].plane_en),
enast(new_wm->wm[7].plane_en),
+ enast(new_wm->trans_wm.plane_en));
+
+ DRM_DEBUG_KMS("[PLANE:%d:%s] lines
%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d"
+ " ->
%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d\n",
+ plane->base.base.id, plane->base.name,
+ old_wm->wm[0].plane_res_l,
old_wm->wm[1].plane_res_l,
+ old_wm->wm[2].plane_res_l,
old_wm->wm[3].plane_res_l,
+ old_wm->wm[4].plane_res_l,
old_wm->w
[Intel-gfx] [PATCH v2] drm/i915: Reacquire priolist cache after dropping the engine lock
If we drop the engine lock, we may run execlists_dequeue which may free
the priolist. Therefore if we ever drop the execution lock on the
engine, we have to discard our cache and refetch the priolist to ensure
we do not use a stale pointer.
[ 506.418935] [IGT] gem_exec_whisper: starting subtest contexts-priority
[ 593.240825] general protection fault: [#1] SMP
[ 593.240863] CPU: 1 PID: 494 Comm: gem_exec_whispe Tainted: G U
5.0.0-rc6+ #100
[ 593.240879] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0029.2016.1124.1625
11/24/2016
[ 593.240965] RIP: 0010:__i915_schedule+0x1fe/0x320 [i915]
[ 593.240981] Code: 48 8b 0c 24 48 89 c3 49 8b 45 28 49 8b 75 20 4c 89 3c 24
48 89 46 08 48 89 30 48 8b 43 08 48 89 4b 08 49 89 5d 20 49 89 45 28 <48> 89 08
45 39 a7 b8 03 00 00 7d 44 45 89 a7 b8 03 00 00 49 8b 85
[ 593.240999] RSP: 0018:c9057a60 EFLAGS: 00010046
[ 593.241013] RAX: 6b6b6b6b6b6b6b6b RBX: 8882582d7870 RCX: 88826baba6f0
[ 593.241026] RDX: RSI: 8882582d6e70 RDI: 888273482194
[ 593.241049] RBP: c9057a68 R08: 8882582d7680 R09: 8882582d7840
[ 593.241068] R10: R11: ea00095ebe08 R12: 0728
[ 593.241105] R13: 88826baba6d0 R14: c9057a40 R15: 888273482158
[ 593.241120] FS: 7f4613fb3900() GS:888277a8()
knlGS:
[ 593.241133] CS: 0010 DS: ES: CR0: 80050033
[ 593.241146] CR2: 7f57d3c66a84 CR3: 00026e2b6000 CR4: 001406e0
[ 593.241158] Call Trace:
[ 593.241233] i915_schedule+0x1f/0x30 [i915]
[ 593.241326] i915_request_add+0x1a9/0x290 [i915]
[ 593.241393] i915_gem_do_execbuffer+0x45f/0x1150 [i915]
[ 593.241411] ? init_object+0x49/0x80
[ 593.241425] ? ___slab_alloc.constprop.91+0x4b8/0x4e0
[ 593.241491] ? i915_gem_execbuffer2_ioctl+0x99/0x380 [i915]
[ 593.241563] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
[ 593.241629] i915_gem_execbuffer2_ioctl+0x1bb/0x380 [i915]
[ 593.241705] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
[ 593.241724] drm_ioctl_kernel+0x81/0xd0
[ 593.241738] drm_ioctl+0x1a7/0x310
[ 593.241803] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915]
[ 593.241819] ? __update_load_avg_se+0x1c9/0x240
[ 593.241834] ? pick_next_entity+0x7e/0x120
[ 593.241851] do_vfs_ioctl+0x88/0x5d0
[ 593.241880] ksys_ioctl+0x35/0x70
[ 593.241894] __x64_sys_ioctl+0x11/0x20
[ 593.241907] do_syscall_64+0x44/0xf0
[ 593.241924] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 593.241940] RIP: 0033:0x7f4615ffe757
[ 593.241952] Code: 00 00 90 48 8b 05 39 a7 0c 00 64 c7 00 26 00 00 00 48 c7
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 09 a7 0c 00 f7 d8 64 89 01 48
[ 593.241970] RSP: 002b:7ffc1030ddf8 EFLAGS: 0246 ORIG_RAX:
0010
[ 593.241984] RAX: ffda RBX: 7ffc10324420 RCX: 7f4615ffe757
[ 593.241997] RDX: 7ffc1030e220 RSI: 40406469 RDI: 0003
[ 593.242010] RBP: 7ffc1030e220 R08: 7f46160c9208 R09: 7f46160c9240
[ 593.242022] R10: R11: 0246 R12: 40406469
[ 593.242038] R13: 0003 R14: R15:
[ 593.242058] Modules linked in: i915 intel_gtt drm_kms_helper prime_numbers
v2: Track the local engine cache and explicitly clear it when switching
engine locks.
Fixes: a02eb975be78 ("drm/i915/execlists: Cache the priolist when rescheduling")
Testcase: igt/gem_exec_whisper/contexts-priority # rare!
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index d01683167c77..8bc042551692 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -223,8 +223,14 @@ i915_sched_lookup_priolist(struct intel_engine_cs *engine,
int prio)
return &p->requests[idx];
}
+struct sched_cache {
+ struct list_head *priolist;
+};
+
static struct intel_engine_cs *
-sched_lock_engine(struct i915_sched_node *node, struct intel_engine_cs *locked)
+sched_lock_engine(const struct i915_sched_node *node,
+ struct intel_engine_cs *locked,
+ struct sched_cache *cache)
{
struct intel_engine_cs *engine = node_to_request(node)->engine;
@@ -232,6 +238,7 @@ sched_lock_engine(struct i915_sched_node *node, struct
intel_engine_cs *locked)
if (engine != locked) {
spin_unlock(&locked->timeline.lock);
+ memset(cache, 0, sizeof(*cache));
spin_lock(&engine->timeline.lock);
}
@@ -253,11 +260,11 @@ static bool inflight(const struct i915_request *rq,
static void __i915_schedule(struct
Re: [Intel-gfx] [PULL] topic/component-typed
On Mon, Feb 11, 2019 at 08:18:04PM +0100, Daniel Vetter wrote: > On Mon, Feb 11, 2019 at 7:57 PM Takashi Iwai wrote: > > > > On Mon, 11 Feb 2019 19:25:12 +0100, > > Sam Ravnborg wrote: > > > > > > Hi Daniel. > > > > > > On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote: > > > > Hi all, > > > > > > > > Here's the typed component topic branch. > > > > > > > > drm-intel maintainers: Please pull, I need this for the mei hdcp work > > > > from Ram. > > > > > > > > drm-misc maintainers: Please pull, there's a drm doc patch follow-up > > > > that I want to stuff into drm-misc-next. > > > > > > > > Greg: The drm side missed our feature cutoff, so will only land in 5.2. > > > > > > With all the dependencies why not bend the rule a little and get this in > > > now? > > > It is not like this is a huge patchset. > > > > Yeah, that's likely the most straightforward way. > > > > BTW, I tried to pull onto sound git tree for-next branch, and it > > worked without conflicts. So I don't think it needs to be pulled onto > > mine. > > Yeah right now it's all conflict free, I'm more worried about what's > going to happen the next 3 months. That's also why I think it'd be > good if Greg can pull this still. Ok, I've pulled this into my branch, it should go into 5.1-rc1. thanks, greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
== Series Details ==
Series: series starting with [1/2] drm/i915: Pull sync_scru for device reset
outside of wedge_mutex
URL : https://patchwork.freedesktop.org/series/56496/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5588_full -> Patchwork_12194_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12194_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-hsw: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-c-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-apl: PASS -> FAIL [fdo#103166] +1
Possible fixes
* igt@gem_eio@unwedge-stress:
- shard-snb: FAIL [fdo#107799] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-kbl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_cursor_crc@cursor-64x21-onscreen:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_legacy@all-pipes-torture-move:
- shard-hsw: DMESG-WARN [fdo#107122] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_setmode@basic:
- shard-glk: FAIL [fdo#99912] -> PASS
Warnings
* igt@i915_suspend@shrink:
- shard-glk: INCOMPLETE [fdo#103359] / [fdo#106886] /
[k.org#198133] -> DMESG-WARN [fdo#109244]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[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#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
[fdo#107122]: https://bugs.freedesktop.org/show_bug.cgi?id=107122
[fdo#107799]: https://bugs.freedesktop.org/show_bug.cgi?id=107799
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#109244]: https://bugs.freedesktop.org/show_bug.cgi?id=109244
[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
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5588 -> Patchwork_12194
CI_DRM_5588: 133ed6b29f62713f2edd95eac6ccc2ae1d6e4d6e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4816: f62577c85c9ef0539d468d6fad105b706a15139c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12194: 956ea687c738a4d9a9facc967f137a305c41a00f @
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_12194/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/component-typed
On Mon, Feb 11, 2019 at 7:57 PM Takashi Iwai wrote: > > On Mon, 11 Feb 2019 19:25:12 +0100, > Sam Ravnborg wrote: > > > > Hi Daniel. > > > > On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote: > > > Hi all, > > > > > > Here's the typed component topic branch. > > > > > > drm-intel maintainers: Please pull, I need this for the mei hdcp work > > > from Ram. > > > > > > drm-misc maintainers: Please pull, there's a drm doc patch follow-up > > > that I want to stuff into drm-misc-next. > > > > > > Greg: The drm side missed our feature cutoff, so will only land in 5.2. > > > > With all the dependencies why not bend the rule a little and get this in > > now? > > It is not like this is a huge patchset. > > Yeah, that's likely the most straightforward way. > > BTW, I tried to pull onto sound git tree for-next branch, and it > worked without conflicts. So I don't think it needs to be pulled onto > mine. Yeah right now it's all conflict free, I'm more worried about what's going to happen the next 3 months. That's also why I think it'd be good if Greg can pull this still. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
Quoting Patchwork (2019-02-11 19:38:40) > == Series Details == > > Series: series starting with [1/2] drm/i915: Pull sync_scru for device reset > outside of wedge_mutex > URL : https://patchwork.freedesktop.org/series/56496/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_5588_full -> Patchwork_12194_full > > > Summary > --- > > **SUCCESS** > > No regressions found. Not mentioned was that this didn't fix the hang. Nevertheless, it should prevent one corner case from ending up in a deadlock, and it does mean that the srcu is not responsible for the timeout here. The mystery remains exactly what is. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Show the GEM trace if reset times out
As a debug aide for CI, include the GEM trace up to the point the reset times out to try and work out where/why it is timing out. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_reset.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c index c1b53533ada6..09bacaaedbcb 100644 --- a/drivers/gpu/drm/i915/i915_reset.c +++ b/drivers/gpu/drm/i915/i915_reset.c @@ -1356,6 +1356,7 @@ static void i915_wedge_me(struct work_struct *work) dev_err(w->i915->drm.dev, "%s timed out, cancelling all in-flight rendering.\n", w->name); + GEM_TRACE_DUMP(); i915_gem_set_wedged(w->i915); } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reacquire priolist cache after dropping the engine lock (rev3)
== Series Details ==
Series: drm/i915: Reacquire priolist cache after dropping the engine lock (rev3)
URL : https://patchwork.freedesktop.org/series/56501/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5590 -> Patchwork_12198
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56501/revisions/3/mbox/
Known issues
Here are the changes found in Patchwork_12198 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] -> PASS
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: FAIL [fdo#108511] -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: FAIL [fdo#103182] -> 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#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#109226]: https://bugs.freedesktop.org/show_bug.cgi?id=109226
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Participating hosts (47 -> 40)
--
Additional (1): fi-skl-6700hq
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-cfl-guc fi-ctg-p8600 fi-kbl-7560u fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5590 -> Patchwork_12198
CI_DRM_5590: c853cc6da5214a4b6aca74bb7481cb691126697a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4817: 08cdb644686629dcf968c6cc00e054ed5f5aae6a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12198: 303076c1c9bc29dac1457c48db1c547d9e383a39 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
303076c1c9bc drm/i915: Reacquire priolist cache after dropping the engine lock
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12198/
___
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: Show the GEM trace if reset times out
== Series Details ==
Series: drm/i915: Show the GEM trace if reset times out
URL : https://patchwork.freedesktop.org/series/56512/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5590 -> Patchwork_12199
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56512/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12199 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965]
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182] +1
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#109485]
Possible fixes
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: FAIL [fdo#108511] -> PASS
- {fi-icl-y}: INCOMPLETE -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: FAIL [fdo#103182] -> 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#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (47 -> 42)
--
Additional (1): fi-skl-6700hq
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5590 -> Patchwork_12199
CI_DRM_5590: c853cc6da5214a4b6aca74bb7481cb691126697a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4817: 08cdb644686629dcf968c6cc00e054ed5f5aae6a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12199: 046ca4fd5e0cf224b09bfc3a069f07577fbb1948 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
046ca4fd5e0c drm/i915: Show the GEM trace if reset times out
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12199/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Reacquire priolist cache after dropping the engine lock (rev3)
== Series Details ==
Series: drm/i915: Reacquire priolist cache after dropping the engine lock (rev3)
URL : https://patchwork.freedesktop.org/series/56501/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5590_full -> Patchwork_12198_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12198_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@unwedge-stress:
- shard-snb: PASS -> FAIL [fdo#107799]
* igt@gem_mmap_gtt@hang:
- shard-kbl: PASS -> INCOMPLETE [fdo#103665] / [fdo#109605 ]
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232] +2
* igt@kms_flip@2x-plain-flip-ts-check-interruptible:
- shard-glk: PASS -> FAIL [fdo#100368]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166] +3
* igt@kms_plane_multiple@atomic-pipe-a-tiling-yf:
- shard-glk: PASS -> FAIL [fdo#103166]
Possible fixes
* igt@gem_mmap_gtt@hang:
- shard-hsw: INCOMPLETE [fdo#103540] / [fdo#109605 ] -> PASS
* igt@kms_color@pipe-b-ctm-max:
- shard-apl: FAIL [fdo#108147] -> PASS
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-apl: FAIL [fdo#103232] -> PASS +5
* igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-apl: FAIL [fdo#109350] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
- shard-apl: FAIL [fdo#103167] -> PASS
* igt@kms_plane@pixel-format-pipe-c-planes:
- shard-glk: FAIL [fdo#103166] -> PASS +1
* igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-apl: FAIL [fdo#103166] -> PASS +2
* igt@kms_setmode@basic:
- shard-apl: FAIL [fdo#99912] -> PASS
* igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
- shard-kbl: INCOMPLETE [fdo#103665] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[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#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#107799]: https://bugs.freedesktop.org/show_bug.cgi?id=107799
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109350]: https://bugs.freedesktop.org/show_bug.cgi?id=109350
[fdo#109605 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109605
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5590 -> Patchwork_12198
CI_DRM_5590: c853cc6da5214a4b6aca74bb7481cb691126697a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4817: 08cdb644686629dcf968c6cc00e054ed5f5aae6a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12198: 303076c1c9bc29dac1457c48db1c547d9e383a39 @
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_12198/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
