Re: [Intel-gfx] [PATCH v2] drm/i915: Pass down rc in intel_encoder->compute_config()
On Tue, 15 Jan 2019, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that means we have the potential to hit a normal modeset
> deadlock. However, because ->compute_config() only returns a bool this
> means we can't return -EDEADLK when we need to drop locks and try again
> which means we end up just failing the atomic check permanently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Changes since v1:
> * Add some newlines
> * Return only -EINVAL from hsw_crt_compute_config()
> * Propogate return code from intel_dp_compute_dsc_params()
> * Change all of the intel_dp_compute_link_config*() variants
> * Don't miss if (hdmi_port_clock_valid()) branch in
> intel_hdmi_compute_config()
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 8 ++--
> drivers/gpu/drm/i915/intel_crt.c | 35 +++---
> drivers/gpu/drm/i915/intel_ddi.c | 6 +--
> drivers/gpu/drm/i915/intel_display.c | 11 +++--
> drivers/gpu/drm/i915/intel_dp.c | 71 +++-
> drivers/gpu/drm/i915/intel_dp_mst.c | 12 ++---
> drivers/gpu/drm/i915/intel_drv.h | 18 +++
> drivers/gpu/drm/i915/intel_dvo.c | 11 +++--
> drivers/gpu/drm/i915/intel_hdmi.c| 14 +++---
> drivers/gpu/drm/i915/intel_lvds.c| 12 ++---
> drivers/gpu/drm/i915/intel_sdvo.c| 14 +++---
> drivers/gpu/drm/i915/intel_tv.c | 8 ++--
> drivers/gpu/drm/i915/vlv_dsi.c | 14 +++---
> 13 files changed, 122 insertions(+), 112 deletions(-)
Despite being an all i915 patch, this got applied to drm-misc-next,
causing conflicts where there really should have been none. :(
I am tempted to suggest reverting and re-applying to drm-intel, because
it will take weeks to sync both to drm-next and backmerge, and applying
further work on top in drm-intel will just cause more trouble.
Other ideas?
BR,
Jani.
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index f3a5f03646ce..355b48d1c937 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
> *encoder,
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
> }
>
> -static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int gen11_dsi_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
> base);
> @@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct
> intel_encoder *encoder,
> pipe_config->clock_set = true;
> pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
>
> - return true;
> + return 0;
> }
>
> static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 33bd2addcbdd..081c333f30d2 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -345,51 +345,52 @@ intel_crt_mode_valid(struct drm_connector *connector,
> return MODE_OK;
> }
>
> -static bool intel_crt_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int intel_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode =
> _config->base.adjusted_mode;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return false;
> + return -EINVAL;
>
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> - return true;
> +
> + return 0;
> }
>
> -static bool pch_crt_compute_config(struct intel_encoder *encoder,
> -struct intel_crtc_state *pipe_config,
> -struct drm_connector_state *conn_state)
>
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: Fix error handling of mutex_lock_killable()
== Series Details == Series: drm/i915/userptr: Fix error handling of mutex_lock_killable() URL : https://patchwork.freedesktop.org/series/55267/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5430_full -> Patchwork_11303_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11303_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11303_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_11303_full: ### IGT changes ### Possible regressions * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-kbl: PASS -> DMESG-WARN Known issues Here are the changes found in Patchwork_11303_full that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries_display_off: - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] * igt@gem_exec_schedule@pi-ringfull-render: - shard-glk: NOTRUN -> FAIL [fdo#103158] - shard-apl: NOTRUN -> FAIL [fdo#103158] - shard-kbl: NOTRUN -> FAIL [fdo#103158] - shard-iclb: NOTRUN -> FAIL [fdo#103158] * igt@gem_userptr_blits@readonly-unsync: - shard-skl: NOTRUN -> TIMEOUT [fdo#108887] * igt@gem_workarounds@suspend-resume-fd: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] - shard-iclb: PASS -> INCOMPLETE [fdo#107713] * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-snb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_ccs@pipe-a-crc-primary-rotation-180: - shard-iclb: NOTRUN -> FAIL [fdo#107725] * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145] * igt@kms_chv_cursor_fail@pipe-a-128x128-left-edge: - shard-skl: NOTRUN -> FAIL [fdo#104671] * igt@kms_content_protection@atomic: - shard-kbl: NOTRUN -> FAIL [fdo#108597] - shard-apl: NOTRUN -> FAIL [fdo#108597] +1 * igt@kms_cursor_crc@cursor-256x256-random: - shard-apl: PASS -> FAIL [fdo#103232] +3 * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_crc@cursor-256x85-sliding: - shard-glk: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x64-onscreen: - shard-skl: NOTRUN -> FAIL [fdo#103232] - shard-iclb: NOTRUN -> FAIL [fdo#103232] +1 - shard-apl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: PASS -> FAIL [fdo#104873] * igt@kms_fbcon_fbt@psr: - shard-iclb: NOTRUN -> FAIL [fdo#107882] * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: NOTRUN -> FAIL [fdo#107882] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-iclb: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-blt: - shard-glk: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-skl: NOTRUN -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-blt: - shard-skl: NOTRUN -> FAIL [fdo#103167] +6 * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb: - shard-glk: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb: - shard-kbl: NOTRUN -> FAIL [fdo#108145] +1 - shard-apl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] +1 - shard-iclb: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf: - shard-iclb: NOTRUN -> FAIL [fdo#103166] * igt@kms_rmfb@rmfb-ioctl: - shard-iclb: PASS -> DMESG-WARN
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Move intel_execlists_show_requests() aside
== Series Details == Series: drm/i915: Move intel_execlists_show_requests() aside URL : https://patchwork.freedesktop.org/series/55265/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5430_full -> Patchwork_11302_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11302_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11302_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_11302_full: ### IGT changes ### Possible regressions * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup: - shard-skl: NOTRUN -> INCOMPLETE * igt@pm_rpm@gem-mmap-gtt: - shard-iclb: PASS -> INCOMPLETE Known issues Here are the changes found in Patchwork_11302_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_cpu_reloc@full: - shard-skl: NOTRUN -> TIMEOUT [fdo#108248] * igt@gem_softpin@noreloc-s3: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] * igt@gem_tiled_swapping@non-threaded: - shard-skl: PASS -> DMESG-WARN [fdo#108686] * igt@gem_userptr_blits@map-fixed-invalidate-gup: - shard-snb: PASS -> INCOMPLETE [fdo#105411] * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup: - shard-kbl: PASS -> INCOMPLETE [fdo#103665] * igt@gem_userptr_blits@map-fixed-invalidate-overlap-gup: - shard-hsw: PASS -> INCOMPLETE [fdo#103540] +1 * igt@kms_atomic@test_only: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +11 * igt@kms_atomic_transition@plane-all-transition: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#109225] * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +2 * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-snb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145] +1 - shard-glk: PASS -> FAIL [fdo#108145] * igt@kms_cursor_crc@cursor-64x21-sliding: - shard-apl: PASS -> FAIL [fdo#103232] +2 * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-ytiled: - shard-skl: NOTRUN -> FAIL [fdo#103184] * igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled: - shard-iclb: PASS -> WARN [fdo#108336] * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: NOTRUN -> FAIL [fdo#107882] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-iclb: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +3 * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-skl: NOTRUN -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-blt: - shard-skl: NOTRUN -> FAIL [fdo#103167] +3 * igt@kms_frontbuffer_tracking@fbcpsr-stridechange: - shard-iclb: PASS -> FAIL [fdo#105683] / [fdo#108040] * igt@kms_frontbuffer_tracking@fbcpsr-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#106978] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +4 * igt@kms_panel_fitting@legacy: - shard-skl: NOTRUN -> FAIL [fdo#105456] * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-iclb: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] +2 * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> DMESG-FAIL [fdo#108950] * igt@kms_rotation_crc@primary-rotation-270: - shard-skl: NOTRUN -> FAIL [fdo#103925] / [fdo#107815] * igt@kms_setmode@basic: - shard-apl: PASS -> FAIL [fdo#99912] - shard-skl: NOTRUN -> FAIL [fdo#99912] * igt@pm_backlight@fade_with_suspend: - shard-skl: NOTRUN -> FAIL [fdo#107847] * igt@pm_rpm@basic-pci-d3-state: - shard-iclb: PASS -> DMESG-WARN [fdo#108654] * igt@pm_rpm@universal-planes: -
Re: [Intel-gfx] [PATCH] drm: Split out drm_probe_helper.h
On Tue, Jan 15, 2019 at 5:41 AM Daniel Vetter wrote: > > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. > > v2: Make it compile. There was so much compile fail on arm drivers > that I figured I'll better not include any of the acks on v1. > > v3: Massive rebase because i915 has lost a lot of drmP.h includes, but > not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h > there was still one, which this patch largely removes. Which means > rolling out lots more includes all over. > > This will also conflict with ongoing drmP.h cleanup by others I > expect. > > v3: Rebase on top of atomic bochs. > > Cc: Sam Ravnborg > Cc: Jani Nikula > Cc: Laurent Pinchart > Acked-by: Rodrigo Vivi (v2) > Acked-by: Benjamin Gaignard (v2) > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: etna...@lists.freedesktop.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-gfx@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-te...@vger.kernel.org > Cc: xen-de...@lists.xen.org > --- > Merging this is going to be a bit a mess due to all the ongoing drmP.h > cleanups. I think the following should work: > - Apply Sam's prep patches for removing drmP.h from > drm_modeset_helper.h > - Get the i915 drmP.h cleanup backmerged into drm-misc-next > - Apply this patch. > - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h > - All through drm-misc-next, which has some potential for trivial > conflicts around #includes with other drivers unfortunately. > > I hope there's no other driver who'll blow up accidentally because > someone else is doing a drmP.h cleanup. Laurent maybe? > > Jani, ack on this? > -Daniel amdgpu and radeon: Acked-by: Alex Deucher ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Pass down rc in intel_encoder->compute_config() (rev2)
== Series Details == Series: drm/i915: Pass down rc in intel_encoder->compute_config() (rev2) URL : https://patchwork.freedesktop.org/series/55203/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5429_full -> Patchwork_11301_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11301_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11301_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_11301_full: ### IGT changes ### Possible regressions * igt@gem_userptr_blits@map-fixed-invalidate-busy: - shard-skl: NOTRUN -> INCOMPLETE +1 * igt@gem_userptr_blits@map-fixed-invalidate-gup: - shard-iclb: PASS -> INCOMPLETE - shard-skl: PASS -> INCOMPLETE * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy: - shard-iclb: NOTRUN -> INCOMPLETE * igt@kms_invalid_dotclock: - shard-glk: PASS -> DMESG-WARN Known issues Here are the changes found in Patchwork_11301_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vecs0-s3: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@gem_exec_schedule@pi-ringfull-vebox: - shard-skl: NOTRUN -> FAIL [fdo#103158] * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy: - shard-kbl: PASS -> INCOMPLETE [fdo#103665] +1 * igt@gem_userptr_blits@map-fixed-invalidate-overlap-gup: - shard-snb: PASS -> INCOMPLETE [fdo#105411] * igt@gem_userptr_blits@readonly-unsync: - shard-skl: NOTRUN -> TIMEOUT [fdo#108887] * igt@i915_suspend@shrink: - shard-apl: NOTRUN -> DMESG-WARN [fdo#107886] / [fdo#109244] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-pageflip-hang-newfb-render-c: - shard-apl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_chv_cursor_fail@pipe-b-256x256-right-edge: - shard-skl: NOTRUN -> FAIL [fdo#104671] * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-glk: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-128x42-sliding: - shard-skl: NOTRUN -> FAIL [fdo#103232] +1 * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic: - shard-apl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +6 * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: NOTRUN -> FAIL [fdo#107882] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +3 * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-apl: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt: - shard-glk: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-skl: NOTRUN -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen: - shard-iclb: NOTRUN -> FAIL [fdo#103167] * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: - shard-iclb: NOTRUN -> FAIL [fdo#108948] * igt@kms_plane@pixel-format-pipe-b-planes: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane@plane-panning-top-left-pipe-c-planes: - shard-skl: NOTRUN -> FAIL [fdo#103166] * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590] * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +2 * igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb: - shard-apl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-glk: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: - shard-apl: PASS -> FAIL [fdo#103166] - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_setmode@basic: - shard-kbl: NOTRUN -> FAIL [fdo#99912] * igt@kms_sysfs_edid_timing: - shard-apl: NOTRUN -> FAIL [fdo#100047] *
[Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm-intel tree
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_drv.h
between commits:
e845f099f1c6 ("drm/i915/dsc: Add Per connector debugfs node for DSC
support/enable")
f6bff60e927b ("drm/i915/icl: Fix HPD handling for TypeC legacy ports")
from the drm-intel tree and commit:
96550555a78c ("drm/i915: Pass down rc in intel_encoder->compute_config()")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/intel_dp.c
index 0a3ac98a779e,d18b72b5f0b8..
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -2062,11 -2055,11 +2066,12 @@@ intel_dp_compute_link_config(struct int
);
/* enable compression if the mode doesn't fit available BW */
- if (ret) {
+ DRM_DEBUG_KMS("Force DSC en = %d\n", intel_dp->force_dsc_en);
- if (!ret || intel_dp->force_dsc_en) {
- if (!intel_dp_dsc_compute_config(intel_dp, pipe_config,
-conn_state, ))
- return false;
++ if (ret || intel_dp->force_dsc_en) {
+ ret = intel_dp_dsc_compute_config(intel_dp, pipe_config,
+ conn_state, );
+ if (ret < 0)
+ return ret;
}
if (pipe_config->dsc_params.compression_enable) {
diff --cc drivers/gpu/drm/i915/intel_drv.h
index 5e5ceec7c004,19d9abd2666e..
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@@ -1816,10 -1805,10 +1815,10 @@@ void intel_dp_sink_set_decompression_st
bool enable);
void intel_dp_encoder_reset(struct drm_encoder *encoder);
void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
-void intel_dp_encoder_destroy(struct drm_encoder *encoder);
+void intel_dp_encoder_flush_work(struct drm_encoder *encoder);
- bool intel_dp_compute_config(struct intel_encoder *encoder,
-struct intel_crtc_state *pipe_config,
-struct drm_connector_state *conn_state);
+ int intel_dp_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state);
bool intel_dp_is_edp(struct intel_dp *intel_dp);
bool intel_dp_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port,
pgpzI5Z66v3ay.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD
On Tue, Jan 08, 2019 at 12:32:05PM -0800, Kenneth Graunke wrote: > On Tuesday, January 8, 2019 7:53:05 AM PST Joonas Lahtinen wrote: > > + Ken/Jason for Mesa > > Quoting Matt Roper (2019-01-07 21:19:31) > > > On Mon, Jan 07, 2019 at 01:23:50PM +0100, Michał Winiarski wrote: > > > > On Mon, Jan 07, 2019 at 01:01:16PM +0200, Joonas Lahtinen wrote: > > > > > Quoting José Roberto de Souza (2019-01-04 19:37:00) > > > > > > According to Workaround database ICL also needs > > > > > > WaEnablePreemptionGranularityControlByUMD, to allow userspace to do > > > > > > fine-granularity preemptions per-context. > > > > > > > > > > I must wonder where is the userspace component that needs this, and > > > > > why > > > > > it hasn't been noticed earlier? > > > > > > > > > > Or is this one more of the cases when no userspace actually uses the > > > > > register? > > > > > > > > It's used: > > > > https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/brw_state_upload.c#L64 > > > > > > > > -Michał > > > > > > Wasn't this just an artificial i915-only workaround that was added to > > > prevent breakage of pre-preemption UMD's? Initial gen9 driver releases > > > didn't support preemption, so when preemption support did get added to > > > i915, the kernel had to force object-level off by default at context > > > creation to avoid breaking old userspace that didn't build batch buffers > > > with all the necessary preemption workarounds. This CS_CHICKEN1 > > > register was then exposed to userspace so that newer, preemption-aware > > > userspace could opt back in if it properly supported preemption. It's not only that userspace didn't build proper batch buffers with the necessary workarounds, but that most of the workarounds required disabling preemption depending on the type of primitive being drawn. So userspace needed access to CS_CHICKEN1 to be able to enable/disable preemption for those. > > > For gen11, there shouldn't be any "old" userspace around that doesn't > > > support preemption, so shouldn't the kernel just leave object-level > > > preemption enabled by default (meaning there's no need to expose this > > > register to userspace to allow it to explicitly opt-in)? > > > > Makes sense to me. We should have known by know if somebody expects to > > control the register, because they would be failing to do so. > > > > Mesa could also drop the register load for Gen11+ > > > > Regards, Joonas > > + Rafael, as he's done all the preemption work in Mesa. > > That seems reasonable to me. It looks like i965 always enables > mid-object preemption (sets CS_CHICKEN1 bit 0) on Gen10+, and never > disables it. You can probably safely turn it on by default, and we > can stop writing the register altogether. Yeah, I noticed this after re-reading some other thread, right after we got the preemption patches merged. On gen11, we have some workarounds but they don't require us to disable preemption through CS_CHICKEN1, so it should be safe for the kernel to not whitelist or disable it. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 42/46] drm/i915: Enlarge vma->pin_count
On 1/15/2019 12:17, Chris Wilson wrote:
Quoting John Harrison (2019-01-15 19:57:19)
On 1/7/2019 03:55, Chris Wilson wrote:
Previously we only accommodated having a vma pinned by a small number of
users, with the maximum being pinned for use by the display engine. As
such, we used a small bitfield only large enough to allow the vma to
be pinned twice (for back/front buffers) in each scanout plane. Keeping
the maximum permissible pin_count small allows us to quickly catch a
potential leak. However, as we want to split a 4096B page into 64
different cachelines and pin each cacheline for use by a different
timeline, we will exceed the current maximum permissible vma->pin_count
and so time has come to enlarge it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +-
drivers/gpu/drm/i915/i915_vma.h | 28 +---
2 files changed, 22 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index bd679c8c56dd..03ade71b8d9a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -642,19 +642,19 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
/* Flags used by pin/bind */
#define PIN_NONBLOCKBIT_ULL(0)
-#define PIN_MAPPABLE BIT_ULL(1)
-#define PIN_ZONE_4G BIT_ULL(2)
-#define PIN_NONFAULT BIT_ULL(3)
-#define PIN_NOEVICT BIT_ULL(4)
-
-#define PIN_MBZ BIT_ULL(5) /* I915_VMA_PIN_OVERFLOW */
-#define PIN_GLOBAL BIT_ULL(6) /* I915_VMA_GLOBAL_BIND */
-#define PIN_USER BIT_ULL(7) /* I915_VMA_LOCAL_BIND */
-#define PIN_UPDATE BIT_ULL(8)
-
-#define PIN_HIGH BIT_ULL(9)
-#define PIN_OFFSET_BIAS BIT_ULL(10)
-#define PIN_OFFSET_FIXED BIT_ULL(11)
+#define PIN_NONFAULT BIT_ULL(1)
+#define PIN_NOEVICT BIT_ULL(2)
+#define PIN_MAPPABLE BIT_ULL(3)
+#define PIN_ZONE_4G BIT_ULL(4)
+#define PIN_HIGH BIT_ULL(5)
+#define PIN_OFFSET_BIAS BIT_ULL(6)
+#define PIN_OFFSET_FIXED BIT_ULL(7)
+
+#define PIN_MBZ BIT_ULL(8) /* I915_VMA_PIN_OVERFLOW */
+#define PIN_GLOBAL BIT_ULL(9) /* I915_VMA_GLOBAL_BIND */
+#define PIN_USER BIT_ULL(10) /* I915_VMA_LOCAL_BIND */
+#define PIN_UPDATE BIT_ULL(11)
+
The upper bits need moving to accommodate the larger count. And the
HIGH/OFFSET_* fields are not shared with vma-flags so can be moved down
with the other pin only flags. But I don't see a reason to shuffle the
lower bits around? MAPPABLE to NOEVICT were 1,2,3,4 but are now 3,4,1,2.
Is there some semantic meaning to the new order?
Just that:
- bias, mappable, zone_4g: address limit specifiers
+ high: not strictly an address limit, but an address direction to search
+ fixed: address override, limits still apply though
- nonblock, nonfault, noevict: search specifiers
I just hadn't had an excuse to reorder them for a while.
Fair enough. I just wanted to check it was deliberate and not some
accidental remnant of some other change that was dropped along the way.
#define PIN_OFFSET_MASK (-I915_GTT_PAGE_SIZE)
#endif
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 7252abc73d3e..266b226ebef2 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -70,30 +70,20 @@ struct i915_vma {
*/
unsigned int open_count;
unsigned long flags;
- /**
- * How many users have pinned this object in GTT space. The following
- * users can each hold at most one reference: pwrite/pread, execbuffer
- * (objects are not allowed multiple times for the same batchbuffer),
- * and the framebuffer code. When switching/pageflipping, the
- * framebuffer code has at most two buffers pinned per crtc.
- *
- * In the worst case this is 1 + 1 + 1 + 2*2 = 7. That would fit into 3
- * bits with absolutely no headroom. So use 4 bits.
- */
Is it not worth keeping some comment about the maximum pin count being
bounded so 8-bits is guaranteed to be sufficient? Also, is the old
comment actually valid? Surely modern hardware has more than two CRTCs
so the limit of 7 was wrong anyway? Maybe even have a compile time
assert that the mask size is greater than max(1 + 1 + 1 + 1 +
2*MAX_CRTC, PAGE_SIZE/CACHELINE_SIZE)?
Is a comment accurate? rotfl
One can but dream...
Also I think we are up to 3*NUM_PLANES*NUM_CRTCS, but can't be quite sure
with the atomic state tracking, so it might just be still 2 (but just
wait until we have an actual flip queue).
That sounds like we should already be overflowing the current limit of 16?!
I was also wondering if we used 7b + negative byte for the overflow
would generate better code.
Meaning limit the count to 127 and use a signed char cast? Thus
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/userptr: Fix error handling of mutex_lock_killable()
== Series Details ==
Series: drm/i915/userptr: Fix error handling of mutex_lock_killable()
URL : https://patchwork.freedesktop.org/series/55267/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5430 -> Patchwork_11303
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55267/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_11303 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: NOTRUN -> FAIL [fdo#103167]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: NOTRUN -> FAIL [fdo#103191] / [fdo#107362]
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> 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#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
[fdo#109241]: https://bugs.freedesktop.org/show_bug.cgi?id=109241
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (46 -> 44)
--
Additional (2): fi-icl-y fi-byt-clapper
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5430 -> Patchwork_11303
CI_DRM_5430: 19fd97ec0d642516406be0e69280b2136f5399e9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4773: 951e2b1a016b750544d0f42459b13b9c70631c68 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11303: 80a20cff9c6b72f2121fc4db3a596ddf49c8f3d6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
80a20cff9c6b drm/i915/userptr: Fix error handling of mutex_lock_killable()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11303/
___
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: Move intel_execlists_show_requests() aside
== Series Details ==
Series: drm/i915: Move intel_execlists_show_requests() aside
URL : https://patchwork.freedesktop.org/series/55265/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5430 -> Patchwork_11302
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55265/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_11302 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-byt-clapper: NOTRUN -> FAIL [fdo#107362]
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> 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#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
[fdo#109241]: https://bugs.freedesktop.org/show_bug.cgi?id=109241
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (46 -> 43)
--
Additional (2): fi-icl-y fi-byt-clapper
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-glk-j4005
Build changes
-
* Linux: CI_DRM_5430 -> Patchwork_11302
CI_DRM_5430: 19fd97ec0d642516406be0e69280b2136f5399e9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4773: 951e2b1a016b750544d0f42459b13b9c70631c68 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11302: 3b9c12a069827f4843235e04b394a2c43546335e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3b9c12a06982 drm/i915: Move intel_execlists_show_requests() aside
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11302/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/userptr: Fix error handling of mutex_lock_killable()
mutex_lock_killable() returns -EINTR on failure, not the anticipate bool
return like trylock. (Oh no, not again.)
Fixes: 484d9a844d0d ("drm/i915/userptr: Avoid struct_mutex recursion for
mmu_invalidate_range_start")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 38e19a42e0f4..1d3f9a31ad61 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -150,7 +150,7 @@ userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
switch (mutex_trylock_recursive(unlock)) {
default:
case MUTEX_TRYLOCK_FAILED:
- if (!mutex_lock_killable_nested(unlock,
I915_MM_SHRINKER)) {
+ if (mutex_lock_killable_nested(unlock,
I915_MM_SHRINKER)) {
i915_gem_object_put(obj);
return -EINTR;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Move intel_execlists_show_requests() aside
Move the debug pretty printer into a standalone routine prior to
extending it in upcoming feature work.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 55 ++--
drivers/gpu/drm/i915/intel_lrc.c | 58 ++
drivers/gpu/drm/i915/intel_lrc.h | 10 -
3 files changed, 71 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index bf4dae2649ab..8a3fa4a9f66e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1422,15 +1422,12 @@ void intel_engine_dump(struct intel_engine_cs *engine,
struct drm_printer *m,
const char *header, ...)
{
- const int MAX_REQUESTS_TO_SHOW = 8;
struct intel_breadcrumbs * const b = >breadcrumbs;
- const struct intel_engine_execlists * const execlists =
>execlists;
struct i915_gpu_error * const error = >i915->gpu_error;
- struct i915_request *rq, *last;
+ struct i915_request *rq;
intel_wakeref_t wakeref;
unsigned long flags;
struct rb_node *rb;
- int count;
if (header) {
va_list ap;
@@ -1494,52 +1491,9 @@ void intel_engine_dump(struct intel_engine_cs *engine,
drm_printf(m, "\tDevice is asleep; skipping register dump\n");
}
- local_irq_save(flags);
- spin_lock(>timeline.lock);
-
- last = NULL;
- count = 0;
- list_for_each_entry(rq, >timeline.requests, link) {
- if (count++ < MAX_REQUESTS_TO_SHOW - 1)
- print_request(m, rq, "\t\tE ");
- else
- last = rq;
- }
- if (last) {
- if (count > MAX_REQUESTS_TO_SHOW) {
- drm_printf(m,
- "\t\t...skipping %d executing requests...\n",
- count - MAX_REQUESTS_TO_SHOW);
- }
- print_request(m, last, "\t\tE ");
- }
-
- last = NULL;
- count = 0;
- drm_printf(m, "\t\tQueue priority: %d\n", execlists->queue_priority);
- for (rb = rb_first_cached(>queue); rb; rb = rb_next(rb)) {
- struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
- int i;
-
- priolist_for_each_request(rq, p, i) {
- if (count++ < MAX_REQUESTS_TO_SHOW - 1)
- print_request(m, rq, "\t\tQ ");
- else
- last = rq;
- }
- }
- if (last) {
- if (count > MAX_REQUESTS_TO_SHOW) {
- drm_printf(m,
- "\t\t...skipping %d queued requests...\n",
- count - MAX_REQUESTS_TO_SHOW);
- }
- print_request(m, last, "\t\tQ ");
- }
-
- spin_unlock(>timeline.lock);
+ intel_execlists_show_requests(engine, m, print_request, 8);
- spin_lock(>rb_lock);
+ spin_lock_irqsave(>rb_lock, flags);
for (rb = rb_first(>waiters); rb; rb = rb_next(rb)) {
struct intel_wait *w = rb_entry(rb, typeof(*w), node);
@@ -1548,8 +1502,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
task_state_to_char(w->tsk),
w->seqno);
}
- spin_unlock(>rb_lock);
- local_irq_restore(flags);
+ spin_unlock_irqrestore(>rb_lock, flags);
drm_printf(m, "HWSP:\n");
hexdump(m, engine->status_page.page_addr, PAGE_SIZE);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 608458b92db3..cdc4d84900ff 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2702,6 +2702,64 @@ void intel_lr_context_resume(struct drm_i915_private
*i915)
}
}
+void intel_execlists_show_requests(struct intel_engine_cs *engine,
+ struct drm_printer *m,
+ void (*show_request)(struct drm_printer *m,
+ struct i915_request *rq,
+ const char *prefix),
+ unsigned int max)
+{
+ const struct intel_engine_execlists *execlists = >execlists;
+ struct i915_request *rq, *last;
+ unsigned long flags;
+ unsigned int count;
+ struct rb_node *rb;
+
+ spin_lock_irqsave(>timeline.lock, flags);
+
+ last = NULL;
+ count = 0;
+ list_for_each_entry(rq, >timeline.requests, link) {
+ if (count++ < max - 1)
+ show_request(m, rq, "\t\tE ");
+ else
+ last = rq;
+ }
+ if (last) {
+
[Intel-gfx] [PATCH i-g-t] i915/gem_userptr_blits: Only mlock the memfd once, not the arena
We multiply the memfd 64k to create a 2G arena which we then attempt to write into after marking read-only. Howver, when it comes to unlock the arena after the test, performance tanks as the kernel tries to resolve the 64k repeated mappings onto the same set of pages. (Must not be a very common operation!) We can get away with just mlocking the backing store to prevent its eviction, which should prevent the arena mapping from being freed as well. References: https://bugs.freedesktop.org/show_bug.cgi?id=108887 Signed-off-by: Chris Wilson --- tests/i915/gem_userptr_blits.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c index 909dd19df..c4e60ba92 100644 --- a/tests/i915/gem_userptr_blits.c +++ b/tests/i915/gem_userptr_blits.c @@ -1124,7 +1124,7 @@ static void test_readonly(int i915) *(uint32_t *)(space + offset) = offset; } igt_assert_eq_u32(*(uint32_t *)pages, (uint32_t)(total - sz)); - igt_assert(mlock(space, total) == 0); + igt_assert(mlock(pages, sz) == 0); close(memfd); /* Check we can create a normal userptr bo wrapping the wrapper */ @@ -1176,6 +1176,7 @@ static void test_readonly(int i915) } igt_waitchildren(); + munlock(pages, sz); munmap(space, total); munmap(pages, sz); } -- 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: Pass down rc in intel_encoder->compute_config() (rev2)
== Series Details ==
Series: drm/i915: Pass down rc in intel_encoder->compute_config() (rev2)
URL : https://patchwork.freedesktop.org/series/55203/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5429 -> Patchwork_11301
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55203/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_11301 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@gem_ctx_create@basic-files:
- fi-kbl-7560u: PASS -> INCOMPLETE [fdo#103665]
* igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-7500u: PASS -> DMESG-WARN [fdo#105128] / [fdo#107139]
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_selftest@live_evict:
- fi-bsw-kefka: PASS -> DMESG-WARN [fdo#107709]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
- fi-cfl-8109u: DMESG-FAIL -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: FAIL [fdo#103167] -> 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#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128
[fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109241]: https://bugs.freedesktop.org/show_bug.cgi?id=109241
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Participating hosts (46 -> 42)
--
Additional (2): fi-kbl-7567u fi-skl-6700hq
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-glk-j4005 fi-pnv-d510
Build changes
-
* Linux: CI_DRM_5429 -> Patchwork_11301
CI_DRM_5429: b3e3bcfcefbc6f14bb30d54bcadddb63593b559c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4773: 951e2b1a016b750544d0f42459b13b9c70631c68 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11301: 1238102f7caa1322838b0039bba47441a3477552 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
1238102f7caa drm/i915: Pass down rc in intel_encoder->compute_config()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11301/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Pass down rc in intel_encoder->compute_config()
On Tue, Jan 15, 2019 at 03:08:00PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that means we have the potential to hit a normal modeset
> deadlock. However, because ->compute_config() only returns a bool this
> means we can't return -EDEADLK when we need to drop locks and try again
> which means we end up just failing the atomic check permanently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Changes since v1:
> * Add some newlines
> * Return only -EINVAL from hsw_crt_compute_config()
> * Propogate return code from intel_dp_compute_dsc_params()
> * Change all of the intel_dp_compute_link_config*() variants
> * Don't miss if (hdmi_port_clock_valid()) branch in
> intel_hdmi_compute_config()
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
Patch looks great. Hopefully we got them all.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 8 ++--
> drivers/gpu/drm/i915/intel_crt.c | 35 +++---
> drivers/gpu/drm/i915/intel_ddi.c | 6 +--
> drivers/gpu/drm/i915/intel_display.c | 11 +++--
> drivers/gpu/drm/i915/intel_dp.c | 71 +++-
> drivers/gpu/drm/i915/intel_dp_mst.c | 12 ++---
> drivers/gpu/drm/i915/intel_drv.h | 18 +++
> drivers/gpu/drm/i915/intel_dvo.c | 11 +++--
> drivers/gpu/drm/i915/intel_hdmi.c| 14 +++---
> drivers/gpu/drm/i915/intel_lvds.c| 12 ++---
> drivers/gpu/drm/i915/intel_sdvo.c| 14 +++---
> drivers/gpu/drm/i915/intel_tv.c | 8 ++--
> drivers/gpu/drm/i915/vlv_dsi.c | 14 +++---
> 13 files changed, 122 insertions(+), 112 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index f3a5f03646ce..355b48d1c937 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
> *encoder,
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
> }
>
> -static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int gen11_dsi_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
> base);
> @@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct
> intel_encoder *encoder,
> pipe_config->clock_set = true;
> pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
>
> - return true;
> + return 0;
> }
>
> static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 33bd2addcbdd..081c333f30d2 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -345,51 +345,52 @@ intel_crt_mode_valid(struct drm_connector *connector,
> return MODE_OK;
> }
>
> -static bool intel_crt_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int intel_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode =
> _config->base.adjusted_mode;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return false;
> + return -EINVAL;
>
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> - return true;
> +
> + return 0;
> }
>
> -static bool pch_crt_compute_config(struct intel_encoder *encoder,
> -struct intel_crtc_state *pipe_config,
> -struct drm_connector_state *conn_state)
> +static int pch_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode
Re: [Intel-gfx] [PATCH 42/46] drm/i915: Enlarge vma->pin_count
Quoting John Harrison (2019-01-15 19:57:19)
> On 1/7/2019 03:55, Chris Wilson wrote:
> > Previously we only accommodated having a vma pinned by a small number of
> > users, with the maximum being pinned for use by the display engine. As
> > such, we used a small bitfield only large enough to allow the vma to
> > be pinned twice (for back/front buffers) in each scanout plane. Keeping
> > the maximum permissible pin_count small allows us to quickly catch a
> > potential leak. However, as we want to split a 4096B page into 64
> > different cachelines and pin each cacheline for use by a different
> > timeline, we will exceed the current maximum permissible vma->pin_count
> > and so time has come to enlarge it.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +-
> > drivers/gpu/drm/i915/i915_vma.h | 28 +---
> > 2 files changed, 22 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > index bd679c8c56dd..03ade71b8d9a 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > @@ -642,19 +642,19 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
> >
> > /* Flags used by pin/bind */
> > #define PIN_NONBLOCKBIT_ULL(0)
> > -#define PIN_MAPPABLE BIT_ULL(1)
> > -#define PIN_ZONE_4G BIT_ULL(2)
> > -#define PIN_NONFAULT BIT_ULL(3)
> > -#define PIN_NOEVICT BIT_ULL(4)
> > -
> > -#define PIN_MBZ BIT_ULL(5) /* I915_VMA_PIN_OVERFLOW */
> > -#define PIN_GLOBAL BIT_ULL(6) /* I915_VMA_GLOBAL_BIND */
> > -#define PIN_USER BIT_ULL(7) /* I915_VMA_LOCAL_BIND */
> > -#define PIN_UPDATE BIT_ULL(8)
> > -
> > -#define PIN_HIGH BIT_ULL(9)
> > -#define PIN_OFFSET_BIAS BIT_ULL(10)
> > -#define PIN_OFFSET_FIXED BIT_ULL(11)
> > +#define PIN_NONFAULT BIT_ULL(1)
> > +#define PIN_NOEVICT BIT_ULL(2)
> > +#define PIN_MAPPABLE BIT_ULL(3)
> > +#define PIN_ZONE_4G BIT_ULL(4)
> > +#define PIN_HIGH BIT_ULL(5)
> > +#define PIN_OFFSET_BIAS BIT_ULL(6)
> > +#define PIN_OFFSET_FIXED BIT_ULL(7)
> > +
> > +#define PIN_MBZ BIT_ULL(8) /* I915_VMA_PIN_OVERFLOW */
> > +#define PIN_GLOBAL BIT_ULL(9) /* I915_VMA_GLOBAL_BIND */
> > +#define PIN_USER BIT_ULL(10) /* I915_VMA_LOCAL_BIND */
> > +#define PIN_UPDATE BIT_ULL(11)
> > +
> The upper bits need moving to accommodate the larger count. And the
> HIGH/OFFSET_* fields are not shared with vma-flags so can be moved down
> with the other pin only flags. But I don't see a reason to shuffle the
> lower bits around? MAPPABLE to NOEVICT were 1,2,3,4 but are now 3,4,1,2.
> Is there some semantic meaning to the new order?
Just that:
- bias, mappable, zone_4g: address limit specifiers
+ high: not strictly an address limit, but an address direction to search
+ fixed: address override, limits still apply though
- nonblock, nonfault, noevict: search specifiers
I just hadn't had an excuse to reorder them for a while.
> > #define PIN_OFFSET_MASK (-I915_GTT_PAGE_SIZE)
> >
> > #endif
> > diff --git a/drivers/gpu/drm/i915/i915_vma.h
> > b/drivers/gpu/drm/i915/i915_vma.h
> > index 7252abc73d3e..266b226ebef2 100644
> > --- a/drivers/gpu/drm/i915/i915_vma.h
> > +++ b/drivers/gpu/drm/i915/i915_vma.h
> > @@ -70,30 +70,20 @@ struct i915_vma {
> >*/
> > unsigned int open_count;
> > unsigned long flags;
> > - /**
> > - * How many users have pinned this object in GTT space. The following
> > - * users can each hold at most one reference: pwrite/pread, execbuffer
> > - * (objects are not allowed multiple times for the same batchbuffer),
> > - * and the framebuffer code. When switching/pageflipping, the
> > - * framebuffer code has at most two buffers pinned per crtc.
> > - *
> > - * In the worst case this is 1 + 1 + 1 + 2*2 = 7. That would fit into
> > 3
> > - * bits with absolutely no headroom. So use 4 bits.
> > - */
> Is it not worth keeping some comment about the maximum pin count being
> bounded so 8-bits is guaranteed to be sufficient? Also, is the old
> comment actually valid? Surely modern hardware has more than two CRTCs
> so the limit of 7 was wrong anyway? Maybe even have a compile time
> assert that the mask size is greater than max(1 + 1 + 1 + 1 +
> 2*MAX_CRTC, PAGE_SIZE/CACHELINE_SIZE)?
Is a comment accurate? rotfl
Also I think we are up to 3*NUM_PLANES*NUM_CRTCS, but can't be quite sure
with the atomic state tracking, so it might just be still 2 (but just
wait until we have an actual flip queue).
I was also wondering if we used 7b + negative byte for the overflow
would generate better code.
Still a comment towards that this should be
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Pass down rc in intel_encoder->compute_config() (rev2)
== Series Details == Series: drm/i915: Pass down rc in intel_encoder->compute_config() (rev2) URL : https://patchwork.freedesktop.org/series/55203/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Pass down rc in intel_encoder->compute_config() -O:drivers/gpu/drm/i915/intel_dp.c:1922:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dp.c:1923:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_dp.c:1964:58: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_dp.c:1964:58: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dp.c:1965:58: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dp.c:1965:58: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Pass down rc in intel_encoder->compute_config() (rev2)
== Series Details == Series: drm/i915: Pass down rc in intel_encoder->compute_config() (rev2) URL : https://patchwork.freedesktop.org/series/55203/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1238102f7caa drm/i915: Pass down rc in intel_encoder->compute_config() -:26: WARNING:TYPO_SPELLING: 'Propogate' may be misspelled - perhaps 'Propagate'? #26: * Propogate return code from intel_dp_compute_dsc_params() -:467: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct intel_encoder *' should also have an identifier name #467: FILE: drivers/gpu/drm/i915/intel_drv.h:228: + int (*compute_config)(struct intel_encoder *, -:467: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct intel_crtc_state *' should also have an identifier name #467: FILE: drivers/gpu/drm/i915/intel_drv.h:228: + int (*compute_config)(struct intel_encoder *, -:467: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct drm_connector_state *' should also have an identifier name #467: FILE: drivers/gpu/drm/i915/intel_drv.h:228: + int (*compute_config)(struct intel_encoder *, total: 0 errors, 4 warnings, 0 checks, 622 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Pass down rc in intel_encoder->compute_config()
Something that I completely missed when implementing the new MST VCPI
atomic helpers is that with those helpers, there's technically a chance
of us having to grab additional modeset locks in ->compute_config() and
furthermore, that means we have the potential to hit a normal modeset
deadlock. However, because ->compute_config() only returns a bool this
means we can't return -EDEADLK when we need to drop locks and try again
which means we end up just failing the atomic check permanently. Whoops.
So, fix this by modifying ->compute_config() to pass down an actual
error code instead of a bool so that the atomic check can be restarted
on modeset deadlocks.
Thanks to Ville Syrjälä for pointing this out!
Changes since v1:
* Add some newlines
* Return only -EINVAL from hsw_crt_compute_config()
* Propogate return code from intel_dp_compute_dsc_params()
* Change all of the intel_dp_compute_link_config*() variants
* Don't miss if (hdmi_port_clock_valid()) branch in
intel_hdmi_compute_config()
Signed-off-by: Lyude Paul
Cc: Ville Syrjälä
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
---
drivers/gpu/drm/i915/icl_dsi.c | 8 ++--
drivers/gpu/drm/i915/intel_crt.c | 35 +++---
drivers/gpu/drm/i915/intel_ddi.c | 6 +--
drivers/gpu/drm/i915/intel_display.c | 11 +++--
drivers/gpu/drm/i915/intel_dp.c | 71 +++-
drivers/gpu/drm/i915/intel_dp_mst.c | 12 ++---
drivers/gpu/drm/i915/intel_drv.h | 18 +++
drivers/gpu/drm/i915/intel_dvo.c | 11 +++--
drivers/gpu/drm/i915/intel_hdmi.c| 14 +++---
drivers/gpu/drm/i915/intel_lvds.c| 12 ++---
drivers/gpu/drm/i915/intel_sdvo.c| 14 +++---
drivers/gpu/drm/i915/intel_tv.c | 8 ++--
drivers/gpu/drm/i915/vlv_dsi.c | 14 +++---
13 files changed, 122 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index f3a5f03646ce..355b48d1c937 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
}
-static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
-struct intel_crtc_state *pipe_config,
-struct drm_connector_state *conn_state)
+static int gen11_dsi_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
{
struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
base);
@@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct intel_encoder
*encoder,
pipe_config->clock_set = true;
pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
- return true;
+ return 0;
}
static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 33bd2addcbdd..081c333f30d2 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -345,51 +345,52 @@ intel_crt_mode_valid(struct drm_connector *connector,
return MODE_OK;
}
-static bool intel_crt_compute_config(struct intel_encoder *encoder,
-struct intel_crtc_state *pipe_config,
-struct drm_connector_state *conn_state)
+static int intel_crt_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
{
struct drm_display_mode *adjusted_mode =
_config->base.adjusted_mode;
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
- return false;
+ return -EINVAL;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
- return true;
+
+ return 0;
}
-static bool pch_crt_compute_config(struct intel_encoder *encoder,
- struct intel_crtc_state *pipe_config,
- struct drm_connector_state *conn_state)
+static int pch_crt_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
{
struct drm_display_mode *adjusted_mode =
_config->base.adjusted_mode;
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
- return false;
+ return -EINVAL;
pipe_config->has_pch_encoder = true;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
- return
Re: [Intel-gfx] [PATCH 42/46] drm/i915: Enlarge vma->pin_count
On 1/7/2019 03:55, Chris Wilson wrote:
Previously we only accommodated having a vma pinned by a small number of
users, with the maximum being pinned for use by the display engine. As
such, we used a small bitfield only large enough to allow the vma to
be pinned twice (for back/front buffers) in each scanout plane. Keeping
the maximum permissible pin_count small allows us to quickly catch a
potential leak. However, as we want to split a 4096B page into 64
different cachelines and pin each cacheline for use by a different
timeline, we will exceed the current maximum permissible vma->pin_count
and so time has come to enlarge it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +-
drivers/gpu/drm/i915/i915_vma.h | 28 +---
2 files changed, 22 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index bd679c8c56dd..03ade71b8d9a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -642,19 +642,19 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
/* Flags used by pin/bind */
#define PIN_NONBLOCK BIT_ULL(0)
-#define PIN_MAPPABLE BIT_ULL(1)
-#define PIN_ZONE_4GBIT_ULL(2)
-#define PIN_NONFAULT BIT_ULL(3)
-#define PIN_NOEVICTBIT_ULL(4)
-
-#define PIN_MBZBIT_ULL(5) /* I915_VMA_PIN_OVERFLOW */
-#define PIN_GLOBAL BIT_ULL(6) /* I915_VMA_GLOBAL_BIND */
-#define PIN_USER BIT_ULL(7) /* I915_VMA_LOCAL_BIND */
-#define PIN_UPDATE BIT_ULL(8)
-
-#define PIN_HIGH BIT_ULL(9)
-#define PIN_OFFSET_BIASBIT_ULL(10)
-#define PIN_OFFSET_FIXED BIT_ULL(11)
+#define PIN_NONFAULT BIT_ULL(1)
+#define PIN_NOEVICTBIT_ULL(2)
+#define PIN_MAPPABLE BIT_ULL(3)
+#define PIN_ZONE_4GBIT_ULL(4)
+#define PIN_HIGH BIT_ULL(5)
+#define PIN_OFFSET_BIASBIT_ULL(6)
+#define PIN_OFFSET_FIXED BIT_ULL(7)
+
+#define PIN_MBZBIT_ULL(8) /* I915_VMA_PIN_OVERFLOW */
+#define PIN_GLOBAL BIT_ULL(9) /* I915_VMA_GLOBAL_BIND */
+#define PIN_USER BIT_ULL(10) /* I915_VMA_LOCAL_BIND */
+#define PIN_UPDATE BIT_ULL(11)
+
The upper bits need moving to accommodate the larger count. And the
HIGH/OFFSET_* fields are not shared with vma-flags so can be moved down
with the other pin only flags. But I don't see a reason to shuffle the
lower bits around? MAPPABLE to NOEVICT were 1,2,3,4 but are now 3,4,1,2.
Is there some semantic meaning to the new order?
#define PIN_OFFSET_MASK (-I915_GTT_PAGE_SIZE)
#endif
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 7252abc73d3e..266b226ebef2 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -70,30 +70,20 @@ struct i915_vma {
*/
unsigned int open_count;
unsigned long flags;
- /**
-* How many users have pinned this object in GTT space. The following
-* users can each hold at most one reference: pwrite/pread, execbuffer
-* (objects are not allowed multiple times for the same batchbuffer),
-* and the framebuffer code. When switching/pageflipping, the
-* framebuffer code has at most two buffers pinned per crtc.
-*
-* In the worst case this is 1 + 1 + 1 + 2*2 = 7. That would fit into 3
-* bits with absolutely no headroom. So use 4 bits.
-*/
Is it not worth keeping some comment about the maximum pin count being
bounded so 8-bits is guaranteed to be sufficient? Also, is the old
comment actually valid? Surely modern hardware has more than two CRTCs
so the limit of 7 was wrong anyway? Maybe even have a compile time
assert that the mask size is greater than max(1 + 1 + 1 + 1 +
2*MAX_CRTC, PAGE_SIZE/CACHELINE_SIZE)?
-#define I915_VMA_PIN_MASK 0xf
-#define I915_VMA_PIN_OVERFLOW BIT(5)
+#define I915_VMA_PIN_MASK 0xff
+#define I915_VMA_PIN_OVERFLOW BIT(8)
/** Flags and address space this VMA is bound to */
-#define I915_VMA_GLOBAL_BIND BIT(6)
-#define I915_VMA_LOCAL_BINDBIT(7)
+#define I915_VMA_GLOBAL_BIND BIT(9)
+#define I915_VMA_LOCAL_BINDBIT(10)
#define I915_VMA_BIND_MASK (I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND |
I915_VMA_PIN_OVERFLOW)
-#define I915_VMA_GGTT BIT(8)
-#define I915_VMA_CAN_FENCE BIT(9)
-#define I915_VMA_CLOSEDBIT(10)
-#define I915_VMA_USERFAULT_BIT 11
+#define I915_VMA_GGTT BIT(11)
+#define I915_VMA_CAN_FENCE BIT(12)
+#define I915_VMA_CLOSEDBIT(13)
+#define I915_VMA_USERFAULT_BIT 14
#define I915_VMA_USERFAULTBIT(I915_VMA_USERFAULT_BIT)
-#define I915_VMA_GGTT_WRITEBIT(12)
+#define I915_VMA_GGTT_WRITEBIT(15)
unsigned int active_count;
Re: [Intel-gfx] [PATCH i-g-t v5 3/6] lib: Add function to hash a framebuffer
Quoting Liviu Dudau (2019-01-15 17:47:44)
> +int igt_fb_get_crc(struct igt_fb *fb, igt_crc_t *crc)
> +{
> +#define FNV1a_OFFSET_BIAS 2166136261
> +#define FNV1a_PRIME 16777619
> + uint32_t hash;
> + void *map;
> + char *ptr, *line = NULL;
> + int x, y, cpp = igt_drm_format_to_bpp(fb->drm_format) / 8;
> + uint32_t stride = calc_plane_stride(fb, 0);
> +
> + if (fb->is_dumb)
> + map = kmstest_dumb_map_buffer(fb->fd, fb->gem_handle,
> fb->size,
> + PROT_READ);
> + else
> + map = gem_mmap__gtt(fb->fd, fb->gem_handle, fb->size,
> + PROT_READ);
> + ptr = map;
> +
> + /*
> +* Framebuffers are often uncached, which can make byte-wise accesses
> +* very slow. We copy each line of the FB into a local buffer to speed
> +* up the hashing.
> +*/
> + line = malloc(stride);
> + if (!line) {
> + munmap(map, fb->size);
> + return -ENOMEM;
> + }
> +
> + hash = FNV1a_OFFSET_BIAS;
> +
> + for (y = 0; y < fb->height; y++, ptr += stride) {
> +
> + memcpy(line, ptr, stride);
igt_memcpy_from_wc() for the reasons cited above.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 43/46] drm/i915: Allocate a status page for each timeline
Quoting John Harrison (2019-01-15 18:17:21)
> On 1/15/2019 01:50, Chris Wilson wrote:
> > Quoting John Harrison (2019-01-15 00:56:13)
> >> On 1/7/2019 03:55, Chris Wilson wrote:
> >>> +static int alloc_hwsp(struct i915_timeline *timeline)
> >>> +{
> >>> + struct drm_i915_private *i915 = timeline->i915;
> >>> + struct i915_vma *vma;
> >>> + int offset;
> >>> +
> >>> + mutex_lock(>gt.timeline_lock);
> >>> +
> >>> +restart:
> >>> + offset = find_first_cacheline(i915);
> >>> + if (offset == NBITS && i915->gt.timeline_hwsp) {
> >>> + i915_vma_put(i915->gt.timeline_hwsp);
> >>> + i915->gt.timeline_hwsp = NULL;
> >>> + }
> >>> +
> >>> + vma = i915->gt.timeline_hwsp;
> >>> + if (!vma) {
> >>> + struct drm_i915_gem_object *bo;
> >>> +
> >>> + /* Drop the lock before allocations */
> >>> + mutex_unlock(>gt.timeline_lock);
> >>> +
> >>> + BUILD_BUG_ON(NBITS * CACHELINE_BYTES > PAGE_SIZE);
> >>> + bo = i915_gem_object_create_internal(i915, PAGE_SIZE);
> >>> + if (IS_ERR(bo))
> >>> + return PTR_ERR(bo);
> >>> +
> >>> + i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
> >>> +
> >>> + vma = i915_vma_instance(bo, >ggtt.vm, NULL);
> >>> + if (IS_ERR(vma))
> >>> + return PTR_ERR(vma);
> >>> +
> >>> + mutex_lock(>gt.timeline_lock);
> >>> + if (i915->gt.timeline_hwsp) {
> >>> + i915_gem_object_put(bo);
> >>> + goto restart;
> >>> + }
> >>> +
> >>> + i915->gt.timeline_hwsp = vma;
> >>> + i915->gt.timeline_free = ~0ull;
> >>> + offset = 0;
> >>> + }
> >>> +
> >>> + i915->gt.timeline_free &= ~BIT_ULL(offset);
> >>> +
> >>> + timeline->hwsp_ggtt = i915_vma_get(vma);
> >>> + timeline->hwsp_offset = offset * CACHELINE_BYTES;
> >>> +
> >>> + mutex_unlock(>gt.timeline_lock);
> >>> +
> >>> + return 0;
> >>> +}
> >> If I'm reading this correctly then gt.timeline_hwsp/free is the a cached
> >> copy of the most recently allocated but not yet filled bank of seqno
> >> locations. When it gets full, the i915->gt reference gets dropped and a
> >> new page is allocated and used up line by line. Meanwhile, each timeline
> >> has it's own private reference to the page so dropping the i915->gt
> >> reference is safe. And once the last timeline using a given page is
> >> freed, the last reference to that page will be dropped and so the page
> >> itself will also be freed. If a timeline is freed before the currently
> >> cached page is filled, then that timeline's slot will be released and
> >> re-used by the next timeline to be created.
> >>
> >> But what about the scenario of a long running system with a small but
> >> growing number of persistent tasks interspersed with many short lived
> >> tasks? In that case, you would end up with many sparsely populated pages
> >> that whose free slots will not get re-used. You could have a linked list
> >> of cached pages. When a page is filled, move it to a 'full' list. When a
> >> timeline is freed, if it's page was on the 'full' list, clear the slot
> >> and move it back to the 'available' list.
> > Yes. My thinking was a plain slab cache was a quick-and-dirty
> > improvement over a page-per-timeline. And a freelist would be the next
> > step.
> >
> >> Or is the idea that a worst case of a single page vma allocation per
> >> timeline is the least of our worries if there is an ever growing number
> >> of timelines/contexts/users in the system?
> > Nah, it was just an attempt to quickly reduce the number of allocations,
> > where the worst case of one page+vma per timeline was the starting
> > point.
> >
> > We should break this patch down into 1) one-page-per-timeline, 2) slab
> > cache, 3) free list 4) profit.
> >
> > At other times we have been wanting to be able to suballocate pages,
> > something to keep in mind would be extending this to arbitrary cacheline
> > allocations.
> The multi-stage approach sounds good. Keep things simple in this patch
> and then improve the situation later. One thing to be careful of with a
> cacheline allocator would be make sure whatever is being converted
> wasn't using full pages for security reasons. I.e. a page can be private
> to a process, a cacheline will be shared by many. I guess that would
> only really apply to allocations being passed to user land as the kernel
> is considered secure? Or can a user batch buffer write to arbitrary
> locations within the ppHWSP and thereby splat someone else's seqno?
ppHWSP, yes. But for internal allocations, only accessible via the ring
+ GGTT, should be no problem. I agree that we definitely don't want to
expose subpage sharing across the userspace boundary (all isolation
controls are only on pages and above).
If userspace wants suballocations, it can (and does) do them for
[Intel-gfx] [PATCH i-g-t v5 2/6] kms_writeback: Add initial writeback tests
From: Brian Starkey
Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and
WRITEBACK_FB_ID properties on writeback connectors, ensuring their
behaviour is correct.
Signed-off-by: Brian Starkey
[rebased and updated do_writeback_test() function to address feedback]
Signed-off-by: Liviu Dudau
---
tests/Makefile.sources | 1 +
tests/kms_writeback.c | 314 +
tests/meson.build | 1 +
3 files changed, 316 insertions(+)
create mode 100644 tests/kms_writeback.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 519eac792..4438d2165 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -90,6 +90,7 @@ TESTS_progs = \
kms_universal_plane \
kms_vblank \
kms_sequence \
+ kms_writeback \
meta_test \
perf \
perf_pmu \
diff --git a/tests/kms_writeback.c b/tests/kms_writeback.c
new file mode 100644
index 0..66ef48a6c
--- /dev/null
+++ b/tests/kms_writeback.c
@@ -0,0 +1,314 @@
+/*
+ * (C) COPYRIGHT 2017 ARM Limited. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include "igt.h"
+#include "igt_core.h"
+#include "igt_fb.h"
+
+static drmModePropertyBlobRes *get_writeback_formats_blob(igt_output_t *output)
+{
+ drmModePropertyBlobRes *blob = NULL;
+ uint64_t blob_id;
+ int ret;
+
+ ret = kmstest_get_property(output->display->drm_fd,
+ output->config.connector->connector_id,
+ DRM_MODE_OBJECT_CONNECTOR,
+
igt_connector_prop_names[IGT_CONNECTOR_WRITEBACK_PIXEL_FORMATS],
+ NULL, _id, NULL);
+ if (ret)
+ blob = drmModeGetPropertyBlob(output->display->drm_fd, blob_id);
+
+ igt_assert(blob);
+
+ return blob;
+}
+
+static bool check_writeback_config(igt_display_t *display, igt_output_t
*output)
+{
+ igt_fb_t input_fb, output_fb;
+ igt_plane_t *plane;
+ uint32_t writeback_format = DRM_FORMAT_XRGB;
+ uint64_t tiling = igt_fb_mod_to_tiling(0);
+ int width, height, ret;
+ drmModeModeInfo override_mode = {
+ .clock = 25175,
+ .hdisplay = 640,
+ .hsync_start = 656,
+ .hsync_end = 752,
+ .htotal = 800,
+ .hskew = 0,
+ .vdisplay = 480,
+ .vsync_start = 490,
+ .vsync_end = 492,
+ .vtotal = 525,
+ .vscan = 0,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ .name = {"640x480-60"},
+ };
+ igt_output_override_mode(output, _mode);
+
+ width = override_mode.hdisplay;
+ height = override_mode.vdisplay;
+
+ ret = igt_create_fb(display->drm_fd, width, height,
DRM_FORMAT_XRGB, tiling, _fb);
+ igt_assert(ret >= 0);
+
+ ret = igt_create_fb(display->drm_fd, width, height, writeback_format,
tiling, _fb);
+ igt_assert(ret >= 0);
+
+ plane = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
+ igt_plane_set_fb(plane, _fb);
+ igt_output_set_writeback_fb(output, _fb);
+
+ ret = igt_display_try_commit_atomic(display, DRM_MODE_ATOMIC_TEST_ONLY |
+ DRM_MODE_ATOMIC_ALLOW_MODESET,
NULL);
+ igt_plane_set_fb(plane, NULL);
+ igt_remove_fb(display->drm_fd, _fb);
+ igt_remove_fb(display->drm_fd, _fb);
+
+ return !ret;
+}
+
+static igt_output_t *kms_writeback_get_output(igt_display_t *display)
+{
+ int i;
+
+ for (i = 0; i < display->n_outputs; i++) {
+ igt_output_t *output = >outputs[i];
+ int j;
+
+ if
[Intel-gfx] [PATCH i-g-t v5 4/6] kms_writeback: Add writeback-check-output
From: Brian Starkey
Add a test which makes commits using the writeback connector, and
checks the output buffer hash to make sure it is/isn't written as
appropriate.
Signed-off-by: Brian Starkey
---
tests/kms_writeback.c | 124 ++
1 file changed, 124 insertions(+)
diff --git a/tests/kms_writeback.c b/tests/kms_writeback.c
index 66ef48a6c..0f20dadd2 100644
--- a/tests/kms_writeback.c
+++ b/tests/kms_writeback.c
@@ -30,6 +30,7 @@
#include "igt.h"
#include "igt_core.h"
#include "igt_fb.h"
+#include "sw_sync.h"
static drmModePropertyBlobRes *get_writeback_formats_blob(igt_output_t *output)
{
@@ -221,6 +222,116 @@ static void writeback_fb_id(igt_output_t *output,
igt_fb_t *valid_fb, igt_fb_t *
igt_assert(ret == 0);
}
+static void fill_fb(igt_fb_t *fb, double color[3])
+{
+ cairo_t *cr = igt_get_cairo_ctx(fb->fd, fb);
+ igt_assert(cr);
+
+ igt_paint_color(cr, 0, 0, fb->width, fb->height,
+ color[0], color[1], color[2]);
+}
+
+static void get_and_wait_out_fence(igt_output_t *output)
+{
+ int ret;
+
+ igt_assert(output->writeback_out_fence_fd >= 0);
+
+ ret = sync_fence_wait(output->writeback_out_fence_fd, 1000);
+ igt_assert(ret == 0);
+ close(output->writeback_out_fence_fd);
+ output->writeback_out_fence_fd = -1;
+}
+
+static void writeback_sequence(igt_output_t *output, igt_plane_t *plane,
+ igt_fb_t *in_fb, igt_fb_t *out_fbs[], int
n_commits)
+{
+ int i, color_idx = 0;
+ double in_fb_colors[2][3] = {
+ { 1.0, 0.0, 0.0 },
+ { 0.0, 1.0, 0.0 },
+ };
+ double clear_color[3] = { 1.0, 1.0, 1.0 };
+ igt_crc_t cleared_crc, out_expected;
+
+ for (i = 0; i < n_commits; i++, color_idx++) {
+ /* Change the input color each time */
+ fill_fb(in_fb, in_fb_colors[color_idx % 2]);
+
+ if (out_fbs[i]) {
+ igt_crc_t out_before;
+
+ /* Get the expected CRC */
+ fill_fb(out_fbs[i], in_fb_colors[color_idx % 2]);
+ igt_fb_get_crc(out_fbs[i], _expected);
+
+ fill_fb(out_fbs[i], clear_color);
+ if (i == 0)
+ igt_fb_get_crc(out_fbs[i], _crc);
+ igt_fb_get_crc(out_fbs[i], _before);
+ igt_assert_crc_equal(_crc, _before);
+ }
+
+ /* Commit */
+ igt_plane_set_fb(plane, in_fb);
+ igt_output_set_writeback_fb(output, out_fbs[i]);
+
+ igt_display_commit_atomic(output->display,
+ DRM_MODE_ATOMIC_ALLOW_MODESET,
+ NULL);
+ if (out_fbs[i])
+ get_and_wait_out_fence(output);
+
+ /* Make sure the old output buffer is untouched */
+ if (i > 0 && out_fbs[i - 1] && (out_fbs[i] != out_fbs[i - 1])) {
+ igt_crc_t out_prev;
+ igt_fb_get_crc(out_fbs[i - 1], _prev);
+ igt_assert_crc_equal(_crc, _prev);
+ }
+
+ /* Make sure this output buffer is written */
+ if (out_fbs[i]) {
+ igt_crc_t out_after;
+ igt_fb_get_crc(out_fbs[i], _after);
+ igt_assert_crc_equal(_expected, _after);
+
+ /* And clear it, for the next time */
+ fill_fb(out_fbs[i], clear_color);
+ }
+ }
+}
+
+static void writeback_check_output(igt_output_t *output, igt_plane_t *plane,
+ igt_fb_t *input_fb, igt_fb_t *output_fb)
+{
+ igt_fb_t *out_fbs[2] = { 0 };
+ igt_fb_t second_out_fb;
+ int ret;
+
+ /* One commit, with a writeback. */
+ writeback_sequence(output, plane, input_fb, _fb, 1);
+
+ /* Two commits, the second with no writeback */
+ out_fbs[0] = output_fb;
+ writeback_sequence(output, plane, input_fb, out_fbs, 2);
+
+ /* Two commits, both with writeback */
+ out_fbs[1] = output_fb;
+ writeback_sequence(output, plane, input_fb, out_fbs, 2);
+
+ ret = igt_create_fb(output_fb->fd, output_fb->width, output_fb->height,
+ DRM_FORMAT_XRGB,
+ igt_fb_mod_to_tiling(0),
+ _out_fb);
+ igt_require(ret > 0);
+
+ /* Two commits, with different writeback buffers */
+ out_fbs[1] = _out_fb;
+ writeback_sequence(output, plane, input_fb, out_fbs, 2);
+
+ igt_remove_fb(output_fb->fd, _out_fb);
+}
+
igt_main
{
igt_display_t display;
@@ -307,6 +418,19 @@ igt_main
igt_remove_fb(display.drm_fd, _fb);
}
+ igt_subtest("writeback-check-output")
[Intel-gfx] [PATCH i-g-t v5 6/6] kms_writeback: Add tests using a cloned output
From: Brian Starkey
Update the connector search to also optionally attempt to find a
non-writeback connector to clone to.
Add a subtest which is the same as writeback-check-output, but also
clones to the second connector.
Signed-off-by: Brian Starkey
[rebased and addressed comments by Maarten]
Signed-off-by: Liviu Dudau
---
tests/kms_writeback.c | 64 +++
1 file changed, 59 insertions(+), 5 deletions(-)
diff --git a/tests/kms_writeback.c b/tests/kms_writeback.c
index 0f20dadd2..ae536bbfa 100644
--- a/tests/kms_writeback.c
+++ b/tests/kms_writeback.c
@@ -51,7 +51,8 @@ static drmModePropertyBlobRes
*get_writeback_formats_blob(igt_output_t *output)
return blob;
}
-static bool check_writeback_config(igt_display_t *display, igt_output_t
*output)
+static bool check_writeback_config(igt_display_t *display, igt_output_t
*output,
+ int pipe, igt_output_t **clone)
{
igt_fb_t input_fb, output_fb;
igt_plane_t *plane;
@@ -91,6 +92,30 @@ static bool check_writeback_config(igt_display_t *display,
igt_output_t *output)
ret = igt_display_try_commit_atomic(display, DRM_MODE_ATOMIC_TEST_ONLY |
DRM_MODE_ATOMIC_ALLOW_MODESET,
NULL);
+ if (!ret && clone) {
+ /* Try and find a clone */
+ int i, newret;
+ *clone = NULL;
+
+ for (i = 0; i < display->n_outputs; i++) {
+ igt_output_t *second_output = >outputs[i];
+ if (output != second_output &&
+ igt_pipe_connector_valid(pipe, second_output)) {
+
+ igt_output_clone_pipe(second_output, pipe);
+ igt_output_override_mode(output,
_mode);
+ newret = igt_display_try_commit_atomic(display,
DRM_MODE_ATOMIC_TEST_ONLY |
+
DRM_MODE_ATOMIC_ALLOW_MODESET, NULL);
+ igt_output_set_pipe(second_output, PIPE_NONE);
+ igt_debug("try_commit_atomic clone returned
%d\n", newret);
+ if (!newret) {
+ *clone = second_output;
+ igt_debug("Selected clone %s\n",
(*clone)->name);
+ break;
+ }
+ }
+ }
+ }
igt_plane_set_fb(plane, NULL);
igt_remove_fb(display->drm_fd, _fb);
igt_remove_fb(display->drm_fd, _fb);
@@ -98,7 +123,8 @@ static bool check_writeback_config(igt_display_t *display,
igt_output_t *output)
return !ret;
}
-static igt_output_t *kms_writeback_get_output(igt_display_t *display)
+static igt_output_t *kms_writeback_get_output(igt_display_t *display, enum
pipe *pipe,
+ igt_output_t **clone)
{
int i;
@@ -114,10 +140,16 @@ static igt_output_t
*kms_writeback_get_output(igt_display_t *display)
for (j = 0; j < igt_display_get_n_pipes(display); j++) {
igt_output_set_pipe(output, j);
- if (check_writeback_config(display, output)) {
+ if (check_writeback_config(display, output, j, clone)) {
igt_debug("Using connector %u:%s on pipe %d\n",
output->config.connector->connector_id,
output->name, j);
+ if (clone && *clone)
+ igt_debug("Cloning to connector
%u:%s\n",
+
(*clone)->config.connector->connector_id,
+ (*clone)->name);
+ if (pipe)
+ *pipe = j;
return output;
}
}
@@ -335,10 +367,11 @@ static void writeback_check_output(igt_output_t *output,
igt_plane_t *plane,
igt_main
{
igt_display_t display;
- igt_output_t *output;
+ igt_output_t *output, *clone;
igt_plane_t *plane;
igt_fb_t input_fb;
drmModeModeInfo mode;
+ enum pipe pipe;
int ret;
memset(, 0, sizeof(display));
@@ -353,7 +386,7 @@ igt_main
igt_require(display.is_atomic);
- output = kms_writeback_get_output();
+ output = kms_writeback_get_output(, , );
igt_require(output);
if (output->use_override_mode)
@@ -431,6 +464,27 @@ igt_main
igt_remove_fb(display.drm_fd, _fb);
}
+ igt_subtest("writeback-check-output-clone") {
+ igt_fb_t output_fb;
+
+
[Intel-gfx] [PATCH i-g-t v5 0/6] igt: Add support for testing writeback connectors
We're trying to introduce support for writeback connectors, a way to expose in DRM the hardware functionality from display engines that allows to write back into memory the result of the DE's composition of supported planes. Although this is a rebase of v4 with all the comments addressed, I'm not expecting people to remember any of the previous versions, please review this as if it is a new series. Patches have been originally implemented by Brian, I've done the v3 and v4 updates to them. Best regards, Liviu Changelog: - v5: Addressed comments from Brian Starkey. Old v4 changes are here: https://lists.freedesktop.org/archives/igt-dev/2018-November/006806.html - v4: Rebased on the latest i-g-t and switched to the igt_output_xxx() call as suggested by Maarten. v3 is here: https://lists.freedesktop.org/archives/intel-gfx/2018-March/157394.html Maarten's comments came a couple of months later :) https://lists.freedesktop.org/archives/intel-gfx/2018-June/169027.html - v3: I've now dropped all the changes that were trying to split the CRC functionality out of lib/igt_debugfs.c. v2 is here: https://lists.freedesktop.org/archives/intel-gfx/2017-July/133154.html - Added meson support for builting the kms_writeback test Brian Starkey (6): lib/igt_kms: Add writeback support kms_writeback: Add initial writeback tests lib: Add function to hash a framebuffer kms_writeback: Add writeback-check-output lib/igt_kms: Add igt_output_clone_pipe for cloning kms_writeback: Add tests using a cloned output lib/igt_fb.c | 66 ++ lib/igt_fb.h | 3 + lib/igt_kms.c | 157 + lib/igt_kms.h | 11 + tests/Makefile.sources | 1 + tests/kms_writeback.c | 492 + tests/meson.build | 1 + 7 files changed, 693 insertions(+), 38 deletions(-) create mode 100644 tests/kms_writeback.c -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5 5/6] lib/igt_kms: Add igt_output_clone_pipe for cloning
From: Brian Starkey
An output can be added as a clone of any other output(s) attached to a
pipe using igt_output_clone_pipe()
Signed-off-by: Brian Starkey
---
lib/igt_kms.c | 100 +++---
lib/igt_kms.h | 5 +++
2 files changed, 67 insertions(+), 38 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 0bc2996cd..fe51a6c69 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1694,6 +1694,17 @@ static void igt_display_log_shift(igt_display_t
*display, int shift)
igt_assert(display->log_shift >= 0);
}
+static int igt_output_idx(igt_output_t *output)
+{
+ int i;
+
+ for (i = 0; i < output->display->n_outputs; i++)
+ if (>display->outputs[i] == output)
+ return i;
+
+ return -1;
+}
+
static void igt_output_refresh(igt_output_t *output)
{
igt_display_t *display = output->display;
@@ -2190,42 +2201,6 @@ void igt_display_fini(igt_display_t *display)
display->pipes = NULL;
}
-static void igt_display_refresh(igt_display_t *display)
-{
- igt_output_t *output;
- int i;
-
- unsigned long pipes_in_use = 0;
-
- /* Check that two outputs aren't trying to use the same pipe */
- for (i = 0; i < display->n_outputs; i++) {
- output = >outputs[i];
-
- if (output->pending_pipe != PIPE_NONE) {
- if (pipes_in_use & (1 << output->pending_pipe))
- goto report_dup;
-
- pipes_in_use |= 1 << output->pending_pipe;
- }
-
- if (output->force_reprobe)
- igt_output_refresh(output);
- }
-
- return;
-
-report_dup:
- for (; i > 0; i--) {
- igt_output_t *b = >outputs[i - 1];
-
- igt_assert_f(output->pending_pipe !=
-b->pending_pipe,
-"%s and %s are both trying to use pipe %s\n",
-igt_output_name(output), igt_output_name(b),
-kmstest_pipe_name(output->pending_pipe));
- }
-}
-
static igt_pipe_t *igt_output_get_driving_pipe(igt_output_t *output)
{
igt_display_t *display = output->display;
@@ -2249,6 +2224,40 @@ static igt_pipe_t
*igt_output_get_driving_pipe(igt_output_t *output)
return >pipes[pipe];
}
+static void igt_display_refresh(igt_display_t *display)
+{
+ igt_output_t *output;
+ igt_pipe_t *pipe;
+ int i;
+
+ unsigned long pipes_in_use = 0;
+ unsigned long pending_crtc_idx_mask;
+
+ /* Check that outputs and pipes agree wrt. cloning */
+ for (i = 0; i < display->n_outputs; i++) {
+ output = >outputs[i];
+ pending_crtc_idx_mask = 1 << output->pending_pipe;
+
+ pipe = igt_output_get_driving_pipe(output);
+ if (pipe) {
+ igt_assert_f(pipe->outputs & (1 <<
igt_output_idx(output)),
+"Output %s not expected to be using pipe
%s\n",
+igt_output_name(output),
+kmstest_pipe_name(pipe->pipe));
+
+ if (pipes_in_use & pending_crtc_idx_mask)
+ LOG(display, "Output %s clones pipe %s\n",
+ igt_output_name(output),
+ kmstest_pipe_name(pipe->pipe));
+ }
+
+ pipes_in_use |= pending_crtc_idx_mask;
+
+ if (output->force_reprobe)
+ igt_output_refresh(output);
+ }
+}
+
static igt_plane_t *igt_pipe_get_plane(igt_pipe_t *pipe, int plane_idx)
{
igt_require_f(plane_idx >= 0 && plane_idx < pipe->n_planes,
@@ -3587,6 +3596,7 @@ void igt_output_override_mode(igt_output_t *output,
drmModeModeInfo *mode)
output->use_override_mode = !!mode;
if (pipe) {
+ igt_debug("overriding pipe mode in %s way\n",
output->display->is_atomic ? "atomic" : "legacy");
if (output->display->is_atomic)
igt_pipe_obj_replace_prop_blob(pipe, IGT_CRTC_MODE_ID,
igt_output_get_mode(output), sizeof(*mode));
else
@@ -3594,6 +3604,16 @@ void igt_output_override_mode(igt_output_t *output,
drmModeModeInfo *mode)
}
}
+void igt_output_clone_pipe(igt_output_t *output, enum pipe pipe)
+{
+ igt_display_t *display = output->display;
+ uint32_t current_clones = display->pipes[pipe].outputs;
+
+ igt_output_set_pipe(output, pipe);
+
+ display->pipes[pipe].outputs |= current_clones;
+}
+
/*
* igt_output_set_pipe:
* @output: Target output for which the pipe is being set to
@@ -3610,11 +3630,15 @@ void igt_output_set_pipe(igt_output_t *output, enum
pipe pipe)
igt_assert(output->name);
- if (output->pending_pipe != PIPE_NONE)
+ if
[Intel-gfx] [PATCH i-g-t v5 1/6] lib/igt_kms: Add writeback support
From: Brian Starkey
Add support in igt_kms for writeback connectors, with the ability
to attach framebuffers.
Signed-off-by: Brian Starkey
[rebased and updated to the latest igt style]
Signed-off-by: Liviu Dudau
---
lib/igt_kms.c | 57 +++
lib/igt_kms.h | 6 ++
2 files changed, 63 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 684a599ca..0bc2996cd 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -197,6 +197,9 @@ const char * const
igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
[IGT_CONNECTOR_DPMS] = "DPMS",
[IGT_CONNECTOR_BROADCAST_RGB] = "Broadcast RGB",
[IGT_CONNECTOR_CONTENT_PROTECTION] = "Content Protection",
+ [IGT_CONNECTOR_WRITEBACK_PIXEL_FORMATS] = "WRITEBACK_PIXEL_FORMATS",
+ [IGT_CONNECTOR_WRITEBACK_FB_ID] = "WRITEBACK_FB_ID",
+ [IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR] = "WRITEBACK_OUT_FENCE_PTR",
};
/*
@@ -453,6 +456,7 @@ static const struct type_name connector_type_names[] = {
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
{ DRM_MODE_CONNECTOR_DSI, "DSI" },
{ DRM_MODE_CONNECTOR_DPI, "DPI" },
+ { DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
{}
};
@@ -1802,6 +1806,12 @@ static void igt_output_reset(igt_output_t *output)
if (igt_output_has_prop(output, IGT_CONNECTOR_BROADCAST_RGB))
igt_output_set_prop_value(output, IGT_CONNECTOR_BROADCAST_RGB,
BROADCAST_RGB_FULL);
+ if (igt_output_has_prop(output, IGT_CONNECTOR_WRITEBACK_FB_ID))
+ igt_output_set_prop_value(output,
IGT_CONNECTOR_WRITEBACK_FB_ID, 0);
+ if (igt_output_has_prop(output, IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR))
{
+ igt_output_clear_prop_changed(output,
IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR);
+ output->writeback_out_fence_fd = -1;
+ }
}
/**
@@ -1814,6 +1824,8 @@ static void igt_output_reset(igt_output_t *output)
* For outputs:
* - %IGT_CONNECTOR_CRTC_ID
* - %IGT_CONNECTOR_BROADCAST_RGB (if applicable)
+ * - %IGT_CONNECTOR_WRITEBACK_FB_ID
+ * - %IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR
* - igt_output_override_mode() to default.
*
* For pipes:
@@ -1899,6 +1911,8 @@ void igt_display_require(igt_display_t *display, int
drm_fd)
if (drmSetClientCap(drm_fd, DRM_CLIENT_CAP_ATOMIC, 1) == 0)
display->is_atomic = 1;
+ drmSetClientCap(drm_fd, DRM_CLIENT_CAP_WRITEBACK_CONNECTORS, 1);
+
plane_resources = drmModeGetPlaneResources(display->drm_fd);
igt_assert(plane_resources);
@@ -2147,6 +2161,11 @@ static void igt_output_fini(igt_output_t *output)
kmstest_free_connector_config(>config);
free(output->name);
output->name = NULL;
+
+ if (output->writeback_out_fence_fd != -1) {
+ close(output->writeback_out_fence_fd);
+ output->writeback_out_fence_fd = -1;
+ }
}
/**
@@ -3144,6 +3163,11 @@ static void
igt_atomic_prepare_connector_commit(igt_output_t *output, drmModeAto
output->props[i],
output->values[i]));
}
+
+ if (output->writeback_out_fence_fd != -1) {
+ close(output->writeback_out_fence_fd);
+ output->writeback_out_fence_fd = -1;
+ }
}
/*
@@ -3264,6 +3288,16 @@ display_commit_changed(igt_display_t *display, enum
igt_commit_style s)
else
/* no modeset in universal commit, no change to crtc. */
output->changed &= 1 << IGT_CONNECTOR_CRTC_ID;
+
+ if (s == COMMIT_ATOMIC) {
+ if (igt_output_is_prop_changed(output,
IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR))
+ igt_assert(output->writeback_out_fence_fd >= 0);
+
+ output->values[IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR] =
0;
+ output->values[IGT_CONNECTOR_WRITEBACK_FB_ID] = 0;
+ igt_output_clear_prop_changed(output,
IGT_CONNECTOR_WRITEBACK_FB_ID);
+ igt_output_clear_prop_changed(output,
IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR);
+ }
}
if (display->first_commit) {
@@ -3884,6 +3918,29 @@ void igt_pipe_request_out_fence(igt_pipe_t *pipe)
igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_OUT_FENCE_PTR,
(ptrdiff_t)>out_fence_fd);
}
+/**
+ * igt_output_set_writeback_fb:
+ * @output: Target output
+ * @fb: Target framebuffer
+ *
+ * This function sets the given @fb to be used as the target framebuffer for
the
+ * writeback engine at the next atomic commit. It will also request a writeback
+ * out fence that will contain the fd number of the out fence created by KMS if
+ * the given @fb is valid.
+ */
+void igt_output_set_writeback_fb(igt_output_t *output, struct igt_fb *fb)
+{
+ igt_display_t *display =
[Intel-gfx] [PATCH i-g-t v5 3/6] lib: Add function to hash a framebuffer
From: Brian Starkey
To use writeback buffers as a CRC source, we need to be able to hash
them. Implement a simple FVA-1a hashing routine for this purpose.
Doing a bytewise hash on the framebuffer directly can be very slow if
the memory is noncached. By making a copy of each line in the FB first
(which can take advantage of word-access speedup), we can do the hash
on a cached copy, which is much faster (10x speedup on my platform).
Signed-off-by: Brian Starkey
[rebased and updated to the most recent API]
Signed-off-by: Liviu Dudau
---
lib/igt_fb.c | 66
lib/igt_fb.h | 3 +++
2 files changed, 69 insertions(+)
diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 5cd1829a3..11e200b53 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -2379,6 +2379,72 @@ bool igt_fb_supported_format(uint32_t drm_format)
return false;
}
+/*
+ * This implements the FNV-1a hashing algorithm instead of CRC, for
+ * simplicity
+ * http://www.isthe.com/chongo/tech/comp/fnv/index.html
+ *
+ * hash = offset_basis
+ * for each octet_of_data to be hashed
+ * hash = hash xor octet_of_data
+ * hash = hash * FNV_prime
+ * return hash
+ *
+ * 32 bit offset_basis = 2166136261
+ * 32 bit FNV_prime = 224 + 28 + 0x93 = 16777619
+ */
+int igt_fb_get_crc(struct igt_fb *fb, igt_crc_t *crc)
+{
+#define FNV1a_OFFSET_BIAS 2166136261
+#define FNV1a_PRIME 16777619
+ uint32_t hash;
+ void *map;
+ char *ptr, *line = NULL;
+ int x, y, cpp = igt_drm_format_to_bpp(fb->drm_format) / 8;
+ uint32_t stride = calc_plane_stride(fb, 0);
+
+ if (fb->is_dumb)
+ map = kmstest_dumb_map_buffer(fb->fd, fb->gem_handle, fb->size,
+ PROT_READ);
+ else
+ map = gem_mmap__gtt(fb->fd, fb->gem_handle, fb->size,
+ PROT_READ);
+ ptr = map;
+
+ /*
+* Framebuffers are often uncached, which can make byte-wise accesses
+* very slow. We copy each line of the FB into a local buffer to speed
+* up the hashing.
+*/
+ line = malloc(stride);
+ if (!line) {
+ munmap(map, fb->size);
+ return -ENOMEM;
+ }
+
+ hash = FNV1a_OFFSET_BIAS;
+
+ for (y = 0; y < fb->height; y++, ptr += stride) {
+
+ memcpy(line, ptr, stride);
+
+ for (x = 0; x < fb->width * cpp; x++) {
+ hash ^= line[x];
+ hash *= FNV1a_PRIME;
+ }
+ }
+
+ crc->n_words = 1;
+ crc->crc[0] = hash;
+
+ free(line);
+ munmap(map, fb->size);
+
+ return 0;
+#undef FNV1a_OFFSET_BIAS
+#undef FNV1a_PRIME
+}
+
/**
* igt_format_is_yuv:
* @drm_format: drm fourcc
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 9f027deba..948c5380c 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -37,6 +37,7 @@
#include
#include "igt_color_encoding.h"
+#include "igt_debugfs.h"
/**
* igt_fb_t:
@@ -173,5 +174,7 @@ const char *igt_format_str(uint32_t drm_format);
bool igt_fb_supported_format(uint32_t drm_format);
bool igt_format_is_yuv(uint32_t drm_format);
+int igt_fb_get_crc(struct igt_fb *fb, igt_crc_t *crc);
+
#endif /* __IGT_FB_H__ */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 43/46] drm/i915: Allocate a status page for each timeline
On 1/15/2019 01:50, Chris Wilson wrote:
Quoting John Harrison (2019-01-15 00:56:13)
On 1/7/2019 03:55, Chris Wilson wrote:
+static int alloc_hwsp(struct i915_timeline *timeline)
+{
+ struct drm_i915_private *i915 = timeline->i915;
+ struct i915_vma *vma;
+ int offset;
+
+ mutex_lock(>gt.timeline_lock);
+
+restart:
+ offset = find_first_cacheline(i915);
+ if (offset == NBITS && i915->gt.timeline_hwsp) {
+ i915_vma_put(i915->gt.timeline_hwsp);
+ i915->gt.timeline_hwsp = NULL;
+ }
+
+ vma = i915->gt.timeline_hwsp;
+ if (!vma) {
+ struct drm_i915_gem_object *bo;
+
+ /* Drop the lock before allocations */
+ mutex_unlock(>gt.timeline_lock);
+
+ BUILD_BUG_ON(NBITS * CACHELINE_BYTES > PAGE_SIZE);
+ bo = i915_gem_object_create_internal(i915, PAGE_SIZE);
+ if (IS_ERR(bo))
+ return PTR_ERR(bo);
+
+ i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
+
+ vma = i915_vma_instance(bo, >ggtt.vm, NULL);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ mutex_lock(>gt.timeline_lock);
+ if (i915->gt.timeline_hwsp) {
+ i915_gem_object_put(bo);
+ goto restart;
+ }
+
+ i915->gt.timeline_hwsp = vma;
+ i915->gt.timeline_free = ~0ull;
+ offset = 0;
+ }
+
+ i915->gt.timeline_free &= ~BIT_ULL(offset);
+
+ timeline->hwsp_ggtt = i915_vma_get(vma);
+ timeline->hwsp_offset = offset * CACHELINE_BYTES;
+
+ mutex_unlock(>gt.timeline_lock);
+
+ return 0;
+}
If I'm reading this correctly then gt.timeline_hwsp/free is the a cached
copy of the most recently allocated but not yet filled bank of seqno
locations. When it gets full, the i915->gt reference gets dropped and a
new page is allocated and used up line by line. Meanwhile, each timeline
has it's own private reference to the page so dropping the i915->gt
reference is safe. And once the last timeline using a given page is
freed, the last reference to that page will be dropped and so the page
itself will also be freed. If a timeline is freed before the currently
cached page is filled, then that timeline's slot will be released and
re-used by the next timeline to be created.
But what about the scenario of a long running system with a small but
growing number of persistent tasks interspersed with many short lived
tasks? In that case, you would end up with many sparsely populated pages
that whose free slots will not get re-used. You could have a linked list
of cached pages. When a page is filled, move it to a 'full' list. When a
timeline is freed, if it's page was on the 'full' list, clear the slot
and move it back to the 'available' list.
Yes. My thinking was a plain slab cache was a quick-and-dirty
improvement over a page-per-timeline. And a freelist would be the next
step.
Or is the idea that a worst case of a single page vma allocation per
timeline is the least of our worries if there is an ever growing number
of timelines/contexts/users in the system?
Nah, it was just an attempt to quickly reduce the number of allocations,
where the worst case of one page+vma per timeline was the starting
point.
We should break this patch down into 1) one-page-per-timeline, 2) slab
cache, 3) free list 4) profit.
At other times we have been wanting to be able to suballocate pages,
something to keep in mind would be extending this to arbitrary cacheline
allocations.
The multi-stage approach sounds good. Keep things simple in this patch
and then improve the situation later. One thing to be careful of with a
cacheline allocator would be make sure whatever is being converted
wasn't using full pages for security reasons. I.e. a page can be private
to a process, a cacheline will be shared by many. I guess that would
only really apply to allocations being passed to user land as the kernel
is considered secure? Or can a user batch buffer write to arbitrary
locations within the ppHWSP and thereby splat someone else's seqno?
+ if (global_hwsp) {
+ timeline->hwsp_ggtt = i915_vma_get(global_hwsp);
+ timeline->hwsp_offset = I915_GEM_HWS_SEQNO_ADDR;
+ } else {
+ err = alloc_hwsp(timeline);
+ if (err)
+ return err;
+ }
+
+ vaddr = i915_gem_object_pin_map(timeline->hwsp_ggtt->obj, I915_MAP_WB);
+ if (IS_ERR(vaddr)) { /* leak the cacheline, but will clean up later */
Can you explain this comment more? Where/when is the later?
On failure here, the cacheline is still marked as allocated in the slab,
but the reference to the page is released. So the backing page will be
released when everyone else finally drops their reference.
Just laziness, since we have the ability to return the cacheline later
on...
Meaning the actual leak is the bit in 'i915->gt.timeline_free' that says
this
Re: [Intel-gfx] [PATCH] drm/i915: Fix the static code analysis warning in debugfs
On Tue, Jan 15, 2019 at 12:52:29PM +0200, Jani Nikula wrote: > On Wed, 09 Jan 2019, Manasi Navare wrote: > > On Wed, Jan 09, 2019 at 01:14:14PM -0800, Radhakrishna Sripada wrote: > >> intel_dp->dsc_dpcd is defined as an array making the if check redundant. > >> > > > > Yes I agree, I guess when I added that if check it was anot an array to > > begin > > with and then forgot to take it off. > > > > Looks good to me. > > > > Reviewed-by: Manasi Navare > > Manasi, you've got commit rights, please use them! > > Pushed now, with proper Fixes: tag added, thanks for the patch, review, > testing, etc. > Thanks Jani for merging this one. I know I had this in my list of patches to merge but got heads down busy with getting the IGT commit rights and merging the kms_dsc IGT test last few days. Thanks for catching this and for fixes patch RK! Regards Manasi > BR, > Jani. > > > > > > Manasi > > > >> Cc: Rodrigo Vivi > >> Signed-off-by: Radhakrishna Sripada > >> --- > >> drivers/gpu/drm/i915/i915_debugfs.c | 5 ++--- > >> 1 file changed, 2 insertions(+), 3 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > >> b/drivers/gpu/drm/i915/i915_debugfs.c > >> index 95813e21ae02..908e41f9cb7d 100644 > >> --- a/drivers/gpu/drm/i915/i915_debugfs.c > >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c > >> @@ -4958,9 +4958,8 @@ static int i915_dsc_fec_support_show(struct seq_file > >> *m, void *data) > >>crtc_state = to_intel_crtc_state(crtc->state); > >>seq_printf(m, "DSC_Enabled: %s\n", > >> yesno(crtc_state->dsc_params.compression_enable)); > >> - if (intel_dp->dsc_dpcd) > >> - seq_printf(m, "DSC_Sink_Support: %s\n", > >> - > >> yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd))); > >> + seq_printf(m, "DSC_Sink_Support: %s\n", > >> + yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd))); > >>if (!intel_dp_is_edp(intel_dp)) > >>seq_printf(m, "FEC_Sink_Support: %s\n", > >> > >> yesno(drm_dp_sink_supports_fec(intel_dp->fec_capable))); > >> -- > >> 2.20.0.rc2.7.g965798d1f299 > >> > >> ___ > >> 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 > > -- > Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Only dump GPU state on set-wedged if interesting
== Series Details ==
Series: drm/i915: Only dump GPU state on set-wedged if interesting
URL : https://patchwork.freedesktop.org/series/55239/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5424_full -> Patchwork_11298_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_11298_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_cpu_reloc@full:
- shard-skl: NOTRUN -> TIMEOUT [fdo#108248]
* igt@gem_exec_schedule@pi-ringfull-blt:
- shard-skl: NOTRUN -> FAIL [fdo#103158]
* igt@gem_softpin@noreloc-s3:
- shard-snb: PASS -> INCOMPLETE [fdo#105411]
* igt@i915_suspend@forcewake:
- shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107773]
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145]
* igt@kms_cursor_crc@cursor-128x128-dpms:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-dpms:
- shard-apl: PASS -> FAIL [fdo#103232] +2
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-ytiled:
- shard-skl: PASS -> FAIL [fdo#103184]
* igt@kms_flip@2x-modeset-vs-vblank-race-interruptible:
- shard-glk: PASS -> FAIL [fdo#103060]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-pwrite:
- shard-skl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-iclb: PASS -> FAIL [fdo#103167]
* igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-glk: PASS -> FAIL [fdo#108948]
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166] +1
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@pm_rpm@system-suspend-execbuf:
- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
Possible fixes
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-skl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-apl: FAIL [fdo#106510] / [fdo#108145] -> PASS
* igt@kms_chv_cursor_fail@pipe-b-64x64-left-edge:
- shard-skl: FAIL [fdo#104671] -> PASS +1
* igt@kms_color@pipe-b-legacy-gamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-skl: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-apl: FAIL [fdo#103232] -> PASS +3
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-apl: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
- shard-glk: FAIL [fdo#103167] -> PASS +3
* igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-apl: FAIL [fdo#108948] -> PASS
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-apl: FAIL [fdo#103375] -> PASS
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: FAIL [fdo#107815] -> PASS
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-apl: FAIL [fdo#108145] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl: FAIL [fdo#103166] -> PASS +2
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-iclb: FAIL [fdo#103166] -> PASS +2
* igt@kms_psr@no_drrs:
- shard-iclb: FAIL [fdo#108341] -> PASS
* igt@kms_setmode@basic:
- shard-skl: FAIL [fdo#99912] -> PASS
* igt@perf@short-reads:
- shard-skl: FAIL [fdo#103183] -> PASS
* igt@pm_backlight@basic-brightness:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS +1
* igt@pm_rc6_residency@rc6-accuracy:
- shard-snb: {SKIP} [fdo#109271] -> PASS
* igt@pm_rpm@sysfs-read:
- shard-iclb: DMESG-WARN [fdo#108654] -> PASS
{name}: This element is suppressed. This
Re: [Intel-gfx] [PATCH 41/46] drm/i915: Introduce concept of per-timeline (context) HWSP
On 1/15/2019 07:40, Chris Wilson wrote:
Quoting Chris Wilson (2019-01-15 09:14:17)
Quoting John Harrison (2019-01-15 00:55:39)
On 1/7/2019 03:55, Chris Wilson wrote:
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local seqno,
abstracting away the presumption of a global seqno. In this first step,
we point each request back into the engine's HWSP so everything
continues to work with the global timeline.
---
+static inline u32 i915_request_hwsp(const struct i915_request *rq)
+{
+ return READ_ONCE(*rq->hwsp_seqno);
+}
+
Shouldn't the function name have an _seqno as well? Just
'i915_request_hwsp()' is fairly ambiguous, there could be many different
things stored in the HWSP.
It's not even necessarily the HWSP! :)
i915_request_hw_seqno() // dissatisfying
-> i915_request_hwsp_seqno() // but rq only stores one element in HWSP!
-> i915_request_hwsp()
Was the evolution of names I chose.
Of that mix, i915_request_hwsp_seqno(). hw_seqno just feels nondescript.
i915_request_current_[hw]_seqno() maybe, but because we start with
i915_request I find it confusing and expect the seqno to be tied to the
request. So maybe just drop i915_request here, and go with something
like hwsp_breadcrumb(), that just happens to take i915_request as a
convenience.
My vote would be 'hwsp_breadcrumb()' or similar. As you say, the seqno
in the HWSP isn't actually tied to the request. Quite the opposite in
fact - you are generally comparing multiple requests' seqnos to the HWSP
seqno to see which have or have not completed. It should really be tied
to the timeline (or more accurately, to the context as that is what
dictates the timeline). The code is generally starting from a request
structure so it makes sense to have a shortcut via the request. But
logically, it should be req->timeline->hwsp[SEQNO]. Maybe even something
like i915_timeline_out_seqno(rq)? Or i915_timeline_done_seqno(rq)?
Alternatively,
static inline u32 i915_request_hwsp(struct i915_request *rq, int index)
{
return READ_ONCE(rq->hwsp_seqno[index]);
}
And probably rename s/rq->hwsp_seqno/rq->hwsp/. That should compile away
the argument, but you'll still probably want a
static inline u32 i915_request_hwsp_seqno(struct i915_request *rq)
{
return i915_request_hwsp(rq, 0);
}
Given that there is only a single per context element in the HWSP at
present, this version does seem overkill. It might be useful to move to
that later when there are more entries, if that ever happens. For now,
keep things simple I think.
I can't win! But it does look more methodical.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Split out drm_probe_helper.h
== Series Details == Series: drm: Split out drm_probe_helper.h URL : https://patchwork.freedesktop.org/series/55232/ State : success == Summary == CI Bug Log - changes from CI_DRM_5424_full -> Patchwork_11297_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_11297_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_cpu_reloc@full: - shard-skl: NOTRUN -> TIMEOUT [fdo#108248] * igt@gem_eio@in-flight-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] +1 * igt@gem_exec_schedule@pi-ringfull-blt: - shard-skl: NOTRUN -> FAIL [fdo#103158] * igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#109225] * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145] * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: PASS -> FAIL [fdo#108682] * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-glk: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x21-sliding: - shard-apl: PASS -> FAIL [fdo#103232] +2 * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: PASS -> FAIL [fdo#105767] * igt@kms_draw_crc@draw-method-rgb565-render-ytiled: - shard-iclb: PASS -> WARN [fdo#108336] +3 * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt: - shard-glk: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-render: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +3 * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-cpu: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +5 * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-render: - shard-skl: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_plane@pixel-format-pipe-b-planes: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] +1 * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133] * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb: - shard-glk: PASS -> FAIL [fdo#108145] * igt@kms_sysfs_edid_timing: - shard-iclb: PASS -> FAIL [fdo#100047] * igt@kms_vblank@pipe-a-wait-forked-busy: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +17 * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] * igt@pm_rpm@cursor: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@pm_rpm@reg-read-ioctl: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840] Possible fixes * igt@gem_ctx_isolation@vecs0-s3: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS * igt@kms_ccs@pipe-a-crc-primary-rotation-180: - shard-skl: FAIL [fdo#107725] -> PASS * igt@kms_color@pipe-b-legacy-gamma: - shard-apl: FAIL [fdo#104782] -> PASS * igt@kms_cursor_crc@cursor-64x21-random: - shard-apl: FAIL [fdo#103232] -> PASS +2 * igt@kms_cursor_crc@cursor-64x21-sliding: - shard-glk: FAIL [fdo#103232] -> PASS * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-untiled: - shard-skl: FAIL [fdo#108145] / [fdo#108472] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: FAIL [fdo#103167] -> PASS +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-iclb: FAIL [fdo#103167] -> PASS * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc: - shard-glk: FAIL [fdo#103167] -> PASS +2 * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: - shard-apl: FAIL [fdo#108948] -> PASS * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-apl: FAIL [fdo#103375] -> PASS * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-glk: FAIL [fdo#108145] -> PASS +1 * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max: - shard-apl: FAIL
[Intel-gfx] ✗ Fi.CI.BAT: failure for Add uAPI to support ICL VME hardware for new media-driver
== Series Details == Series: Add uAPI to support ICL VME hardware for new media-driver URL : https://patchwork.freedesktop.org/series/55249/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/i915_gem_context.o drivers/gpu/drm/i915/i915_gem_context.c: In function ‘gen8_modify_rpcs_gpu’: drivers/gpu/drm/i915/i915_gem_context.c:1039:2: error: too few arguments to function ‘intel_runtime_pm_put’ intel_runtime_pm_put(i915); ^~~~ In file included from drivers/gpu/drm/i915/i915_trace.h:10:0, from drivers/gpu/drm/i915/i915_drv.h:2577, from drivers/gpu/drm/i915/i915_gem_context.c:90: drivers/gpu/drm/i915/intel_drv.h:2208:6: note: declared here void intel_runtime_pm_put(struct drm_i915_private *i915, intel_wakeref_t wref); ^~~~ In file included from drivers/gpu/drm/i915/i915_gem_context.c:1377:0: drivers/gpu/drm/i915/selftests/i915_gem_context.c: In function ‘__igt_ctx_sseu’: drivers/gpu/drm/i915/selftests/i915_gem_context.c:1097:2: error: too few arguments to function ‘intel_runtime_pm_put’ intel_runtime_pm_put(i915); ^~~~ In file included from drivers/gpu/drm/i915/i915_trace.h:10:0, from drivers/gpu/drm/i915/i915_drv.h:2577, from drivers/gpu/drm/i915/i915_gem_context.c:90: drivers/gpu/drm/i915/intel_drv.h:2208:6: note: declared here void intel_runtime_pm_put(struct drm_i915_private *i915, intel_wakeref_t wref); ^~~~ scripts/Makefile.build:276: recipe for target 'drivers/gpu/drm/i915/i915_gem_context.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_gem_context.o] Error 1 scripts/Makefile.build:492: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:492: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:492: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1042: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi Daniel, Dave,
Here is the drm-misc-next PR for this week.
Thanks!
Maxime
drm-misc-next-2019-01-15:
drm-misc-next for 5.1:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Reorganisation of drm_device and drm_framebuffer headers
- Cleanup of the drmP inclusion
- Fix leaks in the fb-helpers
- Allow for depth different from bpp in fb-helper fbdev emulation
Driver Changes:
- Add reflection properties to rockchip
- a bunch of fixes for virtio
- a bunch of fixes for dp_mst and drivers using it, and introduction of a
new refcounting scheme
- Convertion of bochs to atomic and generic fbdev emulation
- Allow meson to remove the firmware framebuffers
The following changes since commit e3d093070eb0b5e3df668d3eb04100ea79343c65:
Merge tag 'tilcdc-4.22' of https://github.com/jsarha/linux into drm-next
(2019-01-11 06:29:31 +1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-01-15
for you to fetch changes up to ed20151a7699bb2c77eba3610199789a126940c4:
drm/vblank: Allow dynamic per-crtc max_vblank_count (2019-01-14 21:23:55
+0200)
drm-misc-next for 5.1:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Reorganisation of drm_device and drm_framebuffer headers
- Cleanup of the drmP inclusion
- Fix leaks in the fb-helpers
- Allow for depth different from bpp in fb-helper fbdev emulation
Driver Changes:
- Add reflection properties to rockchip
- a bunch of fixes for virtio
- a bunch of fixes for dp_mst and drivers using it, and introduction of a
new refcounting scheme
- Convertion of bochs to atomic and generic fbdev emulation
- Allow meson to remove the firmware framebuffers
Daniel Vetter (14):
drm/todo: Better defio support in the generic fbdev emulation
drm/crtc-helpers: WARN when used with atomic drivers
drm/ch7006: Stop using drm_crtc_force_disable
drm/nouveau: Stop using drm_crtc_force_disable
drm: Unexport drm_crtc_force_disable
drm/atomic: Add missing () to function ref in kerneldoc
drm: Move the legacy kms disable_all helper to crtc helpers
drm/arc: Don't set the dpms hook
drm/tda998x: Don't set dpms hook
drm/doc: Polish kerneldoc for drm_device.h
drm/docs: improve docs for drm_drv.c
drm/of: Fix kerneldoc
drm/panel: Small documentation polish
drm/doc: Move bridge link target to the right place
Daniele Castagna (2):
drm/rockchip: Fix YUV buffers color rendering
drm/rockchip: Add reflection properties
Enric Balletbo i Serra (1):
drm/rockchip: update cursors asynchronously through atomic.
Ezequiel Garcia (5):
drm/virtio: Remove incorrect kfree()
drm/virtio: Add missing virtqueue reset
drm/virtio: Drop deprecated load/unload initialization
drm/rockchip: Fix typo in VOP macros argument
drm/rockchip: Separate RK3288 from RK3368 win01 registers
Gerd Hoffmann (19):
drm/virtio: log error responses
drm/virtio: fix pageflip flush
drm/virtio: drop virtio_gpu_fence_cleanup()
drm/bochs: encoder cleanup
drm/bochs: split bochs_hw_setmode
drm/bochs: atomic: add atomic_flush+atomic_enable callbacks.
drm/bochs: atomic: add mode_set_nofb callback.
drm/bochs: atomic: switch planes to atomic, wire up helpers.
drm/bochs: atomic: use atomic set_config helper
drm/bochs: atomic: use atomic page_flip helper
drm/bochs: atomic: use suspend/resume helpers
drm/bochs: atomic: set DRIVER_ATOMIC
drm/bochs: remove old bochs_crtc_* functions
drm/bochs: drop unused gpu_addr arg from bochs_bo_pin()
drm/bochs: move ttm_bo_(un)reserve calls into bochs_bo_{pin, unpin}
drm/bochs: add basic prime support
drm/bochs: switch to generic drm fbdev emulation
drm/bochs: drop old fbdev emulation code
drm/bochs: move remaining fb bits to kms
Gustavo A. R. Silva (1):
qxl: Use struct_size() in kzalloc()
Kuo-Hsin Yang (1):
drm/gem: Mark pinned pages as unevictable
Linus Walleij (2):
drm/fb-helper: Scale back depth to supported maximum
drm/panel: Add a driver for the TPO TPG110
Lyude Paul (20):
drm/dp_mst: Fix some formatting in drm_dp_add_port()
drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg()
drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi()
drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi()
drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends
drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails
drm/dp_mst: Stop releasing VCPI when removing ports from topology
drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
drm/i915: Keep malloc
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start (rev4)
== Series Details ==
Series: drm/i915/userptr: Avoid struct_mutex recursion for
mmu_invalidate_range_start (rev4)
URL : https://patchwork.freedesktop.org/series/51362/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5427 -> Patchwork_11299
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11299 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11299, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/51362/revisions/4/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11299:
### IGT changes ###
Possible regressions
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: PASS -> WARN
Known issues
Here are the changes found in Patchwork_11299 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_contexts:
- fi-icl-u2: NOTRUN -> DMESG-FAIL [fdo#108569]
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_flip@basic-flip-vs-modeset:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#107362] -> PASS
* igt@pm_rpm@basic-pci-d3-state:
- fi-icl-u2: DMESG-WARN [fdo#108654] -> 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#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#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
Participating hosts (47 -> 42)
--
Additional (1): fi-pnv-d510
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-peppy fi-byt-squawks
fi-bsw-cyan fi-bsw-kefka
Build changes
-
* Linux: CI_DRM_5427 -> Patchwork_11299
CI_DRM_5427: f46471ad9e2c2f5346b117ae79a886ed59016e5e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4773: 951e2b1a016b750544d0f42459b13b9c70631c68 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11299: e1f795fb6dfe5ff187ff6b93f5fd9e087abc8927 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e1f795fb6dfe drm/i915/userptr: Avoid struct_mutex recursion for
mmu_invalidate_range_start
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11299/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 41/46] drm/i915: Introduce concept of per-timeline (context) HWSP
Quoting Chris Wilson (2019-01-15 09:14:17)
> Quoting John Harrison (2019-01-15 00:55:39)
> > On 1/7/2019 03:55, Chris Wilson wrote:
> > > Supplement the per-engine HWSP with a per-timeline HWSP. That is a
> > > per-request pointer through which we can check a local seqno,
> > > abstracting away the presumption of a global seqno. In this first step,
> > > we point each request back into the engine's HWSP so everything
> > > continues to work with the global timeline.
> > > ---
> > > +static inline u32 i915_request_hwsp(const struct i915_request *rq)
> > > +{
> > > + return READ_ONCE(*rq->hwsp_seqno);
> > > +}
> > > +
> > Shouldn't the function name have an _seqno as well? Just
> > 'i915_request_hwsp()' is fairly ambiguous, there could be many different
> > things stored in the HWSP.
>
> It's not even necessarily the HWSP! :)
>
> i915_request_hw_seqno() // dissatisfying
> -> i915_request_hwsp_seqno() // but rq only stores one element in HWSP!
> -> i915_request_hwsp()
>
> Was the evolution of names I chose.
>
> Of that mix, i915_request_hwsp_seqno(). hw_seqno just feels nondescript.
>
> i915_request_current_[hw]_seqno() maybe, but because we start with
> i915_request I find it confusing and expect the seqno to be tied to the
> request. So maybe just drop i915_request here, and go with something
> like hwsp_breadcrumb(), that just happens to take i915_request as a
> convenience.
Alternatively,
static inline u32 i915_request_hwsp(struct i915_request *rq, int index)
{
return READ_ONCE(rq->hwsp_seqno[index]);
}
And probably rename s/rq->hwsp_seqno/rq->hwsp/. That should compile away
the argument, but you'll still probably want a
static inline u32 i915_request_hwsp_seqno(struct i915_request *rq)
{
return i915_request_hwsp(rq, 0);
}
I can't win! But it does look more methodical.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start (rev4)
== Series Details ==
Series: drm/i915/userptr: Avoid struct_mutex recursion for
mmu_invalidate_range_start (rev4)
URL : https://patchwork.freedesktop.org/series/51362/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e1f795fb6dfe drm/i915/userptr: Avoid struct_mutex recursion for
mmu_invalidate_range_start
-:27: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#27:
References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers")
-:27: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 93065ac753e4 ("mm, oom:
distinguish blockable mode for mmu notifiers")'
#27:
References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers")
-:295: ERROR:LOCKING: recursive locking is bad, do not use this ever.
#295: FILE: drivers/gpu/drm/i915/i915_gem_userptr.c:150:
+ switch (mutex_trylock_recursive(unlock)) {
total: 2 errors, 1 warnings, 0 checks, 446 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/dsi: Adjust crtc_clock for burst_mode_ratio
On Sat, Dec 01, 2018 at 12:31:47PM +0100, Hans de Goede wrote: > On devices with a burst_mode_ratio which is not 100 (1:1), the pclk > will have a different value then drm_display_mode.clock . > > On a Prowise PT301 tablet where vbt.lfp_lvds_vbt_mode.clock is 66100 and > burst_mode_ratio is 130 this leads to the following errors: > > [drm:pipe_config_err [i915]] *ERROR* mismatch in > pixel_rate (expected 66100, found 86458) > [drm:pipe_config_err [i915]] *ERROR* mismatch in > base.adjusted_mode.crtc_clock (expected 66100, found 86458) > [drm:pipe_config_err [i915]] *ERROR* mismatch in > port_clock (expected 66100, found 86458) > > This commit makes intel_dsi_compute_config() set > pipe_config.adjusted_mode.crtc_clock, taking the burst_mode_ratio into > account fixing this. > > Signed-off-by: Hans de Goede > --- > drivers/gpu/drm/i915/vlv_dsi.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c > index c21cbfa9653c..d72ccf557a9c 100644 > --- a/drivers/gpu/drm/i915/vlv_dsi.c > +++ b/drivers/gpu/drm/i915/vlv_dsi.c > @@ -347,6 +347,10 @@ static bool intel_dsi_compute_config(struct > intel_encoder *encoder, > return false; > } > > + adjusted_mode->crtc_clock = > + DIV_ROUND_UP(adjusted_mode->crtc_clock * > + intel_dsi->burst_mode_ratio, 100); Hmm. Won't this cause incorrect refresh rate to be used in eg. vblank timestmap calculations? OTOH if the pipe is really fetching data at the higher burst rate then we should rather want to calculate the watermarks/cdclk based on that higher rate. We do have pixel_rate in the crtc state but atm that is computed in generic code. We might have to push that to be encoder specific to do this correctly... > + > pipe_config->clock_set = true; > > return true; > -- > 2.19.1 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Split out drm_probe_helper.h
On 1/15/19 2:26 PM, Neil Armstrong wrote: On 15/01/2019 11:41, Daniel Vetter wrote: Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. v2: Make it compile. There was so much compile fail on arm drivers that I figured I'll better not include any of the acks on v1. v3: Massive rebase because i915 has lost a lot of drmP.h includes, but not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h there was still one, which this patch largely removes. Which means rolling out lots more includes all over. This will also conflict with ongoing drmP.h cleanup by others I expect. v3: Rebase on top of atomic bochs. Cc: Sam Ravnborg Cc: Jani Nikula Cc: Laurent Pinchart Acked-by: Rodrigo Vivi (v2) Acked-by: Benjamin Gaignard (v2) Signed-off-by: Daniel Vetter Cc: linux-arm-ker...@lists.infradead.org Cc: virtualizat...@lists.linux-foundation.org Cc: etna...@lists.freedesktop.org Cc: linux-samsung-...@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-media...@lists.infradead.org Cc: linux-amlo...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: spice-de...@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-te...@vger.kernel.org Cc: xen-de...@lists.xen.org --- Merging this is going to be a bit a mess due to all the ongoing drmP.h cleanups. I think the following should work: - Apply Sam's prep patches for removing drmP.h from drm_modeset_helper.h - Get the i915 drmP.h cleanup backmerged into drm-misc-next - Apply this patch. - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h - All through drm-misc-next, which has some potential for trivial conflicts around #includes with other drivers unfortunately. I hope there's no other driver who'll blow up accidentally because someone else is doing a drmP.h cleanup. Laurent maybe? Jani, ack on this? -Daniel --- .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_crtc.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/arm/malidp_mw.c | 2 +- drivers/gpu/drm/armada/armada_510.c | 2 +- drivers/gpu/drm/armada/armada_crtc.c | 2 +- drivers/gpu/drm/armada/armada_crtc.h | 2 + drivers/gpu/drm/armada/armada_drv.c | 2 +- drivers/gpu/drm/armada/armada_fb.c| 2 +- drivers/gpu/drm/ast/ast_drv.c | 1 + drivers/gpu/drm/ast/ast_mode.c| 1 + .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- drivers/gpu/drm/bochs/bochs_drv.c | 1 + drivers/gpu/drm/bochs/bochs_kms.c | 1 + drivers/gpu/drm/bridge/adv7511/adv7511.h | 5 +- drivers/gpu/drm/bridge/analogix-anx78xx.c | 2 +- .../drm/bridge/analogix/analogix_dp_core.c| 2 +- drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- drivers/gpu/drm/bridge/panel.c| 2 +- drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- drivers/gpu/drm/bridge/tc358764.c | 2 +- drivers/gpu/drm/bridge/tc358767.c | 2 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + drivers/gpu/drm/drm_atomic_helper.c | 1 - drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- drivers/gpu/drm/drm_modeset_helper.c | 2 +- drivers/gpu/drm/drm_probe_helper.c| 2 +-
Re: [Intel-gfx] [PATCH 2/4] drm/i915/dsi: Enable dithering for 6 bpc panels
On Sat, Dec 01, 2018 at 12:31:46PM +0100, Hans de Goede wrote: > The display engine has 2 dithering enable bits which both need to be set > for dithering to happen, 1 in the PIPECONF register which is taken care of > by i9xx_set_pipeconf() and a second bit at the encoder level. > > The dsi code was not setting the encoder level dithering enable bit causing > dithering to be disabled, this commit fixes this. > > Signed-off-by: Hans de Goede > --- > drivers/gpu/drm/i915/vlv_dsi.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c > index c10def5efa22..c21cbfa9653c 100644 > --- a/drivers/gpu/drm/i915/vlv_dsi.c > +++ b/drivers/gpu/drm/i915/vlv_dsi.c > @@ -711,6 +711,10 @@ static void intel_dsi_port_enable(struct intel_encoder > *encoder, > LANE_CONFIGURATION_DUAL_LINK_B : > LANE_CONFIGURATION_DUAL_LINK_A; > } > + > + if (intel_dsi->pixel_format != MIPI_DSI_FMT_RGB888) > + temp |= DITHERING_ENABLE; The docs say this was only made to work in C0 stepping. Not sure any BYT-Ts were ever shipped with B2/3, nor am I sure if setting the bit would have any effect there. IMO let's just set the bit and hope for the best. Reviewed-by: Ville Syrjälä > + > /* assert ip_tg_enable signal */ > I915_WRITE(port_ctrl, temp | DPI_ENABLE); > POSTING_READ(port_ctrl); > -- > 2.19.1 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/dsi: Fix pipe_bpp for handling for 6 bpc pixel-formats
On Sat, Dec 01, 2018 at 12:31:45PM +0100, Hans de Goede wrote:
> There are 3 problems with the dsi code's pipe_bpp handling for 6 bpc
> pixel-formats which this commit addresses:
>
> 1) It assumes that the pipe_bpp is the same as the bpp going over the dsi
> lanes. This assumption is not valid for MIPI_DSI_FMT_RGB666, where pipe_bpp
> should be 18 so that we do proper dithering but we actually send 24 bpp
> over the dsi lanes (MIPI_DSI_FMT_RGB666_PACKED sends 18 bpp).
>
> This assumption is enforced by an assert in *_dsi_get_pclk(). This assert
> triggers on the initial hw-state readback on BYT/CHT devices which use
> MIPI_DSI_FMT_RGB666, such as the Prowise PT301 tablet. PIPECONF is set to
> 6BPC / 18 bpp by the GOP, while mipi_dsi_pixel_format_to_bpp() returns 24.
>
> This commits switches the calculations in *_dsi_get_pclk() to use the bpp
> from mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format) which
> returns the bpp going over the mipi lanes and drops the assert.
>
> 2) On BXT bxt_dsi_get_pipe_config() wrongly overrides the pipe_bpp which
> i9xx_get_pipe_config() reads from PIPECONF with the return value from
> mipi_dsi_pixel_format_to_bpp(). This avoids the assert from 1. but is wrong
> since the pipe is actually running at the value configured in PIPECONF.
>
> This commit drops the override of pipe_bpp from bxt_dsi_get_pipe_config().
>
> 3) The dsi encoder's compute_config() never assigns a value to pipe_bpp,
> unlike most other encoders. Falling back on compute_baseline_pipe_bpp()
> which always picks 24. 24 is only correct for MIPI_DSI_FMT_RGB88 for the
> others we should use 18 bpp so that we correctly do 6bpc color dithering.
>
> This commit adds code to intel_dsi_compute_config() to properly set
> pipe_bpp based on intel_dsi->pixel_format.
>
> Signed-off-by: Hans de Goede
lgtm
Reviewed-by: Ville Syrjälä
That said, I think we could make everything less confusing by doing
something like this:
compute_config() {
port_clock = bitrate;
}
get_config() {
port_clock = readout from pll;
crtc_clock = derive from port_clock;
}
> ---
> drivers/gpu/drm/i915/intel_dsi.h | 4 ++--
> drivers/gpu/drm/i915/vlv_dsi.c | 17
> drivers/gpu/drm/i915/vlv_dsi_pll.c | 31 ++
> 3 files changed, 17 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index c888c219835f..c796a2962a43 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -160,7 +160,7 @@ int vlv_dsi_pll_compute(struct intel_encoder *encoder,
> void vlv_dsi_pll_enable(struct intel_encoder *encoder,
> const struct intel_crtc_state *config);
> void vlv_dsi_pll_disable(struct intel_encoder *encoder);
> -u32 vlv_dsi_get_pclk(struct intel_encoder *encoder, int pipe_bpp,
> +u32 vlv_dsi_get_pclk(struct intel_encoder *encoder,
>struct intel_crtc_state *config);
> void vlv_dsi_reset_clocks(struct intel_encoder *encoder, enum port port);
>
> @@ -170,7 +170,7 @@ int bxt_dsi_pll_compute(struct intel_encoder *encoder,
> void bxt_dsi_pll_enable(struct intel_encoder *encoder,
> const struct intel_crtc_state *config);
> void bxt_dsi_pll_disable(struct intel_encoder *encoder);
> -u32 bxt_dsi_get_pclk(struct intel_encoder *encoder, int pipe_bpp,
> +u32 bxt_dsi_get_pclk(struct intel_encoder *encoder,
>struct intel_crtc_state *config);
> void bxt_dsi_reset_clocks(struct intel_encoder *encoder, enum port port);
>
> diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
> index be3af5f6c7a0..c10def5efa22 100644
> --- a/drivers/gpu/drm/i915/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/vlv_dsi.c
> @@ -322,6 +322,11 @@ static bool intel_dsi_compute_config(struct
> intel_encoder *encoder,
> /* DSI uses short packets for sync events, so clear mode flags for DSI
> */
> adjusted_mode->flags = 0;
>
> + if (intel_dsi->pixel_format == MIPI_DSI_FMT_RGB888)
> + pipe_config->pipe_bpp = 24;
> + else
> + pipe_config->pipe_bpp = 18;
> +
> if (IS_GEN9_LP(dev_priv)) {
> /* Enable Frame time stamp based scanline reporting */
> adjusted_mode->private_flags |=
> @@ -1097,10 +1102,8 @@ static void bxt_dsi_get_pipe_config(struct
> intel_encoder *encoder,
> }
>
> fmt = I915_READ(MIPI_DSI_FUNC_PRG(port)) & VID_MODE_FORMAT_MASK;
> - pipe_config->pipe_bpp =
> - mipi_dsi_pixel_format_to_bpp(
> - pixel_format_from_register_bits(fmt));
> - bpp = pipe_config->pipe_bpp;
> + bpp = mipi_dsi_pixel_format_to_bpp(
> + pixel_format_from_register_bits(fmt));
>
> /* Enable Frame time stamo based scanline reporting */
> adjusted_mode->private_flags |=
> @@ -1238,11 +1241,9 @@ static void intel_dsi_get_config(struct
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/ddi: Move DDI port detection to the corresponding helper (rev2)
On Fri, Dec 21, 2018 at 04:02:07PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] drm/i915/ddi: Move DDI port detection to > the corresponding helper (rev2) > URL : https://patchwork.freedesktop.org/series/54341/ > State : success Thanks for the review, pushed patches 1 and 2 to -dinq. Any chance Jani to get some comment on patch 3? > > == Summary == > > CI Bug Log - changes from CI_DRM_5336_full -> Patchwork_11141_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Known issues > > > Here are the changes found in Patchwork_11141_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_schedule@pi-ringfull-blt: > - shard-skl: NOTRUN -> FAIL [fdo#103158] > > * igt@gem_ppgtt@blt-vs-render-ctxn: > - shard-skl: PASS -> TIMEOUT [fdo#108039] > > * igt@i915_selftest@live_workarounds: > - shard-iclb: PASS -> DMESG-FAIL [fdo#108954] > > * igt@i915_suspend@shrink: > - shard-skl: NOTRUN -> DMESG-WARN [fdo#108784] > > * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: > - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 > > * igt@kms_busy@extended-pageflip-hang-newfb-render-c: > - shard-glk: PASS -> DMESG-WARN [fdo#107956] > > * igt@kms_color@pipe-c-ctm-max: > - shard-apl: PASS -> FAIL [fdo#108147] > > * igt@kms_cursor_crc@cursor-128x128-onscreen: > - shard-skl: NOTRUN -> FAIL [fdo#103232] +1 > > * igt@kms_cursor_crc@cursor-128x128-suspend: > - shard-iclb: NOTRUN -> FAIL [fdo#103232] > > * igt@kms_cursor_crc@cursor-256x256-onscreen: > - shard-skl: PASS -> FAIL [fdo#103232] +1 > > * igt@kms_cursor_crc@cursor-256x85-sliding: > - shard-apl: PASS -> FAIL [fdo#103232] > > * igt@kms_flip@basic-flip-vs-wf_vblank: > - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +9 > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: > - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +4 > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-gtt: > - shard-apl: PASS -> FAIL [fdo#103167] +1 > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite: > - shard-skl: PASS -> FAIL [fdo#103167] +3 > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: > - shard-glk: PASS -> FAIL [fdo#103167] +4 > > * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-blt: > - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +5 > > * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt: > - shard-iclb: PASS -> FAIL [fdo#103167] +2 > > * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: > - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] +1 > > * igt@kms_plane_alpha_blend@pipe-a-alpha-basic: > - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] > > * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: > - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145] > > * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: > - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 > > * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: > - shard-glk: PASS -> FAIL [fdo#103166] +4 > > * igt@kms_plane_multiple@atomic-pipe-c-tiling-x: > - shard-apl: PASS -> FAIL [fdo#103166] +1 > > * igt@kms_plane_multiple@atomic-pipe-c-tiling-y: > - shard-iclb: PASS -> FAIL [fdo#103166] > > * igt@kms_setmode@basic: > - shard-kbl: PASS -> FAIL [fdo#99912] > > * igt@kms_sysfs_edid_timing: > - shard-iclb: PASS -> FAIL [fdo#100047] > > * igt@pm_rpm@fences: > - shard-iclb: NOTRUN -> INCOMPLETE [fdo#108840] > > * igt@pm_rpm@i2c: > - shard-iclb: PASS -> FAIL [fdo#104097] > > * igt@pm_rpm@universal-planes: > - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108654] / > [fdo#108756] > > * igt@sw_sync@sync_busy_fork: > - shard-iclb: PASS -> INCOMPLETE [fdo#108889] > > > Possible fixes > > * igt@gem_eio@unwedge-stress: > - shard-glk: FAIL [fdo#105957] -> PASS > > * igt@gem_userptr_blits@readonly-unsync: > - shard-skl: TIMEOUT [fdo#108887] -> PASS > > * igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels: > - shard-iclb: DMESG-WARN [fdo#107724] -> PASS +10 > > * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: > - shard-glk: FAIL [fdo#108145] -> PASS > > * igt@kms_chv_cursor_fail@pipe-b-128x128-bottom-edge: > - shard-apl: DMESG-WARN [fdo#103558] / [fdo#105602] -> PASS +11 > > * igt@kms_cursor_crc@cursor-128x128-dpms: > - shard-apl:
[Intel-gfx] [PATCH 2/6] drm/i915: Record the sseu configuration per-context & engine
From: Lionel Landwerlin
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)
v4: rename i915_gem_sseu into intel_sseu (Chris)
use to_intel_context() (Chris)
v5: More to_intel_context() (Tvrtko)
Switch intel_sseu from union to struct (Tvrtko)
Move context default sseu in existing loop (Chris)
v6: s/intel_sseu_from_device_sseu/intel_device_default_sseu/ (Tvrtko)
Tvrtko Ursulin:
v7:
* Pass intel_sseu by pointer instead of value to make_rpcs.
* Rebase for make_rpcs changes.
v8:
* Rebase for RPCS edit on pin.
v9:
* Rebase for context image setup changes.
v10:
* Rename dev_priv to i915. (Chris Wilson)
v11:
* Rebase.
v12:
* Rebase for IS_GEN changes.
v13:
* Rebase for RUNTIME_INFO.
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 14 +++
drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_gem_context.h | 4
drivers/gpu/drm/i915/i915_request.h | 10
drivers/gpu/drm/i915/intel_lrc.c| 31 +
5 files changed, 46 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 956c1c86f90d..d9120b70d9b4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3331,6 +3331,20 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
return (struct intel_device_info *)INTEL_INFO(dev_priv);
}
+static inline struct intel_sseu
+intel_device_default_sseu(struct drm_i915_private *i915)
+{
+ const struct sseu_dev_info *sseu = _INFO(i915)->sseu;
+ struct intel_sseu value = {
+ .slice_mask = sseu->slice_mask,
+ .subslice_mask = sseu->subslice_mask[0],
+ .min_eus_per_subslice = sseu->max_eus_per_subslice,
+ .max_eus_per_subslice = sseu->max_eus_per_subslice,
+ };
+
+ return value;
+}
+
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
extern int intel_modeset_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5933adbe3d99..a182045e3808 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -342,6 +342,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct intel_context *ce = >__engine[n];
ce->gem_context = ctx;
+ /* Use the whole device by default */
+ ce->sseu = intel_device_default_sseu(dev_priv);
}
INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index f6d870b1f73e..ef04e422cf9a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -31,6 +31,7 @@
#include "i915_gem.h"
#include "i915_scheduler.h"
+#include "intel_device_info.h"
struct pid;
@@ -171,6 +172,9 @@ struct i915_gem_context {
int pin_count;
const struct intel_context_ops *ops;
+
+ /** sseu: Control eu/slice partitioning */
+ struct intel_sseu sseu;
} __engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index d014b0605445..907bd8f11aeb 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -38,6 +38,16 @@ struct drm_i915_gem_object;
struct i915_request;
struct i915_timeline;
+/*
+ * Powergating configuration for a particular (context,engine).
+ */
+struct intel_sseu {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 min_eus_per_subslice;
+ u8 max_eus_per_subslice;
+};
+
struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 24328745a0ea..31bf84b22e61 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1169,7 +1169,8 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
}
-static u32 make_rpcs(struct drm_i915_private *dev_priv);
+static u32
+make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu);
static void
__execlists_update_reg_state(struct intel_engine_cs *engine,
@@
[Intel-gfx] [PATCH 6/6] drm/i915/selftests: Context SSEU reconfiguration tests
From: Tvrtko Ursulin
Exercise the context image reconfiguration logic for idle and busy
contexts, with the resets thrown into the mix as well.
Free from the uAPI restrictions this test runs on all Gen9+ platforms
with slice power gating.
v2:
* Rename some helpers for clarity.
* Include subtest names in error logs.
* Remove unnecessary function export.
v3:
* Rebase for RUNTIME_INFO.
v4:
* Fix incomplete unexport from v2. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 31 +-
.../gpu/drm/i915/selftests/i915_gem_context.c | 481 ++
2 files changed, 502 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index f65d3e9089b6..0444cfa96cf5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1042,23 +1042,19 @@ gen8_modify_rpcs_gpu(struct intel_context *ce,
}
static int
-i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
- struct intel_engine_cs *engine,
- struct intel_sseu sseu)
+__i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
{
struct intel_context *ce = to_intel_context(ctx, engine);
- int ret;
+ int ret = 0;
GEM_BUG_ON(INTEL_GEN(ctx->i915) < 8);
GEM_BUG_ON(engine->id != RCS);
- ret = mutex_lock_interruptible(>i915->drm.struct_mutex);
- if (ret)
- return ret;
-
/* Nothing to do if unmodified. */
if (!memcmp(>sseu, , sizeof(sseu)))
- goto out;
+ return 0;
/*
* If context is not idle we have to submit an ordered request to modify
@@ -1071,7 +1067,22 @@ i915_gem_context_reconfigure_sseu(struct
i915_gem_context *ctx,
if (!ret)
ce->sseu = sseu;
-out:
+ return ret;
+}
+
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ int ret;
+
+ ret = mutex_lock_interruptible(>i915->drm.struct_mutex);
+ if (ret)
+ return ret;
+
+ ret = __i915_gem_context_reconfigure_sseu(ctx, engine, sseu);
+
mutex_unlock(>i915->drm.struct_mutex);
return ret;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 4cba50679607..91ceacd81de6 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -27,6 +27,8 @@
#include "../i915_selftest.h"
#include "i915_random.h"
#include "igt_flush_test.h"
+#include "igt_reset.h"
+#include "igt_spinner.h"
#include "mock_drm.h"
#include "mock_gem_device.h"
@@ -653,6 +655,484 @@ static int igt_ctx_exec(void *arg)
return err;
}
+static struct i915_vma *rpcs_query_batch(struct i915_vma *vma)
+{
+ struct drm_i915_gem_object *obj;
+ u32 *cmd;
+ int err;
+
+ if (INTEL_GEN(vma->vm->i915) < 8)
+ return ERR_PTR(-EINVAL);
+
+ obj = i915_gem_object_create_internal(vma->vm->i915, PAGE_SIZE);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+
+ cmd = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ if (IS_ERR(cmd)) {
+ err = PTR_ERR(cmd);
+ goto err;
+ }
+
+ *cmd++ = MI_STORE_REGISTER_MEM_GEN8;
+ *cmd++ = i915_mmio_reg_offset(GEN8_R_PWR_CLK_STATE);
+ *cmd++ = lower_32_bits(vma->node.start);
+ *cmd++ = upper_32_bits(vma->node.start);
+ *cmd = MI_BATCH_BUFFER_END;
+
+ i915_gem_object_unpin_map(obj);
+
+ err = i915_gem_object_set_to_gtt_domain(obj, false);
+ if (err)
+ goto err;
+
+ vma = i915_vma_instance(obj, vma->vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ if (err)
+ goto err;
+
+ return vma;
+
+err:
+ i915_gem_object_put(obj);
+ return ERR_PTR(err);
+}
+
+static int
+emit_rpcs_query(struct drm_i915_gem_object *obj,
+ struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct i915_request **rq_out)
+{
+ struct i915_address_space *vm;
+ struct i915_request *rq;
+ struct i915_vma *batch;
+ struct i915_vma *vma;
+ int err;
+
+ GEM_BUG_ON(!ctx->ppgtt);
+ GEM_BUG_ON(!intel_engine_can_store_dword(engine));
+
+ vm = >ppgtt->vm;
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma))
+
Re: [Intel-gfx] [PATCH] drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
Quoting Mika Kuoppala (2019-01-15 14:44:13)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2019-01-15 10:45:50)
> >> Chris Wilson writes:
> >>
> >> > drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or
> >> > member 'wakeref' not described in 'i915_perf_stream'
> >> >
> >> > Reported-by: kbuild-...@01.org
> >> > Fixes: 6619c0075f78 ("drm/i915/perf: Track the rpm wakeref")
> >> > Signed-off-by: Chris Wilson
> >> > Cc: Mika Kuoppala
> >>
> >> Reviewed-by: Mika Kuoppala
> >
> > Thanks for the quick review, pushed.
>
> It was too quick, not noticing the subject typo. Ahwell..
Into the doghouse you go. Just a Freudian slip.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915: Add timeline barrier support
From: Tvrtko Ursulin
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it automatically gets
cleared and things continue as normal.
This facility will be used by the upcoming context SSEU code.
v2:
* Assert barrier has been retired on timeline_fini. (Chris Wilson)
* Fix mock_timeline.
v3:
* Improved comment language. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 13 +
drivers/gpu/drm/i915/i915_timeline.c | 3 +++
drivers/gpu/drm/i915/i915_timeline.h | 27 +++
.../gpu/drm/i915/selftests/mock_timeline.c| 2 ++
4 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d1355154886a..496217305a00 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -509,6 +509,15 @@ i915_request_alloc_slow(struct intel_context *ce)
return kmem_cache_alloc(ce->gem_context->i915->requests, GFP_KERNEL);
}
+static int add_timeline_barrier(struct i915_request *rq)
+{
+ struct i915_request *barrier =
+ i915_gem_active_raw(>timeline->barrier,
+ >i915->drm.struct_mutex);
+
+ return barrier ? i915_request_await_dma_fence(rq, >fence) : 0;
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -652,6 +661,10 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
*/
rq->head = rq->ring->emit;
+ ret = add_timeline_barrier(rq);
+ if (ret)
+ goto err_unwind;
+
ret = engine->request_alloc(rq);
if (ret)
goto err_unwind;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 4667cc08c416..5a87c5bd5154 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -37,6 +37,8 @@ void i915_timeline_init(struct drm_i915_private *i915,
INIT_LIST_HEAD(>requests);
i915_syncmap_init(>sync);
+
+ init_request_active(>barrier, NULL);
}
/**
@@ -69,6 +71,7 @@ void i915_timelines_park(struct drm_i915_private *i915)
void i915_timeline_fini(struct i915_timeline *timeline)
{
GEM_BUG_ON(!list_empty(>requests));
+ GEM_BUG_ON(i915_gem_active_isset(>barrier));
i915_syncmap_free(>sync);
diff --git a/drivers/gpu/drm/i915/i915_timeline.h
b/drivers/gpu/drm/i915/i915_timeline.h
index 38c1e15e927a..af6c05333d76 100644
--- a/drivers/gpu/drm/i915/i915_timeline.h
+++ b/drivers/gpu/drm/i915/i915_timeline.h
@@ -64,6 +64,16 @@ struct i915_timeline {
*/
struct i915_syncmap *sync;
+ /**
+* Barrier provides the ability to serialize ordering between different
+* timelines.
+*
+* Users can call i915_timeline_set_barrier which will make all
+* subsequent submissions to this timeline be executed only after the
+* barrier has been completed.
+*/
+ struct i915_gem_active barrier;
+
struct list_head link;
const char *name;
@@ -136,4 +146,21 @@ static inline bool i915_timeline_sync_is_later(struct
i915_timeline *tl,
void i915_timelines_park(struct drm_i915_private *i915);
+/**
+ * i915_timeline_set_barrier - orders submission between different timelines
+ * @timeline: timeline to set the barrier on
+ * @rq: request after which new submissions can proceed
+ *
+ * Sets the passed in request as the serialization point for all subsequent
+ * submissions on @timeline. Subsequent requests will not be submitted to GPU
+ * until the barrier has been completed.
+ */
+static inline void
+i915_timeline_set_barrier(struct i915_timeline *timeline,
+ struct i915_request *rq)
+{
+ GEM_BUG_ON(timeline->fence_context == rq->timeline->fence_context);
+ i915_gem_active_set(>barrier, rq);
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/selftests/mock_timeline.c
b/drivers/gpu/drm/i915/selftests/mock_timeline.c
index dcf3b16f5a07..a718b64c988e 100644
--- a/drivers/gpu/drm/i915/selftests/mock_timeline.c
+++ b/drivers/gpu/drm/i915/selftests/mock_timeline.c
@@ -19,6 +19,8 @@ void mock_timeline_init(struct i915_timeline *timeline, u64
context)
i915_syncmap_init(>sync);
+ init_request_active(>barrier, NULL);
+
INIT_LIST_HEAD(>link);
}
--
2.17.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
From: Tvrtko Ursulin
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg =
{ .param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer()
};
/* Query device defaults. */
gem_context_get_param(fd, );
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, );
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context (Chris)
v7: Synchronize the requests following a powergating setting change using a
global
dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users (Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris
[Intel-gfx] [PATCH 1/6] drm/i915/execlists: Move RPCS setup to context pin
From: Tvrtko Ursulin
Configuring RPCS in context image just before pin is sufficient and will
come extra handy in one of the following patches.
v2:
* Split image setup a bit differently. (Chris Wilson)
v3:
* Update context image after reset as well - otherwise the application
of pinned default state clears the RPCS.
v4:
* Use local variable throughout the function. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_lrc.c | 45
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 608458b92db3..24328745a0ea 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1169,6 +1169,24 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
}
+static u32 make_rpcs(struct drm_i915_private *dev_priv);
+
+static void
+__execlists_update_reg_state(struct intel_engine_cs *engine,
+struct intel_context *ce)
+{
+ u32 *regs = ce->lrc_reg_state;
+ struct intel_ring *ring = ce->ring;
+
+ regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(ring->vma);
+ regs[CTX_RING_HEAD + 1] = ring->head;
+ regs[CTX_RING_TAIL + 1] = ring->tail;
+
+ /* RPCS */
+ if (engine->class == RENDER_CLASS)
+ regs[CTX_R_PWR_CLK_STATE + 1] = make_rpcs(engine->i915);
+}
+
static struct intel_context *
__execlists_context_pin(struct intel_engine_cs *engine,
struct i915_gem_context *ctx,
@@ -1207,10 +1225,8 @@ __execlists_context_pin(struct intel_engine_cs *engine,
GEM_BUG_ON(!intel_ring_offset_valid(ce->ring, ce->ring->head));
ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
- ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
- i915_ggtt_offset(ce->ring->vma);
- ce->lrc_reg_state[CTX_RING_HEAD + 1] = ce->ring->head;
- ce->lrc_reg_state[CTX_RING_TAIL + 1] = ce->ring->tail;
+
+ __execlists_update_reg_state(engine, ce);
ce->state->obj->pin_global++;
i915_gem_context_get(ctx);
@@ -1834,14 +1850,14 @@ static void execlists_reset(struct intel_engine_cs
*engine,
engine->pinned_default_state + LRC_STATE_PN * PAGE_SIZE,
engine->context_size - PAGE_SIZE);
}
- execlists_init_reg_state(regs,
-request->gem_context, engine, request->ring);
/* Move the RING_HEAD onto the breadcrumb, past the hanging batch */
- regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(request->ring->vma);
-
request->ring->head = intel_ring_wrap(request->ring, request->postfix);
- regs[CTX_RING_HEAD + 1] = request->ring->head;
+
+ execlists_init_reg_state(regs, request->gem_context, engine,
+request->ring);
+
+ __execlists_update_reg_state(engine, request->hw_context);
intel_ring_update_space(request->ring);
@@ -2530,8 +2546,7 @@ static void execlists_init_reg_state(u32 *regs,
if (rcs) {
regs[CTX_LRI_HEADER_2] = MI_LOAD_REGISTER_IMM(1);
- CTX_REG(regs, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
- make_rpcs(dev_priv));
+ CTX_REG(regs, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE, 0);
i915_oa_init_reg_state(engine, ctx, regs);
}
@@ -2692,12 +2707,8 @@ void intel_lr_context_resume(struct drm_i915_private
*i915)
intel_ring_reset(ce->ring, 0);
- if (ce->pin_count) { /* otherwise done in context_pin */
- u32 *regs = ce->lrc_reg_state;
-
- regs[CTX_RING_HEAD + 1] = ce->ring->head;
- regs[CTX_RING_TAIL + 1] = ce->ring->tail;
- }
+ if (ce->pin_count) /* otherwise done in context_pin */
+ __execlists_update_reg_state(engine, ce);
}
}
}
--
2.17.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915/perf: lock powergating configuration to default when active
From: Lionel Landwerlin
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.
Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.
Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active.
On most platforms there are no issues with this apart from a performance
penality for some media workloads that benefit from running on a partially
powergated GPU. We already prevent RC6 from affecting the programming so
it doesn't sound completely unreasonable to hold on powergating for the
same reason.
On Icelake however there would a functional problem if the slices not-
containing the VME block were left enabled with a running media workload
which explicitly disabled them. To avoid a GPU hang in this case, on
Icelake we lock the enablement to only slices which contain VME blocks.
Downside is that it means degraded GPU performance when OA is active but
there is no known alternative solution for this.
v2: Leave RPCS programming in intel_lrc.c (Lionel)
v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Tvrtko Ursulin:
v4:
* Rebase for make_rpcs changes.
v5:
* Apply OA restriction from make_rpcs directly.
v6:
* Rebase for context image setup changes.
v7:
* Move stream assignment before metric enable.
v8-9:
* Rebase.
v10:
* Squashed with ICL support patch.
Bspec: 21140
Co-Developed-by: Tvrtko Ursulin
Signed-off-by: Lionel Landwerlin
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Reviewed-by: Chris Wilson # v9
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_perf.c | 13 ++---
drivers/gpu/drm/i915/intel_lrc.c | 46
drivers/gpu/drm/i915/intel_lrc.h | 2 ++
3 files changed, 46 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index faff6cf1aaa1..07170e49ecb3 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1677,6 +1677,11 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
+
+ CTX_REG(reg_state, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
+ gen8_make_rpcs(dev_priv,
+ _intel_context(ctx,
+dev_priv->engine[RCS])->sseu));
}
/*
@@ -2098,21 +2103,21 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
if (ret)
goto err_lock;
+ stream->ops = _oa_stream_ops;
+ dev_priv->perf.oa.exclusive_stream = stream;
+
ret = dev_priv->perf.oa.ops.enable_metric_set(stream);
if (ret) {
DRM_DEBUG("Unable to enable metric set\n");
goto err_enable;
}
- stream->ops = _oa_stream_ops;
-
- dev_priv->perf.oa.exclusive_stream = stream;
-
mutex_unlock(_priv->drm.struct_mutex);
return 0;
err_enable:
+ dev_priv->perf.oa.exclusive_stream = NULL;
dev_priv->perf.oa.ops.disable_metric_set(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 31bf84b22e61..f32be56ec503 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1169,9 +1169,6 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
}
-static u32
-make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu);
-
static void
__execlists_update_reg_state(struct intel_engine_cs *engine,
struct intel_context *ce)
@@ -1185,8 +1182,8 @@ __execlists_update_reg_state(struct intel_engine_cs
*engine,
/* RPCS */
if (engine->class == RENDER_CLASS)
-
[Intel-gfx] [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
Hi all, I would like to have some Acked-by's from you, the distro media folks Cc'd here, to document your intent to start using Intel's new media driver[1]. So if you recognize yourself (or are otherwise interested), please read on. TL;DR Distro folks, please give your Acked-by on patch [5/6] I believe most are already aware of the situation that Intel is moving to the new codebase for libva backend to support new Intel integrated graphics devices. The existing intel-libva-driver will be continue to be be supported for pre-Icelake platforms (https://patchwork.freedesktop.org/series/49190/ The userspace changes are reviewed and rebased here: https://github.com/intel/media-driver/pull/271 https://github.com/intel/media-driver/pull/463 Best Regards, Joonas Lahtinen Cc: dri-de...@lists.freedesktop.org Cc: Timo Aaltonen Cc: Takashi Iwai Cc: Stephane Marchesin Cc: Dave Airlie Cc: Daniel Vetter PS. This series might result in some CI failures reported as it adds new uAPI and Patchwork / CI synchronization of tests and kernel is currently WIP. [1] https://github.com/intel/media-driver [2] https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements Lionel Landwerlin (2): drm/i915: Record the sseu configuration per-context & engine drm/i915/perf: lock powergating configuration to default when active Tvrtko Ursulin (4): drm/i915/execlists: Move RPCS setup to context pin drm/i915: Add timeline barrier support drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) drm/i915/selftests: Context SSEU reconfiguration tests drivers/gpu/drm/i915/i915_drv.h | 14 + drivers/gpu/drm/i915/i915_gem_context.c | 354 - drivers/gpu/drm/i915/i915_gem_context.h | 10 + drivers/gpu/drm/i915/i915_perf.c | 13 +- drivers/gpu/drm/i915/i915_request.c | 13 + drivers/gpu/drm/i915/i915_request.h | 10 + drivers/gpu/drm/i915/i915_timeline.c | 3 + drivers/gpu/drm/i915/i915_timeline.h | 27 + drivers/gpu/drm/i915/intel_lrc.c | 100 ++-- drivers/gpu/drm/i915/intel_lrc.h | 2 + .../gpu/drm/i915/selftests/i915_gem_context.c | 481 ++ .../gpu/drm/i915/selftests/mock_timeline.c| 2 + include/uapi/drm/i915_drm.h | 64 +++ 13 files changed, 1056 insertions(+), 37 deletions(-) -- 2.17.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-01-15 10:45:50)
>> Chris Wilson writes:
>>
>> > drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or
>> > member 'wakeref' not described in 'i915_perf_stream'
>> >
>> > Reported-by: kbuild-...@01.org
>> > Fixes: 6619c0075f78 ("drm/i915/perf: Track the rpm wakeref")
>> > Signed-off-by: Chris Wilson
>> > Cc: Mika Kuoppala
>>
>> Reviewed-by: Mika Kuoppala
>
> Thanks for the quick review, pushed.
It was too quick, not noticing the subject typo. Ahwell..
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Split out drm_probe_helper.h
Hi Daniel, Thank you for the patch. On Tuesday, 15 January 2019 12:41:37 EET Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. > > v2: Make it compile. There was so much compile fail on arm drivers > that I figured I'll better not include any of the acks on v1. > > v3: Massive rebase because i915 has lost a lot of drmP.h includes, but > not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h > there was still one, which this patch largely removes. Which means > rolling out lots more includes all over. > > This will also conflict with ongoing drmP.h cleanup by others I > expect. > > v3: Rebase on top of atomic bochs. > > Cc: Sam Ravnborg > Cc: Jani Nikula > Cc: Laurent Pinchart > Acked-by: Rodrigo Vivi (v2) > Acked-by: Benjamin Gaignard (v2) > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: etna...@lists.freedesktop.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-gfx@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-te...@vger.kernel.org > Cc: xen-de...@lists.xen.org > --- > Merging this is going to be a bit a mess due to all the ongoing drmP.h > cleanups. I think the following should work: > - Apply Sam's prep patches for removing drmP.h from > drm_modeset_helper.h > - Get the i915 drmP.h cleanup backmerged into drm-misc-next > - Apply this patch. > - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h > - All through drm-misc-next, which has some potential for trivial > conflicts around #includes with other drivers unfortunately. > > I hope there's no other driver who'll blow up accidentally because > someone else is doing a drmP.h cleanup. Laurent maybe? There's a drmP.h cleanup in the R-Car DU driver, but it doesn't conflict with this patch, the combination of both compiles fine. > Jani, ack on this? > -Daniel > --- [snip] > drivers/gpu/drm/bridge/adv7511/adv7511.h | 5 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 2 +- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > drivers/gpu/drm/drm_atomic_helper.c | 1 - > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > drivers/gpu/drm/drm_probe_helper.c| 2 +- > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > drivers/gpu/drm/omapdrm/omap_connector.c | 2 +- > drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +- > drivers/gpu/drm/omapdrm/omap_drv.c| 2 +- > drivers/gpu/drm/omapdrm/omap_drv.h| 2 +- > drivers/gpu/drm/omapdrm/omap_encoder.c| 2 +- > drivers/gpu/drm/omapdrm/omap_fb.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +- > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 1 + > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 1 + > drivers/gpu/drm/shmobile/shmob_drm_kms.c | 1 + > include/drm/drm_crtc_helper.h | 16 -- > include/drm/drm_probe_helper.h| 50 +++ For the above files, with the comments below addressed, Reviewed-by: Laurent Pinchart > 227 files changed, 289 insertions(+), 200 deletions(-) > create mode 100644 include/drm/drm_probe_helper.h [snip] > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h > b/drivers/gpu/drm/bridge/adv7511/adv7511.h index 73d8ccb97742..d52ffab41eb4 > 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h > @@ -14,8 +14,11 @@ > #include > #include > > -#include > +#include The probe helpers are needed in adv7511_drv.c only, I would move the include there. > #include > +#include > +#include > +#include Please keep the headers alphabetically sorted, here and in all other drivers. > #define ADV7511_REG_CHIP_REVISION0x00 > #define
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Add a new "remapped" gtt_view
Quoting Ville Syrjälä (2019-01-15 13:43:41) > On Mon, Jan 14, 2019 at 09:55:10AM +, Tvrtko Ursulin wrote: > > > > On 11/01/2019 19:46, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > To overcome display engine stride limits we'll want to remap the > > > pages in the GTT. To that end we need a new gtt_view type which > > > is just like the "rotated" type except not rotated. > > > > I think I asked this before, so sorry if you also answered it - what > > about rotated setups which go over display engine stride limits? > > We already have the code to do the rotated mapping. The worry, that I think Tvrtko shared, is whether the simple formula for the rotated view could accommodate a rotated, remapped view. Oh, of course it works out, the rotated view is already calculated on a per-CRTC subset. Worry not. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
== Series Details ==
Series: drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
URL : https://patchwork.freedesktop.org/series/55226/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5421_full -> Patchwork_11296_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_11296_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_cpu_reloc@full:
- shard-skl: NOTRUN -> TIMEOUT [fdo#108248]
* igt@gem_userptr_blits@readonly-unsync:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-snb: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +3
* igt@kms_cursor_crc@cursor-128x128-dpms:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-random:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_draw_crc@draw-method-xrgb-mmap-wc-untiled:
- shard-skl: PASS -> FAIL [fdo#108145] / [fdo#108472]
* igt@kms_fbcon_fbt@psr-suspend:
- shard-iclb: NOTRUN -> FAIL [fdo#107882]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +2
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-iclb: NOTRUN -> FAIL [fdo#103167]
* igt@kms_panel_fitting@legacy:
- shard-skl: NOTRUN -> FAIL [fdo#105456]
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-iclb: PASS -> DMESG-FAIL [fdo#103166] / [fdo#107724]
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +2
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk: PASS -> FAIL [fdo#108145] +1
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
- shard-iclb: PASS -> FAIL [fdo#103166]
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-glk: PASS -> DMESG-FAIL [fdo#105763] / [fdo#106538]
* igt@kms_setmode@basic:
- shard-skl: NOTRUN -> FAIL [fdo#99912]
- shard-hsw: PASS -> FAIL [fdo#99912]
* igt@pm_backlight@basic-brightness:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +2
* igt@pm_backlight@fade_with_suspend:
- shard-skl: NOTRUN -> FAIL [fdo#107847]
* igt@pm_rpm@gem-pread:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840]
Possible fixes
* igt@gem_fence_thrash@bo-write-verify-threaded-x:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@gem_softpin@noreloc-s3:
- shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS
- shard-snb: INCOMPLETE [fdo#105411] -> PASS
* igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing:
- shard-iclb: DMESG-WARN [fdo#107724] / [fdo#109225] -> PASS +1
* igt@kms_chv_cursor_fail@pipe-b-256x256-right-edge:
- shard-iclb: DMESG-WARN [fdo#107724] / [fdo#108336] -> PASS +14
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-64x21-onscreen:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled:
- shard-iclb: WARN [fdo#108336] -> PASS +3
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-ytiled:
- shard-skl: FAIL [fdo#103184] -> PASS
* igt@kms_flip@dpms-vs-vblank-race:
- shard-snb: FAIL [fdo#103060] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-iclb: FAIL [fdo#105363] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc:
- shard-snb: {SKIP} [fdo#109271] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-gtt:
- shard-iclb: DMESG-FAIL [fdo#107724] -> PASS +8
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move:
- shard-iclb: FAIL [fdo#103167] -> PASS +1
*
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only dump GPU state on set-wedged if interesting
== Series Details ==
Series: drm/i915: Only dump GPU state on set-wedged if interesting
URL : https://patchwork.freedesktop.org/series/55239/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5424 -> Patchwork_11298
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55239/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_11298 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-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: NOTRUN -> DMESG-WARN [fdo#102505] / [fdo#103558] /
[fdo#105079] / [fdo#105602]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: NOTRUN -> FAIL [fdo#108767]
* igt@kms_flip@basic-flip-vs-modeset:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
Possible fixes
* igt@gem_mmap_gtt@basic-small-copy-xy:
- fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@i915_selftest@live_evict:
- fi-bsw-kefka: DMESG-WARN [fdo#107709] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (45 -> 43)
--
Additional (2): fi-ivb-3770 fi-kbl-7500u
Missing(4): fi-kbl-7567u fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5424 -> Patchwork_11298
CI_DRM_5424: 47fde994f99d9d4c04538b38279e2e9ae4b2c978 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4773: 951e2b1a016b750544d0f42459b13b9c70631c68 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11298: e32046642befd0999a627b13662ad2e086a04c1f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e32046642bef drm/i915: Only dump GPU state on set-wedged if interesting
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11298/
___
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: Split out drm_probe_helper.h
== Series Details ==
Series: drm: Split out drm_probe_helper.h
URL : https://patchwork.freedesktop.org/series/55232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5424 -> Patchwork_11297
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55232/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_11297 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@common-hpd-after-suspend:
- fi-kbl-7500u: NOTRUN -> DMESG-WARN [fdo#102505] / [fdo#103558] /
[fdo#105079] / [fdo#105602]
* igt@kms_flip@basic-flip-vs-modeset:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998] +1
* igt@kms_pipe_crc_basic@hang-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@gem_mmap_gtt@basic-small-copy-xy:
- fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: {SKIP} [fdo#109271] / [fdo#109278] -> PASS +2
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (45 -> 43)
--
Additional (2): fi-ivb-3770 fi-kbl-7500u
Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-apl-guc
Build changes
-
* Linux: CI_DRM_5424 -> Patchwork_11297
CI_DRM_5424: 47fde994f99d9d4c04538b38279e2e9ae4b2c978 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4773: 951e2b1a016b750544d0f42459b13b9c70631c68 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11297: 43cc5973457cf25805a77bc10248e11ff755db84 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
43cc5973457c drm: Split out drm_probe_helper.h
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11297/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Add a new "remapped" gtt_view
On Mon, Jan 14, 2019 at 09:55:10AM +, Tvrtko Ursulin wrote:
>
> On 11/01/2019 19:46, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > To overcome display engine stride limits we'll want to remap the
> > pages in the GTT. To that end we need a new gtt_view type which
> > is just like the "rotated" type except not rotated.
>
> I think I asked this before, so sorry if you also answered it - what
> about rotated setups which go over display engine stride limits?
We already have the code to do the rotated mapping.
>
> > v2: Use intel_remapped_plane_info base type
> > s/unused/unused_mbz/ (Chris)
> > Separate BUILD_BUG_ON()s (Chris)
> > Use I915_GTT_PAGE_SIZE (Chris)
> > v3: Use i915_gem_object_get_dma_address() (Chris)
> > Trim the sg (Tvrtko)
> > v4: Actually trim this time. Limit the max length
> > to one row of pages to keep things simple
> >
> > Cc: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 12
> > drivers/gpu/drm/i915/i915_drv.h | 4 ++
> > drivers/gpu/drm/i915/i915_gem.c | 17 -
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 88 +++
> > drivers/gpu/drm/i915/i915_gem_gtt.h | 25 +--
> > drivers/gpu/drm/i915/i915_vma.c | 6 +-
> > drivers/gpu/drm/i915/i915_vma.h | 3 +
> > drivers/gpu/drm/i915/intel_display.c | 11 +++
> > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > drivers/gpu/drm/i915/selftests/i915_vma.c | 6 +-
> > 10 files changed, 163 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index d460ef522d9c..cab7771799ad 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -196,6 +196,18 @@ describe_obj(struct seq_file *m, struct
> > drm_i915_gem_object *obj)
> >
> > vma->ggtt_view.rotated.plane[1].offset);
> > break;
> >
> > + case I915_GGTT_VIEW_REMAPPED:
> > + seq_printf(m, ", remapped [(%ux%u, stride=%u,
> > offset=%u), (%ux%u, stride=%u, offset=%u)]",
> > +
> > vma->ggtt_view.remapped.plane[0].width,
> > +
> > vma->ggtt_view.remapped.plane[0].height,
> > +
> > vma->ggtt_view.remapped.plane[0].stride,
> > +
> > vma->ggtt_view.remapped.plane[0].offset,
> > +
> > vma->ggtt_view.remapped.plane[1].width,
> > +
> > vma->ggtt_view.remapped.plane[1].height,
> > +
> > vma->ggtt_view.remapped.plane[1].stride,
> > +
> > vma->ggtt_view.remapped.plane[1].offset);
> > + break;
> > +
> > default:
> > MISSING_CASE(vma->ggtt_view.type);
> > break;
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 5df26ccda8a4..cef76cf343c4 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2845,6 +2845,10 @@ i915_gem_object_get_dirty_page(struct
> > drm_i915_gem_object *obj,
> >unsigned int n);
> >
> > dma_addr_t
> > +i915_gem_object_get_dma_address_len(struct drm_i915_gem_object *obj,
> > + unsigned long n,
> > + unsigned int *len);
> > +dma_addr_t
> > i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj,
> > unsigned long n);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index ea85da393662..f65d81f4f3d7 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -6041,16 +6041,29 @@ i915_gem_object_get_dirty_page(struct
> > drm_i915_gem_object *obj,
> > }
> >
> > dma_addr_t
> > -i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj,
> > - unsigned long n)
> > +i915_gem_object_get_dma_address_len(struct drm_i915_gem_object *obj,
> > + unsigned long n,
> > + unsigned int *len)
> > {
> > struct scatterlist *sg;
> > unsigned int offset;
> >
> > sg = i915_gem_object_get_sg(obj, n, );
> > +
> > + if (len)
> > + *len = sg_dma_len(sg) - (offset << PAGE_SHIFT);
> > +
> > return sg_dma_address(sg) + (offset << PAGE_SHIFT);
> > }
> >
> > +dma_addr_t
> > +i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj,
> > + unsigned long n)
> > +{
> > + return
Re: [Intel-gfx] [PATCH] drm/i915: Pass down rc in intel_encoder->compute_config()
On Mon, Jan 14, 2019 at 05:29:31PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that means we have the potential to hit a normal modeset
> deadlock. However, because ->compute_config() only returns a bool this
> means we can't return -EDEADLK when we need to drop locks and try again
> which means we end up just failing the atomic check permanently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 8 +++
> drivers/gpu/drm/i915/intel_crt.c | 34 ++--
> drivers/gpu/drm/i915/intel_ddi.c | 6 ++---
> drivers/gpu/drm/i915/intel_display.c | 11 +
> drivers/gpu/drm/i915/intel_dp.c | 32 +-
> drivers/gpu/drm/i915/intel_dp_mst.c | 12 +-
> drivers/gpu/drm/i915/intel_drv.h | 18 +++
> drivers/gpu/drm/i915/intel_dvo.c | 10
> drivers/gpu/drm/i915/intel_hdmi.c| 12 +-
> drivers/gpu/drm/i915/intel_lvds.c| 12 +-
> drivers/gpu/drm/i915/intel_sdvo.c| 14 ++--
> drivers/gpu/drm/i915/intel_tv.c | 8 +++
> drivers/gpu/drm/i915/vlv_dsi.c | 14 ++--
> 13 files changed, 97 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index f3a5f03646ce..355b48d1c937 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
> *encoder,
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
> }
>
> -static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int gen11_dsi_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
> base);
> @@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct
> intel_encoder *encoder,
> pipe_config->clock_set = true;
> pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
>
> - return true;
> + return 0;
> }
>
> static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 33bd2addcbdd..625794883433 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -345,51 +345,51 @@ intel_crt_mode_valid(struct drm_connector *connector,
> return MODE_OK;
> }
>
> -static bool intel_crt_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int intel_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode =
> _config->base.adjusted_mode;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return false;
> + return -EINVAL;
>
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
Please add a newline here while at it.
> - return true;
> + return 0;
> }
>
> -static bool pch_crt_compute_config(struct intel_encoder *encoder,
> -struct intel_crtc_state *pipe_config,
> -struct drm_connector_state *conn_state)
> +static int pch_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode =
> _config->base.adjusted_mode;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return false;
> + return -EINVAL;
>
> pipe_config->has_pch_encoder = true;
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
>
> -
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Split out drm_probe_helper.h
== Series Details == Series: drm: Split out drm_probe_helper.h URL : https://patchwork.freedesktop.org/series/55232/ State : warning == Summary == $ dim checkpatch origin/drm-tip 43cc5973457c drm: Split out drm_probe_helper.h -:606: WARNING:OBSOLETE: drivers/gpu/drm/cirrus/cirrus_drv.c is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. -:609: WARNING:OBSOLETE: drivers/gpu/drm/cirrus/cirrus_drv.c is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. -:618: WARNING:OBSOLETE: drivers/gpu/drm/cirrus/cirrus_mode.c is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. -:621: WARNING:OBSOLETE: drivers/gpu/drm/cirrus/cirrus_mode.c is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. -:3014: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #3014: new file mode 100644 -:3019: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #3019: FILE: include/drm/drm_probe_helper.h:1: +/* -:3068: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 7 warnings, 0 checks, 1879 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Only dump GPU state on set-wedged if interesting
Quoting Mika Kuoppala (2019-01-15 12:50:50)
> Chris Wilson writes:
>
> > As we may frequently mark the device as wedged to flush requests off it
> > during the normal course of events, quite often we have a large state
> > dump that is of no interest. Don't bother dumping it all if the engines
> > are all idle.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 90c167f71345..80264cb9ca7f 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3192,7 +3192,7 @@ void i915_gem_set_wedged(struct drm_i915_private
> > *i915)
> >
> > GEM_TRACE("start\n");
> >
> > - if (GEM_SHOW_DEBUG()) {
> > + if (GEM_SHOW_DEBUG() && !intel_engines_are_idle(i915)) {
>
> This atleast keeps the concurrency on reports at bay
> as wedged driver has only idle engines.
Nah, we are calling i915_gem_set_wedged() concurrently and get
interleaved reports for some errors :)
This is just making CI logging tidier by removing noise.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Only dump GPU state on set-wedged if interesting
Chris Wilson writes:
> As we may frequently mark the device as wedged to flush requests off it
> during the normal course of events, quite often we have a large state
> dump that is of no interest. Don't bother dumping it all if the engines
> are all idle.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 90c167f71345..80264cb9ca7f 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3192,7 +3192,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>
> GEM_TRACE("start\n");
>
> - if (GEM_SHOW_DEBUG()) {
> + if (GEM_SHOW_DEBUG() && !intel_engines_are_idle(i915)) {
This atleast keeps the concurrency on reports at bay
as wedged driver has only idle engines.
Reviewed-by: Mika Kuoppala
> struct drm_printer p = drm_debug_printer(__func__);
>
> for_each_engine(engine, i915, id)
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull the work into the main callback and
avoid the sleight-of-hand in using a workqueue to avoid lockdep.
However, not all paths to mmu_invalidate_range_start are prepared to
handle failure, so instead of reporting the recursion, deal with it by
propagating the failure upwards, who can decide themselves to handle it
or report it.
v2: Mark up the recursive lock behaviour and comment on the various weak
points.
v3: Follow commit 3824e41975ae ("drm/i915: Use mutex_lock_killable() from
inside the shrinker") and also use mutex_lock_killeable().
v3.1: No leak on EINTR.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108375
References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 30 +++-
drivers/gpu/drm/i915/i915_gem_object.h | 7 +
drivers/gpu/drm/i915/i915_gem_userptr.c | 224
4 files changed, 139 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 956c1c86f90d..da055a86db4d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2935,8 +2935,8 @@ enum i915_mm_subclass { /* lockdep subclass for
obj->mm.lock/struct_mutex */
I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
};
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass);
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass);
void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
enum i915_map_type {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0bfed33178e1..90c167f71345 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2303,8 +2303,8 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
*obj)
struct sg_table *pages;
pages = fetch_and_zero(>mm.pages);
- if (!pages)
- return NULL;
+ if (IS_ERR_OR_NULL(pages))
+ return pages;
spin_lock(>mm.obj_lock);
list_del(>mm.link);
@@ -2328,22 +2328,23 @@ __i915_gem_object_unset_pages(struct
drm_i915_gem_object *obj)
return pages;
}
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass)
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass)
{
struct sg_table *pages;
+ int ret;
if (i915_gem_object_has_pinned_pages(obj))
- return;
+ return -EBUSY;
GEM_BUG_ON(obj->bind_count);
- if (!i915_gem_object_has_pages(obj))
- return;
/* May be called by shrinker from within get_pages() (on another bo) */
mutex_lock_nested(>mm.lock, subclass);
- if (unlikely(atomic_read(>mm.pages_pin_count)))
+ if (unlikely(atomic_read(>mm.pages_pin_count))) {
+ ret = -EBUSY;
goto unlock;
+ }
/*
* ->put_pages might need to allocate memory for the bit17 swizzle
@@ -2351,11 +2352,24 @@ void __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj,
* lists early.
*/
pages = __i915_gem_object_unset_pages(obj);
+
+ /*
+* XXX Temporary hijinx to avoid updating all backends to handle
+* NULL pages. In the future, when we have more asynchronous
+* get_pages backends we should be better able to handle the
+* cancellation of the async task in a more uniform manner.
+*/
+ if (!pages && !i915_gem_object_needs_async_cancel(obj))
+ pages = ERR_PTR(-EINVAL);
+
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
+ ret = 0;
unlock:
mutex_unlock(>mm.lock);
+
+ return ret;
}
bool i915_sg_trim(struct sg_table *orig_st)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index ff3da64470dd..cb1b0144d274 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -57,6 +57,7 @@ struct drm_i915_gem_object_ops {
#define I915_GEM_OBJECT_HAS_STRUCT_PAGEBIT(0)
#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
#define I915_GEM_OBJECT_IS_PROXY BIT(2)
+#define I915_GEM_OBJECT_ASYNC_CANCEL BIT(3)
/* Interface between the GEM
Re: [Intel-gfx] [CI] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start
Quoting Tvrtko Ursulin (2019-01-15 12:37:43)
>
> On 15/01/2019 12:17, Chris Wilson wrote:
> > + if (!unlock) {
> > + unlock = >mm->i915->drm.struct_mutex;
> > +
> > + switch (mutex_trylock_recursive(unlock)) {
> > + default:
> > + case MUTEX_TRYLOCK_FAILED:
> > + if (!mutex_lock_killable_nested(unlock,
> > I915_MM_SHRINKER))
> > + return -EINTR;
>
> Need to put object reference here I think.
I knew you would cause trouble, I knew it! You and your fancy error
reporting mutex_lock! :-p
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start
On 15/01/2019 12:17, Chris Wilson wrote:
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull the work into the main callback and
avoid the sleight-of-hand in using a workqueue to avoid lockdep.
However, not all paths to mmu_invalidate_range_start are prepared to
handle failure, so instead of reporting the recursion, deal with it by
propagating the failure upwards, who can decide themselves to handle it
or report it.
v2: Mark up the recursive lock behaviour and comment on the various weak
points.
v3: Follow commit 3824e41975ae ("drm/i915: Use mutex_lock_killable() from
inside the shrinker") and also use mutex_lock_killeable().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108375
References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 30 +++-
drivers/gpu/drm/i915/i915_gem_object.h | 7 +
drivers/gpu/drm/i915/i915_gem_userptr.c | 222 +++-
4 files changed, 137 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 956c1c86f90d..da055a86db4d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2935,8 +2935,8 @@ enum i915_mm_subclass { /* lockdep subclass for
obj->mm.lock/struct_mutex */
I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
};
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass);
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass);
void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
enum i915_map_type {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0bfed33178e1..90c167f71345 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2303,8 +2303,8 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
*obj)
struct sg_table *pages;
pages = fetch_and_zero(>mm.pages);
- if (!pages)
- return NULL;
+ if (IS_ERR_OR_NULL(pages))
+ return pages;
spin_lock(>mm.obj_lock);
list_del(>mm.link);
@@ -2328,22 +2328,23 @@ __i915_gem_object_unset_pages(struct
drm_i915_gem_object *obj)
return pages;
}
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass)
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass)
{
struct sg_table *pages;
+ int ret;
if (i915_gem_object_has_pinned_pages(obj))
- return;
+ return -EBUSY;
GEM_BUG_ON(obj->bind_count);
- if (!i915_gem_object_has_pages(obj))
- return;
/* May be called by shrinker from within get_pages() (on another bo) */
mutex_lock_nested(>mm.lock, subclass);
- if (unlikely(atomic_read(>mm.pages_pin_count)))
+ if (unlikely(atomic_read(>mm.pages_pin_count))) {
+ ret = -EBUSY;
goto unlock;
+ }
/*
* ->put_pages might need to allocate memory for the bit17 swizzle
@@ -2351,11 +2352,24 @@ void __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj,
* lists early.
*/
pages = __i915_gem_object_unset_pages(obj);
+
+ /*
+* XXX Temporary hijinx to avoid updating all backends to handle
+* NULL pages. In the future, when we have more asynchronous
+* get_pages backends we should be better able to handle the
+* cancellation of the async task in a more uniform manner.
+*/
+ if (!pages && !i915_gem_object_needs_async_cancel(obj))
+ pages = ERR_PTR(-EINVAL);
+
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
+ ret = 0;
unlock:
mutex_unlock(>mm.lock);
+
+ return ret;
}
bool i915_sg_trim(struct sg_table *orig_st)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index ff3da64470dd..cb1b0144d274 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -57,6 +57,7 @@ struct drm_i915_gem_object_ops {
#define I915_GEM_OBJECT_HAS_STRUCT_PAGE BIT(0)
#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
#define I915_GEM_OBJECT_IS_PROXY BIT(2)
+#define I915_GEM_OBJECT_ASYNC_CANCEL BIT(3)
/* Interface
Re: [Intel-gfx] [PATCH] drm: Split out drm_probe_helper.h
On 15/01/2019 11:41, Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. > > v2: Make it compile. There was so much compile fail on arm drivers > that I figured I'll better not include any of the acks on v1. > > v3: Massive rebase because i915 has lost a lot of drmP.h includes, but > not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h > there was still one, which this patch largely removes. Which means > rolling out lots more includes all over. > > This will also conflict with ongoing drmP.h cleanup by others I > expect. > > v3: Rebase on top of atomic bochs. > > Cc: Sam Ravnborg > Cc: Jani Nikula > Cc: Laurent Pinchart > Acked-by: Rodrigo Vivi (v2) > Acked-by: Benjamin Gaignard (v2) > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: etna...@lists.freedesktop.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-gfx@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-te...@vger.kernel.org > Cc: xen-de...@lists.xen.org > --- > Merging this is going to be a bit a mess due to all the ongoing drmP.h > cleanups. I think the following should work: > - Apply Sam's prep patches for removing drmP.h from > drm_modeset_helper.h > - Get the i915 drmP.h cleanup backmerged into drm-misc-next > - Apply this patch. > - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h > - All through drm-misc-next, which has some potential for trivial > conflicts around #includes with other drivers unfortunately. > > I hope there's no other driver who'll blow up accidentally because > someone else is doing a drmP.h cleanup. Laurent maybe? > > Jani, ack on this? > -Daniel > --- > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > drivers/gpu/drm/armada/armada_510.c | 2 +- > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > drivers/gpu/drm/armada/armada_crtc.h | 2 + > drivers/gpu/drm/armada/armada_drv.c | 2 +- > drivers/gpu/drm/armada/armada_fb.c| 2 +- > drivers/gpu/drm/ast/ast_drv.c | 1 + > drivers/gpu/drm/ast/ast_mode.c| 1 + > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > drivers/gpu/drm/bridge/adv7511/adv7511.h | 5 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 2 +- > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > drivers/gpu/drm/bridge/panel.c| 2 +- > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > drivers/gpu/drm/bridge/sii902x.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > drivers/gpu/drm/bridge/tc358764.c | 2 +- > drivers/gpu/drm/bridge/tc358767.c | 2 +- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > drivers/gpu/drm/drm_atomic_helper.c | 1 - > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- >
[Intel-gfx] [PATCH] drm/i915: Only dump GPU state on set-wedged if interesting
As we may frequently mark the device as wedged to flush requests off it
during the normal course of events, quite often we have a large state
dump that is of no interest. Don't bother dumping it all if the engines
are all idle.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 90c167f71345..80264cb9ca7f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3192,7 +3192,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
GEM_TRACE("start\n");
- if (GEM_SHOW_DEBUG()) {
+ if (GEM_SHOW_DEBUG() && !intel_engines_are_idle(i915)) {
struct drm_printer p = drm_debug_printer(__func__);
for_each_engine(engine, i915, id)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull the work into the main callback and
avoid the sleight-of-hand in using a workqueue to avoid lockdep.
However, not all paths to mmu_invalidate_range_start are prepared to
handle failure, so instead of reporting the recursion, deal with it by
propagating the failure upwards, who can decide themselves to handle it
or report it.
v2: Mark up the recursive lock behaviour and comment on the various weak
points.
v3: Follow commit 3824e41975ae ("drm/i915: Use mutex_lock_killable() from
inside the shrinker") and also use mutex_lock_killeable().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108375
References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 30 +++-
drivers/gpu/drm/i915/i915_gem_object.h | 7 +
drivers/gpu/drm/i915/i915_gem_userptr.c | 222 +++-
4 files changed, 137 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 956c1c86f90d..da055a86db4d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2935,8 +2935,8 @@ enum i915_mm_subclass { /* lockdep subclass for
obj->mm.lock/struct_mutex */
I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
};
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass);
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass);
void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
enum i915_map_type {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0bfed33178e1..90c167f71345 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2303,8 +2303,8 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
*obj)
struct sg_table *pages;
pages = fetch_and_zero(>mm.pages);
- if (!pages)
- return NULL;
+ if (IS_ERR_OR_NULL(pages))
+ return pages;
spin_lock(>mm.obj_lock);
list_del(>mm.link);
@@ -2328,22 +2328,23 @@ __i915_gem_object_unset_pages(struct
drm_i915_gem_object *obj)
return pages;
}
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass)
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass)
{
struct sg_table *pages;
+ int ret;
if (i915_gem_object_has_pinned_pages(obj))
- return;
+ return -EBUSY;
GEM_BUG_ON(obj->bind_count);
- if (!i915_gem_object_has_pages(obj))
- return;
/* May be called by shrinker from within get_pages() (on another bo) */
mutex_lock_nested(>mm.lock, subclass);
- if (unlikely(atomic_read(>mm.pages_pin_count)))
+ if (unlikely(atomic_read(>mm.pages_pin_count))) {
+ ret = -EBUSY;
goto unlock;
+ }
/*
* ->put_pages might need to allocate memory for the bit17 swizzle
@@ -2351,11 +2352,24 @@ void __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj,
* lists early.
*/
pages = __i915_gem_object_unset_pages(obj);
+
+ /*
+* XXX Temporary hijinx to avoid updating all backends to handle
+* NULL pages. In the future, when we have more asynchronous
+* get_pages backends we should be better able to handle the
+* cancellation of the async task in a more uniform manner.
+*/
+ if (!pages && !i915_gem_object_needs_async_cancel(obj))
+ pages = ERR_PTR(-EINVAL);
+
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
+ ret = 0;
unlock:
mutex_unlock(>mm.lock);
+
+ return ret;
}
bool i915_sg_trim(struct sg_table *orig_st)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index ff3da64470dd..cb1b0144d274 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -57,6 +57,7 @@ struct drm_i915_gem_object_ops {
#define I915_GEM_OBJECT_HAS_STRUCT_PAGEBIT(0)
#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
#define I915_GEM_OBJECT_IS_PROXY BIT(2)
+#define I915_GEM_OBJECT_ASYNC_CANCEL BIT(3)
/* Interface between the GEM object and its backing
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Serialise concurrent calls to i915_gem_set_wedged()
Quoting Mika Kuoppala (2019-01-15 11:56:11) > Chris Wilson writes: > > > Make i915_gem_set_wedged() and i915_gem_unset_wedged() behaviour more > > consistently if called concurrently. > > More is needed in here. The purpose is to make them wait in turns > on top of mutex, instead of racing on the bit? Where is > the inconsistency tho. We report set-wedged multiple times on failure paths. Worse is when we report set-wedged multiple times simultaneously. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/userptr: Probe vma range before gup
Quoting Tvrtko Ursulin (2019-01-15 10:52:52) > > On 15/01/2019 10:41, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-01-15 10:27:02) > >> > >> On 14/01/2019 21:17, Chris Wilson wrote: > >>> + if (err) > >>> + goto err_unlock; > >>> + > >>> + err = __i915_gem_userptr_get_pages_schedule(obj); > >>> + if (err == -EAGAIN) > >>>__i915_gem_userptr_set_active(obj, true); > >>> > >>> - if (IS_ERR(pages)) > >>> - release_pages(pvec, pinned); > >>> - kvfree(pvec); > >>> +err_unlock: > >>> + up_read(>mmap_sem); > >> > >> May be safer to drop the lock earlier, immediately after probe. I don't > >> see holding it while queuing the worker and doing internal book-keeping > >> is useful and might just create more lock chain dependencies. > > > > Hmm, I thought we need to cover up to set-active (probe + queue + insert > > into rbtree) as I thought the mmu-invalidate was under the mmap_sem wlock. > > We have our own lock for set active so I don't see that we need mmap_sem > for it. Certainly wasn't needed before this patch so don't see that > would change now. We had it before this patch, by ensuring that we added the rbtree tracking before we queued the obj for gup, and then serialised inside the mmu-invalidate. > Btw, what you said regarding nested mmap_sem.. do we have lock inversion > with it and obj->mm.lock then? I mean both mmap_sem -> obj->mm.lock and > obj->mm.lock -> mmap_sem chains? Hmm. Yes, there is a recursive read lock here. You want proof that it is just limited to this single instance! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/userptr: Probe vma range before gup
Quoting Tvrtko Ursulin (2019-01-15 10:40:24) > > On 15/01/2019 10:30, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-01-15 10:19:11) > >> > >> On 14/01/2019 21:17, Chris Wilson wrote: > >>> @@ -620,40 +682,24 @@ static int i915_gem_userptr_get_pages(struct > >>> drm_i915_gem_object *obj) > >>>return -EAGAIN; > >>>} > >>> > >>> - pvec = NULL; > >>> - pinned = 0; > >>> + if (mm == current->mm && try_fast_gup(obj) == 0) > >>> + return 0; > >> > >> Is try_fast_gup guaranteed to fail on ranges probe_range would have > >> rejected? > > > > If a page isn't present, it will fail. For our purposes that means > > fast_gup fails for GGTT mmaps, as well as other ranges. > > What if it has been pre-faulted? It will still not have a struct page :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start
Quoting Tvrtko Ursulin (2019-01-15 11:54:15)
>
> On 14/01/2019 21:17, Chris Wilson wrote:
> > -static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier
> > *_mn,
> > - const struct mmu_notifier_range *range)
> > +static struct mutex *__i915_mutex_lock_recursive(struct mutex *m)
> > +{
> > + switch (mutex_trylock_recursive(m)) {
> > + default:
> > + case MUTEX_TRYLOCK_FAILED:
> > + mutex_lock_nested(m, I915_MM_SHRINKER);
>
> Worth using killable and refactoring the caller to handle the failure?
> If this path ends up deadlocking one day it would be slightly better
> that the process can be removed.
Good call.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Serialise concurrent calls to i915_gem_set_wedged()
Chris Wilson writes:
> Make i915_gem_set_wedged() and i915_gem_unset_wedged() behaviour more
> consistently if called concurrently.
More is needed in here. The purpose is to make them wait in turns
on top of mutex, instead of racing on the bit? Where is
the inconsistency tho.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 32 ++-
> drivers/gpu/drm/i915/i915_gpu_error.h | 4 ++-
> .../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
> 3 files changed, 28 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0bfed33178e1..910c49befc50 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3173,10 +3173,15 @@ static void nop_submit_request(struct i915_request
> *request)
>
> void i915_gem_set_wedged(struct drm_i915_private *i915)
> {
> + struct i915_gpu_error *error = >gpu_error;
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
>
> - GEM_TRACE("start\n");
> + mutex_lock(>wedge_mutex);
> + if (test_bit(I915_WEDGED, >flags)) {
> + mutex_unlock(>wedge_mutex);
> + return;
> + }
>
> if (GEM_SHOW_DEBUG()) {
> struct drm_printer p = drm_debug_printer(__func__);
> @@ -3185,8 +3190,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
> intel_engine_dump(engine, , "%s\n", engine->name);
> }
>
> - if (test_and_set_bit(I915_WEDGED, >gpu_error.flags))
> - goto out;
> + GEM_TRACE("start\n");
>
> /*
>* First, stop submission to hw, but do not yet complete requests by
> @@ -3222,23 +3226,31 @@ void i915_gem_set_wedged(struct drm_i915_private
> *i915)
> intel_engine_wakeup(engine);
> }
>
> -out:
> + smp_mb__before_atomic();
I was thinking of what state you want to guard against as you
now hold the mutex for wedging. But the answer must: any other
external state. Make everything visible before flipping the bit.
-Mika
> + set_bit(I915_WEDGED, >flags);
> +
> GEM_TRACE("end\n");
> + mutex_unlock(>wedge_mutex);
>
> - wake_up_all(>gpu_error.reset_queue);
> + wake_up_all(>reset_queue);
> }
>
> bool i915_gem_unset_wedged(struct drm_i915_private *i915)
> {
> + struct i915_gpu_error *error = >gpu_error;
> struct i915_timeline *tl;
> + bool ret = false;
>
> lockdep_assert_held(>drm.struct_mutex);
> - if (!test_bit(I915_WEDGED, >gpu_error.flags))
> +
> + if (!test_bit(I915_WEDGED, >flags))
> return true;
>
> if (!i915->gt.scratch) /* Never full initialised, recovery impossible */
> return false;
>
> + mutex_lock(>wedge_mutex);
> +
> GEM_TRACE("start\n");
>
> /*
> @@ -3272,7 +3284,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private
> *i915)
>*/
> if (dma_fence_default_wait(>fence, true,
> MAX_SCHEDULE_TIMEOUT) < 0)
> - return false;
> + goto unlock;
> }
> i915_retire_requests(i915);
> GEM_BUG_ON(i915->gt.active_requests);
> @@ -3295,8 +3307,11 @@ bool i915_gem_unset_wedged(struct drm_i915_private
> *i915)
>
> smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
> clear_bit(I915_WEDGED, >gpu_error.flags);
> + ret = true;
> +unlock:
> + mutex_unlock(>gpu_error.wedge_mutex);
>
> - return true;
> + return ret;
> }
>
> static void
> @@ -5692,6 +5707,7 @@ int i915_gem_init_early(struct drm_i915_private
> *dev_priv)
> i915_gem_idle_work_handler);
> init_waitqueue_head(_priv->gpu_error.wait_queue);
> init_waitqueue_head(_priv->gpu_error.reset_queue);
> + mutex_init(_priv->gpu_error.wedge_mutex);
>
> atomic_set(_priv->mm.bsd_engine_dispatch_index, 0);
>
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
> b/drivers/gpu/drm/i915/i915_gpu_error.h
> index 6d9f45468ac1..604291f7762d 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.h
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.h
> @@ -271,8 +271,8 @@ struct i915_gpu_error {
> #define I915_RESET_BACKOFF 0
> #define I915_RESET_HANDOFF 1
> #define I915_RESET_MODESET 2
> +#define I915_RESET_ENGINE3
> #define I915_WEDGED (BITS_PER_LONG - 1)
> -#define I915_RESET_ENGINE(I915_WEDGED - I915_NUM_ENGINES)
>
> /** Number of times an engine has been reset */
> u32 reset_engine_count[I915_NUM_ENGINES];
> @@ -283,6 +283,8 @@ struct i915_gpu_error {
> /** Reason for the current *global* reset */
> const char *reason;
>
> + struct mutex wedge_mutex; /* serialises wedging/unwedging */
> +
> /**
>* Waitqueue to signal when a hang is detected. Used to for waiters
>* to release the struct_mutex
Re: [Intel-gfx] [PATCH 2/3] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start
On 14/01/2019 21:17, Chris Wilson wrote:
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull the work into the main callback and
avoid the sleight-of-hand in using a workqueue to avoid lockdep.
However, not all paths to mmu_invalidate_range_start are prepared to
handle failure, so instead of reporting the recursion, deal with it by
propagating the failure upwards, who can decide themselves to handle it
or report it.
v2: Mark up the recursive lock behaviour and comment on the various weak
points.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108375
References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 30 +++-
drivers/gpu/drm/i915/i915_gem_object.h | 7 +
drivers/gpu/drm/i915/i915_gem_userptr.c | 220 +++-
4 files changed, 135 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fa99824f63b3..4b67037c0318 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2931,8 +2931,8 @@ enum i915_mm_subclass { /* lockdep subclass for
obj->mm.lock/struct_mutex */
I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
};
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass);
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass);
void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
enum i915_map_type {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0bfed33178e1..90c167f71345 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2303,8 +2303,8 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
*obj)
struct sg_table *pages;
pages = fetch_and_zero(>mm.pages);
- if (!pages)
- return NULL;
+ if (IS_ERR_OR_NULL(pages))
+ return pages;
spin_lock(>mm.obj_lock);
list_del(>mm.link);
@@ -2328,22 +2328,23 @@ __i915_gem_object_unset_pages(struct
drm_i915_gem_object *obj)
return pages;
}
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass)
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass)
{
struct sg_table *pages;
+ int ret;
if (i915_gem_object_has_pinned_pages(obj))
- return;
+ return -EBUSY;
GEM_BUG_ON(obj->bind_count);
- if (!i915_gem_object_has_pages(obj))
- return;
/* May be called by shrinker from within get_pages() (on another bo) */
mutex_lock_nested(>mm.lock, subclass);
- if (unlikely(atomic_read(>mm.pages_pin_count)))
+ if (unlikely(atomic_read(>mm.pages_pin_count))) {
+ ret = -EBUSY;
goto unlock;
+ }
/*
* ->put_pages might need to allocate memory for the bit17 swizzle
@@ -2351,11 +2352,24 @@ void __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj,
* lists early.
*/
pages = __i915_gem_object_unset_pages(obj);
+
+ /*
+* XXX Temporary hijinx to avoid updating all backends to handle
+* NULL pages. In the future, when we have more asynchronous
+* get_pages backends we should be better able to handle the
+* cancellation of the async task in a more uniform manner.
+*/
+ if (!pages && !i915_gem_object_needs_async_cancel(obj))
+ pages = ERR_PTR(-EINVAL);
+
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
+ ret = 0;
unlock:
mutex_unlock(>mm.lock);
+
+ return ret;
}
bool i915_sg_trim(struct sg_table *orig_st)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index ff3da64470dd..cb1b0144d274 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -57,6 +57,7 @@ struct drm_i915_gem_object_ops {
#define I915_GEM_OBJECT_HAS_STRUCT_PAGE BIT(0)
#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
#define I915_GEM_OBJECT_IS_PROXY BIT(2)
+#define I915_GEM_OBJECT_ASYNC_CANCEL BIT(3)
/* Interface between the GEM object and its backing storage.
* get_pages() is called once prior to the use of the associated set
@@ -387,6 +388,12 @@
Re: [Intel-gfx] Forced push done to drm-intel-next-queued
Hi,
On 15-01-19 10:56, Daniel Vetter wrote:
On Thu, Dec 27, 2018 at 04:24:51PM +0100, Hans de Goede wrote:
Hi,
On 27-12-18 15:42, Jani Nikula wrote:
On Tue, 25 Dec 2018, Hans de Goede wrote:
Hi,
As mentioned in the "I messed up drm-intel-next-queued!" mail-thread
I made a big mistake yesterday:
"Ugh, I just messed up drm-intel-next-queued big time.
I somehow rebased my work on top of drm-tip (I believe I did the rebase
in the wrong dir) and then after running a bunch of tests I
did a "dim push-branch drm-intel-next-queued" which pushed the
patches I intended to push rebased on top of drm-tip
pushing drm-tip to dinq :(
I'm so sorry about this.
I just checked my reflog and the last commit before me messing
up is commit d4de753526f4d99f541f1b6ed1d963005c09700c
("drm/i915: Unwind failure on pinning the gen7 ppgtt")"
To fix this I've just done a forced push resetting
drm-intel-next-queued to the mentioned d4de753526f4 commit.
I first checked no-one pushed anything on top of my mess,
but if you pushed anything to drm-intel-next-queued in the
last 24 hours, please double-check it is there.
Once more my apologies for this.
It happens, don't worry about it. Thanks for being open about it instead
of trying to brush it under the rug.
Thanks.
Did you pass -f to dim? I suspect drm-tip wouldn't pass the push checks
in dim without it. Perhaps we'll need to add more.
No I did not pass -f, I did wonder myself how the push managed to
proceed after my screw-up. Looking at how dim builds drm-tip, it seems
it starts with dinq and then merges in other branches, so a push
from a drm-tip based branch to dinq is a fast-forward (I think),
so dinq is special in this case.
Do you still have the git tree you've pushed wrongly and could publish it
somewhere? I'm suprised that dim push didn't catch this, we've added a few
more sanity checks last time around this happened. I'd have expected dim
to complain about all the patches lacking you're signed-off-by, since a
rebase would have changed a lot of patches to be committed by you.
I'm afraid I don't have that tree around anymore. What I did was I accidentally
rebased the 2 patches I wanted to push on top of drm-tip, so I pushed the
last drm-tip push (including the integration manifest) with my 2 patches on top.
So I pushed the latest unmodified state of drm-tip and none of the patches
in there were re-commited by me during the rebase.
Basically what I believe I pushed is a fast-forward from dinq to drm-tip +
the 2 patches I intended to push.
I even did a gitk before pushing to graphically check what I was pushing
(I always do this) and I saw my 2 patches on top of a remote branch, which
looked fine. What I did not notice it was the wrong remote and the wrong
branch. This is something which I've learned to also check now.
One check which I believe would have caught this is checking there are no
merge-commits in what is being pushed and require some commandline option
to override this for special cases.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start
On 15/01/2019 10:00, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-15 09:47:45)
On 14/01/2019 21:17, Chris Wilson wrote:
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull the work into the main callback and
avoid the sleight-of-hand in using a workqueue to avoid lockdep.
However, not all paths to mmu_invalidate_range_start are prepared to
handle failure, so instead of reporting the recursion, deal with it by
propagating the failure upwards, who can decide themselves to handle it
or report it.
v2: Mark up the recursive lock behaviour and comment on the various weak
points.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108375
References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 30 +++-
drivers/gpu/drm/i915/i915_gem_object.h | 7 +
drivers/gpu/drm/i915/i915_gem_userptr.c | 220 +++-
4 files changed, 135 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fa99824f63b3..4b67037c0318 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2931,8 +2931,8 @@ enum i915_mm_subclass { /* lockdep subclass for
obj->mm.lock/struct_mutex */
I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
};
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
- enum i915_mm_subclass subclass);
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass);
void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
enum i915_map_type {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0bfed33178e1..90c167f71345 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2303,8 +2303,8 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
*obj)
struct sg_table *pages;
pages = fetch_and_zero(>mm.pages);
- if (!pages)
- return NULL;
+ if (IS_ERR_OR_NULL(pages))
+ return pages;
spin_lock(>mm.obj_lock);
list_del(>mm.link);
@@ -2328,22 +2328,23 @@ __i915_gem_object_unset_pages(struct
drm_i915_gem_object *obj)
return pages;
}
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
- enum i915_mm_subclass subclass)
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass)
{
struct sg_table *pages;
+ int ret;
if (i915_gem_object_has_pinned_pages(obj))
- return;
+ return -EBUSY;
GEM_BUG_ON(obj->bind_count);
- if (!i915_gem_object_has_pages(obj))
- return;
/* May be called by shrinker from within get_pages() (on another bo) */
mutex_lock_nested(>mm.lock, subclass);
- if (unlikely(atomic_read(>mm.pages_pin_count)))
+ if (unlikely(atomic_read(>mm.pages_pin_count))) {
+ ret = -EBUSY;
goto unlock;
+ }
/*
* ->put_pages might need to allocate memory for the bit17 swizzle
@@ -2351,11 +2352,24 @@ void __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj,
* lists early.
*/
pages = __i915_gem_object_unset_pages(obj);
+
+ /*
+ * XXX Temporary hijinx to avoid updating all backends to handle
+ * NULL pages. In the future, when we have more asynchronous
+ * get_pages backends we should be better able to handle the
+ * cancellation of the async task in a more uniform manner.
+ */
+ if (!pages && !i915_gem_object_needs_async_cancel(obj))
+ pages = ERR_PTR(-EINVAL);
+
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
+ ret = 0;
unlock:
mutex_unlock(>mm.lock);
+
+ return ret;
}
bool i915_sg_trim(struct sg_table *orig_st)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index ff3da64470dd..cb1b0144d274 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -57,6 +57,7 @@ struct drm_i915_gem_object_ops {
#define I915_GEM_OBJECT_HAS_STRUCT_PAGE BIT(0)
#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
#define I915_GEM_OBJECT_IS_PROXYBIT(2)
+#define I915_GEM_OBJECT_ASYNC_CANCEL BIT(3)
/* Interface between the GEM object and its backing storage.
* get_pages() is called
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Add a new "remapped" gtt_view
On 15/01/2019 10:58, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-14 09:55:10)
On 11/01/2019 19:46, Ville Syrjala wrote:
From: Ville Syrjälä
To overcome display engine stride limits we'll want to remap the
pages in the GTT. To that end we need a new gtt_view type which
is just like the "rotated" type except not rotated.
I think I asked this before, so sorry if you also answered it - what
about rotated setups which go over display engine stride limits?
There's always a task for tomorrow. For such a remapping, I guess we
want to allow an arbitrary remapping table.
struct intel_arb_ggtt_view {
unsigned long *indices;
};
True, nothing here would make that impossible it seems, which was my
concern when I asked this question.
Btw.. would this make calling this one "tiled" view more future proof?
Then we would be able to call the arbitrarily remapped view just remapped.
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/perf: Annotate i915_perf.wakeref for keneldoc
Quoting Mika Kuoppala (2019-01-15 10:45:50)
> Chris Wilson writes:
>
> > drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or member
> > 'wakeref' not described in 'i915_perf_stream'
> >
> > Reported-by: kbuild-...@01.org
> > Fixes: 6619c0075f78 ("drm/i915/perf: Track the rpm wakeref")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
>
> Reviewed-by: Mika Kuoppala
Thanks for the quick review, pushed.
-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/perf: Annotate i915_perf.wakeref for keneldoc
== Series Details ==
Series: drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
URL : https://patchwork.freedesktop.org/series/55226/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5421 -> Patchwork_11296
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55226/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_11296 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:PASS -> DMESG-FAIL [fdo#108735]
* igt@pm_rpm@module-reload:
- fi-icl-u2: PASS -> DMESG-WARN [fdo#108654]
Possible fixes
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-n3050: {SKIP} [fdo#109271] -> PASS
* igt@pm_rpm@basic-rte:
- fi-bsw-n3050: FAIL [fdo#108800] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
[fdo#109241]: https://bugs.freedesktop.org/show_bug.cgi?id=109241
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Participating hosts (35 -> 29)
--
Additional (2): fi-icl-y fi-hsw-4770r
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 fi-pnv-d510
Build changes
-
* Linux: CI_DRM_5421 -> Patchwork_11296
CI_DRM_5421: b45de1859c21c29025d85b32b7cfca60a827bb69 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4773: 951e2b1a016b750544d0f42459b13b9c70631c68 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11296: e2a00e68bd40d315a34347991ad427a9e32c72d0 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e2a00e68bd40 drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11296/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Add a new "remapped" gtt_view
Quoting Tvrtko Ursulin (2019-01-14 09:55:10)
>
> On 11/01/2019 19:46, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > To overcome display engine stride limits we'll want to remap the
> > pages in the GTT. To that end we need a new gtt_view type which
> > is just like the "rotated" type except not rotated.
>
> I think I asked this before, so sorry if you also answered it - what
> about rotated setups which go over display engine stride limits?
There's always a task for tomorrow. For such a remapping, I guess we
want to allow an arbitrary remapping table.
struct intel_arb_ggtt_view {
unsigned long *indices;
};
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Split out drm_probe_helper.h
On Tue, 15 Jan 2019, Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. > > v2: Make it compile. There was so much compile fail on arm drivers > that I figured I'll better not include any of the acks on v1. > > v3: Massive rebase because i915 has lost a lot of drmP.h includes, but > not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h > there was still one, which this patch largely removes. Which means > rolling out lots more includes all over. > > This will also conflict with ongoing drmP.h cleanup by others I > expect. > > v3: Rebase on top of atomic bochs. > > Cc: Sam Ravnborg > Cc: Jani Nikula > Cc: Laurent Pinchart > Acked-by: Rodrigo Vivi (v2) > Acked-by: Benjamin Gaignard (v2) > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: etna...@lists.freedesktop.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-gfx@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-te...@vger.kernel.org > Cc: xen-de...@lists.xen.org > --- > Merging this is going to be a bit a mess due to all the ongoing drmP.h > cleanups. I think the following should work: > - Apply Sam's prep patches for removing drmP.h from > drm_modeset_helper.h > - Get the i915 drmP.h cleanup backmerged into drm-misc-next > - Apply this patch. > - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h > - All through drm-misc-next, which has some potential for trivial > conflicts around #includes with other drivers unfortunately. > > I hope there's no other driver who'll blow up accidentally because > someone else is doing a drmP.h cleanup. Laurent maybe? > > Jani, ack on this? Acked-by: Jani Nikula -- 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 3/3] drm/i915/userptr: Probe vma range before gup
On 15/01/2019 10:41, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-15 10:27:02) On 14/01/2019 21:17, Chris Wilson wrote: + if (err) + goto err_unlock; + + err = __i915_gem_userptr_get_pages_schedule(obj); + if (err == -EAGAIN) __i915_gem_userptr_set_active(obj, true); - if (IS_ERR(pages)) - release_pages(pvec, pinned); - kvfree(pvec); +err_unlock: + up_read(>mmap_sem); May be safer to drop the lock earlier, immediately after probe. I don't see holding it while queuing the worker and doing internal book-keeping is useful and might just create more lock chain dependencies. Hmm, I thought we need to cover up to set-active (probe + queue + insert into rbtree) as I thought the mmu-invalidate was under the mmap_sem wlock. We have our own lock for set active so I don't see that we need mmap_sem for it. Certainly wasn't needed before this patch so don't see that would change now. Btw, what you said regarding nested mmap_sem.. do we have lock inversion with it and obj->mm.lock then? I mean both mmap_sem -> obj->mm.lock and obj->mm.lock -> mmap_sem chains? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
== Series Details == Series: drm/i915/perf: Annotate i915_perf.wakeref for keneldoc URL : https://patchwork.freedesktop.org/series/55226/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/perf: Annotate i915_perf.wakeref for keneldoc -drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3577:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Clang warning in drivers/gpu/drm/i915/i915_debugfs.c
On Tue, 08 Jan 2019, Nathan Chancellor wrote:
> Hi all,
>
> Commit e845f099f1c6 ("drm/i915/dsc: Add Per connector debugfs node for
> DSC support/enable") causes a Clang warning:
>
> drivers/gpu/drm/i915/i915_debugfs.c:4961:17: warning: address of array
> 'intel_dp->dsc_dpcd' will always evaluate to 'true'
> [-Wpointer-bool-conversion]
> if (intel_dp->dsc_dpcd)
> ~~ ~~^~~~
> 1 warning generated.
>
> Did you mean to dereference it or should that print statement just
> always show? I normally would send a patch myself but since I'm not
> familiar with this code, I'd rather not shoot in the dark :) especially
> since it's for a trivial logging statement.
Fixed by fed85691b408 ("drm/i915: Fix the static code analysis warning
in debugfs"), thanks for the report & review on that one.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix the static code analysis warning in debugfs
On Wed, 09 Jan 2019, Manasi Navare wrote: > On Wed, Jan 09, 2019 at 01:14:14PM -0800, Radhakrishna Sripada wrote: >> intel_dp->dsc_dpcd is defined as an array making the if check redundant. >> > > Yes I agree, I guess when I added that if check it was anot an array to begin > with and then forgot to take it off. > > Looks good to me. > > Reviewed-by: Manasi Navare Manasi, you've got commit rights, please use them! Pushed now, with proper Fixes: tag added, thanks for the patch, review, testing, etc. BR, Jani. > > Manasi > >> Cc: Rodrigo Vivi >> Signed-off-by: Radhakrishna Sripada >> --- >> drivers/gpu/drm/i915/i915_debugfs.c | 5 ++--- >> 1 file changed, 2 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c >> b/drivers/gpu/drm/i915/i915_debugfs.c >> index 95813e21ae02..908e41f9cb7d 100644 >> --- a/drivers/gpu/drm/i915/i915_debugfs.c >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c >> @@ -4958,9 +4958,8 @@ static int i915_dsc_fec_support_show(struct seq_file >> *m, void *data) >> crtc_state = to_intel_crtc_state(crtc->state); >> seq_printf(m, "DSC_Enabled: %s\n", >> yesno(crtc_state->dsc_params.compression_enable)); >> -if (intel_dp->dsc_dpcd) >> -seq_printf(m, "DSC_Sink_Support: %s\n", >> - >> yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd))); >> +seq_printf(m, "DSC_Sink_Support: %s\n", >> + yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd))); >> if (!intel_dp_is_edp(intel_dp)) >> seq_printf(m, "FEC_Sink_Support: %s\n", >> >> yesno(drm_dp_sink_supports_fec(intel_dp->fec_capable))); >> -- >> 2.20.0.rc2.7.g965798d1f299 >> >> ___ >> 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 -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
Chris Wilson writes:
> drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or member
> 'wakeref' not described in 'i915_perf_stream'
>
> Reported-by: kbuild-...@01.org
> Fixes: 6619c0075f78 ("drm/i915/perf: Track the rpm wakeref")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fa99824f63b3..956c1c86f90d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1336,6 +1336,10 @@ struct i915_perf_stream {
>*/
> struct list_head link;
>
> + /**
> + * @wakeref: As we keep the device awake while the perf stream is
> + * active, we track our runtime pm reference for later release.
> + */
> intel_wakeref_t wakeref;
>
> /**
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/userptr: Probe vma range before gup
Quoting Tvrtko Ursulin (2019-01-15 10:27:02) > > On 14/01/2019 21:17, Chris Wilson wrote: > > + if (err) > > + goto err_unlock; > > + > > + err = __i915_gem_userptr_get_pages_schedule(obj); > > + if (err == -EAGAIN) > > __i915_gem_userptr_set_active(obj, true); > > > > - if (IS_ERR(pages)) > > - release_pages(pvec, pinned); > > - kvfree(pvec); > > +err_unlock: > > + up_read(>mmap_sem); > > May be safer to drop the lock earlier, immediately after probe. I don't > see holding it while queuing the worker and doing internal book-keeping > is useful and might just create more lock chain dependencies. Hmm, I thought we need to cover up to set-active (probe + queue + insert into rbtree) as I thought the mmu-invalidate was under the mmap_sem wlock. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/userptr: Probe vma range before gup
On 15/01/2019 10:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-15 10:19:11)
On 14/01/2019 21:17, Chris Wilson wrote:
@@ -620,40 +682,24 @@ static int i915_gem_userptr_get_pages(struct
drm_i915_gem_object *obj)
return -EAGAIN;
}
- pvec = NULL;
- pinned = 0;
+ if (mm == current->mm && try_fast_gup(obj) == 0)
+ return 0;
Is try_fast_gup guaranteed to fail on ranges probe_range would have
rejected?
If a page isn't present, it will fail. For our purposes that means
fast_gup fails for GGTT mmaps, as well as other ranges.
What if it has been pre-faulted?
- if (mm == current->mm) {
- pvec = kvmalloc_array(num_pages, sizeof(struct page *),
- GFP_KERNEL |
- __GFP_NORETRY |
- __GFP_NOWARN);
- if (pvec) /* defer to worker if malloc fails */
- pinned = __get_user_pages_fast(obj->userptr.ptr,
-num_pages,
-
!i915_gem_object_is_readonly(obj),
-pvec);
- }
+ /* lockdep doesn't yet automatically allow nesting of readers */
+ down_read_nested(>mmap_sem, SINGLE_DEPTH_NESTING);
Why is nesting needed - comment needs to explain.
We get called with mm->mmap_sem held for reading on a fault path, and
without mm->mmap_sem held otherwise. lockdep doesn't allow nesting of
readers, hence the comment.
Something like that in the comment yes please. :)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/userptr: Probe vma range before gup
Quoting Tvrtko Ursulin (2019-01-15 10:19:11)
>
> On 14/01/2019 21:17, Chris Wilson wrote:
> > @@ -620,40 +682,24 @@ static int i915_gem_userptr_get_pages(struct
> > drm_i915_gem_object *obj)
> > return -EAGAIN;
> > }
> >
> > - pvec = NULL;
> > - pinned = 0;
> > + if (mm == current->mm && try_fast_gup(obj) == 0)
> > + return 0;
>
> Is try_fast_gup guaranteed to fail on ranges probe_range would have
> rejected?
If a page isn't present, it will fail. For our purposes that means
fast_gup fails for GGTT mmaps, as well as other ranges.
> > - if (mm == current->mm) {
> > - pvec = kvmalloc_array(num_pages, sizeof(struct page *),
> > - GFP_KERNEL |
> > - __GFP_NORETRY |
> > - __GFP_NOWARN);
> > - if (pvec) /* defer to worker if malloc fails */
> > - pinned = __get_user_pages_fast(obj->userptr.ptr,
> > -num_pages,
> > -
> > !i915_gem_object_is_readonly(obj),
> > -pvec);
> > - }
> > + /* lockdep doesn't yet automatically allow nesting of readers */
> > + down_read_nested(>mmap_sem, SINGLE_DEPTH_NESTING);
>
> Why is nesting needed - comment needs to explain.
We get called with mm->mmap_sem held for reading on a fault path, and
without mm->mmap_sem held otherwise. lockdep doesn't allow nesting of
readers, hence the comment.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/userptr: Probe vma range before gup
On 14/01/2019 21:17, Chris Wilson wrote:
We want to exclude any GGTT objects from being present on our internal
lists to avoid the deadlock we may run into with our requirement for
struct_mutex during invalidate. However, if the gup_fast fails, we put
the userptr onto the workqueue and mark it as active, so that we
remember to serialise the worker upon mmu_invalidate.
Note that despite the previous fix, it is still better to avoid the
struct_mutex recursion where possible, leaving the recursion only to
handle the shrinker-esque paths.
v2: Hold mmap_sem to prevent modifications to the mm while we probe and
add ourselves to the interval-tree for notificiation.
v3: Rely on mmap_sem for a simpler patch.
v4: Mark up the mmap_sem nesting
v5: Don't deactivate on -EAGAIN as that means the worker is queued
v6: Fight the indentation and chained if-else error handling
v7: Fight again.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104209
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 150
1 file changed, 98 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 9c2008a480e2..7b9e14bc3bc5 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -435,7 +435,7 @@ struct get_pages_work {
struct task_struct *task;
};
-static struct sg_table *
+static int
__i915_gem_userptr_alloc_pages(struct drm_i915_gem_object *obj,
struct page **pvec, int num_pages)
{
@@ -446,7 +446,7 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (!st)
- return ERR_PTR(-ENOMEM);
+ return -ENOMEM;
alloc_table:
ret = __sg_alloc_table_from_pages(st, pvec, num_pages,
@@ -455,7 +455,7 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
GFP_KERNEL);
if (ret) {
kfree(st);
- return ERR_PTR(ret);
+ return ret;
}
ret = i915_gem_gtt_prepare_pages(obj, st);
@@ -468,14 +468,14 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
}
kfree(st);
- return ERR_PTR(ret);
+ return ret;
}
sg_page_sizes = i915_sg_page_sizes(st->sgl);
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
- return st;
+ return 0;
}
static void
@@ -520,19 +520,14 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
mutex_lock(>mm.lock);
if (obj->userptr.work == >work) {
- struct sg_table *pages = ERR_PTR(ret);
-
if (pinned == npages) {
- pages = __i915_gem_userptr_alloc_pages(obj, pvec,
- npages);
- if (!IS_ERR(pages)) {
+ ret = __i915_gem_userptr_alloc_pages(obj, pvec, npages);
+ if (!ret)
pinned = 0;
- pages = NULL;
- }
}
- obj->userptr.work = ERR_CAST(pages);
- if (IS_ERR(pages))
+ obj->userptr.work = ERR_PTR(ret);
+ if (ret)
__i915_gem_userptr_set_active(obj, false);
}
mutex_unlock(>mm.lock);
@@ -545,7 +540,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
kfree(work);
}
-static struct sg_table *
+static int
__i915_gem_userptr_get_pages_schedule(struct drm_i915_gem_object *obj)
{
struct get_pages_work *work;
@@ -571,7 +566,7 @@ __i915_gem_userptr_get_pages_schedule(struct
drm_i915_gem_object *obj)
*/
work = kmalloc(sizeof(*work), GFP_KERNEL);
if (work == NULL)
- return ERR_PTR(-ENOMEM);
+ return -ENOMEM;
obj->userptr.work = >work;
@@ -583,19 +578,86 @@ __i915_gem_userptr_get_pages_schedule(struct drm_i915_gem_object *obj)
INIT_WORK(>work, __i915_gem_userptr_get_pages_worker);
queue_work(to_i915(obj->base.dev)->mm.userptr_wq, >work);
- return ERR_PTR(-EAGAIN);
+ return -EAGAIN;
}
-static int i915_gem_userptr_get_pages(struct drm_i915_gem_object *obj)
+static int
+probe_range(struct mm_struct *mm, unsigned long addr, unsigned long len)
+{
+ const unsigned long end = addr + len;
+ struct vm_area_struct *vma;
+ int ret = -EFAULT;
+
+ for (vma = find_vma(mm, addr); vma; vma = vma->vm_next) {
+ if (vma->vm_start > addr)
+ break;
+
+ /*
+* Exclude any VMA that is not backed only by struct_page, i.e.
+* IO regions that include our own GGTT mmaps.
[Intel-gfx] [PATCH] drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or member
'wakeref' not described in 'i915_perf_stream'
Reported-by: kbuild-...@01.org
Fixes: 6619c0075f78 ("drm/i915/perf: Track the rpm wakeref")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fa99824f63b3..956c1c86f90d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1336,6 +1336,10 @@ struct i915_perf_stream {
*/
struct list_head link;
+ /**
+* @wakeref: As we keep the device awake while the perf stream is
+* active, we track our runtime pm reference for later release.
+*/
intel_wakeref_t wakeref;
/**
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/userptr: Probe vma range before gup
On 14/01/2019 21:17, Chris Wilson wrote:
We want to exclude any GGTT objects from being present on our internal
lists to avoid the deadlock we may run into with our requirement for
struct_mutex during invalidate. However, if the gup_fast fails, we put
the userptr onto the workqueue and mark it as active, so that we
remember to serialise the worker upon mmu_invalidate.
Note that despite the previous fix, it is still better to avoid the
struct_mutex recursion where possible, leaving the recursion only to
handle the shrinker-esque paths.
v2: Hold mmap_sem to prevent modifications to the mm while we probe and
add ourselves to the interval-tree for notificiation.
v3: Rely on mmap_sem for a simpler patch.
v4: Mark up the mmap_sem nesting
v5: Don't deactivate on -EAGAIN as that means the worker is queued
v6: Fight the indentation and chained if-else error handling
v7: Fight again.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104209
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 150
1 file changed, 98 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 9c2008a480e2..7b9e14bc3bc5 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -435,7 +435,7 @@ struct get_pages_work {
struct task_struct *task;
};
-static struct sg_table *
+static int
__i915_gem_userptr_alloc_pages(struct drm_i915_gem_object *obj,
struct page **pvec, int num_pages)
{
@@ -446,7 +446,7 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (!st)
- return ERR_PTR(-ENOMEM);
+ return -ENOMEM;
alloc_table:
ret = __sg_alloc_table_from_pages(st, pvec, num_pages,
@@ -455,7 +455,7 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
GFP_KERNEL);
if (ret) {
kfree(st);
- return ERR_PTR(ret);
+ return ret;
}
ret = i915_gem_gtt_prepare_pages(obj, st);
@@ -468,14 +468,14 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
}
kfree(st);
- return ERR_PTR(ret);
+ return ret;
}
sg_page_sizes = i915_sg_page_sizes(st->sgl);
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
- return st;
+ return 0;
}
static void
@@ -520,19 +520,14 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
mutex_lock(>mm.lock);
if (obj->userptr.work == >work) {
- struct sg_table *pages = ERR_PTR(ret);
-
if (pinned == npages) {
- pages = __i915_gem_userptr_alloc_pages(obj, pvec,
- npages);
- if (!IS_ERR(pages)) {
+ ret = __i915_gem_userptr_alloc_pages(obj, pvec, npages);
+ if (!ret)
pinned = 0;
- pages = NULL;
- }
}
- obj->userptr.work = ERR_CAST(pages);
- if (IS_ERR(pages))
+ obj->userptr.work = ERR_PTR(ret);
+ if (ret)
__i915_gem_userptr_set_active(obj, false);
}
mutex_unlock(>mm.lock);
@@ -545,7 +540,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
kfree(work);
}
-static struct sg_table *
+static int
__i915_gem_userptr_get_pages_schedule(struct drm_i915_gem_object *obj)
{
struct get_pages_work *work;
@@ -571,7 +566,7 @@ __i915_gem_userptr_get_pages_schedule(struct
drm_i915_gem_object *obj)
*/
work = kmalloc(sizeof(*work), GFP_KERNEL);
if (work == NULL)
- return ERR_PTR(-ENOMEM);
+ return -ENOMEM;
obj->userptr.work = >work;
@@ -583,19 +578,86 @@ __i915_gem_userptr_get_pages_schedule(struct drm_i915_gem_object *obj)
INIT_WORK(>work, __i915_gem_userptr_get_pages_worker);
queue_work(to_i915(obj->base.dev)->mm.userptr_wq, >work);
- return ERR_PTR(-EAGAIN);
+ return -EAGAIN;
}
-static int i915_gem_userptr_get_pages(struct drm_i915_gem_object *obj)
+static int
+probe_range(struct mm_struct *mm, unsigned long addr, unsigned long len)
+{
+ const unsigned long end = addr + len;
+ struct vm_area_struct *vma;
+ int ret = -EFAULT;
+
+ for (vma = find_vma(mm, addr); vma; vma = vma->vm_next) {
+ if (vma->vm_start > addr)
+ break;
+
+ /*
+* Exclude any VMA that is not backed only by struct_page, i.e.
+* IO regions that include our own GGTT mmaps.
Re: [Intel-gfx] [PATCH v2] drm/i915/cnl: Fix CNL macros for Voltage Swing programming
On Thu, 10 Jan 2019, Aditya Swarup wrote:
> CNL macros for register groups CNL_PORT_TX_DW2_* / CNL_PORT_TX_DW5_* are
> configured incorrectly wrt definition of _CNL_PORT_TX_DW_GRP.
>
> v2: Jani suggested to keep the macros organized semantically i.e., by
> function, secondarily by port/pipe/transcoder.->(dw, port)
>
> Cc: Clint Taylor
> Cc: Imre Deak
> Cc: Jani Nikula
> Signed-off-by: Aditya Swarup
Pushed to dinq with the appropriate Fixes: tag added, thanks for the
patch.
> ---
> There are still inconsistencies in some macro definitions. The macros
> for MG phy registers are (port, ln) e.g.,
> MG_TX2_LINK_PARAMS(port, ln) and also CNL_PORT_TX_DW4_LN(port, ln)
> whereas for ICL -> _ICL_PORT_PCS_DW_LN(dw, ln, port).
>
> Do you feel that we need to make these definitions consistent and what
> should be the sequence -> (dw, ln, port)/(ln, port) or (dw, port, ln)/
> (port,ln)?
Feel free to send the patches. I think (dw, port, ln).
BR,
Jani.
>
> drivers/gpu/drm/i915/i915_reg.h | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 44958d994bfa..fad5a9e8b44d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1814,7 +1814,7 @@ enum i915_power_well_id {
> #define _CNL_PORT_TX_C_LN0_OFFSET0x162C40
> #define _CNL_PORT_TX_D_LN0_OFFSET0x162E40
> #define _CNL_PORT_TX_F_LN0_OFFSET0x162840
> -#define _CNL_PORT_TX_DW_GRP(port, dw)(_PICK((port), \
> +#define _CNL_PORT_TX_DW_GRP(dw, port)(_PICK((port), \
> _CNL_PORT_TX_AE_GRP_OFFSET, \
> _CNL_PORT_TX_B_GRP_OFFSET, \
> _CNL_PORT_TX_B_GRP_OFFSET, \
> @@ -1822,7 +1822,7 @@ enum i915_power_well_id {
> _CNL_PORT_TX_AE_GRP_OFFSET, \
> _CNL_PORT_TX_F_GRP_OFFSET) + \
> 4 * (dw))
> -#define _CNL_PORT_TX_DW_LN0(port, dw)(_PICK((port), \
> +#define _CNL_PORT_TX_DW_LN0(dw, port)(_PICK((port), \
> _CNL_PORT_TX_AE_LN0_OFFSET, \
> _CNL_PORT_TX_B_LN0_OFFSET, \
> _CNL_PORT_TX_B_LN0_OFFSET, \
> @@ -1858,9 +1858,9 @@ enum i915_power_well_id {
>
> #define _CNL_PORT_TX_DW4_LN0_AE 0x162450
> #define _CNL_PORT_TX_DW4_LN1_AE 0x1624D0
> -#define CNL_PORT_TX_DW4_GRP(port)_MMIO(_CNL_PORT_TX_DW_GRP((port), 4))
> -#define CNL_PORT_TX_DW4_LN0(port)_MMIO(_CNL_PORT_TX_DW_LN0((port), 4))
> -#define CNL_PORT_TX_DW4_LN(port, ln) _MMIO(_CNL_PORT_TX_DW_LN0((port), 4)
> + \
> +#define CNL_PORT_TX_DW4_GRP(port)_MMIO(_CNL_PORT_TX_DW_GRP(4, (port)))
> +#define CNL_PORT_TX_DW4_LN0(port)_MMIO(_CNL_PORT_TX_DW_LN0(4, (port)))
> +#define CNL_PORT_TX_DW4_LN(port, ln) _MMIO(_CNL_PORT_TX_DW_LN0(4, (port))
> + \
> ((ln) * (_CNL_PORT_TX_DW4_LN1_AE - \
> _CNL_PORT_TX_DW4_LN0_AE)))
> #define ICL_PORT_TX_DW4_AUX(port)_MMIO(_ICL_PORT_TX_DW_AUX(4, port))
> @@ -1888,8 +1888,8 @@ enum i915_power_well_id {
> #define RTERM_SELECT(x)((x) << 3)
> #define RTERM_SELECT_MASK (0x7 << 3)
>
> -#define CNL_PORT_TX_DW7_GRP(port)_MMIO(_CNL_PORT_TX_DW_GRP((port), 7))
> -#define CNL_PORT_TX_DW7_LN0(port)_MMIO(_CNL_PORT_TX_DW_LN0((port), 7))
> +#define CNL_PORT_TX_DW7_GRP(port)_MMIO(_CNL_PORT_TX_DW_GRP(7, (port)))
> +#define CNL_PORT_TX_DW7_LN0(port)_MMIO(_CNL_PORT_TX_DW_LN0(7, (port)))
> #define ICL_PORT_TX_DW7_AUX(port)_MMIO(_ICL_PORT_TX_DW_AUX(7, port))
> #define ICL_PORT_TX_DW7_GRP(port)_MMIO(_ICL_PORT_TX_DW_GRP(7, port))
> #define ICL_PORT_TX_DW7_LN0(port)_MMIO(_ICL_PORT_TX_DW_LN(7, 0, port))
--
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/3] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start
Quoting Tvrtko Ursulin (2019-01-15 09:47:45)
>
> On 14/01/2019 21:17, Chris Wilson wrote:
> > Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
> > notifiers") we have been able to report failure from
> > mmu_invalidate_range_start which allows us to use a trylock on the
> > struct_mutex to avoid potential recursion and report -EBUSY instead.
> > Furthermore, this allows us to pull the work into the main callback and
> > avoid the sleight-of-hand in using a workqueue to avoid lockdep.
> >
> > However, not all paths to mmu_invalidate_range_start are prepared to
> > handle failure, so instead of reporting the recursion, deal with it by
> > propagating the failure upwards, who can decide themselves to handle it
> > or report it.
> >
> > v2: Mark up the recursive lock behaviour and comment on the various weak
> > points.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108375
> > References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
> > notifiers")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 4 +-
> > drivers/gpu/drm/i915/i915_gem.c | 30 +++-
> > drivers/gpu/drm/i915/i915_gem_object.h | 7 +
> > drivers/gpu/drm/i915/i915_gem_userptr.c | 220 +++-
> > 4 files changed, 135 insertions(+), 126 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index fa99824f63b3..4b67037c0318 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2931,8 +2931,8 @@ enum i915_mm_subclass { /* lockdep subclass for
> > obj->mm.lock/struct_mutex */
> > I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
> > };
> >
> > -void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
> > - enum i915_mm_subclass subclass);
> > +int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
> > + enum i915_mm_subclass subclass);
> > void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
> >
> > enum i915_map_type {
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 0bfed33178e1..90c167f71345 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2303,8 +2303,8 @@ __i915_gem_object_unset_pages(struct
> > drm_i915_gem_object *obj)
> > struct sg_table *pages;
> >
> > pages = fetch_and_zero(>mm.pages);
> > - if (!pages)
> > - return NULL;
> > + if (IS_ERR_OR_NULL(pages))
> > + return pages;
> >
> > spin_lock(>mm.obj_lock);
> > list_del(>mm.link);
> > @@ -2328,22 +2328,23 @@ __i915_gem_object_unset_pages(struct
> > drm_i915_gem_object *obj)
> > return pages;
> > }
> >
> > -void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
> > - enum i915_mm_subclass subclass)
> > +int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
> > + enum i915_mm_subclass subclass)
> > {
> > struct sg_table *pages;
> > + int ret;
> >
> > if (i915_gem_object_has_pinned_pages(obj))
> > - return;
> > + return -EBUSY;
> >
> > GEM_BUG_ON(obj->bind_count);
> > - if (!i915_gem_object_has_pages(obj))
> > - return;
> >
> > /* May be called by shrinker from within get_pages() (on another bo)
> > */
> > mutex_lock_nested(>mm.lock, subclass);
> > - if (unlikely(atomic_read(>mm.pages_pin_count)))
> > + if (unlikely(atomic_read(>mm.pages_pin_count))) {
> > + ret = -EBUSY;
> > goto unlock;
> > + }
> >
> > /*
> >* ->put_pages might need to allocate memory for the bit17 swizzle
> > @@ -2351,11 +2352,24 @@ void __i915_gem_object_put_pages(struct
> > drm_i915_gem_object *obj,
> >* lists early.
> >*/
> > pages = __i915_gem_object_unset_pages(obj);
> > +
> > + /*
> > + * XXX Temporary hijinx to avoid updating all backends to handle
> > + * NULL pages. In the future, when we have more asynchronous
> > + * get_pages backends we should be better able to handle the
> > + * cancellation of the async task in a more uniform manner.
> > + */
> > + if (!pages && !i915_gem_object_needs_async_cancel(obj))
> > + pages = ERR_PTR(-EINVAL);
> > +
> > if (!IS_ERR(pages))
> > obj->ops->put_pages(obj, pages);
> >
> > + ret = 0;
> > unlock:
> > mutex_unlock(>mm.lock);
> > +
> > + return ret;
> > }
> >
> > bool i915_sg_trim(struct sg_table *orig_st)
> > diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
> > b/drivers/gpu/drm/i915/i915_gem_object.h
> > index ff3da64470dd..cb1b0144d274 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_object.h
>
Re: [Intel-gfx] Forced push done to drm-intel-next-queued
On Thu, Dec 27, 2018 at 04:24:51PM +0100, Hans de Goede wrote:
> Hi,
>
> On 27-12-18 15:42, Jani Nikula wrote:
> > On Tue, 25 Dec 2018, Hans de Goede wrote:
> > > Hi,
> > >
> > > As mentioned in the "I messed up drm-intel-next-queued!" mail-thread
> > > I made a big mistake yesterday:
> > >
> > > "Ugh, I just messed up drm-intel-next-queued big time.
> > >
> > > I somehow rebased my work on top of drm-tip (I believe I did the rebase
> > > in the wrong dir) and then after running a bunch of tests I
> > > did a "dim push-branch drm-intel-next-queued" which pushed the
> > > patches I intended to push rebased on top of drm-tip
> > > pushing drm-tip to dinq :(
> > >
> > > I'm so sorry about this.
> > >
> > > I just checked my reflog and the last commit before me messing
> > > up is commit d4de753526f4d99f541f1b6ed1d963005c09700c
> > > ("drm/i915: Unwind failure on pinning the gen7 ppgtt")"
> > >
> > > To fix this I've just done a forced push resetting
> > > drm-intel-next-queued to the mentioned d4de753526f4 commit.
> > >
> > > I first checked no-one pushed anything on top of my mess,
> > > but if you pushed anything to drm-intel-next-queued in the
> > > last 24 hours, please double-check it is there.
> > >
> > > Once more my apologies for this.
> >
> > It happens, don't worry about it. Thanks for being open about it instead
> > of trying to brush it under the rug.
>
> Thanks.
>
> > Did you pass -f to dim? I suspect drm-tip wouldn't pass the push checks
> > in dim without it. Perhaps we'll need to add more.
>
> No I did not pass -f, I did wonder myself how the push managed to
> proceed after my screw-up. Looking at how dim builds drm-tip, it seems
> it starts with dinq and then merges in other branches, so a push
> from a drm-tip based branch to dinq is a fast-forward (I think),
> so dinq is special in this case.
Do you still have the git tree you've pushed wrongly and could publish it
somewhere? I'm suprised that dim push didn't catch this, we've added a few
more sanity checks last time around this happened. I'd have expected dim
to complain about all the patches lacking you're signed-off-by, since a
rebase would have changed a lot of patches to be committed by you.
-Daniel
>
> > Anyway, checking against what I had on Friday, I think it all checks
> > out. It's of course possible something was pushed on top, but I doubt
> > it.
>
> Great, thank you for double checking.
>
> Regards,
>
> Hans
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 43/46] drm/i915: Allocate a status page for each timeline
Quoting John Harrison (2019-01-15 00:56:13)
> On 1/7/2019 03:55, Chris Wilson wrote:
> > +static int alloc_hwsp(struct i915_timeline *timeline)
> > +{
> > + struct drm_i915_private *i915 = timeline->i915;
> > + struct i915_vma *vma;
> > + int offset;
> > +
> > + mutex_lock(>gt.timeline_lock);
> > +
> > +restart:
> > + offset = find_first_cacheline(i915);
> > + if (offset == NBITS && i915->gt.timeline_hwsp) {
> > + i915_vma_put(i915->gt.timeline_hwsp);
> > + i915->gt.timeline_hwsp = NULL;
> > + }
> > +
> > + vma = i915->gt.timeline_hwsp;
> > + if (!vma) {
> > + struct drm_i915_gem_object *bo;
> > +
> > + /* Drop the lock before allocations */
> > + mutex_unlock(>gt.timeline_lock);
> > +
> > + BUILD_BUG_ON(NBITS * CACHELINE_BYTES > PAGE_SIZE);
> > + bo = i915_gem_object_create_internal(i915, PAGE_SIZE);
> > + if (IS_ERR(bo))
> > + return PTR_ERR(bo);
> > +
> > + i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
> > +
> > + vma = i915_vma_instance(bo, >ggtt.vm, NULL);
> > + if (IS_ERR(vma))
> > + return PTR_ERR(vma);
> > +
> > + mutex_lock(>gt.timeline_lock);
> > + if (i915->gt.timeline_hwsp) {
> > + i915_gem_object_put(bo);
> > + goto restart;
> > + }
> > +
> > + i915->gt.timeline_hwsp = vma;
> > + i915->gt.timeline_free = ~0ull;
> > + offset = 0;
> > + }
> > +
> > + i915->gt.timeline_free &= ~BIT_ULL(offset);
> > +
> > + timeline->hwsp_ggtt = i915_vma_get(vma);
> > + timeline->hwsp_offset = offset * CACHELINE_BYTES;
> > +
> > + mutex_unlock(>gt.timeline_lock);
> > +
> > + return 0;
> > +}
> If I'm reading this correctly then gt.timeline_hwsp/free is the a cached
> copy of the most recently allocated but not yet filled bank of seqno
> locations. When it gets full, the i915->gt reference gets dropped and a
> new page is allocated and used up line by line. Meanwhile, each timeline
> has it's own private reference to the page so dropping the i915->gt
> reference is safe. And once the last timeline using a given page is
> freed, the last reference to that page will be dropped and so the page
> itself will also be freed. If a timeline is freed before the currently
> cached page is filled, then that timeline's slot will be released and
> re-used by the next timeline to be created.
>
> But what about the scenario of a long running system with a small but
> growing number of persistent tasks interspersed with many short lived
> tasks? In that case, you would end up with many sparsely populated pages
> that whose free slots will not get re-used. You could have a linked list
> of cached pages. When a page is filled, move it to a 'full' list. When a
> timeline is freed, if it's page was on the 'full' list, clear the slot
> and move it back to the 'available' list.
Yes. My thinking was a plain slab cache was a quick-and-dirty
improvement over a page-per-timeline. And a freelist would be the next
step.
> Or is the idea that a worst case of a single page vma allocation per
> timeline is the least of our worries if there is an ever growing number
> of timelines/contexts/users in the system?
Nah, it was just an attempt to quickly reduce the number of allocations,
where the worst case of one page+vma per timeline was the starting
point.
We should break this patch down into 1) one-page-per-timeline, 2) slab
cache, 3) free list 4) profit.
At other times we have been wanting to be able to suballocate pages,
something to keep in mind would be extending this to arbitrary cacheline
allocations.
> > + if (global_hwsp) {
> > + timeline->hwsp_ggtt = i915_vma_get(global_hwsp);
> > + timeline->hwsp_offset = I915_GEM_HWS_SEQNO_ADDR;
> > + } else {
> > + err = alloc_hwsp(timeline);
> > + if (err)
> > + return err;
> > + }
> > +
> > + vaddr = i915_gem_object_pin_map(timeline->hwsp_ggtt->obj,
> > I915_MAP_WB);
> > + if (IS_ERR(vaddr)) { /* leak the cacheline, but will clean up later */
> Can you explain this comment more? Where/when is the later?
On failure here, the cacheline is still marked as allocated in the slab,
but the reference to the page is released. So the backing page will be
released when everyone else finally drops their reference.
Just laziness, since we have the ability to return the cacheline later
on...
> > @@ -2616,7 +2628,7 @@ static int execlists_context_deferred_alloc(struct
> > i915_gem_context *ctx,
> > goto error_deref_obj;
> > }
> >
> > - timeline = i915_timeline_create(ctx->i915, ctx->name);
> > + timeline = i915_timeline_create(ctx->i915, ctx->name, NULL);
> Why does this use the global HWSP rather than a per context one?
Re: [Intel-gfx] [PATCH 2/3] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start
On 14/01/2019 21:17, Chris Wilson wrote:
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull the work into the main callback and
avoid the sleight-of-hand in using a workqueue to avoid lockdep.
However, not all paths to mmu_invalidate_range_start are prepared to
handle failure, so instead of reporting the recursion, deal with it by
propagating the failure upwards, who can decide themselves to handle it
or report it.
v2: Mark up the recursive lock behaviour and comment on the various weak
points.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108375
References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 30 +++-
drivers/gpu/drm/i915/i915_gem_object.h | 7 +
drivers/gpu/drm/i915/i915_gem_userptr.c | 220 +++-
4 files changed, 135 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fa99824f63b3..4b67037c0318 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2931,8 +2931,8 @@ enum i915_mm_subclass { /* lockdep subclass for
obj->mm.lock/struct_mutex */
I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
};
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass);
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass);
void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
enum i915_map_type {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0bfed33178e1..90c167f71345 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2303,8 +2303,8 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
*obj)
struct sg_table *pages;
pages = fetch_and_zero(>mm.pages);
- if (!pages)
- return NULL;
+ if (IS_ERR_OR_NULL(pages))
+ return pages;
spin_lock(>mm.obj_lock);
list_del(>mm.link);
@@ -2328,22 +2328,23 @@ __i915_gem_object_unset_pages(struct
drm_i915_gem_object *obj)
return pages;
}
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass)
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass)
{
struct sg_table *pages;
+ int ret;
if (i915_gem_object_has_pinned_pages(obj))
- return;
+ return -EBUSY;
GEM_BUG_ON(obj->bind_count);
- if (!i915_gem_object_has_pages(obj))
- return;
/* May be called by shrinker from within get_pages() (on another bo) */
mutex_lock_nested(>mm.lock, subclass);
- if (unlikely(atomic_read(>mm.pages_pin_count)))
+ if (unlikely(atomic_read(>mm.pages_pin_count))) {
+ ret = -EBUSY;
goto unlock;
+ }
/*
* ->put_pages might need to allocate memory for the bit17 swizzle
@@ -2351,11 +2352,24 @@ void __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj,
* lists early.
*/
pages = __i915_gem_object_unset_pages(obj);
+
+ /*
+* XXX Temporary hijinx to avoid updating all backends to handle
+* NULL pages. In the future, when we have more asynchronous
+* get_pages backends we should be better able to handle the
+* cancellation of the async task in a more uniform manner.
+*/
+ if (!pages && !i915_gem_object_needs_async_cancel(obj))
+ pages = ERR_PTR(-EINVAL);
+
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
+ ret = 0;
unlock:
mutex_unlock(>mm.lock);
+
+ return ret;
}
bool i915_sg_trim(struct sg_table *orig_st)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index ff3da64470dd..cb1b0144d274 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -57,6 +57,7 @@ struct drm_i915_gem_object_ops {
#define I915_GEM_OBJECT_HAS_STRUCT_PAGE BIT(0)
#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
#define I915_GEM_OBJECT_IS_PROXY BIT(2)
+#define I915_GEM_OBJECT_ASYNC_CANCEL BIT(3)
/* Interface between the GEM object and its backing storage.
* get_pages() is called once prior to the use of the associated set
@@ -387,6 +388,12 @@
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Prevent concurrent GGTT update and use on Braswell (again)
Quoting Tvrtko Ursulin (2019-01-15 09:04:47)
>
> On 14/01/2019 21:17, Chris Wilson wrote:
> > On Braswell, under heavy stress, if we update the GGTT while
> > simultaneously accessing another region inside the GTT, we are returned
> > the wrong values. To prevent this we stop the machine to update the GGTT
> > entries so that no memory traffic can occur at the same time.
> >
> > This was first spotted in
> >
> > commit 5bab6f60cb4d1417ad7c599166bcfec87529c1a2
> > Author: Chris Wilson
> > Date: Fri Oct 23 18:43:32 2015 +0100
> >
> > drm/i915: Serialise updates to GGTT with access through GGTT on
> > Braswell
> >
> > but removed again in forlorn hope with
> >
> > commit 4509276ee824bb967885c095c610767e42345c36
> > Author: Chris Wilson
> > Date: Mon Feb 20 12:47:18 2017 +
> >
> > drm/i915: Remove Braswell GGTT update w/a
> >
> > However, gem_concurrent_blit is once again only stable with the patch
> > applied and CI is detecting the odd failure in forked gem_mmap_gtt tests
> > (which smell like the same issue). Fwiw, a wide variety of CPU memory
> > barriers (around GGTT flushing, fence updates, PTE updates) and GPU
> > flushes/invalidates (between requests, after PTE updates) were tried as
> > part of the investigation to find an alternate cause, nothing comes
> > close to serialised GGTT updates.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105591
> > Testcase: igt/gem_concurrent_blit
> > Testcase: igt/gem_mmap_gtt/*forked*
> > References: 5bab6f60cb4d ("drm/i915: Serialise updates to GGTT with access
> > through GGTT on Braswell")
> > References: 4509276ee824 ("drm/i915: Remove Braswell GGTT update w/a")
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index dbea14bf67cc..f0d46366fb0b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -3232,7 +3232,8 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
> > ggtt->vm.insert_entries = gen8_ggtt_insert_entries;
> >
> > /* Serialize GTT updates with aperture access on BXT if VT-d is on. */
> > - if (intel_ggtt_update_needs_vtd_wa(dev_priv)) {
> > + if (intel_ggtt_update_needs_vtd_wa(dev_priv) ||
> > + IS_CHERRYVIEW(dev_priv) /* fails with concurrent use/update */) {
> > ggtt->vm.insert_entries = bxt_vtd_ggtt_insert_entries__BKL;
> > ggtt->vm.insert_page= bxt_vtd_ggtt_insert_page__BKL;
> > if (ggtt->vm.clear_range != nop_clear_range)
> >
> Reviewed-by: Tvrtko Ursulin
Thanks, pushed and closed the bugzilla. If I am allowed to be
optimistic, maybe this will be the cause of the fail-on-boot as well?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 41/46] drm/i915: Introduce concept of per-timeline (context) HWSP
Quoting John Harrison (2019-01-15 00:55:39)
> On 1/7/2019 03:55, Chris Wilson wrote:
> > Supplement the per-engine HWSP with a per-timeline HWSP. That is a
> > per-request pointer through which we can check a local seqno,
> > abstracting away the presumption of a global seqno. In this first step,
> > we point each request back into the engine's HWSP so everything
> > continues to work with the global timeline.
> > ---
> > +static inline u32 i915_request_hwsp(const struct i915_request *rq)
> > +{
> > + return READ_ONCE(*rq->hwsp_seqno);
> > +}
> > +
> Shouldn't the function name have an _seqno as well? Just
> 'i915_request_hwsp()' is fairly ambiguous, there could be many different
> things stored in the HWSP.
It's not even necessarily the HWSP! :)
i915_request_hw_seqno() // dissatisfying
-> i915_request_hwsp_seqno() // but rq only stores one element in HWSP!
-> i915_request_hwsp()
Was the evolution of names I chose.
Of that mix, i915_request_hwsp_seqno(). hw_seqno just feels nondescript.
i915_request_current_[hw]_seqno() maybe, but because we start with
i915_request I find it confusing and expect the seqno to be tied to the
request. So maybe just drop i915_request here, and go with something
like hwsp_breadcrumb(), that just happens to take i915_request as a
convenience.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
