[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Add tiled blits selftest (rev2)
== Series Details == Series: drm/i915/selftests: Add tiled blits selftest (rev2) URL : https://patchwork.freedesktop.org/series/76746/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0cf43fdf0ac0 drm/i915/selftests: Add tiled blits selftest -:603: WARNING:LINE_SPACING: Missing a blank line after declarations #603: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c:696: + struct drm_i915_private *i915 = arg; + I915_RND_STATE(prng); -:651: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author '' total: 0 errors, 2 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] ✓ Fi.CI.BAT: success for drm/i915/selftests: Add tiled blits selftest (rev2)
== Series Details == Series: drm/i915/selftests: Add tiled blits selftest (rev2) URL : https://patchwork.freedesktop.org/series/76746/ State : success == Summary == CI Bug Log - changes from CI_DRM_8399 -> Patchwork_17525 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/index.html Known issues Here are the changes found in Patchwork_17525 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_selftest@live@gt_pm: - fi-skl-6700k2: [INCOMPLETE][1] -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/fi-skl-6700k2/igt@i915_selftest@live@gt_pm.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/fi-skl-6700k2/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@gt_timelines: - fi-bwr-2160:[INCOMPLETE][3] ([i915#489]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/fi-bwr-2160/igt@i915_selftest@live@gt_timelines.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/fi-bwr-2160/igt@i915_selftest@live@gt_timelines.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [FAIL][5] ([i915#62]) -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (49 -> 41) -- Additional (1): fi-kbl-7560u Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ilk-650 fi-kbl-7500u fi-ctg-p8600 fi-icl-y fi-byt-clapper Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8399 -> Patchwork_17525 CI-20190529: 20190529 CI_DRM_8399: f7cb045d81d2a82a28448638962979ad986d7003 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5616: faab65ff9bfa28d18c23e6f69d30e133b0acd767 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17525: 0cf43fdf0ac051fa943ec1624e5edfb30d79f64d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0cf43fdf0ac0 drm/i915/selftests: Add tiled blits selftest == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI] drm/i915/selftests: Add tiled blits selftest
Quoting Chris Wilson (2020-04-30 07:49:57) > From: Zbigniew Kempczyński > > Extend coverage of the blitter client by exercising conversion to and > from tiled sources. In the process we perform spot checks to verify that > the tiling/detiling is being applied correctly, along with position > invariance of the tiling parameters. > > Signed-off-by: Zbigniew Kempczyński > Cc: Chris Wilson > Cc: Joonas Lahtinen This does what I asked for a minimal and accurate replacement of tiled blits, thanks! It can be bumped for sensitivity (spot check a few more pixels, or the whole surface), it can also be adjusted for checking tiling parameters and fine copies. What it tests right now is that we can move objects around inside the GTT without losing tiling, which is the foundational level of assurance we need. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/6] drm/i915/gt: Always enable busy-stats for execlists
== Series Details == Series: series starting with [CI,1/6] drm/i915/gt: Always enable busy-stats for execlists URL : https://patchwork.freedesktop.org/series/76744/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8395_full -> Patchwork_17522_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17522_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17522_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_17522_full: ### IGT changes ### Possible regressions * igt@perf@gen8-unprivileged-single-ctx-counters: - shard-apl: [PASS][1] -> [TIMEOUT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8395/shard-apl3/igt@p...@gen8-unprivileged-single-ctx-counters.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17522/shard-apl8/igt@p...@gen8-unprivileged-single-ctx-counters.html - shard-glk: [PASS][3] -> [TIMEOUT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8395/shard-glk7/igt@p...@gen8-unprivileged-single-ctx-counters.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17522/shard-glk2/igt@p...@gen8-unprivileged-single-ctx-counters.html Known issues Here are the changes found in Patchwork_17522_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_params@invalid-bsd-ring: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8395/shard-iclb2/igt@gem_exec_par...@invalid-bsd-ring.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17522/shard-iclb7/igt@gem_exec_par...@invalid-bsd-ring.html * igt@gem_exec_whisper@basic-contexts-all: - shard-glk: [PASS][7] -> [INCOMPLETE][8] ([i915#58] / [k.org#198133]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8395/shard-glk1/igt@gem_exec_whis...@basic-contexts-all.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17522/shard-glk6/igt@gem_exec_whis...@basic-contexts-all.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8395/shard-kbl7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17522/shard-kbl7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145] / [i915#265]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8395/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17522/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_psr@psr2_sprite_mmap_cpu: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8395/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_cpu.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17522/shard-iclb7/igt@kms_psr@psr2_sprite_mmap_cpu.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8395/shard-apl4/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17522/shard-apl4/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html Possible fixes * igt@i915_pm_rps@min-max-config-loaded: - shard-tglb: [FAIL][17] ([i915#413]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8395/shard-tglb6/igt@i915_pm_...@min-max-config-loaded.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17522/shard-tglb6/igt@i915_pm_...@min-max-config-loaded.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [DMESG-WARN][19] ([i915#180]) -> [PASS][20] +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8395/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17522/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-offscreen: - shard-apl: [FAIL][21] ([i915#54] / [i915#95]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8395/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-128x42-offscreen.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip
Re: [Intel-gfx] [PATCH v26 2/9] drm/i915: Use bw state for per crtc SAGV evaluation
On Thu, Apr 23, 2020 at 10:58:55AM +0300, Stanislav Lisovskiy wrote:
> Future platforms require per-crtc SAGV evaluation
> and serializing global state when those are changed
> from different commits.
>
> v2: - Add has_sagv check to intel_crtc_can_enable_sagv
> so that it sets bit in reject mask.
> - Use bw_state in intel_pre/post_plane_enable_sagv
> instead of atomic state
>
> v3: - Fixed rebase conflict, now using
> intel_atomic_crtc_state_for_each_plane_state in
> order to call it from atomic check
> v4: - Use fb modifier from plane state
>
> v5: - Make intel_has_sagv static again(Ville)
> - Removed unnecessary NULL assignments(Ville)
> - Removed unnecessary SAGV debug(Ville)
> - Call intel_compute_sagv_mask only for modesets(Ville)
> - Serialize global state only if sagv results change, but
> not mask itself(Ville)
>
> v6: - use lock global state instead of serialize(Ville)
What I meant is that we need both. Serialize if sagv state is going to
change, otherwise lock if the mask changes.
>
> Signed-off-by: Stanislav Lisovskiy
> Cc: Ville Syrjälä
> Cc: James Ausmus
> ---
> drivers/gpu/drm/i915/display/intel_bw.h | 6 ++
> drivers/gpu/drm/i915/intel_pm.c | 113 ++--
> drivers/gpu/drm/i915/intel_pm.h | 3 +-
> 3 files changed, 93 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index ac004d6f4276..d6df91058223 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -18,6 +18,12 @@ struct intel_crtc_state;
> struct intel_bw_state {
> struct intel_global_state base;
>
> + /*
> + * Contains a bit mask, used to determine, whether correspondent
> + * pipe allows SAGV or not.
> + */
> + u8 pipe_sagv_reject;
> +
> unsigned int data_rate[I915_MAX_PIPES];
> u8 num_active_planes[I915_MAX_PIPES];
> };
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 338a82577b76..7e15cf3368ad 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -43,6 +43,7 @@
> #include "i915_fixed.h"
> #include "i915_irq.h"
> #include "i915_trace.h"
> +#include "display/intel_bw.h"
> #include "intel_pm.h"
> #include "intel_sideband.h"
> #include "../../../platform/x86/intel_ips.h"
> @@ -3760,34 +3761,75 @@ intel_disable_sagv(struct drm_i915_private *dev_priv)
> void intel_sagv_pre_plane_update(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + const struct intel_bw_state *new_bw_state;
>
> - if (!intel_can_enable_sagv(state))
> + /*
> + * Just return if we can't control SAGV or don't have it.
> + * This is different from situation when we have SAGV but just can't
> + * afford it due to DBuf limitation - in case if SAGV is completely
> + * disabled in a BIOS, we are not even allowed to send a PCode request,
> + * as it will throw an error. So have to check it here.
> + */
> + if (!intel_has_sagv(dev_priv))
> + return;
> +
> + new_bw_state = intel_atomic_get_new_bw_state(state);
> + if (!new_bw_state)
> + return;
> +
> + if (!intel_can_enable_sagv(new_bw_state))
> intel_disable_sagv(dev_priv);
> }
>
> void intel_sagv_post_plane_update(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + const struct intel_bw_state *new_bw_state;
>
> - if (intel_can_enable_sagv(state))
> + /*
> + * Just return if we can't control SAGV or don't have it.
> + * This is different from situation when we have SAGV but just can't
> + * afford it due to DBuf limitation - in case if SAGV is completely
> + * disabled in a BIOS, we are not even allowed to send a PCode request,
> + * as it will throw an error. So have to check it here.
> + */
> + if (!intel_has_sagv(dev_priv))
> + return;
> +
> + new_bw_state = intel_atomic_get_new_bw_state(state);
> + if (!new_bw_state)
> + return;
> +
> + if (intel_can_enable_sagv(new_bw_state))
> intel_enable_sagv(dev_priv);
> }
>
> static bool intel_crtc_can_enable_sagv(const struct intel_crtc_state
> *crtc_state)
> {
> - struct drm_device *dev = crtc_state->uapi.crtc->dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> + struct intel_atomic_state *state =
> to_intel_atomic_state(crtc_state->uapi.state);
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> struct intel_plane *plane;
> + const struct intel_plane_state *plane_state;
> int level, latency;
>
> + if (!intel_has_sagv(dev_priv))
> + return false;
> +
>
Re: [Intel-gfx] [PATCH v26 2/9] drm/i915: Use bw state for per crtc SAGV evaluation
On Thu, Apr 30, 2020 at 12:09:22PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 23, 2020 at 10:58:55AM +0300, Stanislav Lisovskiy wrote:
> > Future platforms require per-crtc SAGV evaluation
> > and serializing global state when those are changed
> > from different commits.
> >
> > v2: - Add has_sagv check to intel_crtc_can_enable_sagv
> > so that it sets bit in reject mask.
> > - Use bw_state in intel_pre/post_plane_enable_sagv
> > instead of atomic state
> >
> > v3: - Fixed rebase conflict, now using
> > intel_atomic_crtc_state_for_each_plane_state in
> > order to call it from atomic check
> > v4: - Use fb modifier from plane state
> >
> > v5: - Make intel_has_sagv static again(Ville)
> > - Removed unnecessary NULL assignments(Ville)
> > - Removed unnecessary SAGV debug(Ville)
> > - Call intel_compute_sagv_mask only for modesets(Ville)
> > - Serialize global state only if sagv results change, but
> > not mask itself(Ville)
> >
> > v6: - use lock global state instead of serialize(Ville)
>
> What I meant is that we need both. Serialize if sagv state is going to
> change, otherwise lock if the mask changes.
As I understand whenever we modify global state but not a real hw, we do
only global state locking - pipe sagv mask is not actually a hw, but just
a virtual thing. It affects the QGV points we enable and if it happens to
affect those in a way that those change - we'll any way have serialize
called from intel_bw.c. Thus shouldn't be an issue.
I can change it anyway of course.
Stan
>
> >
> > Signed-off-by: Stanislav Lisovskiy
> > Cc: Ville Syrjälä
> > Cc: James Ausmus
> > ---
> > drivers/gpu/drm/i915/display/intel_bw.h | 6 ++
> > drivers/gpu/drm/i915/intel_pm.c | 113 ++--
> > drivers/gpu/drm/i915/intel_pm.h | 3 +-
> > 3 files changed, 93 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > b/drivers/gpu/drm/i915/display/intel_bw.h
> > index ac004d6f4276..d6df91058223 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > @@ -18,6 +18,12 @@ struct intel_crtc_state;
> > struct intel_bw_state {
> > struct intel_global_state base;
> >
> > + /*
> > +* Contains a bit mask, used to determine, whether correspondent
> > +* pipe allows SAGV or not.
> > +*/
> > + u8 pipe_sagv_reject;
> > +
> > unsigned int data_rate[I915_MAX_PIPES];
> > u8 num_active_planes[I915_MAX_PIPES];
> > };
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 338a82577b76..7e15cf3368ad 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -43,6 +43,7 @@
> > #include "i915_fixed.h"
> > #include "i915_irq.h"
> > #include "i915_trace.h"
> > +#include "display/intel_bw.h"
> > #include "intel_pm.h"
> > #include "intel_sideband.h"
> > #include "../../../platform/x86/intel_ips.h"
> > @@ -3760,34 +3761,75 @@ intel_disable_sagv(struct drm_i915_private
> > *dev_priv)
> > void intel_sagv_pre_plane_update(struct intel_atomic_state *state)
> > {
> > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > + const struct intel_bw_state *new_bw_state;
> >
> > - if (!intel_can_enable_sagv(state))
> > + /*
> > +* Just return if we can't control SAGV or don't have it.
> > +* This is different from situation when we have SAGV but just can't
> > +* afford it due to DBuf limitation - in case if SAGV is completely
> > +* disabled in a BIOS, we are not even allowed to send a PCode request,
> > +* as it will throw an error. So have to check it here.
> > +*/
> > + if (!intel_has_sagv(dev_priv))
> > + return;
> > +
> > + new_bw_state = intel_atomic_get_new_bw_state(state);
> > + if (!new_bw_state)
> > + return;
> > +
> > + if (!intel_can_enable_sagv(new_bw_state))
> > intel_disable_sagv(dev_priv);
> > }
> >
> > void intel_sagv_post_plane_update(struct intel_atomic_state *state)
> > {
> > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > + const struct intel_bw_state *new_bw_state;
> >
> > - if (intel_can_enable_sagv(state))
> > + /*
> > +* Just return if we can't control SAGV or don't have it.
> > +* This is different from situation when we have SAGV but just can't
> > +* afford it due to DBuf limitation - in case if SAGV is completely
> > +* disabled in a BIOS, we are not even allowed to send a PCode request,
> > +* as it will throw an error. So have to check it here.
> > +*/
> > + if (!intel_has_sagv(dev_priv))
> > + return;
> > +
> > + new_bw_state = intel_atomic_get_new_bw_state(state);
> > + if (!new_bw_state)
> > + return;
> > +
> > + if (intel_can_enable_sagv(new_bw_state))
> > intel_enable_sagv(dev_priv);
> > }
> >
> > static bool intel_crtc_can_ena
Re: [Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
On Thu, Apr 23, 2020 at 10:58:56AM +0300, Stanislav Lisovskiy wrote:
> We need to calculate SAGV mask also in a non-modeset
> commit, however currently active_pipes are only calculated
> for modesets in global atomic state, thus now we will be
> tracking those also in bw_state in order to be able to
> properly access global data.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_bw.h | 3 +++
> drivers/gpu/drm/i915/intel_pm.c | 15 ++-
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index d6df91058223..898b4a85ccab 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -26,6 +26,9 @@ struct intel_bw_state {
>
> unsigned int data_rate[I915_MAX_PIPES];
> u8 num_active_planes[I915_MAX_PIPES];
> +
> + /* bitmask of active pipes */
> + u8 active_pipes;
> };
>
> #define to_intel_bw_state(x) container_of((x), struct intel_bw_state, base)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 7e15cf3368ad..f7249bca3f6f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3874,6 +3874,7 @@ static int intel_compute_sagv_mask(struct
> intel_atomic_state *state)
> struct intel_bw_state *new_bw_state = NULL;
> const struct intel_bw_state *old_bw_state = NULL;
> int i;
> + bool active_pipes_calculated = false;
>
> for_each_new_intel_crtc_in_state(state, crtc,
>new_crtc_state, i) {
> @@ -3883,6 +3884,12 @@ static int intel_compute_sagv_mask(struct
> intel_atomic_state *state)
>
> old_bw_state = intel_atomic_get_old_bw_state(state);
>
> + if (!active_pipes_calculated) {
> + state->active_pipes = new_bw_state->active_pipes =
I don't think we should touch state->active_pipes here.
> + intel_calc_active_pipes(state,
> old_bw_state->active_pipes);
> + active_pipes_calculated = true;
> + }
I'd do this after the loop so we don't need this extra boolean. As far
as the active_pipes check in intel_crtc_can_enable_sagv(), I think we
can pull it out into intel_compute_sagv_mask() so that we do the check
after computing the mask. And of course change it to use
bw_state->active_pipes instead.
We're also going to need to lock_global_state() if bw_state->active_pipes
mask changes.
> +
> if (intel_crtc_can_enable_sagv(new_crtc_state))
> new_bw_state->pipe_sagv_reject &= ~BIT(crtc->pipe);
> else
> @@ -5911,11 +5918,9 @@ skl_compute_wm(struct intel_atomic_state *state)
> if (ret)
> return ret;
>
> - if (state->modeset) {
> - ret = intel_compute_sagv_mask(state);
> - if (ret)
> - return ret;
> - }
> + ret = intel_compute_sagv_mask(state);
> + if (ret)
> + return ret;
We also need to remove the state->modeset checks around
sagv_{pre,post}_update().
>
> /*
>* skl_compute_ddb() will have adjusted the final watermarks
> --
> 2.24.1.485.gad05a3d8e5
--
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 v26 2/9] drm/i915: Use bw state for per crtc SAGV evaluation
On Thu, Apr 30, 2020 at 12:13:35PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Apr 30, 2020 at 12:09:22PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 23, 2020 at 10:58:55AM +0300, Stanislav Lisovskiy wrote:
> > > Future platforms require per-crtc SAGV evaluation
> > > and serializing global state when those are changed
> > > from different commits.
> > >
> > > v2: - Add has_sagv check to intel_crtc_can_enable_sagv
> > > so that it sets bit in reject mask.
> > > - Use bw_state in intel_pre/post_plane_enable_sagv
> > > instead of atomic state
> > >
> > > v3: - Fixed rebase conflict, now using
> > > intel_atomic_crtc_state_for_each_plane_state in
> > > order to call it from atomic check
> > > v4: - Use fb modifier from plane state
> > >
> > > v5: - Make intel_has_sagv static again(Ville)
> > > - Removed unnecessary NULL assignments(Ville)
> > > - Removed unnecessary SAGV debug(Ville)
> > > - Call intel_compute_sagv_mask only for modesets(Ville)
> > > - Serialize global state only if sagv results change, but
> > > not mask itself(Ville)
> > >
> > > v6: - use lock global state instead of serialize(Ville)
> >
> > What I meant is that we need both. Serialize if sagv state is going to
> > change, otherwise lock if the mask changes.
>
> As I understand whenever we modify global state but not a real hw, we do
> only global state locking - pipe sagv mask is not actually a hw, but just
> a virtual thing. It affects the QGV points we enable and if it happens to
> affect those in a way that those change - we'll any way have serialize
> called from intel_bw.c. Thus shouldn't be an issue.
I don't like the code to rely on magic happening elsewhere. IMO
it just makes it hard to reason about the logic when you have
constantly remind youself what may or may not happen some other
piece of code. Also we don't even have qgv points on all the
platforms, so presumably we may not even excute that other
piece of code always?
>
> I can change it anyway of course.
>
> Stan
>
> >
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > Cc: Ville Syrjälä
> > > Cc: James Ausmus
> > > ---
> > > drivers/gpu/drm/i915/display/intel_bw.h | 6 ++
> > > drivers/gpu/drm/i915/intel_pm.c | 113 ++--
> > > drivers/gpu/drm/i915/intel_pm.h | 3 +-
> > > 3 files changed, 93 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > index ac004d6f4276..d6df91058223 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > @@ -18,6 +18,12 @@ struct intel_crtc_state;
> > > struct intel_bw_state {
> > > struct intel_global_state base;
> > >
> > > + /*
> > > + * Contains a bit mask, used to determine, whether correspondent
> > > + * pipe allows SAGV or not.
> > > + */
> > > + u8 pipe_sagv_reject;
> > > +
> > > unsigned int data_rate[I915_MAX_PIPES];
> > > u8 num_active_planes[I915_MAX_PIPES];
> > > };
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 338a82577b76..7e15cf3368ad 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -43,6 +43,7 @@
> > > #include "i915_fixed.h"
> > > #include "i915_irq.h"
> > > #include "i915_trace.h"
> > > +#include "display/intel_bw.h"
> > > #include "intel_pm.h"
> > > #include "intel_sideband.h"
> > > #include "../../../platform/x86/intel_ips.h"
> > > @@ -3760,34 +3761,75 @@ intel_disable_sagv(struct drm_i915_private
> > > *dev_priv)
> > > void intel_sagv_pre_plane_update(struct intel_atomic_state *state)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > + const struct intel_bw_state *new_bw_state;
> > >
> > > - if (!intel_can_enable_sagv(state))
> > > + /*
> > > + * Just return if we can't control SAGV or don't have it.
> > > + * This is different from situation when we have SAGV but just can't
> > > + * afford it due to DBuf limitation - in case if SAGV is completely
> > > + * disabled in a BIOS, we are not even allowed to send a PCode request,
> > > + * as it will throw an error. So have to check it here.
> > > + */
> > > + if (!intel_has_sagv(dev_priv))
> > > + return;
> > > +
> > > + new_bw_state = intel_atomic_get_new_bw_state(state);
> > > + if (!new_bw_state)
> > > + return;
> > > +
> > > + if (!intel_can_enable_sagv(new_bw_state))
> > > intel_disable_sagv(dev_priv);
> > > }
> > >
> > > void intel_sagv_post_plane_update(struct intel_atomic_state *state)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > + const struct intel_bw_state *new_bw_state;
> > >
> > > - if (intel_can_enable_sagv(state))
> > > + /*
> > > + * Just return if we can't control SAGV or don't have it.
> > > + * This is different from situation when we have SAGV but
[Intel-gfx] [PATCH i-g-t] perf: Bump the timestamp tolerance for really slow devices
Slow devices with low CS frequencies may take longer than expected
between the PIPECONTROL timestamp and the OA timestamp, hovering just
above the arbitrary 500ns threshold. The discrepancy seems relatively
stable, just the device taking longer than anticipated without affecting
the results, so make the threshold a little more lenient.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
---
tests/perf.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/tests/perf.c b/tests/perf.c
index 5d3c68789..b1e2a2e64 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -3415,13 +3415,13 @@
gen8_test_single_ctx_render_target_writes_a_counter(void)
uint64_t timestamp0_64, timestamp1_64;
uint32_t delta_ts64, delta_oa32;
uint64_t delta_ts64_ns, delta_oa32_ns;
- uint32_t delta_delta;
int width = 800;
int height = 600;
uint32_t ctx_id = 0x; /* invalid handle */
uint32_t ctx1_id = 0x; /* invalid handle */
uint32_t current_ctx_id = 0x;
uint32_t n_invalid_ctx = 0;
+ int delta_delta;
int ret;
struct accumulator accumulator = {
.format = test_set->perf_oa_format
@@ -3589,12 +3589,10 @@
gen8_test_single_ctx_render_target_writes_a_counter(void)
/* The delta as calculated via the PIPE_CONTROL
timestamp or
* the OA report timestamps should be almost identical
but
-* allow a 500 nanoseconds margin.
+* allow a 2 microsecond margin.
*/
- delta_delta = delta_ts64_ns > delta_oa32_ns ?
- (delta_ts64_ns - delta_oa32_ns) :
- (delta_oa32_ns - delta_ts64_ns);
- if (delta_delta > 500) {
+ delta_delta = delta_ts64_ns - delta_oa32_ns;
+ if (abs(delta_delta) > 2000) {
igt_debug("Too slow %d; skipping\n",
delta_delta);
ret = EAGAIN;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v26 2/9] drm/i915: Use bw state for per crtc SAGV evaluation
On Thu, Apr 30, 2020 at 12:25:38PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 30, 2020 at 12:13:35PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Apr 30, 2020 at 12:09:22PM +0300, Ville Syrjälä wrote:
> > > On Thu, Apr 23, 2020 at 10:58:55AM +0300, Stanislav Lisovskiy wrote:
> > > > Future platforms require per-crtc SAGV evaluation
> > > > and serializing global state when those are changed
> > > > from different commits.
> > > >
> > > > v2: - Add has_sagv check to intel_crtc_can_enable_sagv
> > > > so that it sets bit in reject mask.
> > > > - Use bw_state in intel_pre/post_plane_enable_sagv
> > > > instead of atomic state
> > > >
> > > > v3: - Fixed rebase conflict, now using
> > > > intel_atomic_crtc_state_for_each_plane_state in
> > > > order to call it from atomic check
> > > > v4: - Use fb modifier from plane state
> > > >
> > > > v5: - Make intel_has_sagv static again(Ville)
> > > > - Removed unnecessary NULL assignments(Ville)
> > > > - Removed unnecessary SAGV debug(Ville)
> > > > - Call intel_compute_sagv_mask only for modesets(Ville)
> > > > - Serialize global state only if sagv results change, but
> > > > not mask itself(Ville)
> > > >
> > > > v6: - use lock global state instead of serialize(Ville)
> > >
> > > What I meant is that we need both. Serialize if sagv state is going to
> > > change, otherwise lock if the mask changes.
> >
> > As I understand whenever we modify global state but not a real hw, we do
> > only global state locking - pipe sagv mask is not actually a hw, but just
> > a virtual thing. It affects the QGV points we enable and if it happens to
> > affect those in a way that those change - we'll any way have serialize
> > called from intel_bw.c. Thus shouldn't be an issue.
>
> I don't like the code to rely on magic happening elsewhere. IMO
> it just makes it hard to reason about the logic when you have
> constantly remind youself what may or may not happen some other
> piece of code. Also we don't even have qgv points on all the
> platforms, so presumably we may not even excute that other
> piece of code always?
Agree, sounds reasonable. Would be cool may be to unite both serialize
and global state locking, under some helper function, so that same
code snippet is not copy-paste all over the place.
like intel_lock_or_serialize_state(state, bool global_state_changed, bool
hw_state_changed)
Stan
>
> >
> > I can change it anyway of course.
> >
> > Stan
> >
> > >
> > > >
> > > > Signed-off-by: Stanislav Lisovskiy
> > > > Cc: Ville Syrjälä
> > > > Cc: James Ausmus
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_bw.h | 6 ++
> > > > drivers/gpu/drm/i915/intel_pm.c | 113 ++--
> > > > drivers/gpu/drm/i915/intel_pm.h | 3 +-
> > > > 3 files changed, 93 insertions(+), 29 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > index ac004d6f4276..d6df91058223 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > @@ -18,6 +18,12 @@ struct intel_crtc_state;
> > > > struct intel_bw_state {
> > > > struct intel_global_state base;
> > > >
> > > > + /*
> > > > +* Contains a bit mask, used to determine, whether correspondent
> > > > +* pipe allows SAGV or not.
> > > > +*/
> > > > + u8 pipe_sagv_reject;
> > > > +
> > > > unsigned int data_rate[I915_MAX_PIPES];
> > > > u8 num_active_planes[I915_MAX_PIPES];
> > > > };
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 338a82577b76..7e15cf3368ad 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -43,6 +43,7 @@
> > > > #include "i915_fixed.h"
> > > > #include "i915_irq.h"
> > > > #include "i915_trace.h"
> > > > +#include "display/intel_bw.h"
> > > > #include "intel_pm.h"
> > > > #include "intel_sideband.h"
> > > > #include "../../../platform/x86/intel_ips.h"
> > > > @@ -3760,34 +3761,75 @@ intel_disable_sagv(struct drm_i915_private
> > > > *dev_priv)
> > > > void intel_sagv_pre_plane_update(struct intel_atomic_state *state)
> > > > {
> > > > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > > + const struct intel_bw_state *new_bw_state;
> > > >
> > > > - if (!intel_can_enable_sagv(state))
> > > > + /*
> > > > +* Just return if we can't control SAGV or don't have it.
> > > > +* This is different from situation when we have SAGV but just
> > > > can't
> > > > +* afford it due to DBuf limitation - in case if SAGV is
> > > > completely
> > > > +* disabled in a BIOS, we are not even allowed to send a PCode
> > > > request,
> > > > +* as it will throw an error. So have to check it here.
> > > > +*/
> >
Re: [Intel-gfx] [PATCH v26 2/9] drm/i915: Use bw state for per crtc SAGV evaluation
On Thu, Apr 30, 2020 at 12:52:42PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Apr 30, 2020 at 12:25:38PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 30, 2020 at 12:13:35PM +0300, Lisovskiy, Stanislav wrote:
> > > On Thu, Apr 30, 2020 at 12:09:22PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Apr 23, 2020 at 10:58:55AM +0300, Stanislav Lisovskiy wrote:
> > > > > Future platforms require per-crtc SAGV evaluation
> > > > > and serializing global state when those are changed
> > > > > from different commits.
> > > > >
> > > > > v2: - Add has_sagv check to intel_crtc_can_enable_sagv
> > > > > so that it sets bit in reject mask.
> > > > > - Use bw_state in intel_pre/post_plane_enable_sagv
> > > > > instead of atomic state
> > > > >
> > > > > v3: - Fixed rebase conflict, now using
> > > > > intel_atomic_crtc_state_for_each_plane_state in
> > > > > order to call it from atomic check
> > > > > v4: - Use fb modifier from plane state
> > > > >
> > > > > v5: - Make intel_has_sagv static again(Ville)
> > > > > - Removed unnecessary NULL assignments(Ville)
> > > > > - Removed unnecessary SAGV debug(Ville)
> > > > > - Call intel_compute_sagv_mask only for modesets(Ville)
> > > > > - Serialize global state only if sagv results change, but
> > > > > not mask itself(Ville)
> > > > >
> > > > > v6: - use lock global state instead of serialize(Ville)
> > > >
> > > > What I meant is that we need both. Serialize if sagv state is going to
> > > > change, otherwise lock if the mask changes.
> > >
> > > As I understand whenever we modify global state but not a real hw, we do
> > > only global state locking - pipe sagv mask is not actually a hw, but just
> > > a virtual thing. It affects the QGV points we enable and if it happens to
> > > affect those in a way that those change - we'll any way have serialize
> > > called from intel_bw.c. Thus shouldn't be an issue.
> >
> > I don't like the code to rely on magic happening elsewhere. IMO
> > it just makes it hard to reason about the logic when you have
> > constantly remind youself what may or may not happen some other
> > piece of code. Also we don't even have qgv points on all the
> > platforms, so presumably we may not even excute that other
> > piece of code always?
>
> Agree, sounds reasonable. Would be cool may be to unite both serialize
> and global state locking, under some helper function, so that same
> code snippet is not copy-paste all over the place.
>
> like intel_lock_or_serialize_state(state, bool global_state_changed, bool
> hw_state_changed)
intel_lock_or_serialize_state(state,
a != b,
x != y);
doesn't really make the intent clear at all. So not really in favor of a
function that takes two booleans.
>
> Stan
>
> >
> > >
> > > I can change it anyway of course.
> > >
> > > Stan
> > >
> > > >
> > > > >
> > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > Cc: Ville Syrjälä
> > > > > Cc: James Ausmus
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_bw.h | 6 ++
> > > > > drivers/gpu/drm/i915/intel_pm.c | 113
> > > > > ++--
> > > > > drivers/gpu/drm/i915/intel_pm.h | 3 +-
> > > > > 3 files changed, 93 insertions(+), 29 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > index ac004d6f4276..d6df91058223 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > @@ -18,6 +18,12 @@ struct intel_crtc_state;
> > > > > struct intel_bw_state {
> > > > > struct intel_global_state base;
> > > > >
> > > > > + /*
> > > > > + * Contains a bit mask, used to determine, whether correspondent
> > > > > + * pipe allows SAGV or not.
> > > > > + */
> > > > > + u8 pipe_sagv_reject;
> > > > > +
> > > > > unsigned int data_rate[I915_MAX_PIPES];
> > > > > u8 num_active_planes[I915_MAX_PIPES];
> > > > > };
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > index 338a82577b76..7e15cf3368ad 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > @@ -43,6 +43,7 @@
> > > > > #include "i915_fixed.h"
> > > > > #include "i915_irq.h"
> > > > > #include "i915_trace.h"
> > > > > +#include "display/intel_bw.h"
> > > > > #include "intel_pm.h"
> > > > > #include "intel_sideband.h"
> > > > > #include "../../../platform/x86/intel_ips.h"
> > > > > @@ -3760,34 +3761,75 @@ intel_disable_sagv(struct drm_i915_private
> > > > > *dev_priv)
> > > > > void intel_sagv_pre_plane_update(struct intel_atomic_state *state)
> > > > > {
> > > > > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > > > + const struct intel_bw_state *new_bw_state;
> > > > >
> > > > > - if (!inte
Re: [Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
On Thu, Apr 30, 2020 at 12:21:04PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 23, 2020 at 10:58:56AM +0300, Stanislav Lisovskiy wrote:
> > We need to calculate SAGV mask also in a non-modeset
> > commit, however currently active_pipes are only calculated
> > for modesets in global atomic state, thus now we will be
> > tracking those also in bw_state in order to be able to
> > properly access global data.
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/i915/display/intel_bw.h | 3 +++
> > drivers/gpu/drm/i915/intel_pm.c | 15 ++-
> > 2 files changed, 13 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > b/drivers/gpu/drm/i915/display/intel_bw.h
> > index d6df91058223..898b4a85ccab 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > @@ -26,6 +26,9 @@ struct intel_bw_state {
> >
> > unsigned int data_rate[I915_MAX_PIPES];
> > u8 num_active_planes[I915_MAX_PIPES];
> > +
> > + /* bitmask of active pipes */
> > + u8 active_pipes;
> > };
> >
> > #define to_intel_bw_state(x) container_of((x), struct intel_bw_state, base)
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 7e15cf3368ad..f7249bca3f6f 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3874,6 +3874,7 @@ static int intel_compute_sagv_mask(struct
> > intel_atomic_state *state)
> > struct intel_bw_state *new_bw_state = NULL;
> > const struct intel_bw_state *old_bw_state = NULL;
> > int i;
> > + bool active_pipes_calculated = false;
> >
> > for_each_new_intel_crtc_in_state(state, crtc,
> > new_crtc_state, i) {
> > @@ -3883,6 +3884,12 @@ static int intel_compute_sagv_mask(struct
> > intel_atomic_state *state)
> >
> > old_bw_state = intel_atomic_get_old_bw_state(state);
> >
> > + if (!active_pipes_calculated) {
> > + state->active_pipes = new_bw_state->active_pipes =
>
> I don't think we should touch state->active_pipes here.
Well, that was my question actually here as well. I understand that changing
state->active_pipes here feels like some unneeded side effect, however having
state->active_pipes and bw_state->active_pipes going out of sync doesn't sound
very attractive to me either. That is why I don't like this idea of duplication
at all - having constant need to sync those state, bw_state, cdclk_state,
because
they all might have different active_pipes now.
>
> > + intel_calc_active_pipes(state,
> > old_bw_state->active_pipes);
> > + active_pipes_calculated = true;
> > + }
>
> I'd do this after the loop so we don't need this extra boolean. As far
> as the active_pipes check in intel_crtc_can_enable_sagv(), I think we
> can pull it out into intel_compute_sagv_mask() so that we do the check
> after computing the mask. And of course change it to use
> bw_state->active_pipes instead.
intel_crtc_can_enable_sagv is called per crtc - so can't just pull it out,
will have to have to cycles then - one will compute bw_state->active_pipes,
and another pipe_sagv_mask.
>
> We're also going to need to lock_global_state() if bw_state->active_pipes
> mask changes.
Ohh.. right.
Stan
>
> > +
> > if (intel_crtc_can_enable_sagv(new_crtc_state))
> > new_bw_state->pipe_sagv_reject &= ~BIT(crtc->pipe);
> > else
> > @@ -5911,11 +5918,9 @@ skl_compute_wm(struct intel_atomic_state *state)
> > if (ret)
> > return ret;
> >
> > - if (state->modeset) {
> > - ret = intel_compute_sagv_mask(state);
> > - if (ret)
> > - return ret;
> > - }
> > + ret = intel_compute_sagv_mask(state);
> > + if (ret)
> > + return ret;
>
> We also need to remove the state->modeset checks around
> sagv_{pre,post}_update().
>
> >
> > /*
> > * skl_compute_ddb() will have adjusted the final watermarks
> > --
> > 2.24.1.485.gad05a3d8e5
>
> --
> 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 v26 2/9] drm/i915: Use bw state for per crtc SAGV evaluation
On Thu, Apr 30, 2020 at 01:08:20PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 30, 2020 at 12:52:42PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Apr 30, 2020 at 12:25:38PM +0300, Ville Syrjälä wrote:
> > > On Thu, Apr 30, 2020 at 12:13:35PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Thu, Apr 30, 2020 at 12:09:22PM +0300, Ville Syrjälä wrote:
> > > > > On Thu, Apr 23, 2020 at 10:58:55AM +0300, Stanislav Lisovskiy wrote:
> > > > > > Future platforms require per-crtc SAGV evaluation
> > > > > > and serializing global state when those are changed
> > > > > > from different commits.
> > > > > >
> > > > > > v2: - Add has_sagv check to intel_crtc_can_enable_sagv
> > > > > > so that it sets bit in reject mask.
> > > > > > - Use bw_state in intel_pre/post_plane_enable_sagv
> > > > > > instead of atomic state
> > > > > >
> > > > > > v3: - Fixed rebase conflict, now using
> > > > > > intel_atomic_crtc_state_for_each_plane_state in
> > > > > > order to call it from atomic check
> > > > > > v4: - Use fb modifier from plane state
> > > > > >
> > > > > > v5: - Make intel_has_sagv static again(Ville)
> > > > > > - Removed unnecessary NULL assignments(Ville)
> > > > > > - Removed unnecessary SAGV debug(Ville)
> > > > > > - Call intel_compute_sagv_mask only for modesets(Ville)
> > > > > > - Serialize global state only if sagv results change, but
> > > > > > not mask itself(Ville)
> > > > > >
> > > > > > v6: - use lock global state instead of serialize(Ville)
> > > > >
> > > > > What I meant is that we need both. Serialize if sagv state is going to
> > > > > change, otherwise lock if the mask changes.
> > > >
> > > > As I understand whenever we modify global state but not a real hw, we do
> > > > only global state locking - pipe sagv mask is not actually a hw, but
> > > > just
> > > > a virtual thing. It affects the QGV points we enable and if it happens
> > > > to
> > > > affect those in a way that those change - we'll any way have serialize
> > > > called from intel_bw.c. Thus shouldn't be an issue.
> > >
> > > I don't like the code to rely on magic happening elsewhere. IMO
> > > it just makes it hard to reason about the logic when you have
> > > constantly remind youself what may or may not happen some other
> > > piece of code. Also we don't even have qgv points on all the
> > > platforms, so presumably we may not even excute that other
> > > piece of code always?
> >
> > Agree, sounds reasonable. Would be cool may be to unite both serialize
> > and global state locking, under some helper function, so that same
> > code snippet is not copy-paste all over the place.
> >
> > like intel_lock_or_serialize_state(state, bool global_state_changed, bool
> > hw_state_changed)
>
> intel_lock_or_serialize_state(state,
> a != b,
> x != y);
>
> doesn't really make the intent clear at all. So not really in favor of a
> function that takes two booleans.
bool global_state_changed = new_sagv_pipe_mask != old_sagv_pipe_mask;
bool hw_state_changed = new_can_enable_sagv != old_can_enable_sagv;
intel_lock_or_serialize(state, global_state_changed, hw_state_changed);
I think together with proper comment this looks pretty clear and also
eliminates the need in duplicating conditions all over the place.
Just a proposal though.
Stan
>
> >
> > Stan
> >
> > >
> > > >
> > > > I can change it anyway of course.
> > > >
> > > > Stan
> > > >
> > > > >
> > > > > >
> > > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > > Cc: Ville Syrjälä
> > > > > > Cc: James Ausmus
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/display/intel_bw.h | 6 ++
> > > > > > drivers/gpu/drm/i915/intel_pm.c | 113
> > > > > > ++--
> > > > > > drivers/gpu/drm/i915/intel_pm.h | 3 +-
> > > > > > 3 files changed, 93 insertions(+), 29 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > index ac004d6f4276..d6df91058223 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > @@ -18,6 +18,12 @@ struct intel_crtc_state;
> > > > > > struct intel_bw_state {
> > > > > > struct intel_global_state base;
> > > > > >
> > > > > > + /*
> > > > > > +* Contains a bit mask, used to determine, whether correspondent
> > > > > > +* pipe allows SAGV or not.
> > > > > > +*/
> > > > > > + u8 pipe_sagv_reject;
> > > > > > +
> > > > > > unsigned int data_rate[I915_MAX_PIPES];
> > > > > > u8 num_active_planes[I915_MAX_PIPES];
> > > > > > };
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > index 338a82577b76..7e15cf3368ad 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > @@ -43
Re: [Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
On Thu, Apr 30, 2020 at 01:05:15PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Apr 30, 2020 at 12:21:04PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 23, 2020 at 10:58:56AM +0300, Stanislav Lisovskiy wrote:
> > > We need to calculate SAGV mask also in a non-modeset
> > > commit, however currently active_pipes are only calculated
> > > for modesets in global atomic state, thus now we will be
> > > tracking those also in bw_state in order to be able to
> > > properly access global data.
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > ---
> > > drivers/gpu/drm/i915/display/intel_bw.h | 3 +++
> > > drivers/gpu/drm/i915/intel_pm.c | 15 ++-
> > > 2 files changed, 13 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > index d6df91058223..898b4a85ccab 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > @@ -26,6 +26,9 @@ struct intel_bw_state {
> > >
> > > unsigned int data_rate[I915_MAX_PIPES];
> > > u8 num_active_planes[I915_MAX_PIPES];
> > > +
> > > + /* bitmask of active pipes */
> > > + u8 active_pipes;
> > > };
> > >
> > > #define to_intel_bw_state(x) container_of((x), struct intel_bw_state,
> > > base)
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 7e15cf3368ad..f7249bca3f6f 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -3874,6 +3874,7 @@ static int intel_compute_sagv_mask(struct
> > > intel_atomic_state *state)
> > > struct intel_bw_state *new_bw_state = NULL;
> > > const struct intel_bw_state *old_bw_state = NULL;
> > > int i;
> > > + bool active_pipes_calculated = false;
> > >
> > > for_each_new_intel_crtc_in_state(state, crtc,
> > >new_crtc_state, i) {
> > > @@ -3883,6 +3884,12 @@ static int intel_compute_sagv_mask(struct
> > > intel_atomic_state *state)
> > >
> > > old_bw_state = intel_atomic_get_old_bw_state(state);
> > >
> > > + if (!active_pipes_calculated) {
> > > + state->active_pipes = new_bw_state->active_pipes =
> >
> > I don't think we should touch state->active_pipes here.
>
> Well, that was my question actually here as well. I understand that changing
> state->active_pipes here feels like some unneeded side effect, however having
> state->active_pipes and bw_state->active_pipes going out of sync doesn't sound
> very attractive to me either. That is why I don't like this idea of
> duplication
> at all - having constant need to sync those state, bw_state, cdclk_state,
> because
> they all might have different active_pipes now.
Having an out of date active_pipes anywhere would be a bug in that
specific code. Also state->active_pipes is definitely going the way of
the dodo soon.
>
> >
> > > + intel_calc_active_pipes(state,
> > > old_bw_state->active_pipes);
> > > + active_pipes_calculated = true;
> > > + }
> >
> > I'd do this after the loop so we don't need this extra boolean. As far
> > as the active_pipes check in intel_crtc_can_enable_sagv(), I think we
> > can pull it out into intel_compute_sagv_mask() so that we do the check
> > after computing the mask. And of course change it to use
> > bw_state->active_pipes instead.
>
> intel_crtc_can_enable_sagv is called per crtc - so can't just pull it out,
> will have to have to cycles then - one will compute bw_state->active_pipes,
> and another pipe_sagv_mask.
Hmm. Actually I think what we should probably do is keep the
active_pipes check in intel_can_enable_sagv(). Ie something like this:
intel_can_enable_sagv(bw_state) {
if (active_pipes && !is_power_of_2(active_pipes))
return false;
return sagv_reject != 0;
}
compute_sagv() {
for_each_crtc() {
if (crtc_can_sagv())
sagv_reject &= ~pipe;
else
sagv_reject |= pipe;
}
active_pipes = calc_active_pipes();
... lock/serialize etc.
}
That way we don't have to update sagv_reject at all based on
active_pipes. I think that even makes more sense since the
active_pipes check is a global thing and not tied to any specific
crtc.
We can then make the check conditional on pre-icl (or whatever we want)
in a later patch. And finally we can remove it altogether in a separate
patch, since I don't think we should have to do it on any platform.
>
> >
> > We're also going to need to lock_global_state() if bw_state->active_pipes
> > mask changes.
>
> Ohh.. right.
>
>
> Stan
>
> >
> > > +
> > > if (intel_crtc_can_enable_sagv(new_crtc_state))
> > > new_bw_state->pipe_sagv_reject &= ~BIT(crtc->pipe);
> > > else
> > > @@ -5911,11 +5918,9 @@ skl_compute_wm(struct int
Re: [Intel-gfx] [PATCH v26 2/9] drm/i915: Use bw state for per crtc SAGV evaluation
On Thu, Apr 30, 2020 at 01:14:57PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Apr 30, 2020 at 01:08:20PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 30, 2020 at 12:52:42PM +0300, Lisovskiy, Stanislav wrote:
> > > On Thu, Apr 30, 2020 at 12:25:38PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Apr 30, 2020 at 12:13:35PM +0300, Lisovskiy, Stanislav wrote:
> > > > > On Thu, Apr 30, 2020 at 12:09:22PM +0300, Ville Syrjälä wrote:
> > > > > > On Thu, Apr 23, 2020 at 10:58:55AM +0300, Stanislav Lisovskiy wrote:
> > > > > > > Future platforms require per-crtc SAGV evaluation
> > > > > > > and serializing global state when those are changed
> > > > > > > from different commits.
> > > > > > >
> > > > > > > v2: - Add has_sagv check to intel_crtc_can_enable_sagv
> > > > > > > so that it sets bit in reject mask.
> > > > > > > - Use bw_state in intel_pre/post_plane_enable_sagv
> > > > > > > instead of atomic state
> > > > > > >
> > > > > > > v3: - Fixed rebase conflict, now using
> > > > > > > intel_atomic_crtc_state_for_each_plane_state in
> > > > > > > order to call it from atomic check
> > > > > > > v4: - Use fb modifier from plane state
> > > > > > >
> > > > > > > v5: - Make intel_has_sagv static again(Ville)
> > > > > > > - Removed unnecessary NULL assignments(Ville)
> > > > > > > - Removed unnecessary SAGV debug(Ville)
> > > > > > > - Call intel_compute_sagv_mask only for modesets(Ville)
> > > > > > > - Serialize global state only if sagv results change, but
> > > > > > > not mask itself(Ville)
> > > > > > >
> > > > > > > v6: - use lock global state instead of serialize(Ville)
> > > > > >
> > > > > > What I meant is that we need both. Serialize if sagv state is going
> > > > > > to
> > > > > > change, otherwise lock if the mask changes.
> > > > >
> > > > > As I understand whenever we modify global state but not a real hw, we
> > > > > do
> > > > > only global state locking - pipe sagv mask is not actually a hw, but
> > > > > just
> > > > > a virtual thing. It affects the QGV points we enable and if it
> > > > > happens to
> > > > > affect those in a way that those change - we'll any way have serialize
> > > > > called from intel_bw.c. Thus shouldn't be an issue.
> > > >
> > > > I don't like the code to rely on magic happening elsewhere. IMO
> > > > it just makes it hard to reason about the logic when you have
> > > > constantly remind youself what may or may not happen some other
> > > > piece of code. Also we don't even have qgv points on all the
> > > > platforms, so presumably we may not even excute that other
> > > > piece of code always?
> > >
> > > Agree, sounds reasonable. Would be cool may be to unite both serialize
> > > and global state locking, under some helper function, so that same
> > > code snippet is not copy-paste all over the place.
> > >
> > > like intel_lock_or_serialize_state(state, bool global_state_changed, bool
> > > hw_state_changed)
> >
> > intel_lock_or_serialize_state(state,
> > a != b,
> > x != y);
> >
> > doesn't really make the intent clear at all. So not really in favor of a
> > function that takes two booleans.
>
> bool global_state_changed = new_sagv_pipe_mask != old_sagv_pipe_mask;
> bool hw_state_changed = new_can_enable_sagv != old_can_enable_sagv;
If we consistently make those functions instead of
variables then I could probably buy it.
>
> intel_lock_or_serialize(state, global_state_changed, hw_state_changed);
>
> I think together with proper comment this looks pretty clear and also
> eliminates the need in duplicating conditions all over the place.
If we have to add a comment I'd say the plan has already
failed. Good code needs no comments.
>
> Just a proposal though.
>
> Stan
>
> >
> > >
> > > Stan
> > >
> > > >
> > > > >
> > > > > I can change it anyway of course.
> > > > >
> > > > > Stan
> > > > >
> > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > > > Cc: Ville Syrjälä
> > > > > > > Cc: James Ausmus
> > > > > > > ---
> > > > > > > drivers/gpu/drm/i915/display/intel_bw.h | 6 ++
> > > > > > > drivers/gpu/drm/i915/intel_pm.c | 113
> > > > > > > ++--
> > > > > > > drivers/gpu/drm/i915/intel_pm.h | 3 +-
> > > > > > > 3 files changed, 93 insertions(+), 29 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > index ac004d6f4276..d6df91058223 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > @@ -18,6 +18,12 @@ struct intel_crtc_state;
> > > > > > > struct intel_bw_state {
> > > > > > > struct intel_global_state base;
> > > > > > >
> > > > > > > + /*
> > > > > > > + * Contains a bit mask, used to determine, whether correspondent
> > > > > > > + * pipe allows
Re: [Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
On Thu, Apr 30, 2020 at 01:32:17PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 30, 2020 at 01:05:15PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Apr 30, 2020 at 12:21:04PM +0300, Ville Syrjälä wrote:
> > > On Thu, Apr 23, 2020 at 10:58:56AM +0300, Stanislav Lisovskiy wrote:
> > > > We need to calculate SAGV mask also in a non-modeset
> > > > commit, however currently active_pipes are only calculated
> > > > for modesets in global atomic state, thus now we will be
> > > > tracking those also in bw_state in order to be able to
> > > > properly access global data.
> > > >
> > > > Signed-off-by: Stanislav Lisovskiy
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_bw.h | 3 +++
> > > > drivers/gpu/drm/i915/intel_pm.c | 15 ++-
> > > > 2 files changed, 13 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > index d6df91058223..898b4a85ccab 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > @@ -26,6 +26,9 @@ struct intel_bw_state {
> > > >
> > > > unsigned int data_rate[I915_MAX_PIPES];
> > > > u8 num_active_planes[I915_MAX_PIPES];
> > > > +
> > > > + /* bitmask of active pipes */
> > > > + u8 active_pipes;
> > > > };
> > > >
> > > > #define to_intel_bw_state(x) container_of((x), struct intel_bw_state,
> > > > base)
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 7e15cf3368ad..f7249bca3f6f 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -3874,6 +3874,7 @@ static int intel_compute_sagv_mask(struct
> > > > intel_atomic_state *state)
> > > > struct intel_bw_state *new_bw_state = NULL;
> > > > const struct intel_bw_state *old_bw_state = NULL;
> > > > int i;
> > > > + bool active_pipes_calculated = false;
> > > >
> > > > for_each_new_intel_crtc_in_state(state, crtc,
> > > > new_crtc_state, i) {
> > > > @@ -3883,6 +3884,12 @@ static int intel_compute_sagv_mask(struct
> > > > intel_atomic_state *state)
> > > >
> > > > old_bw_state = intel_atomic_get_old_bw_state(state);
> > > >
> > > > + if (!active_pipes_calculated) {
> > > > + state->active_pipes =
> > > > new_bw_state->active_pipes =
> > >
> > > I don't think we should touch state->active_pipes here.
> >
> > Well, that was my question actually here as well. I understand that changing
> > state->active_pipes here feels like some unneeded side effect, however
> > having
> > state->active_pipes and bw_state->active_pipes going out of sync doesn't
> > sound
> > very attractive to me either. That is why I don't like this idea of
> > duplication
> > at all - having constant need to sync those state, bw_state, cdclk_state,
> > because
> > they all might have different active_pipes now.
>
> Having an out of date active_pipes anywhere would be a bug in that
> specific code. Also state->active_pipes is definitely going the way of
> the dodo soon.
>
> >
> > >
> > > > + intel_calc_active_pipes(state,
> > > > old_bw_state->active_pipes);
> > > > + active_pipes_calculated = true;
> > > > + }
> > >
> > > I'd do this after the loop so we don't need this extra boolean. As far
> > > as the active_pipes check in intel_crtc_can_enable_sagv(), I think we
> > > can pull it out into intel_compute_sagv_mask() so that we do the check
> > > after computing the mask. And of course change it to use
> > > bw_state->active_pipes instead.
> >
> > intel_crtc_can_enable_sagv is called per crtc - so can't just pull it out,
> > will have to have to cycles then - one will compute bw_state->active_pipes,
> > and another pipe_sagv_mask.
>
> Hmm. Actually I think what we should probably do is keep the
> active_pipes check in intel_can_enable_sagv(). Ie something like this:
>
> intel_can_enable_sagv(bw_state) {
> if (active_pipes && !is_power_of_2(active_pipes))
> return false;
> return sagv_reject != 0;
> }
I need active_pipes check here for skl code only, as it disables SAGV for
multipipe
scenarios. Adding this here would generalize it for other platforms and we
don't want that for ICL+.
In fact that is the only reason I need active pipes here - otherwise I think
it was even your comment that we actually don't need those here at all,
as we just iterate through crtcs in state - pretty clearly remember we discussed
this. Just same way how it's done in intel bw check and other places.
Stan
>
> compute_sagv() {
> for_each_crtc() {
> if (crtc_can_sagv())
> sagv_reject &= ~pipe;
> else
> sagv_reject |= pipe;
> }
>
Re: [Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
On Thu, Apr 30, 2020 at 01:47:02PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Apr 30, 2020 at 01:32:17PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 30, 2020 at 01:05:15PM +0300, Lisovskiy, Stanislav wrote:
> > > On Thu, Apr 30, 2020 at 12:21:04PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Apr 23, 2020 at 10:58:56AM +0300, Stanislav Lisovskiy wrote:
> > > > > We need to calculate SAGV mask also in a non-modeset
> > > > > commit, however currently active_pipes are only calculated
> > > > > for modesets in global atomic state, thus now we will be
> > > > > tracking those also in bw_state in order to be able to
> > > > > properly access global data.
> > > > >
> > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_bw.h | 3 +++
> > > > > drivers/gpu/drm/i915/intel_pm.c | 15 ++-
> > > > > 2 files changed, 13 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > index d6df91058223..898b4a85ccab 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > @@ -26,6 +26,9 @@ struct intel_bw_state {
> > > > >
> > > > > unsigned int data_rate[I915_MAX_PIPES];
> > > > > u8 num_active_planes[I915_MAX_PIPES];
> > > > > +
> > > > > + /* bitmask of active pipes */
> > > > > + u8 active_pipes;
> > > > > };
> > > > >
> > > > > #define to_intel_bw_state(x) container_of((x), struct
> > > > > intel_bw_state, base)
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > index 7e15cf3368ad..f7249bca3f6f 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > @@ -3874,6 +3874,7 @@ static int intel_compute_sagv_mask(struct
> > > > > intel_atomic_state *state)
> > > > > struct intel_bw_state *new_bw_state = NULL;
> > > > > const struct intel_bw_state *old_bw_state = NULL;
> > > > > int i;
> > > > > + bool active_pipes_calculated = false;
> > > > >
> > > > > for_each_new_intel_crtc_in_state(state, crtc,
> > > > >new_crtc_state, i) {
> > > > > @@ -3883,6 +3884,12 @@ static int intel_compute_sagv_mask(struct
> > > > > intel_atomic_state *state)
> > > > >
> > > > > old_bw_state = intel_atomic_get_old_bw_state(state);
> > > > >
> > > > > + if (!active_pipes_calculated) {
> > > > > + state->active_pipes =
> > > > > new_bw_state->active_pipes =
> > > >
> > > > I don't think we should touch state->active_pipes here.
> > >
> > > Well, that was my question actually here as well. I understand that
> > > changing
> > > state->active_pipes here feels like some unneeded side effect, however
> > > having
> > > state->active_pipes and bw_state->active_pipes going out of sync doesn't
> > > sound
> > > very attractive to me either. That is why I don't like this idea of
> > > duplication
> > > at all - having constant need to sync those state, bw_state, cdclk_state,
> > > because
> > > they all might have different active_pipes now.
> >
> > Having an out of date active_pipes anywhere would be a bug in that
> > specific code. Also state->active_pipes is definitely going the way of
> > the dodo soon.
> >
> > >
> > > >
> > > > > + intel_calc_active_pipes(state,
> > > > > old_bw_state->active_pipes);
> > > > > + active_pipes_calculated = true;
> > > > > + }
> > > >
> > > > I'd do this after the loop so we don't need this extra boolean. As far
> > > > as the active_pipes check in intel_crtc_can_enable_sagv(), I think we
> > > > can pull it out into intel_compute_sagv_mask() so that we do the check
> > > > after computing the mask. And of course change it to use
> > > > bw_state->active_pipes instead.
> > >
> > > intel_crtc_can_enable_sagv is called per crtc - so can't just pull it
> > > out,
> > > will have to have to cycles then - one will compute
> > > bw_state->active_pipes,
> > > and another pipe_sagv_mask.
> >
> > Hmm. Actually I think what we should probably do is keep the
> > active_pipes check in intel_can_enable_sagv(). Ie something like this:
> >
> > intel_can_enable_sagv(bw_state) {
> > if (active_pipes && !is_power_of_2(active_pipes))
> > return false;
> > return sagv_reject != 0;
> > }
>
> I need active_pipes check here for skl code only, as it disables SAGV for
> multipipe
> scenarios. Adding this here would generalize it for other platforms and we
> don't want that for ICL+.
Which is why I said "We can then make the check conditional on pre-icl
(or whatever we want) in a later patch". Why in a later patch? Because
currently the check is unconditional and it's generally a good idea to
limit the number of functional changes per patch
Re: [Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
On Thu, Apr 30, 2020 at 01:55:59PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 30, 2020 at 01:47:02PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Apr 30, 2020 at 01:32:17PM +0300, Ville Syrjälä wrote:
> > > On Thu, Apr 30, 2020 at 01:05:15PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Thu, Apr 30, 2020 at 12:21:04PM +0300, Ville Syrjälä wrote:
> > > > > On Thu, Apr 23, 2020 at 10:58:56AM +0300, Stanislav Lisovskiy wrote:
> > > > > > We need to calculate SAGV mask also in a non-modeset
> > > > > > commit, however currently active_pipes are only calculated
> > > > > > for modesets in global atomic state, thus now we will be
> > > > > > tracking those also in bw_state in order to be able to
> > > > > > properly access global data.
> > > > > >
> > > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/display/intel_bw.h | 3 +++
> > > > > > drivers/gpu/drm/i915/intel_pm.c | 15 ++-
> > > > > > 2 files changed, 13 insertions(+), 5 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > index d6df91058223..898b4a85ccab 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > @@ -26,6 +26,9 @@ struct intel_bw_state {
> > > > > >
> > > > > > unsigned int data_rate[I915_MAX_PIPES];
> > > > > > u8 num_active_planes[I915_MAX_PIPES];
> > > > > > +
> > > > > > + /* bitmask of active pipes */
> > > > > > + u8 active_pipes;
> > > > > > };
> > > > > >
> > > > > > #define to_intel_bw_state(x) container_of((x), struct
> > > > > > intel_bw_state, base)
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > index 7e15cf3368ad..f7249bca3f6f 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > @@ -3874,6 +3874,7 @@ static int intel_compute_sagv_mask(struct
> > > > > > intel_atomic_state *state)
> > > > > > struct intel_bw_state *new_bw_state = NULL;
> > > > > > const struct intel_bw_state *old_bw_state = NULL;
> > > > > > int i;
> > > > > > + bool active_pipes_calculated = false;
> > > > > >
> > > > > > for_each_new_intel_crtc_in_state(state, crtc,
> > > > > > new_crtc_state, i) {
> > > > > > @@ -3883,6 +3884,12 @@ static int intel_compute_sagv_mask(struct
> > > > > > intel_atomic_state *state)
> > > > > >
> > > > > > old_bw_state = intel_atomic_get_old_bw_state(state);
> > > > > >
> > > > > > + if (!active_pipes_calculated) {
> > > > > > + state->active_pipes =
> > > > > > new_bw_state->active_pipes =
> > > > >
> > > > > I don't think we should touch state->active_pipes here.
> > > >
> > > > Well, that was my question actually here as well. I understand that
> > > > changing
> > > > state->active_pipes here feels like some unneeded side effect, however
> > > > having
> > > > state->active_pipes and bw_state->active_pipes going out of sync
> > > > doesn't sound
> > > > very attractive to me either. That is why I don't like this idea of
> > > > duplication
> > > > at all - having constant need to sync those state, bw_state,
> > > > cdclk_state, because
> > > > they all might have different active_pipes now.
> > >
> > > Having an out of date active_pipes anywhere would be a bug in that
> > > specific code. Also state->active_pipes is definitely going the way of
> > > the dodo soon.
> > >
> > > >
> > > > >
> > > > > > + intel_calc_active_pipes(state,
> > > > > > old_bw_state->active_pipes);
> > > > > > + active_pipes_calculated = true;
> > > > > > + }
> > > > >
> > > > > I'd do this after the loop so we don't need this extra boolean. As far
> > > > > as the active_pipes check in intel_crtc_can_enable_sagv(), I think we
> > > > > can pull it out into intel_compute_sagv_mask() so that we do the check
> > > > > after computing the mask. And of course change it to use
> > > > > bw_state->active_pipes instead.
> > > >
> > > > intel_crtc_can_enable_sagv is called per crtc - so can't just pull it
> > > > out,
> > > > will have to have to cycles then - one will compute
> > > > bw_state->active_pipes,
> > > > and another pipe_sagv_mask.
> > >
> > > Hmm. Actually I think what we should probably do is keep the
> > > active_pipes check in intel_can_enable_sagv(). Ie something like this:
> > >
> > > intel_can_enable_sagv(bw_state) {
> > > if (active_pipes && !is_power_of_2(active_pipes))
> > > return false;
> > > return sagv_reject != 0;
> > > }
> >
> > I need active_pipes check here for skl code only, as it disables SAGV for
> > multipipe
> > scenarios. Adding this here would generalize it for other platforms and we
> > don't want that for ICL+.
>
> Which is why I said
[Intel-gfx] [PATCH 7/9] drm/i915/gem: Separate the ww_mutex walker into its own list
In preparation for making eb_vma bigger and heavy to run inn parallel,
we need to stop apply an in-place swap() to reorder around ww_mutex
deadlocks. Keep the array intact and reorder the locks using a dedicated
list.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 48 +++
drivers/gpu/drm/i915/i915_utils.h | 6 +++
2 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cc5ccc37be8c..dcb79891dc94 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -35,6 +35,7 @@ struct eb_vma {
struct drm_i915_gem_exec_object2 *exec;
struct list_head bind_link;
struct list_head reloc_link;
+ struct list_head lock_link;
struct hlist_node node;
u32 handle;
@@ -253,6 +254,8 @@ struct i915_execbuffer {
/** list of vma that have execobj.relocation_count */
struct list_head relocs;
+ struct list_head lock;
+
/**
* Track the most recently used object for relocations, as we
* frequently have to perform multiple relocations within the same
@@ -396,6 +399,10 @@ static int eb_create(struct i915_execbuffer *eb)
eb->lut_size = -eb->buffer_count;
}
+ INIT_LIST_HEAD(&eb->relocs);
+ INIT_LIST_HEAD(&eb->unbound);
+ INIT_LIST_HEAD(&eb->lock);
+
return 0;
}
@@ -601,6 +608,8 @@ eb_add_vma(struct i915_execbuffer *eb,
eb_unreserve_vma(ev);
list_add_tail(&ev->bind_link, &eb->unbound);
}
+
+ list_add_tail(&ev->lock_link, &eb->lock);
}
static inline int use_cpu_reloc(const struct reloc_cache *cache,
@@ -877,9 +886,6 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
unsigned int i;
int err = 0;
- INIT_LIST_HEAD(&eb->relocs);
- INIT_LIST_HEAD(&eb->unbound);
-
for (i = 0; i < eb->buffer_count; i++) {
struct i915_vma *vma;
@@ -1615,38 +1621,39 @@ static int eb_relocate(struct i915_execbuffer *eb)
static int eb_move_to_gpu(struct i915_execbuffer *eb)
{
- const unsigned int count = eb->buffer_count;
struct ww_acquire_ctx acquire;
- unsigned int i;
+ struct eb_vma *ev;
int err = 0;
ww_acquire_init(&acquire, &reservation_ww_class);
- for (i = 0; i < count; i++) {
- struct eb_vma *ev = &eb->vma[i];
+ list_for_each_entry(ev, &eb->lock, lock_link) {
struct i915_vma *vma = ev->vma;
err = ww_mutex_lock_interruptible(&vma->resv->lock, &acquire);
if (err == -EDEADLK) {
- GEM_BUG_ON(i == 0);
- do {
- int j = i - 1;
+ struct eb_vma *unlock = ev, *en;
- ww_mutex_unlock(&eb->vma[j].vma->resv->lock);
-
- swap(eb->vma[i], eb->vma[j]);
- } while (--i);
+ list_for_each_entry_safe_continue_reverse(unlock, en,
&eb->lock, lock_link) {
+ ww_mutex_unlock(&unlock->vma->resv->lock);
+ list_move_tail(&unlock->lock_link, &eb->lock);
+ }
+ GEM_BUG_ON(!list_is_first(&ev->lock_link, &eb->lock));
err = ww_mutex_lock_slow_interruptible(&vma->resv->lock,
&acquire);
}
- if (err)
- break;
+ if (err) {
+ list_for_each_entry_continue_reverse(ev, &eb->lock,
lock_link)
+ ww_mutex_unlock(&ev->vma->resv->lock);
+
+ ww_acquire_fini(&acquire);
+ goto err_skip;
+ }
}
ww_acquire_done(&acquire);
- while (i--) {
- struct eb_vma *ev = &eb->vma[i];
+ list_for_each_entry(ev, &eb->lock, lock_link) {
struct i915_vma *vma = ev->vma;
unsigned int flags = ev->flags;
struct drm_i915_gem_object *obj = vma->obj;
@@ -1947,9 +1954,10 @@ static int eb_parse(struct i915_execbuffer *eb)
if (err)
goto err_trampoline;
- eb->vma[eb->buffer_count].vma = i915_vma_get(shadow);
- eb->vma[eb->buffer_count].flags = __EXEC_OBJECT_HAS_PIN;
eb->batch = &eb->vma[eb->buffer_count++];
+ eb->batch->vma = i915_vma_get(shadow);
+ eb->batch->flags = __EXEC_OBJECT_HAS_PIN;
+ list_add_tail(&eb->batch->lock_link, &eb->lock);
eb->vma[eb->buffer_count].vma = NULL;
eb->trampoline = trampoline;
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 03a
[Intel-gfx] [PATCH 5/9] drm/i915/gem: Assign context id for async work
Allocate a few dma fence context id that we can use to associate async work
[for the CPU] launched on behalf of this context. For extra fun, we allow
a configurable concurrency width.
A current example would be that we spawn an unbound worker for every
userptr get_pages. In the future, we wish to charge this work to the
context that initiated the async work and to impose concurrency limits
based on the context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4
drivers/gpu/drm/i915/gem/i915_gem_context.h | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 6 ++
3 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 900ea8b7fc8f..fd7d064a0e46 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -715,6 +715,10 @@ __create_context(struct drm_i915_private *i915)
ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
mutex_init(&ctx->mutex);
+ ctx->async.width = rounddown_pow_of_two(num_online_cpus());
+ ctx->async.context = dma_fence_context_alloc(ctx->async.width);
+ ctx->async.width--;
+
spin_lock_init(&ctx->stale.lock);
INIT_LIST_HEAD(&ctx->stale.engines);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 3702b2fb27ab..e104ff0ae740 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -134,6 +134,12 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+static inline u64 i915_gem_context_async_id(struct i915_gem_context *ctx)
+{
+ return (ctx->async.context +
+ (atomic_fetch_inc(&ctx->async.cur) & ctx->async.width));
+}
+
static inline struct i915_gem_context *
i915_gem_context_get(struct i915_gem_context *ctx)
{
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 28760bd03265..5f5cfa3a3e9b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -85,6 +85,12 @@ struct i915_gem_context {
struct intel_timeline *timeline;
+ struct {
+ u64 context;
+ atomic_t cur;
+ unsigned int width;
+ } async;
+
/**
* @vm: unique address space (GTT)
*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/9] drm/i915/gt: Move the batch buffer pool from the engine to the gt
Since the introduction of 'soft-rc6', we aim to park the device quickly
and that results in frequent idling of the whole device. Currently upon
idling we free the batch buffer pool, and so this renders the cache
ineffective for many workloads. If we want to have an effective cache of
recently allocated buffers available for reuse, we need to decouple that
cache from the engine powermanagement and make it timer based. As there
is no reason then to keep it within the engine (where it once made
retirement order easier to track), we can move it up the hierarchy to the
owner of the memory allocations.
v2: Hook up to debugfs/drop_caches to clear the cache on demand.
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 2 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 1 -
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 20 +--
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 18 +--
.../gpu/drm/i915/gem/i915_gem_object_blt.h| 1 -
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 -
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 -
drivers/gpu/drm/i915/gt/intel_engine_pool.h | 34 --
drivers/gpu/drm/i915/gt/intel_engine_types.h | 8 --
drivers/gpu/drm/i915/gt/intel_gt.c| 3 +
...l_engine_pool.c => intel_gt_buffer_pool.c} | 114 --
.../gpu/drm/i915/gt/intel_gt_buffer_pool.h| 37 ++
...l_types.h => intel_gt_buffer_pool_types.h} | 15 ++-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 11 ++
drivers/gpu/drm/i915/gt/mock_engine.c | 2 -
drivers/gpu/drm/i915/i915_debugfs.c | 4 +
16 files changed, 160 insertions(+), 116 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/gt/intel_engine_pool.h
rename drivers/gpu/drm/i915/gt/{intel_engine_pool.c => intel_gt_buffer_pool.c}
(53%)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.h
rename drivers/gpu/drm/i915/gt/{intel_engine_pool_types.h =>
intel_gt_buffer_pool_types.h} (54%)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index caf00d92ea9d..5359c736c789 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -87,11 +87,11 @@ gt-y += \
gt/intel_engine_cs.o \
gt/intel_engine_heartbeat.o \
gt/intel_engine_pm.o \
- gt/intel_engine_pool.o \
gt/intel_engine_user.o \
gt/intel_ggtt.o \
gt/intel_ggtt_fencing.o \
gt/intel_gt.o \
+ gt/intel_gt_buffer_pool.o \
gt/intel_gt_clock_utils.o \
gt/intel_gt_irq.o \
gt/intel_gt_pm.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 0598e5382a1d..3a146aa2593b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -6,7 +6,6 @@
#include "i915_drv.h"
#include "gt/intel_context.h"
#include "gt/intel_engine_pm.h"
-#include "gt/intel_engine_pool.h"
#include "i915_gem_client_blt.h"
#include "i915_gem_object_blt.h"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 964f73f062c1..414859fa2673 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -15,8 +15,8 @@
#include "gem/i915_gem_ioctls.h"
#include "gt/intel_context.h"
-#include "gt/intel_engine_pool.h"
#include "gt/intel_gt.h"
+#include "gt/intel_gt_buffer_pool.h"
#include "gt/intel_gt_pm.h"
#include "gt/intel_ring.h"
@@ -1194,13 +1194,13 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
unsigned int len)
{
struct reloc_cache *cache = &eb->reloc_cache;
- struct intel_engine_pool_node *pool;
+ struct intel_gt_buffer_pool_node *pool;
struct i915_request *rq;
struct i915_vma *batch;
u32 *cmd;
int err;
- pool = intel_engine_get_pool(eb->engine, PAGE_SIZE);
+ pool = intel_gt_get_buffer_pool(eb->engine->gt, PAGE_SIZE);
if (IS_ERR(pool))
return PTR_ERR(pool);
@@ -1229,7 +1229,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
goto err_unpin;
}
- err = intel_engine_pool_mark_active(pool, rq);
+ err = intel_gt_buffer_pool_mark_active(pool, rq);
if (err)
goto err_request;
@@ -1270,7 +1270,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
err_unmap:
i915_gem_object_unpin_map(pool->obj);
out_pool:
- intel_engine_pool_put(pool);
+ intel_gt_buffer_pool_put(pool);
return err;
}
@@ -1887,7 +1887,7 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
static int eb_parse(struct i915_execbuffer *eb)
{
struct drm_i915_private *i915 = eb->i915;
- struct intel_engine_pool_node *pool;
+ struct intel_gt_buffer_pool_node *pool;
struct i91
[Intel-gfx] [PATCH 3/9] drm/i915: Always defer fenced work to the worker
Currently, if an error is raised we always call the cleanup locally
[and skip the main work callback]. However, some future users may need
to take a mutex to cleanup and so we cannot immediately execute the
cleanup as we may still be in interrupt context.
With the execute-immediate flag, for most cases this should result in
immediate cleanup of an error.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence_work.c | 25 +++
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index a3a81bb8f2c3..29f63ebc24e8 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -16,11 +16,14 @@ static void fence_complete(struct dma_fence_work *f)
static void fence_work(struct work_struct *work)
{
struct dma_fence_work *f = container_of(work, typeof(*f), work);
- int err;
- err = f->ops->work(f);
- if (err)
- dma_fence_set_error(&f->dma, err);
+ if (!f->dma.error) {
+ int err;
+
+ err = f->ops->work(f);
+ if (err)
+ dma_fence_set_error(&f->dma, err);
+ }
fence_complete(f);
dma_fence_put(&f->dma);
@@ -36,15 +39,11 @@ fence_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
if (fence->error)
dma_fence_set_error(&f->dma, fence->error);
- if (!f->dma.error) {
- dma_fence_get(&f->dma);
- if (test_bit(DMA_FENCE_WORK_IMM, &f->dma.flags))
- fence_work(&f->work);
- else
- queue_work(system_unbound_wq, &f->work);
- } else {
- fence_complete(f);
- }
+ dma_fence_get(&f->dma);
+ if (test_bit(DMA_FENCE_WORK_IMM, &f->dma.flags))
+ fence_work(&f->work);
+ else
+ queue_work(system_unbound_wq, &f->work);
break;
case FENCE_FREE:
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915/gem: Asynchronous GTT unbinding
It is reasonably common for userspace (even modern drivers like iris) to
reuse an active address for a new buffer. This would cause the
application to stall under its mutex (originally struct_mutex) until the
old batches were idle and it could synchronously remove the stale PTE.
However, we can queue up a job that waits on the signal for the old
nodes to complete and upon those signals, remove the old nodes replacing
them with the new ones for the batch. This is still CPU driven, but in
theory we can do the GTT patching from the GPU. The job itself has a
completion signal allowing the execbuf to wait upon the rebinding, and
also other observers to coordinate with the common VM activity.
Letting userspace queue up more work, lets it do more stuff without
blocking other clients. In turn, we take care not to let it too much
concurrent work, creating a small number of queues for each context to
limit the number of concurrent tasks.
The implementation relies on only scheduling one unbind operation per
vma as we use the unbound vma->node location to track the stale PTE.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1402
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 799 --
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 1 +
drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 4 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 3 +-
drivers/gpu/drm/i915/i915_gem.c | 7 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
drivers/gpu/drm/i915/i915_vma.c | 130 +--
drivers/gpu/drm/i915/i915_vma.h | 5 +
10 files changed, 837 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index dcb79891dc94..1063db957f17 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -18,6 +18,7 @@
#include "gt/intel_gt.h"
#include "gt/intel_gt_buffer_pool.h"
#include "gt/intel_gt_pm.h"
+#include "gt/intel_gt_requests.h"
#include "gt/intel_ring.h"
#include "i915_drv.h"
@@ -31,6 +32,9 @@ struct eb_vma {
struct i915_vma *vma;
unsigned int flags;
+ struct drm_mm_node hole;
+ unsigned int bind_flags;
+
/** This vma's place in the execbuf reservation list */
struct drm_i915_gem_exec_object2 *exec;
struct list_head bind_link;
@@ -57,7 +61,8 @@ enum {
#define __EXEC_OBJECT_HAS_FENCEBIT(30)
#define __EXEC_OBJECT_NEEDS_MAPBIT(29)
#define __EXEC_OBJECT_NEEDS_BIAS BIT(28)
-#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 28) /* all of the above */
+#define __EXEC_OBJECT_HAS_PAGESBIT(27)
+#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 27) /* all of the above */
#define __EXEC_HAS_RELOC BIT(31)
#define __EXEC_INTERNAL_FLAGS (~0u << 31)
@@ -71,11 +76,12 @@ enum {
I915_EXEC_RESOURCE_STREAMER)
/* Catch emission of unexpected errors for CI! */
+#define __EINVAL__ 22
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
#undef EINVAL
#define EINVAL ({ \
DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
- 22; \
+ __EINVAL__; \
})
#endif
@@ -314,6 +320,12 @@ static struct eb_vma_array *eb_vma_array_create(unsigned
int count)
return arr;
}
+static struct eb_vma_array *eb_vma_array_get(struct eb_vma_array *arr)
+{
+ kref_get(&arr->kref);
+ return arr;
+}
+
static inline void eb_unreserve_vma(struct eb_vma *ev)
{
struct i915_vma *vma = ev->vma;
@@ -324,8 +336,12 @@ static inline void eb_unreserve_vma(struct eb_vma *ev)
if (ev->flags & __EXEC_OBJECT_HAS_PIN)
__i915_vma_unpin(vma);
+ if (ev->flags & __EXEC_OBJECT_HAS_PAGES)
+ i915_vma_put_pages(vma);
+
ev->flags &= ~(__EXEC_OBJECT_HAS_PIN |
- __EXEC_OBJECT_HAS_FENCE);
+ __EXEC_OBJECT_HAS_FENCE |
+ __EXEC_OBJECT_HAS_PAGES);
}
static void eb_vma_array_destroy(struct kref *kref)
@@ -411,7 +427,7 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2
*entry,
const struct i915_vma *vma,
unsigned int flags)
{
- if (vma->node.size < entry->pad_to_size)
+ if (vma->node.size < max(vma->size, entry->pad_to_size))
return true;
if (entry->alignment && !IS_ALIGNED(vma->node.start, entry->alignment))
@@ -484,12 +500,18 @@ eb_pin_vma(struct i915_execbuffer *eb,
if (entry->flags & EXEC_OBJECT_PINNED)
return false;
+ /* Concurrent async binds in progress, get in the queue */
+ if (!i915_active_is_idle(&vma->vm->active))
+ return false;
+
[Intel-gfx] [PATCH 1/9] drm/i915/gt: Stop holding onto the pinned_default_state
As we only restore the default context state upon banning a context, we
only need enough of the state to run the ring and nothing more. That is
we only need our bare protocontext.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c| 14 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 -
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 ++
drivers/gpu/drm/i915/gt/selftest_context.c | 11 ++--
drivers/gpu/drm/i915/gt/selftest_lrc.c | 53 +++-
5 files changed, 47 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 446e35ac0224..cf46076c59b2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -22,18 +22,11 @@ static int __engine_unpark(struct intel_wakeref *wf)
struct intel_engine_cs *engine =
container_of(wf, typeof(*engine), wakeref);
struct intel_context *ce;
- void *map;
ENGINE_TRACE(engine, "\n");
intel_gt_pm_get(engine->gt);
- /* Pin the default state for fast resets from atomic context. */
- map = NULL;
- if (engine->default_state)
- map = shmem_pin_map(engine->default_state);
- engine->pinned_default_state = map;
-
/* Discard stale context state from across idling */
ce = engine->kernel_context;
if (ce) {
@@ -43,6 +36,7 @@ static int __engine_unpark(struct intel_wakeref *wf)
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) && ce->state) {
struct drm_i915_gem_object *obj = ce->state->obj;
int type = i915_coherent_map_type(engine->i915);
+ void *map;
map = i915_gem_object_pin_map(obj, type);
if (!IS_ERR(map)) {
@@ -262,12 +256,6 @@ static int __engine_park(struct intel_wakeref *wf)
if (engine->park)
engine->park(engine);
- if (engine->pinned_default_state) {
- shmem_unpin_map(engine->default_state,
- engine->pinned_default_state);
- engine->pinned_default_state = NULL;
- }
-
engine->execlists.no_priolist = false;
/* While gt calls i915_vma_parked(), we have to break the lock cycle */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index f760e2ef285b..68a382229b4a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -340,7 +340,6 @@ struct intel_engine_cs {
unsigned long wakeref_serial;
struct intel_wakeref wakeref;
struct file *default_state;
- void *pinned_default_state;
struct {
struct intel_ring *ring;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 4311b12542fb..dc5517c85df1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1271,14 +1271,11 @@ execlists_check_context(const struct intel_context *ce,
static void restore_default_state(struct intel_context *ce,
struct intel_engine_cs *engine)
{
- u32 *regs = ce->lrc_reg_state;
+ u32 *regs;
- if (engine->pinned_default_state)
- memcpy(regs, /* skip restoring the vanilla PPHWSP */
- engine->pinned_default_state + LRC_STATE_OFFSET,
- engine->context_size - PAGE_SIZE);
+ regs = memset(ce->lrc_reg_state, 0, engine->context_size - PAGE_SIZE);
+ execlists_init_reg_state(regs, ce, engine, ce->ring, true);
- execlists_init_reg_state(regs, ce, engine, ce->ring, false);
ce->runtime.last = intel_context_get_runtime(ce);
}
@@ -4166,8 +4163,6 @@ static void __execlists_reset(struct intel_engine_cs
*engine, bool stalled)
* image back to the expected values to skip over the guilty request.
*/
__i915_request_reset(rq, stalled);
- if (!stalled)
- goto out_replay;
/*
* We want a simple context + ring to execute the breadcrumb update.
@@ -4177,9 +4172,6 @@ static void __execlists_reset(struct intel_engine_cs
*engine, bool stalled)
* future request will be after userspace has had the opportunity
* to recreate its own state.
*/
- GEM_BUG_ON(!intel_context_is_pinned(ce));
- restore_default_state(ce, engine);
-
out_replay:
ENGINE_TRACE(engine, "replay {head:%04x, tail:%04x}\n",
head, ce->ring->tail);
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
index b8ed3cbe1277..a56dff3b157a 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_cont
[Intel-gfx] [PATCH 4/9] drm/i915/gem: Include PIN_GLOBAL prior to using I915_DISPATCH_SECURE
For our gpu relocs, on the older gen 4 and 5 devices, we must use a privileged buffer for MI_STORE_DWORD_IMM. This also presumes that we operate from the global GTT, for consistency we should tell i915_vma_pin() that it will be used with the global address. While there is only the single GTT available for these devices, so it does not change the actual GTT used for pinning. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 414859fa2673..cc5ccc37be8c 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -1197,6 +1197,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb, struct intel_gt_buffer_pool_node *pool; struct i915_request *rq; struct i915_vma *batch; + u32 flags; u32 *cmd; int err; @@ -1219,7 +1220,11 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb, goto err_unmap; } - err = i915_vma_pin(batch, 0, 0, PIN_USER | PIN_NONBLOCK); + flags = PIN_USER | PIN_NOEVICT | PIN_NONBLOCK; + if (cache->gen <= 5) + flags |= PIN_GLOBAL; + + err = i915_vma_pin(batch, 0, 0, flags); if (err) goto err_unmap; @@ -1239,7 +1244,8 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb, err = eb->engine->emit_bb_start(rq, batch->node.start, PAGE_SIZE, - cache->gen > 5 ? 0 : I915_DISPATCH_SECURE); + flags & PIN_GLOBAL ? + I915_DISPATCH_SECURE : 0); if (err) goto skip_request; -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 9/9] drm/i915/gem: Bind the fence async for execbuf
It is illegal to wait on an another vma while holding the vm->mutex, as
that easily leads to ABBA deadlocks (we wait on a second vma that waits
on us to release the vm->mutex). So while the vm->mutex exists, move the
waiting outside of the lock into the async binding pipeline.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 41 --
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 137 +-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 5 +
3 files changed, 166 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1063db957f17..78bac5debcf7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -516,13 +516,23 @@ eb_pin_vma(struct i915_execbuffer *eb,
}
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
- if (unlikely(i915_vma_pin_fence(vma))) {
- i915_vma_unpin(vma);
- return false;
- }
+ struct i915_fence_reg *reg = vma->fence;
- if (vma->fence)
+ /* Avoid waiting to change the fence; defer to async worker */
+ if (reg) {
+ if (READ_ONCE(reg->dirty)) {
+ __i915_vma_unpin(vma);
+ return false;
+ }
+
+ atomic_inc(®->pin_count);
ev->flags |= __EXEC_OBJECT_HAS_FENCE;
+ } else {
+ if (i915_gem_object_is_tiled(vma->obj)) {
+ __i915_vma_unpin(vma);
+ return false;
+ }
+ }
}
ev->flags |= __EXEC_OBJECT_HAS_PIN;
@@ -1052,15 +1062,6 @@ static int eb_reserve_vma(struct eb_vm_work *work,
struct eb_vma *ev)
return err;
pin:
- if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
- err = __i915_vma_pin_fence(vma); /* XXX no waiting */
- if (unlikely(err))
- return err;
-
- if (vma->fence)
- ev->flags |= __EXEC_OBJECT_HAS_FENCE;
- }
-
bind_flags &= ~atomic_read(&vma->flags);
if (bind_flags) {
err = set_bind_fence(vma, work);
@@ -1091,6 +1092,15 @@ static int eb_reserve_vma(struct eb_vm_work *work,
struct eb_vma *ev)
ev->flags |= __EXEC_OBJECT_HAS_PIN;
GEM_BUG_ON(eb_vma_misplaced(entry, vma, ev->flags));
+ if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
+ err = __i915_vma_pin_fence_async(vma, &work->base);
+ if (unlikely(err))
+ return err;
+
+ if (vma->fence)
+ ev->flags |= __EXEC_OBJECT_HAS_FENCE;
+ }
+
return 0;
}
@@ -1126,6 +1136,9 @@ static int __eb_bind_vma(struct eb_vm_work *work, int err)
list_for_each_entry(ev, &work->unbound, bind_link) {
struct i915_vma *vma = ev->vma;
+ if (ev->flags & __EXEC_OBJECT_HAS_FENCE)
+ __i915_vma_apply_fence_async(vma);
+
if (!ev->bind_flags)
goto put;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 7fb36b12fe7a..734b6aa61809 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -21,10 +21,13 @@
* IN THE SOFTWARE.
*/
+#include "i915_active.h"
#include "i915_drv.h"
#include "i915_scatterlist.h"
+#include "i915_sw_fence_work.h"
#include "i915_pvinfo.h"
#include "i915_vgpu.h"
+#include "i915_vma.h"
/**
* DOC: fence register handling
@@ -340,19 +343,37 @@ static struct i915_fence_reg *fence_find(struct i915_ggtt
*ggtt)
return ERR_PTR(-EDEADLK);
}
+static int fence_wait_bind(struct i915_fence_reg *reg)
+{
+ struct dma_fence *fence;
+ int err = 0;
+
+ fence = i915_active_fence_get(®->active.excl);
+ if (fence) {
+ err = dma_fence_wait(fence, true);
+ dma_fence_put(fence);
+ }
+
+ return err;
+}
+
int __i915_vma_pin_fence(struct i915_vma *vma)
{
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vma->vm);
- struct i915_fence_reg *fence;
+ struct i915_fence_reg *fence = vma->fence;
struct i915_vma *set = i915_gem_object_is_tiled(vma->obj) ? vma : NULL;
int err;
lockdep_assert_held(&vma->vm->mutex);
/* Just update our place in the LRU if our fence is getting reused. */
- if (vma->fence) {
- fence = vma->fence;
+ if (fence) {
GEM_BUG_ON(fence->vma != vma);
+
+ err = fence_wait_bind(fence);
+ if (err)
+ return err;
+
[Intel-gfx] [PATCH 6/9] drm/i915: Export a preallocate variant of i915_active_acquire()
Sometimes we have to be very careful not to allocate underneath a mutex
(or spinlock) and yet still want to track activity. Enter
i915_active_acquire_for_context(). This raises the activity counter on
i915_active prior to use and ensures that the fence-tree contains a slot
for the context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 107 ++---
drivers/gpu/drm/i915/i915_active.h | 5 ++
2 files changed, 103 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index d960d0be5bd2..71ad0d452680 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -217,11 +217,10 @@ excl_retire(struct dma_fence *fence, struct dma_fence_cb
*cb)
}
static struct i915_active_fence *
-active_instance(struct i915_active *ref, struct intel_timeline *tl)
+active_instance(struct i915_active *ref, u64 idx)
{
struct active_node *node, *prealloc;
struct rb_node **p, *parent;
- u64 idx = tl->fence_context;
/*
* We track the most recently used timeline to skip a rbtree search
@@ -367,7 +366,7 @@ int i915_active_ref(struct i915_active *ref,
if (err)
return err;
- active = active_instance(ref, tl);
+ active = active_instance(ref, tl->fence_context);
if (!active) {
err = -ENOMEM;
goto out;
@@ -384,32 +383,104 @@ int i915_active_ref(struct i915_active *ref,
atomic_dec(&ref->count);
}
if (!__i915_active_fence_set(active, fence))
- atomic_inc(&ref->count);
+ __i915_active_acquire(ref);
out:
i915_active_release(ref);
return err;
}
-struct dma_fence *
-i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f)
+static struct dma_fence *
+__i915_active_set_fence(struct i915_active *ref,
+ struct i915_active_fence *active,
+ struct dma_fence *fence)
{
struct dma_fence *prev;
/* We expect the caller to manage the exclusive timeline ordering */
GEM_BUG_ON(i915_active_is_idle(ref));
+ if (is_barrier(active)) { /* proto-node used by our idle barrier */
+ /*
+* This request is on the kernel_context timeline, and so
+* we can use it to substitute for the pending idle-barrer
+* request that we want to emit on the kernel_context.
+*/
+ __active_del_barrier(ref, node_from_active(active));
+ RCU_INIT_POINTER(active->fence, NULL);
+ atomic_dec(&ref->count);
+ }
+
rcu_read_lock();
- prev = __i915_active_fence_set(&ref->excl, f);
+ prev = __i915_active_fence_set(active, fence);
if (prev)
prev = dma_fence_get_rcu(prev);
else
- atomic_inc(&ref->count);
+ __i915_active_acquire(ref);
rcu_read_unlock();
return prev;
}
+static struct i915_active_fence *
+__active_lookup(struct i915_active *ref, u64 idx)
+{
+ struct active_node *node;
+ struct rb_node *p;
+
+ /* Like active_instance() but with no malloc */
+
+ node = READ_ONCE(ref->cache);
+ if (node && node->timeline == idx)
+ return &node->base;
+
+ spin_lock_irq(&ref->tree_lock);
+ GEM_BUG_ON(i915_active_is_idle(ref));
+
+ p = ref->tree.rb_node;
+ while (p) {
+ node = rb_entry(p, struct active_node, node);
+ if (node->timeline == idx) {
+ ref->cache = node;
+ spin_unlock_irq(&ref->tree_lock);
+ return &node->base;
+ }
+
+ if (node->timeline < idx)
+ p = p->rb_right;
+ else
+ p = p->rb_left;
+ }
+
+ spin_unlock_irq(&ref->tree_lock);
+
+ return NULL;
+}
+
+struct dma_fence *
+__i915_active_ref(struct i915_active *ref, u64 idx, struct dma_fence *fence)
+{
+ struct dma_fence *prev = ERR_PTR(-ENOENT);
+ struct i915_active_fence *active;
+
+ if (!i915_active_acquire_if_busy(ref))
+ return ERR_PTR(-EINVAL);
+
+ active = __active_lookup(ref, idx);
+ if (active)
+ prev = __i915_active_set_fence(ref, active, fence);
+
+ i915_active_release(ref);
+ return prev;
+}
+
+struct dma_fence *
+i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f)
+{
+ /* We expect the caller to manage the exclusive timeline ordering */
+ return __i915_active_set_fence(ref, &ref->excl, f);
+}
+
bool i915_active_acquire_if_busy(struct i915_active *ref)
{
debug_active_assert(ref);
@@ -443,6 +514,24 @@ int i915_active_acquire(struct i915_active *ref)
return err;
}
+int i915_active_acquire_for_context(struct
Re: [Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
On Thu, Apr 30, 2020 at 02:07:02PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Apr 30, 2020 at 01:55:59PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 30, 2020 at 01:47:02PM +0300, Lisovskiy, Stanislav wrote:
> > > On Thu, Apr 30, 2020 at 01:32:17PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Apr 30, 2020 at 01:05:15PM +0300, Lisovskiy, Stanislav wrote:
> > > > > On Thu, Apr 30, 2020 at 12:21:04PM +0300, Ville Syrjälä wrote:
> > > > > > On Thu, Apr 23, 2020 at 10:58:56AM +0300, Stanislav Lisovskiy wrote:
> > > > > > > We need to calculate SAGV mask also in a non-modeset
> > > > > > > commit, however currently active_pipes are only calculated
> > > > > > > for modesets in global atomic state, thus now we will be
> > > > > > > tracking those also in bw_state in order to be able to
> > > > > > > properly access global data.
> > > > > > >
> > > > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > > > ---
> > > > > > > drivers/gpu/drm/i915/display/intel_bw.h | 3 +++
> > > > > > > drivers/gpu/drm/i915/intel_pm.c | 15 ++-
> > > > > > > 2 files changed, 13 insertions(+), 5 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > index d6df91058223..898b4a85ccab 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > @@ -26,6 +26,9 @@ struct intel_bw_state {
> > > > > > >
> > > > > > > unsigned int data_rate[I915_MAX_PIPES];
> > > > > > > u8 num_active_planes[I915_MAX_PIPES];
> > > > > > > +
> > > > > > > + /* bitmask of active pipes */
> > > > > > > + u8 active_pipes;
> > > > > > > };
> > > > > > >
> > > > > > > #define to_intel_bw_state(x) container_of((x), struct
> > > > > > > intel_bw_state, base)
> > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > index 7e15cf3368ad..f7249bca3f6f 100644
> > > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > @@ -3874,6 +3874,7 @@ static int intel_compute_sagv_mask(struct
> > > > > > > intel_atomic_state *state)
> > > > > > > struct intel_bw_state *new_bw_state = NULL;
> > > > > > > const struct intel_bw_state *old_bw_state = NULL;
> > > > > > > int i;
> > > > > > > + bool active_pipes_calculated = false;
> > > > > > >
> > > > > > > for_each_new_intel_crtc_in_state(state, crtc,
> > > > > > >new_crtc_state, i) {
> > > > > > > @@ -3883,6 +3884,12 @@ static int intel_compute_sagv_mask(struct
> > > > > > > intel_atomic_state *state)
> > > > > > >
> > > > > > > old_bw_state = intel_atomic_get_old_bw_state(state);
> > > > > > >
> > > > > > > + if (!active_pipes_calculated) {
> > > > > > > + state->active_pipes =
> > > > > > > new_bw_state->active_pipes =
> > > > > >
> > > > > > I don't think we should touch state->active_pipes here.
> > > > >
> > > > > Well, that was my question actually here as well. I understand that
> > > > > changing
> > > > > state->active_pipes here feels like some unneeded side effect,
> > > > > however having
> > > > > state->active_pipes and bw_state->active_pipes going out of sync
> > > > > doesn't sound
> > > > > very attractive to me either. That is why I don't like this idea of
> > > > > duplication
> > > > > at all - having constant need to sync those state, bw_state,
> > > > > cdclk_state, because
> > > > > they all might have different active_pipes now.
> > > >
> > > > Having an out of date active_pipes anywhere would be a bug in that
> > > > specific code. Also state->active_pipes is definitely going the way of
> > > > the dodo soon.
> > > >
> > > > >
> > > > > >
> > > > > > > + intel_calc_active_pipes(state,
> > > > > > > old_bw_state->active_pipes);
> > > > > > > + active_pipes_calculated = true;
> > > > > > > + }
> > > > > >
> > > > > > I'd do this after the loop so we don't need this extra boolean. As
> > > > > > far
> > > > > > as the active_pipes check in intel_crtc_can_enable_sagv(), I think
> > > > > > we
> > > > > > can pull it out into intel_compute_sagv_mask() so that we do the
> > > > > > check
> > > > > > after computing the mask. And of course change it to use
> > > > > > bw_state->active_pipes instead.
> > > > >
> > > > > intel_crtc_can_enable_sagv is called per crtc - so can't just pull it
> > > > > out,
> > > > > will have to have to cycles then - one will compute
> > > > > bw_state->active_pipes,
> > > > > and another pipe_sagv_mask.
> > > >
> > > > Hmm. Actually I think what we should probably do is keep the
> > > > active_pipes check in intel_can_enable_sagv(). Ie something like this:
> > > >
> > > > intel_can_enable_sagv(bw_state) {
> > > > if (active_pipes && !is_power_of_2(active_pipes))
> > > >
Re: [Intel-gfx] [PATCH 8/9] drm/i915/gem: Asynchronous GTT unbinding
Quoting Chris Wilson (2020-04-30 12:18:18) > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > b/drivers/gpu/drm/i915/i915_gem_gtt.c > index cb43381b0d37..da081401142e 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -219,6 +219,8 @@ int i915_gem_gtt_insert(struct i915_address_space *vm, > mode = DRM_MM_INSERT_HIGHEST; > if (flags & PIN_MAPPABLE) > mode = DRM_MM_INSERT_LOW; > + if (flags & PIN_NOSEARCH) > + mode = DRM_MM_INSERT_ONCE; Fortuitously only used in patch with DRM_MM_INSERT_BEST, so the mistake is not noticed, but it should be mode |= ONCE; Now the question is does CI notice this mistake? Unlikely. Could CI even notice? Unsure. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
On Thu, Apr 30, 2020 at 02:22:02PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 30, 2020 at 02:07:02PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Apr 30, 2020 at 01:55:59PM +0300, Ville Syrjälä wrote:
> > > On Thu, Apr 30, 2020 at 01:47:02PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Thu, Apr 30, 2020 at 01:32:17PM +0300, Ville Syrjälä wrote:
> > > > > On Thu, Apr 30, 2020 at 01:05:15PM +0300, Lisovskiy, Stanislav wrote:
> > > > > > On Thu, Apr 30, 2020 at 12:21:04PM +0300, Ville Syrjälä wrote:
> > > > > > > On Thu, Apr 23, 2020 at 10:58:56AM +0300, Stanislav Lisovskiy
> > > > > > > wrote:
> > > > > > > > We need to calculate SAGV mask also in a non-modeset
> > > > > > > > commit, however currently active_pipes are only calculated
> > > > > > > > for modesets in global atomic state, thus now we will be
> > > > > > > > tracking those also in bw_state in order to be able to
> > > > > > > > properly access global data.
> > > > > > > >
> > > > > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > > > >
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/i915/display/intel_bw.h | 3 +++
> > > > > > > > drivers/gpu/drm/i915/intel_pm.c | 15 ++-
> > > > > > > > 2 files changed, 13 insertions(+), 5 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > > index d6df91058223..898b4a85ccab 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > > @@ -26,6 +26,9 @@ struct intel_bw_state {
> > > > > > > >
> > > > > > > > unsigned int data_rate[I915_MAX_PIPES];
> > > > > > > > u8 num_active_planes[I915_MAX_PIPES];
> > > > > > > > +
> > > > > > > > + /* bitmask of active pipes */
> > > > > > > > + u8 active_pipes;
> > > > > > > > };
> > > > > > > >
> > > > > > > > #define to_intel_bw_state(x) container_of((x), struct
> > > > > > > > intel_bw_state, base)
> > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > index 7e15cf3368ad..f7249bca3f6f 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > @@ -3874,6 +3874,7 @@ static int intel_compute_sagv_mask(struct
> > > > > > > > intel_atomic_state *state)
> > > > > > > > struct intel_bw_state *new_bw_state = NULL;
> > > > > > > > const struct intel_bw_state *old_bw_state = NULL;
> > > > > > > > int i;
> > > > > > > > + bool active_pipes_calculated = false;
> > > > > > > >
> > > > > > > > for_each_new_intel_crtc_in_state(state, crtc,
> > > > > > > > new_crtc_state, i) {
> > > > > > > > @@ -3883,6 +3884,12 @@ static int
> > > > > > > > intel_compute_sagv_mask(struct intel_atomic_state *state)
> > > > > > > >
> > > > > > > > old_bw_state =
> > > > > > > > intel_atomic_get_old_bw_state(state);
> > > > > > > >
> > > > > > > > + if (!active_pipes_calculated) {
> > > > > > > > + state->active_pipes =
> > > > > > > > new_bw_state->active_pipes =
> > > > > > >
> > > > > > > I don't think we should touch state->active_pipes here.
> > > > > >
> > > > > > Well, that was my question actually here as well. I understand that
> > > > > > changing
> > > > > > state->active_pipes here feels like some unneeded side effect,
> > > > > > however having
> > > > > > state->active_pipes and bw_state->active_pipes going out of sync
> > > > > > doesn't sound
> > > > > > very attractive to me either. That is why I don't like this idea of
> > > > > > duplication
> > > > > > at all - having constant need to sync those state, bw_state,
> > > > > > cdclk_state, because
> > > > > > they all might have different active_pipes now.
> > > > >
> > > > > Having an out of date active_pipes anywhere would be a bug in that
> > > > > specific code. Also state->active_pipes is definitely going the way of
> > > > > the dodo soon.
> > > > >
> > > > > >
> > > > > > >
> > > > > > > > + intel_calc_active_pipes(state,
> > > > > > > > old_bw_state->active_pipes);
> > > > > > > > + active_pipes_calculated = true;
> > > > > > > > + }
> > > > > > >
> > > > > > > I'd do this after the loop so we don't need this extra boolean.
> > > > > > > As far
> > > > > > > as the active_pipes check in intel_crtc_can_enable_sagv(), I
> > > > > > > think we
> > > > > > > can pull it out into intel_compute_sagv_mask() so that we do the
> > > > > > > check
> > > > > > > after computing the mask. And of course change it to use
> > > > > > > bw_state->active_pipes instead.
> > > > > >
> > > > > > intel_crtc_can_enable_sagv is called per crtc - so can't just pull
> > > > > > it out,
> > > > > > will have to have to cy
Re: [Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
On Thu, Apr 30, 2020 at 02:29:51PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Apr 30, 2020 at 02:22:02PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 30, 2020 at 02:07:02PM +0300, Lisovskiy, Stanislav wrote:
> > > On Thu, Apr 30, 2020 at 01:55:59PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Apr 30, 2020 at 01:47:02PM +0300, Lisovskiy, Stanislav wrote:
> > > > > On Thu, Apr 30, 2020 at 01:32:17PM +0300, Ville Syrjälä wrote:
> > > > > > On Thu, Apr 30, 2020 at 01:05:15PM +0300, Lisovskiy, Stanislav
> > > > > > wrote:
> > > > > > > On Thu, Apr 30, 2020 at 12:21:04PM +0300, Ville Syrjälä wrote:
> > > > > > > > On Thu, Apr 23, 2020 at 10:58:56AM +0300, Stanislav Lisovskiy
> > > > > > > > wrote:
> > > > > > > > > We need to calculate SAGV mask also in a non-modeset
> > > > > > > > > commit, however currently active_pipes are only calculated
> > > > > > > > > for modesets in global atomic state, thus now we will be
> > > > > > > > > tracking those also in bw_state in order to be able to
> > > > > > > > > properly access global data.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > > > > >
> > > > > > > > > ---
> > > > > > > > > drivers/gpu/drm/i915/display/intel_bw.h | 3 +++
> > > > > > > > > drivers/gpu/drm/i915/intel_pm.c | 15 ++-
> > > > > > > > > 2 files changed, 13 insertions(+), 5 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > > > index d6df91058223..898b4a85ccab 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > > > @@ -26,6 +26,9 @@ struct intel_bw_state {
> > > > > > > > >
> > > > > > > > > unsigned int data_rate[I915_MAX_PIPES];
> > > > > > > > > u8 num_active_planes[I915_MAX_PIPES];
> > > > > > > > > +
> > > > > > > > > + /* bitmask of active pipes */
> > > > > > > > > + u8 active_pipes;
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > #define to_intel_bw_state(x) container_of((x), struct
> > > > > > > > > intel_bw_state, base)
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > > index 7e15cf3368ad..f7249bca3f6f 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > > @@ -3874,6 +3874,7 @@ static int
> > > > > > > > > intel_compute_sagv_mask(struct intel_atomic_state *state)
> > > > > > > > > struct intel_bw_state *new_bw_state = NULL;
> > > > > > > > > const struct intel_bw_state *old_bw_state = NULL;
> > > > > > > > > int i;
> > > > > > > > > + bool active_pipes_calculated = false;
> > > > > > > > >
> > > > > > > > > for_each_new_intel_crtc_in_state(state, crtc,
> > > > > > > > >new_crtc_state, i) {
> > > > > > > > > @@ -3883,6 +3884,12 @@ static int
> > > > > > > > > intel_compute_sagv_mask(struct intel_atomic_state *state)
> > > > > > > > >
> > > > > > > > > old_bw_state =
> > > > > > > > > intel_atomic_get_old_bw_state(state);
> > > > > > > > >
> > > > > > > > > + if (!active_pipes_calculated) {
> > > > > > > > > + state->active_pipes =
> > > > > > > > > new_bw_state->active_pipes =
> > > > > > > >
> > > > > > > > I don't think we should touch state->active_pipes here.
> > > > > > >
> > > > > > > Well, that was my question actually here as well. I understand
> > > > > > > that changing
> > > > > > > state->active_pipes here feels like some unneeded side effect,
> > > > > > > however having
> > > > > > > state->active_pipes and bw_state->active_pipes going out of sync
> > > > > > > doesn't sound
> > > > > > > very attractive to me either. That is why I don't like this idea
> > > > > > > of duplication
> > > > > > > at all - having constant need to sync those state, bw_state,
> > > > > > > cdclk_state, because
> > > > > > > they all might have different active_pipes now.
> > > > > >
> > > > > > Having an out of date active_pipes anywhere would be a bug in that
> > > > > > specific code. Also state->active_pipes is definitely going the way
> > > > > > of
> > > > > > the dodo soon.
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > > + intel_calc_active_pipes(state,
> > > > > > > > > old_bw_state->active_pipes);
> > > > > > > > > + active_pipes_calculated = true;
> > > > > > > > > + }
> > > > > > > >
> > > > > > > > I'd do this after the loop so we don't need this extra boolean.
> > > > > > > > As far
> > > > > > > > as the active_pipes check in intel_crtc_can_enable_sagv(), I
> > > > > > > > think we
> > > > > > > > can pull it out into intel_compute_sagv_mask() so that we do
> > > > > > > > the check
> > > > > > > >
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Nuke mode.vrefresh usage
> -Original Message- > From: Ville Syrjala > Sent: Thursday, April 30, 2020 12:25 AM > To: intel-gfx@lists.freedesktop.org > Cc: Gupta, Anshuman ; Shankar, Uma > > Subject: [PATCH 1/3] drm/i915: Nuke mode.vrefresh usage > > From: Ville Syrjälä > > mode.vrefresh is rounded to the nearest integer. You don't want to use it > anywhere > that requires precision. Also I want to nuke it. > vtotal*vrefresh == 1000*clock/htotal, so let's use the latter. Looks Good to me. Reviewed-by: Uma Shankar > Cc: Anshuman Gupta > Cc: Uma Shankar > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_audio.c | 10 +++--- > 1 file changed, 3 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c > b/drivers/gpu/drm/i915/display/intel_audio.c > index 36aaee8536f1..f5686e50833f 100644 > --- a/drivers/gpu/drm/i915/display/intel_audio.c > +++ b/drivers/gpu/drm/i915/display/intel_audio.c > @@ -524,14 +524,12 @@ static unsigned int > get_hblank_early_enable_config(struct > intel_encoder *encoder > unsigned int link_clks_available, link_clks_required; > unsigned int tu_data, tu_line, link_clks_active; > unsigned int hblank_rise, hblank_early_prog; > - unsigned int h_active, h_total, hblank_delta, pixel_clk, v_total; > - unsigned int fec_coeff, refresh_rate, cdclk, vdsc_bpp; > + unsigned int h_active, h_total, hblank_delta, pixel_clk; > + unsigned int fec_coeff, cdclk, vdsc_bpp; > > h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay; > h_total = crtc_state->hw.adjusted_mode.crtc_htotal; > - v_total = crtc_state->hw.adjusted_mode.crtc_vtotal; > pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock; > - refresh_rate = crtc_state->hw.adjusted_mode.vrefresh; > vdsc_bpp = crtc_state->dsc.compressed_bpp; > cdclk = i915->cdclk.hw.cdclk; > /* fec= 0.972261, using rounding multiplier of 100 */ @@ -549,9 > +547,7 @@ static unsigned int get_hblank_early_enable_config(struct > intel_encoder > *encoder > link_clks_available = h_total - h_active) * > ((crtc_state->port_clock * ROUNDING_FACTOR) / > pixel_clk)) / ROUNDING_FACTOR) - 28); > - > - link_clks_required = DIV_ROUND_UP(192000, (refresh_rate * > - v_total)) * ((48 / > + link_clks_required = DIV_ROUND_UP(192000, (1000 * pixel_clk / > +h_total)) * ((48 / > crtc_state->lane_count) + 2); > > if (link_clks_available > link_clks_required) > -- > 2.24.1 ___ 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: Rename variables to be consistent with bspec
> -Original Message-
> From: Ville Syrjala
> Sent: Thursday, April 30, 2020 12:25 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Gupta, Anshuman ; Shankar, Uma
>
> Subject: [PATCH 2/3] drm/i915: Rename variables to be consistent with bspec
>
> From: Ville Syrjälä
>
> Since the code seems insistent on using the variable names from the bspec
> formulat,
> let's be consistent and use those names for all the things. For some reason
> 'link_clk'
> and 'lanes' were left out in the code until now.
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Anshuman Gupta
> Cc: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_audio.c | 30 --
> 1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index f5686e50833f..00f7a3cf9a04 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -526,6 +526,7 @@ static unsigned int get_hblank_early_enable_config(struct
> intel_encoder *encoder
> unsigned int hblank_rise, hblank_early_prog;
> unsigned int h_active, h_total, hblank_delta, pixel_clk;
> unsigned int fec_coeff, cdclk, vdsc_bpp;
> + unsigned int link_clk, lanes;
>
> h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
> h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
> @@ -534,40 +535,40 @@ static unsigned int
> get_hblank_early_enable_config(struct
> intel_encoder *encoder
> cdclk = i915->cdclk.hw.cdclk;
> /* fec= 0.972261, using rounding multiplier of 100 */
> fec_coeff = 972261;
> + link_clk = crtc_state->port_clock;
> + lanes = crtc_state->lane_count;
>
> drm_dbg_kms(&i915->drm, "h_active = %u link_clk = %u :"
> "lanes = %u vdsc_bpp = %u cdclk = %u\n",
> - h_active, crtc_state->port_clock, crtc_state->lane_count,
> - vdsc_bpp, cdclk);
> + h_active, link_clk, lanes, vdsc_bpp, cdclk);
>
> - if (WARN_ON(!crtc_state->port_clock || !crtc_state->lane_count ||
> - !crtc_state->dsc.compressed_bpp || !i915->cdclk.hw.cdclk))
> + if (WARN_ON(!link_clk || !lanes || !vdsc_bpp || !cdclk))
> return 0;
>
> link_clks_available = h_total - h_active) *
> -((crtc_state->port_clock * ROUNDING_FACTOR) /
> +((link_clk * ROUNDING_FACTOR) /
> pixel_clk)) / ROUNDING_FACTOR) - 28);
> link_clks_required = DIV_ROUND_UP(192000, (1000 * pixel_clk / h_total))
> *
> ((48 /
> - crtc_state->lane_count) + 2);
> + lanes) + 2);
>
> if (link_clks_available > link_clks_required)
> hblank_delta = 32;
> else
> hblank_delta = DIV_ROUND_UP(5 * ROUNDING_FACTOR) /
> - crtc_state->port_clock) + ((5 *
> + link_clk) + ((5 *
> ROUNDING_FACTOR) /
> cdclk)) * pixel_clk),
> ROUNDING_FACTOR);
>
> - tu_data = (pixel_clk * vdsc_bpp * 8) / ((crtc_state->port_clock *
> -crtc_state->lane_count * fec_coeff) / 100);
> - tu_line = (((h_active * crtc_state->port_clock * fec_coeff) /
> + tu_data = (pixel_clk * vdsc_bpp * 8) / ((link_clk *
> +lanes * fec_coeff) / 100);
> + tu_line = (((h_active * link_clk * fec_coeff) /
> 100) / (64 * pixel_clk));
> link_clks_active = (tu_line - 1) * 64 + tu_data;
>
> hblank_rise = ((link_clks_active + 6 * DIV_ROUND_UP(link_clks_active,
> 250) + 4) * ((pixel_clk * ROUNDING_FACTOR) /
> - crtc_state->port_clock)) / ROUNDING_FACTOR;
> + link_clk)) / ROUNDING_FACTOR;
>
> hblank_early_prog = h_active - hblank_rise + hblank_delta;
>
> @@ -577,16 +578,19 @@ static unsigned int
> get_hblank_early_enable_config(struct
> intel_encoder *encoder static unsigned int get_sample_room_req_config(const
> struct intel_crtc_state *crtc_state) {
> unsigned int h_active, h_total, pixel_clk;
> + unsigned int link_clk, lanes;
> unsigned int samples_room;
>
> h_active = crtc_state->hw.adjusted_mode.hdisplay;
> h_total = crtc_state->hw.adjusted_mode.htotal;
> pixel_clk = crtc_state->hw.adjusted_mode.clock;
> + link_clk = crtc_state->port_clock;
> + lanes = crtc_state->lane_count;
>
> - samples_room = h_total - h_active) * ((crtc_state->port_clock *
> + samples_room = h_total - h_active) * ((link_clk *
> ROUNDING_FACTOR) / pixel_clk)) /
> ROUNDING_FACTOR) - 12) / ((48 /
Re: [Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
On Thu, Apr 30, 2020 at 02:40:37PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 30, 2020 at 02:29:51PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Apr 30, 2020 at 02:22:02PM +0300, Ville Syrjälä wrote:
> > > On Thu, Apr 30, 2020 at 02:07:02PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Thu, Apr 30, 2020 at 01:55:59PM +0300, Ville Syrjälä wrote:
> > > > > On Thu, Apr 30, 2020 at 01:47:02PM +0300, Lisovskiy, Stanislav wrote:
> > > > > > On Thu, Apr 30, 2020 at 01:32:17PM +0300, Ville Syrjälä wrote:
> > > > > > > On Thu, Apr 30, 2020 at 01:05:15PM +0300, Lisovskiy, Stanislav
> > > > > > > wrote:
> > > > > > > > On Thu, Apr 30, 2020 at 12:21:04PM +0300, Ville Syrjälä wrote:
> > > > > > > > > On Thu, Apr 23, 2020 at 10:58:56AM +0300, Stanislav Lisovskiy
> > > > > > > > > wrote:
> > > > > > > > > > We need to calculate SAGV mask also in a non-modeset
> > > > > > > > > > commit, however currently active_pipes are only calculated
> > > > > > > > > > for modesets in global atomic state, thus now we will be
> > > > > > > > > > tracking those also in bw_state in order to be able to
> > > > > > > > > > properly access global data.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > > drivers/gpu/drm/i915/display/intel_bw.h | 3 +++
> > > > > > > > > > drivers/gpu/drm/i915/intel_pm.c | 15
> > > > > > > > > > ++-
> > > > > > > > > > 2 files changed, 13 insertions(+), 5 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > > > > index d6df91058223..898b4a85ccab 100644
> > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > > > > > > > @@ -26,6 +26,9 @@ struct intel_bw_state {
> > > > > > > > > >
> > > > > > > > > > unsigned int data_rate[I915_MAX_PIPES];
> > > > > > > > > > u8 num_active_planes[I915_MAX_PIPES];
> > > > > > > > > > +
> > > > > > > > > > + /* bitmask of active pipes */
> > > > > > > > > > + u8 active_pipes;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > #define to_intel_bw_state(x) container_of((x), struct
> > > > > > > > > > intel_bw_state, base)
> > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > > > index 7e15cf3368ad..f7249bca3f6f 100644
> > > > > > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > > > @@ -3874,6 +3874,7 @@ static int
> > > > > > > > > > intel_compute_sagv_mask(struct intel_atomic_state *state)
> > > > > > > > > > struct intel_bw_state *new_bw_state = NULL;
> > > > > > > > > > const struct intel_bw_state *old_bw_state = NULL;
> > > > > > > > > > int i;
> > > > > > > > > > + bool active_pipes_calculated = false;
> > > > > > > > > >
> > > > > > > > > > for_each_new_intel_crtc_in_state(state, crtc,
> > > > > > > > > > new_crtc_state, i) {
> > > > > > > > > > @@ -3883,6 +3884,12 @@ static int
> > > > > > > > > > intel_compute_sagv_mask(struct intel_atomic_state *state)
> > > > > > > > > >
> > > > > > > > > > old_bw_state =
> > > > > > > > > > intel_atomic_get_old_bw_state(state);
> > > > > > > > > >
> > > > > > > > > > + if (!active_pipes_calculated) {
> > > > > > > > > > + state->active_pipes =
> > > > > > > > > > new_bw_state->active_pipes =
> > > > > > > > >
> > > > > > > > > I don't think we should touch state->active_pipes here.
> > > > > > > >
> > > > > > > > Well, that was my question actually here as well. I understand
> > > > > > > > that changing
> > > > > > > > state->active_pipes here feels like some unneeded side effect,
> > > > > > > > however having
> > > > > > > > state->active_pipes and bw_state->active_pipes going out of
> > > > > > > > sync doesn't sound
> > > > > > > > very attractive to me either. That is why I don't like this
> > > > > > > > idea of duplication
> > > > > > > > at all - having constant need to sync those state, bw_state,
> > > > > > > > cdclk_state, because
> > > > > > > > they all might have different active_pipes now.
> > > > > > >
> > > > > > > Having an out of date active_pipes anywhere would be a bug in that
> > > > > > > specific code. Also state->active_pipes is definitely going the
> > > > > > > way of
> > > > > > > the dodo soon.
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > + intel_calc_active_pipes(state,
> > > > > > > > > > old_bw_state->active_pipes);
> > > > > > > > > > + active_pipes_calculated = true;
> > > > > > > > > > + }
> > > > > > > > >
> > > > > > > > > I'd do this after the loop so we don't need this extra
> > > > > > > > > boo
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Streamline the artihmetic
On Wed, Apr 29, 2020 at 08:11:04PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-04-29 19:54:57)
> > From: Ville Syrjälä
> >
> > All these ROUNDIND_FACTORs and whatnot are making this thing hard to
> > read. Get rid of them. And let's massage some of the fractions to
> > give us less questionable intermediate results and perhaps less
> > divisions.
> >
> > Also looks like a good helping of 64bit math stuff is needed to
> > avoid some of overflows present in the current code. There
> > might still be a few overflows, namely when calculating
> > link_clks_available/samples_room (would require a huge hblank
> > though), and potentially when calculating hblank_rise (not sure
> > how large link_clks_active can get).
> >
> > It looks like we're still not calculating exactly what the spec says
> > since we truncate tu_data and tu_line early. But I'm too lazy to
> > figure out if we could avoid that.
> >
> > Cc: Anshuman Gupta
> > Cc: Uma Shankar
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_audio.c | 54 --
> > 1 file changed, 19 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> > b/drivers/gpu/drm/i915/display/intel_audio.c
> > index 00f7a3cf9a04..05cab508c626 100644
> > --- a/drivers/gpu/drm/i915/display/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> > @@ -517,16 +517,16 @@ static void hsw_audio_codec_disable(struct
> > intel_encoder *encoder,
> > /* Add a factor to take care of rounding and truncations */
> > #define ROUNDING_FACTOR 1
> >
> > -static unsigned int get_hblank_early_enable_config(struct intel_encoder
> > *encoder,
> > - const struct
> > intel_crtc_state *crtc_state)
> > +static unsigned int calc_hblank_early_prog(struct intel_encoder *encoder,
> > + const struct intel_crtc_state
> > *crtc_state)
> > {
> > struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > unsigned int link_clks_available, link_clks_required;
> > unsigned int tu_data, tu_line, link_clks_active;
> > - unsigned int hblank_rise, hblank_early_prog;
> > unsigned int h_active, h_total, hblank_delta, pixel_clk;
> > unsigned int fec_coeff, cdclk, vdsc_bpp;
> > unsigned int link_clk, lanes;
> > + unsigned int hblank_rise;
> >
> > h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
> > h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
> > @@ -542,44 +542,33 @@ static unsigned int
> > get_hblank_early_enable_config(struct intel_encoder *encoder
> > "lanes = %u vdsc_bpp = %u cdclk = %u\n",
> > h_active, link_clk, lanes, vdsc_bpp, cdclk);
> >
> > - if (WARN_ON(!link_clk || !lanes || !vdsc_bpp || !cdclk))
> > + if (WARN_ON(!link_clk || !pixel_clk || !lanes || !vdsc_bpp ||
> > !cdclk))
> > return 0;
> >
> > - link_clks_available = h_total - h_active) *
> > - ((link_clk * ROUNDING_FACTOR) /
> > - pixel_clk)) / ROUNDING_FACTOR) - 28);
> > - link_clks_required = DIV_ROUND_UP(192000, (1000 * pixel_clk /
> > h_total)) * ((48 /
> > - lanes) + 2);
> > + link_clks_available = (h_total - h_active) * link_clk / pixel_clk -
> > 28;
> > + link_clks_required = DIV_ROUND_UP(192000 * h_total, 1000 *
> > pixel_clk) * (48 / lanes + 2);
>
> That's a relief.
>
> >
> > if (link_clks_available > link_clks_required)
> > hblank_delta = 32;
> > else
> > - hblank_delta = DIV_ROUND_UP(5 * ROUNDING_FACTOR) /
> > - link_clk) + ((5 *
> > - ROUNDING_FACTOR) /
> > - cdclk)) * pixel_clk),
> > - ROUNDING_FACTOR);
> > + hblank_delta = DIV64_U64_ROUND_UP(mul_u32_u32(5 * link_clk
> > + 5 * cdclk, pixel_clk),
> > + mul_u32_u32(link_clk,
> > cdclk));
>
> 5 * mul_u32_u32(link_clk, cdclk, pixel_clk)
I presume you meant
5 * mul_u32_u32(link_clk + cdclk, pixel_clk)
mul_u32_u32(5 * (link_clk + cdclk), pixel_clk)
would seem to be the cheaper option by avoiding
the 64bit multiply.
>
> >
> > - tu_data = (pixel_clk * vdsc_bpp * 8) / ((link_clk *
> > - lanes * fec_coeff) / 100);
> > - tu_line = (((h_active * link_clk * fec_coeff) /
> > - 100) / (64 * pixel_clk));
> > + tu_data = div64_u64(mul_u32_u32(pixel_clk * vdsc_bpp * 8, 100),
> > + mul_u32_u32(link_clk * lanes, fec_coeff));
>
> That 100 is fec_scale.
>
> > + tu_line = div64_u64(h_active * mul_u32_u32(link_clk,
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915/gt: Stop holding onto the pinned_default_state
== Series Details ==
Series: series starting with [1/9] drm/i915/gt: Stop holding onto the
pinned_default_state
URL : https://patchwork.freedesktop.org/series/76771/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0e9eeaba9f3e drm/i915/gt: Stop holding onto the pinned_default_state
bdbc12ae68bf drm/i915/gt: Move the batch buffer pool from the engine to the gt
-:291: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#291:
deleted file mode 100644
total: 0 errors, 1 warnings, 0 checks, 589 lines checked
fc352b043c47 drm/i915: Always defer fenced work to the worker
83f24f70e12c drm/i915/gem: Include PIN_GLOBAL prior to using
I915_DISPATCH_SECURE
d5bcc12365db drm/i915/gem: Assign context id for async work
24191a6a4fde drm/i915: Export a preallocate variant of i915_active_acquire()
e96477842906 drm/i915/gem: Separate the ww_mutex walker into its own list
-:92: WARNING:LONG_LINE: line over 100 characters
#92: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1637:
+ list_for_each_entry_safe_continue_reverse(unlock, en,
&eb->lock, lock_link) {
-:140: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible
side-effects?
#140: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+ n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
-:140: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#140: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+ n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
-:140: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'member' - possible
side-effects?
#140: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+ n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
total: 0 errors, 1 warnings, 3 checks, 120 lines checked
0187f28a9b9b drm/i915/gem: Asynchronous GTT unbinding
16a3283586a7 drm/i915/gem: Bind the fence async for execbuf
___
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: Streamline the artihmetic
> -Original Message-
> From: Ville Syrjala
> Sent: Thursday, April 30, 2020 12:25 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Gupta, Anshuman ; Shankar, Uma
>
> Subject: [PATCH 3/3] drm/i915: Streamline the artihmetic
>
> From: Ville Syrjälä
>
> All these ROUNDIND_FACTORs and whatnot are making this thing hard to read. Get
Nit pick: Typo in ROUNDING
> rid of them. And let's massage some of the fractions to give us less
> questionable
> intermediate results and perhaps less divisions.
>
> Also looks like a good helping of 64bit math stuff is needed to avoid some of
> overflows present in the current code. There might still be a few overflows,
> namely
> when calculating link_clks_available/samples_room (would require a huge hblank
> though), and potentially when calculating hblank_rise (not sure how large
> link_clks_active can get).
>
> It looks like we're still not calculating exactly what the spec says since we
> truncate
> tu_data and tu_line early. But I'm too lazy to figure out if we could avoid
> that.
>
> Cc: Anshuman Gupta
> Cc: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_audio.c | 54 --
> 1 file changed, 19 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 00f7a3cf9a04..05cab508c626 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -517,16 +517,16 @@ static void hsw_audio_codec_disable(struct intel_encoder
> *encoder,
> /* Add a factor to take care of rounding and truncations */ #define
> ROUNDING_FACTOR 1
We should drop this declaration as well, as its of no use now.
Overall this looks much better for sure, thanks Ville.
Reviewed-by: Uma Shankar
> -static unsigned int get_hblank_early_enable_config(struct intel_encoder
> *encoder,
> -const struct intel_crtc_state
> *crtc_state)
> +static unsigned int calc_hblank_early_prog(struct intel_encoder *encoder,
> +const struct intel_crtc_state
> *crtc_state)
> {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> unsigned int link_clks_available, link_clks_required;
> unsigned int tu_data, tu_line, link_clks_active;
> - unsigned int hblank_rise, hblank_early_prog;
> unsigned int h_active, h_total, hblank_delta, pixel_clk;
> unsigned int fec_coeff, cdclk, vdsc_bpp;
> unsigned int link_clk, lanes;
> + unsigned int hblank_rise;
>
> h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
> h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
> @@ -542,44 +542,33 @@ static unsigned int
> get_hblank_early_enable_config(struct
> intel_encoder *encoder
> "lanes = %u vdsc_bpp = %u cdclk = %u\n",
> h_active, link_clk, lanes, vdsc_bpp, cdclk);
>
> - if (WARN_ON(!link_clk || !lanes || !vdsc_bpp || !cdclk))
> + if (WARN_ON(!link_clk || !pixel_clk || !lanes || !vdsc_bpp || !cdclk))
> return 0;
>
> - link_clks_available = h_total - h_active) *
> -((link_clk * ROUNDING_FACTOR) /
> - pixel_clk)) / ROUNDING_FACTOR) - 28);
> - link_clks_required = DIV_ROUND_UP(192000, (1000 * pixel_clk / h_total))
> *
> ((48 /
> - lanes) + 2);
> + link_clks_available = (h_total - h_active) * link_clk / pixel_clk - 28;
> + link_clks_required = DIV_ROUND_UP(192000 * h_total, 1000 * pixel_clk)
> +* (48 / lanes + 2);
>
> if (link_clks_available > link_clks_required)
> hblank_delta = 32;
> else
> - hblank_delta = DIV_ROUND_UP(5 * ROUNDING_FACTOR) /
> - link_clk) + ((5 *
> - ROUNDING_FACTOR) /
> - cdclk)) * pixel_clk),
> - ROUNDING_FACTOR);
> + hblank_delta = DIV64_U64_ROUND_UP(mul_u32_u32(5 * link_clk +
> 5 * cdclk, pixel_clk),
> + mul_u32_u32(link_clk, cdclk));
>
> - tu_data = (pixel_clk * vdsc_bpp * 8) / ((link_clk *
> -lanes * fec_coeff) / 100);
> - tu_line = (((h_active * link_clk * fec_coeff) /
> -100) / (64 * pixel_clk));
> + tu_data = div64_u64(mul_u32_u32(pixel_clk * vdsc_bpp * 8, 100),
> + mul_u32_u32(link_clk * lanes, fec_coeff));
> + tu_line = div64_u64(h_active * mul_u32_u32(link_clk, fec_coeff),
> + mul_u32_u32(64 * pixel_clk, 100));
> link_clks_active = (tu_line - 1) * 64 + tu_data;
>
> - hblank_rise = ((link_clks_active + 6 * DIV_ROUND_UP(link_clks_active,
> - 250) + 4) * ((pixel_clk * ROUNDIN
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915/gt: Stop holding onto the pinned_default_state
== Series Details ==
Series: series starting with [1/9] drm/i915/gt: Stop holding onto the
pinned_default_state
URL : https://patchwork.freedesktop.org/series/76771/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8401 -> Patchwork_17526
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17526:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@debugfs_test@read_all_entries:
- fi-kbl-7500u: NOTRUN -> [{ABORT}][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/fi-kbl-7500u/igt@debugfs_test@read_all_entries.html
Known issues
Here are the changes found in Patchwork_17526 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@gem_contexts:
- fi-bwr-2160:[INCOMPLETE][2] ([i915#489]) -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/fi-bwr-2160/igt@i915_selftest@live@gem_contexts.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/fi-bwr-2160/igt@i915_selftest@live@gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
Participating hosts (50 -> 43)
--
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8401 -> Patchwork_17526
CI-20190529: 20190529
CI_DRM_8401: 41fac0e3809be301af095c66e717eb9843b80212 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5617: 807b26292a3f21057ef7865a4028d22c512590df @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17526: 16a3283586a72e2e921fdb2e8646a92f6af32078 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
16a3283586a7 drm/i915/gem: Bind the fence async for execbuf
0187f28a9b9b drm/i915/gem: Asynchronous GTT unbinding
e96477842906 drm/i915/gem: Separate the ww_mutex walker into its own list
24191a6a4fde drm/i915: Export a preallocate variant of i915_active_acquire()
d5bcc12365db drm/i915/gem: Assign context id for async work
83f24f70e12c drm/i915/gem: Include PIN_GLOBAL prior to using
I915_DISPATCH_SECURE
fc352b043c47 drm/i915: Always defer fenced work to the worker
bdbc12ae68bf drm/i915/gt: Move the batch buffer pool from the engine to the gt
0e9eeaba9f3e drm/i915/gt: Stop holding onto the pinned_default_state
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-next
Quoting Zhenyu Wang (2020-04-26 05:46:19) > On 2020.04.22 13:12:30 +0800, Zhenyu Wang wrote: > > > > Hi, > > > > Here's current gvt-next. This removes left non-upstream xen support bits > > which will be kept out of tree instead. And several guest context shadow > > optimizations from Yan. > > > > Thanks > > -- > > Ping for merge.. Pulled now. Thanks for the PR. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next
Hi Dave & Daniel, Fix for performance regression GitLab #1698: Iris Plus 655 and 4K screen. Missing workarounds for Tigerlake, and a fix for DP display audio WA. Unbreaking enable_dpcd_backlight, fixes to power code for Icelake+. Improvements to the soft-RC6 code to improve power efficiency, a fix for the timestamp corruption on Tigerlake and plenty of smaller fixes for CI found corner cases. Lots of refactoring that prep for upcoming changes, so I expect the next PR to be quite busy. Includes gvt-next-2020-04-22: Removes left non-upstream xen support bits which will be kept out of tree instead. And several guest context shadow optimizations. Regards, Joonas PS. Noticed the ack for locking rules, thanks! Will merge it. *** drm-intel-next-2020-04-30: Driver Changes: - Fix GitLab #1698: Performance regression with Linux 5.7-rc1 on Iris Plus 655 and 4K screen (Chris) - Add Wa_14011059788 for Tigerlake (Matt A) - Add per ctx batchbuffer wa for timestamp for Gen12 (Mika) - Use indirect ctx bb to load cmd buffer control value from context image to avoid corruption (Mika) - Enable DP Display Audio WA (Uma, Jani) - Update forcewake firmware ranges for Icelake (Radhakrishna) - Add missing deinitialization cases of load failure for display (Jose) - Implement TC cold sequences for Icelake and Tigerlake (Jose) - Unbreak enable_dpcd_backlight modparam (Lyude) - Move the late flush_submission in retire to the end (Chris) - Demote "Reducing compressed framebufer size" message to info (Peter) - Push MST link retraining to the hotplug work (Ville) - Hold obj->vma.lock over for_each_ggtt_vma() (Chris) - Fix timeout handling during TypeC AUX power well enabling for ICL (Imre) - Fix skl+ non-scaled pfit modes (Ville) - Prefer soft-rc6 over RPS DOWN_TIMEOUT (Chris) - Sanitize GT first before poisoning HWSP (Chris) - Fix up clock RPS frequency readout (Chris) - Avoid reusing the same logical CCID (Chris) - Avoid dereferencing a dead context (Chris) - Always enable busy-stats for execlists (Chris) - Apply the aggressive downclocking to parking (Chris) - Restore aggressive post-boost downclocking (Chris) - Scrub execlists state on resume (Chris) - Add debugfs attributes for LPSP (Ansuman) - Improvements to kernel selftests (Chris, Mika) - Add tiled blits selftest (Zbigniew) - Fix error handling in __live_lrc_indirect_ctx_bb() (Dan) - Add pre/post plane updates for SAGV (Stanislav) - Add ICL PG3 PW ID for EHL (Anshuman) - Fix Sphinx build duplicate label warning (Jani) - Error log non-zero audio power refcount after unbind (Jani) - Remove object_is_locked assertion from unpin_from_display_plane (Chris) - Use single set of AUX powerwell ops for gen11+ (Matt R) - Prefer drm_WARN_ON over WARN_ON (Pankaj) - Poison residual state [HWSP] across resume (Chris, Tvrtko) - Convert request-before-CS assertion to debug (Chris) - Carefully order virtual_submission_tasklet (Chris) - Check carefully for an idle engine in wait-for-idle (Chris) - Only close vma we open (Chris) - Trace RPS events (Chris) - Use the RPM config register to determine clk frequencies (Chris) - Drop rq->ring->vma peeking from error capture (Chris) - Check preempt-timeout target before submit_ports (Chris) - Check HWSP cacheline is valid before acquiring (Chris) - Use proper fault mask in interrupt postinstall too (Matt R) - Keep a no-frills swappable copy of the default context state (Chris) - Add atomic helpers for bandwidth (Stanislav) - Refactor setting dma info to a common helper from device info (Michael) - Refactor DDI transcoder code for clairty (Ville) - Extend PG3 power well ID to ICL (Anshuman) - Refactor PFIT code for readability and future extensibility (Ville) - Clarify code split between intel_ddi.c and intel_dp.c (Ville) - Move out code to return the digital_port of the aux ch (Jose) - Move rps.enabled/active and use of RPS interrupts to flags (Chris) - Remove superfluous inlines and dead code (Jani) - Re-disable -Wframe-address from top-level Makefile (Nick) - Static checker and spelling fixes (Colin, Nathan) - Split long lines (Ville) The following changes since commit b06ef327e26367b9286a2079b31cde8d2161c0d8: drm/i915: Update DRIVER_DATE to 20200417 (2020-04-17 09:35:00 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-04-30 for you to fetch changes up to 230982d8d8df7f9d9aa216840ea2db1df6ad5d37: drm/i915: Update DRIVER_DATE to 20200430 (2020-04-30 11:13:21 +0300) Driver Changes: - Fix GitLab #1698: Performance regression with Linux 5.7-rc1 on Iris Plus 655 and 4K screen (Chris) - Add Wa_14011059788 for Tigerlake (Matt A) - Add per ctx batchbuffer wa for timestamp for Gen12 (Mika) - Use indirect ctx bb to load cmd buffer control value from context image to avoid corruption (Mika) - Enable DP Display Audio WA (Uma, Jani) - Update forcewake firmware ranges for Icela
[Intel-gfx] [PATCH 2/2] drm/i915: Remove cnl pre-prod workarounds
From: Ville Syrjälä
Remove all the stepping dependent cnl workarounds. Bspec lists
more steppings than this so presumably these are classed as
pre-production. And this is cnl after all so no one should
really care anyway.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 8 +---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 17 -
drivers/gpu/drm/i915/intel_pm.c | 7 ---
drivers/gpu/drm/i915/intel_wopcm.c | 3 +--
4 files changed, 2 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index 1c1923ec8be7..ab675d35030d 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -113,7 +113,6 @@ static void gen9_rc6_enable(struct intel_rc6 *rc6)
struct intel_uncore *uncore = rc6_to_uncore(rc6);
struct intel_engine_cs *engine;
enum intel_engine_id id;
- u32 rc6_mode;
/* 2b: Program RC6 thresholds.*/
if (INTEL_GEN(rc6_to_i915(rc6)) >= 10) {
@@ -165,16 +164,11 @@ static void gen9_rc6_enable(struct intel_rc6 *rc6)
/* 3a: Enable RC6 */
set(uncore, GEN6_RC6_THRESHOLD, 37500); /* 37.5/125ms per EI */
- /* WaRsUseTimeoutMode:cnl (pre-prod) */
- if (IS_CNL_REVID(rc6_to_i915(rc6), CNL_REVID_A0, CNL_REVID_C0))
- rc6_mode = GEN7_RC_CTL_TO_MODE;
- else
- rc6_mode = GEN6_RC_CTL_EI_MODE(1);
rc6->ctl_enable =
GEN6_RC_CTL_HW_ENABLE |
GEN6_RC_CTL_RC6_ENABLE |
- rc6_mode;
+ GEN6_RC_CTL_EI_MODE(1);
/*
* WaRsDisableCoarsePowerGating:skl,cnl
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index adddc5c93b48..aa90e6b7a118 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -485,25 +485,14 @@ static void cfl_ctx_workarounds_init(struct
intel_engine_cs *engine,
static void cnl_ctx_workarounds_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
{
- struct drm_i915_private *i915 = engine->i915;
-
/* WaForceContextSaveRestoreNonCoherent:cnl */
WA_SET_BIT_MASKED(CNL_HDC_CHICKEN0,
HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT);
- /* WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod) */
- if (IS_CNL_REVID(i915, CNL_REVID_B0, CNL_REVID_B0))
- WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, THROTTLE_12_5);
-
/* WaDisableReplayBufferBankArbitrationOptimization:cnl */
WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
- /* WaDisableEnhancedSBEVertexCaching:cnl (pre-prod) */
- if (IS_CNL_REVID(i915, 0, CNL_REVID_B0))
- WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
- GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE);
-
/* WaPushConstantDereferenceHoldDisable:cnl */
WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2, PUSH_CONSTANT_DEREF_DISABLE);
@@ -872,12 +861,6 @@ cnl_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
{
wa_init_mcr(i915, wal);
- /* WaDisableI2mCycleOnWRPort:cnl (pre-prod) */
- if (IS_CNL_REVID(i915, CNL_REVID_B0, CNL_REVID_B0))
- wa_write_or(wal,
- GAMT_CHKN_BIT_REG,
- GAMT_CHKN_DISABLE_I2M_CYCLE_ON_WR_PORT);
-
/* WaInPlaceDecompressionHang:cnl */
wa_write_or(wal,
GEN9_GAMT_ECO_REG_RW_IA,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 65a3236ce277..53fb66396ffa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5198,10 +5198,6 @@ static void skl_compute_transition_wm(const struct
intel_crtc_state *crtc_state,
trans_offset_b;
} else {
res_blocks = wm0_sel_res_b + trans_offset_b;
-
- /* WA BUG:1938466 add one block for non y-tile planes */
- if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))
- res_blocks += 1;
}
/*
@@ -6917,9 +6913,6 @@ static void cnl_init_clock_gating(struct drm_i915_private
*dev_priv)
val = I915_READ(SLICE_UNIT_LEVEL_CLKGATE);
/* ReadHitWriteOnlyDisable:cnl */
val |= RCCUNIT_CLKGATE_DIS;
- /* WaSarbUnitClockGatingDisable:cnl (pre-prod) */
- if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0))
- val |= SARBUNIT_CLKGATE_DIS;
I915_WRITE(SLICE_UNIT_LEVEL_CLKGATE, val);
/* Wa_2201832410:cnl */
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 6942487c14a9..ec776591e1cf 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/d
[Intel-gfx] [PATCH 1/2] drm/i915: Fix glk watermark calculations
From: Ville Syrjälä
GLK wants the +1 adjustement for the "blocks per line" value
for x-tile/y-tile, just like cnl+.
Also the x-tile and linear cases are almost identical. The only
difference is this +1 which is always done for glk+, and only
done for linear on skl/bxt. Let's unify it to a single branch
with a special case for the +1, just like we do for y-tile.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bfb180fe8047..65a3236ce277 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4810,7 +4810,7 @@ skl_wm_method1(const struct drm_i915_private *dev_priv,
u32 pixel_rate,
wm_intermediate_val = latency * pixel_rate * cpp;
ret = div_fixed16(wm_intermediate_val, 1000 * dbuf_block_size);
- if (INTEL_GEN(dev_priv) >= 10)
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
ret = add_fixed16_u32(ret, 1);
return ret;
@@ -4945,18 +4945,19 @@ skl_compute_wm_params(const struct intel_crtc_state
*crtc_state,
wp->y_min_scanlines,
wp->dbuf_block_size);
- if (INTEL_GEN(dev_priv) >= 10)
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
interm_pbpl++;
wp->plane_blocks_per_line = div_fixed16(interm_pbpl,
wp->y_min_scanlines);
- } else if (wp->x_tiled && IS_GEN(dev_priv, 9)) {
- interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line,
- wp->dbuf_block_size);
- wp->plane_blocks_per_line = u32_to_fixed16(interm_pbpl);
} else {
interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line,
- wp->dbuf_block_size) + 1;
+ wp->dbuf_block_size);
+
+ if (!wp->x_tiled ||
+ INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ interm_pbpl++;
+
wp->plane_blocks_per_line = u32_to_fixed16(interm_pbpl);
}
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 4/4] drm/i915/perf: enable filtering on multiple contexts
Quoting Lionel Landwerlin (2020-04-28 13:08:16)
> Add 2 new properties to the i915-perf open ioctl to specify an array
> of GEM context handles as well as the length of the array.
>
> This can be used by drivers using multiple GEM contexts to implement a
> single GL context.
>
> Signed-off-by: Lionel Landwerlin
Do add link to the userspace changes in the actual patch so that it
is preserved at merge time, not only the cover letter.
Regards, Joonas
> ---
> drivers/gpu/drm/i915/i915_perf.c | 58 ++--
> include/uapi/drm/i915_drm.h | 21
> 2 files changed, 76 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 79f68efd7d5b..e236d2a8720b 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -3686,7 +3686,8 @@ static int read_properties_unlocked(struct i915_perf
> *perf,
> struct perf_open_properties *props)
> {
> u64 __user *uprop = uprops;
> - u32 i;
> + u32 __user *uctx_handles = NULL;
> + u32 i, n_uctx_handles = 0;
> int err;
>
> memset(props, 0, sizeof(struct perf_open_properties));
> @@ -3737,7 +3738,7 @@ static int read_properties_unlocked(struct i915_perf
> *perf,
>
> switch ((enum drm_i915_perf_property_id)id) {
> case DRM_I915_PERF_PROP_CTX_HANDLE:
> - if (props->n_ctx_handles > 0) {
> + if (props->n_ctx_handles > 0 || n_uctx_handles > 0) {
> DRM_DEBUG("Context handle specified multiple
> times\n");
> err = -EINVAL;
> goto error;
> @@ -3851,6 +3852,38 @@ static int read_properties_unlocked(struct i915_perf
> *perf,
> }
> props->poll_oa_period = value;
> break;
> + case DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY:
> + /* HSW can only filter in HW and only on a single
> +* context.
> +*/
> + if (IS_HASWELL(perf->i915)) {
> + DRM_DEBUG("Multi context filter not supported
> on HSW\n");
> + err = -ENODEV;
> + goto error;
> + }
> + uctx_handles = u64_to_user_ptr(value);
> + break;
> + case DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY_LENGTH:
> + if (IS_HASWELL(perf->i915)) {
> + DRM_DEBUG("Multi context filter not supported
> on HSW\n");
> + err = -ENODEV;
> + goto error;
> + }
> + if (props->n_ctx_handles > 0 || n_uctx_handles > 0) {
> + DRM_DEBUG("Context handle specified multiple
> times\n");
> + err = -EINVAL;
> + goto error;
> + }
> + props->ctx_handles =
> + kmalloc_array(value,
> + sizeof(*props->ctx_handles),
> + GFP_KERNEL);
> + if (!props->ctx_handles) {
> + err = -ENOMEM;
> + goto error;
> + }
> + n_uctx_handles = value;
> + break;
> case DRM_I915_PERF_PROP_MAX:
> MISSING_CASE(id);
> err = -EINVAL;
> @@ -3860,6 +3893,21 @@ static int read_properties_unlocked(struct i915_perf
> *perf,
> uprop += 2;
> }
>
> + if (n_uctx_handles > 0 && props->n_ctx_handles > 0) {
> + DRM_DEBUG("Context handle specified multiple times\n");
> + err = -EINVAL;
> + goto error;
> + }
> +
> + for (i = 0; i < n_uctx_handles; i++) {
> + err = get_user(props->ctx_handles[i], uctx_handles);
> + if (err)
> + goto error;
> +
> + uctx_handles++;
> + props->n_ctx_handles++;
> + }
> +
> return 0;
>
> error:
> @@ -4643,8 +4691,12 @@ int i915_perf_ioctl_version(void)
> *
> * 5: Add DRM_I915_PERF_PROP_POLL_OA_PERIOD parameter that controls
> the
> *interval for the hrtimer used to check for OA data.
> +*
> +* 6: Add DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY &
> +*DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY_LENGTH to allow an
> +*application monitor/pin multiple contexts.
> */
> - return 5;
> + return 6;
> }
>
> #if IS_EN
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove cnl pre-prod workarounds
Quoting Ville Syrjala (2020-04-30 13:58:22) > From: Ville Syrjälä > > Remove all the stepping dependent cnl workarounds. Bspec lists > more steppings than this so presumably these are classed as > pre-production. And this is cnl after all so no one should > really care anyway. > > Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson -Chris ___ 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: Update Slylake PCI IDs
== Series Details == Series: drm/i915: Update Slylake PCI IDs URL : https://patchwork.freedesktop.org/series/76750/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8399_full -> Patchwork_17524_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17524_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17524_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_17524_full: ### IGT changes ### Possible regressions * igt@perf@gen8-unprivileged-single-ctx-counters: - shard-glk: [PASS][1] -> [TIMEOUT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-glk2/igt@p...@gen8-unprivileged-single-ctx-counters.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17524/shard-glk1/igt@p...@gen8-unprivileged-single-ctx-counters.html Known issues Here are the changes found in Patchwork_17524_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-contexts-10ms: - shard-snb: [PASS][3] -> [INCOMPLETE][4] ([i915#82]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-snb2/igt@gem_...@in-flight-contexts-10ms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17524/shard-snb6/igt@gem_...@in-flight-contexts-10ms.html * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-apl6/igt@gen9_exec_pa...@allowed-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17524/shard-apl7/igt@gen9_exec_pa...@allowed-all.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#1515]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-iclb4/igt@i915_pm_rc6_reside...@rc6-idle.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17524/shard-iclb1/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@i915_suspend@fence-restore-untiled: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#69]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-skl10/igt@i915_susp...@fence-restore-untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17524/shard-skl9/igt@i915_susp...@fence-restore-untiled.html * igt@kms_color@pipe-a-ctm-max: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#168]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-skl7/igt@kms_co...@pipe-a-ctm-max.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17524/shard-skl3/igt@kms_co...@pipe-a-ctm-max.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17524/shard-apl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#72]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17524/shard-glk2/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_fbcon_fbt@psr-suspend: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([i915#1185]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-iclb6/igt@kms_fbcon_...@psr-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17524/shard-iclb3/igt@kms_fbcon_...@psr-suspend.html * igt@kms_flip_tiling@flip-changes-tiling-yf: - shard-kbl: [PASS][19] -> [FAIL][20] ([i915#699] / [i915#93] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-kbl7/igt@kms_flip_til...@flip-changes-tiling-yf.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17524/shard-kbl7/igt@kms_flip_til...@flip-changes-tiling-yf.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-kbl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17524/shard-kbl6/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][23] ->
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix glk watermark calculations
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix glk watermark calculations
URL : https://patchwork.freedesktop.org/series/76774/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8401 -> Patchwork_17527
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17527:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@debugfs_test@read_all_entries:
- fi-kbl-7500u: NOTRUN -> [{ABORT}][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/fi-kbl-7500u/igt@debugfs_test@read_all_entries.html
Known issues
Here are the changes found in Patchwork_17527 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@sanitycheck:
- fi-bwr-2160:[PASS][2] -> [INCOMPLETE][3] ([i915#489])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/fi-bwr-2160/igt@i915_selftest@l...@sanitycheck.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/fi-bwr-2160/igt@i915_selftest@l...@sanitycheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489
Participating hosts (50 -> 44)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8401 -> Patchwork_17527
CI-20190529: 20190529
CI_DRM_8401: 41fac0e3809be301af095c66e717eb9843b80212 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5617: 807b26292a3f21057ef7865a4028d22c512590df @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17527: 790b959bc5a3ec7a8820074aec9822ed0118c677 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
790b959bc5a3 drm/i915: Remove cnl pre-prod workarounds
f0177337991d drm/i915: Fix glk watermark calculations
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 16/16] drm: Replace mode->export_head with a boolean
Hi Ville I don't fully grok the i915 changes to provide meaningful review. There are couple of small comments below, but regardless of those Patches 01-11 and 14-16 are: Reviewed-by: Emil Velikov On Tue, 28 Apr 2020 at 18:20, Ville Syrjala wrote: > The downside is that drm_mode_expose_to_userspace() gets to > iterate a few more modes. It already was O(n^2), now it's > a slightly worse O(n^2). > Personally I'd drop the O() sentence, or change it to It already was O(n^2), now it's slightly worse O((n+y)^2). > Another alternative would be a temp bitmask so we wouldn't have > to have anything in the mode struct itself. The main issue is > how large of a bitmask do we need? I guess we could allocate > it dynamically but that means an extra kcalloc() and an extra > loop through the modes to count them first (or grow the bitmask > with krealloc() as needed). > If the walk is even remotely close to being an issue, we could consider the bitmask. I don't think that's the case yet. Hmm the original code never discards any entries from export_head. I wonder if there's some corner case where we could end with an "old" mode showing in the list? For example: - creates a user mode via drmModeCreatePropertyBlob() - calls drmModeGetConnector() and sees their mode - optional (?) does a modeset to and away from said mode - removes their blob drmModeDestroyPropertyBlob() - calls drmModeGetConnector() and still sees their removed mode. If this is a bug (?) that we care about, we might want to add an igt test for it. Conversely, if this is a behaviour we want to keep this patch needs some work. HTH Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 3/4] drm/i915/perf: prepare driver to receive multiple ctx handles
Make all the internal necessary changes before we flip the switch.
v2: Use an unlimited number of intel contexts (Chris)
v3: Handle GEM context with multiple RCS0 logical contexts (Chris)
v4: Let the intel_context create its own timeline (Chris)
Only pin configuration context when needed (Chris)
v5: Pass filtering context ID by argument (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 584 +++--
drivers/gpu/drm/i915/i915_perf_types.h | 37 +-
2 files changed, 379 insertions(+), 242 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 44148b705a5a..1d5a7d31516a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -192,6 +192,7 @@
*/
#include
+#include
#include
#include
@@ -329,7 +330,8 @@ static const struct i915_oa_format
gen12_oa_formats[I915_OA_FORMAT_MAX] = {
* @single_context: Whether a single or all gpu contexts should be monitored
* @hold_preemption: Whether the preemption is disabled for the filtered
* context
- * @ctx_handle: A gem ctx handle for use with @single_context
+ * @n_ctx_handles: Length of @ctx_handles
+ * @ctx_handles: An array of gem context handles
* @metrics_set: An ID for an OA unit metric set advertised via sysfs
* @oa_format: An OA unit HW report format
* @oa_periodic: Whether to enable periodic OA unit sampling
@@ -349,9 +351,10 @@ static const struct i915_oa_format
gen12_oa_formats[I915_OA_FORMAT_MAX] = {
struct perf_open_properties {
u32 sample_flags;
- u64 single_context:1;
u64 hold_preemption:1;
- u64 ctx_handle;
+
+ u32 n_ctx_handles;
+ u32 *ctx_handles;
/* OA sampling state */
int metrics_set;
@@ -631,6 +634,23 @@ static int append_oa_sample(struct i915_perf_stream
*stream,
return 0;
}
+static int ctx_id_equal(const void *key, const void *elem)
+{
+ const struct i915_perf_context_detail *details = elem;
+
+ return ((int)details->id) - (uintptr_t)key;
+}
+
+static inline bool ctx_id_match(struct i915_perf_stream *stream,
+ u32 masked_ctx_id)
+{
+ return bsearch((void *)(uintptr_t)masked_ctx_id,
+ stream->pinned_ctxs,
+ stream->n_pinned_ctxs,
+ sizeof(*stream->pinned_ctxs),
+ ctx_id_equal) != NULL;
+}
+
/**
* Copies all buffered OA reports into userspace read() buffer.
* @stream: An i915-perf stream opened for OA metrics
@@ -742,7 +762,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
continue;
}
- ctx_id = report32[2] & stream->specific_ctx_id_mask;
+ ctx_id = report32[2] & stream->ctx_id_mask;
/*
* Squash whatever is in the CTX_ID field if it's marked as
@@ -787,26 +807,32 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* switches since it's not-uncommon for periodic samples to
* identify a switch before any 'context switch' report.
*/
- if (!stream->perf->exclusive_stream->ctx ||
- stream->specific_ctx_id == ctx_id ||
- stream->oa_buffer.last_ctx_id == stream->specific_ctx_id ||
- reason & OAREPORT_REASON_CTX_SWITCH) {
-
- /*
-* While filtering for a single context we avoid
-* leaking the IDs of other contexts.
-*/
- if (stream->perf->exclusive_stream->ctx &&
- stream->specific_ctx_id != ctx_id) {
- report32[2] = INVALID_CTX_ID;
- }
-
+ if (!stream->perf->exclusive_stream->n_ctxs) {
ret = append_oa_sample(stream, buf, count, offset,
report);
if (ret)
break;
+ } else {
+ bool ctx_match = ctx_id != INVALID_CTX_ID &&
+ ctx_id_match(stream, ctx_id);
+
+ if (ctx_match ||
+ stream->oa_buffer.last_ctx_match ||
+ reason & OAREPORT_REASON_CTX_SWITCH) {
+ /*
+* While filtering for a single context we avoid
+* leaking the IDs of other contexts.
+*/
+ if (!ctx_match)
+ report32[2] = INVALID_CTX_ID;
+
+ ret = append_oa_sample(stream, buf, count,
offset,
+ report);
+
[Intel-gfx] [PATCH v10 4/4] drm/i915/perf: enable filtering on multiple contexts
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
This can be used by drivers using multiple GEM contexts to implement a
single GL context.
Signed-off-by: Lionel Landwerlin
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4464
---
drivers/gpu/drm/i915/i915_perf.c | 58 ++--
include/uapi/drm/i915_drm.h | 21
2 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 1d5a7d31516a..9cb028b0fb5c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3709,7 +3709,8 @@ static int read_properties_unlocked(struct i915_perf
*perf,
struct perf_open_properties *props)
{
u64 __user *uprop = uprops;
- u32 i;
+ u32 __user *uctx_handles = NULL;
+ u32 i, n_uctx_handles = 0;
int err;
memset(props, 0, sizeof(struct perf_open_properties));
@@ -3760,7 +3761,7 @@ static int read_properties_unlocked(struct i915_perf
*perf,
switch ((enum drm_i915_perf_property_id)id) {
case DRM_I915_PERF_PROP_CTX_HANDLE:
- if (props->n_ctx_handles > 0) {
+ if (props->n_ctx_handles > 0 || n_uctx_handles > 0) {
DRM_DEBUG("Context handle specified multiple
times\n");
err = -EINVAL;
goto error;
@@ -3874,6 +3875,38 @@ static int read_properties_unlocked(struct i915_perf
*perf,
}
props->poll_oa_period = value;
break;
+ case DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY:
+ /* HSW can only filter in HW and only on a single
+* context.
+*/
+ if (IS_HASWELL(perf->i915)) {
+ DRM_DEBUG("Multi context filter not supported
on HSW\n");
+ err = -ENODEV;
+ goto error;
+ }
+ uctx_handles = u64_to_user_ptr(value);
+ break;
+ case DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY_LENGTH:
+ if (IS_HASWELL(perf->i915)) {
+ DRM_DEBUG("Multi context filter not supported
on HSW\n");
+ err = -ENODEV;
+ goto error;
+ }
+ if (props->n_ctx_handles > 0 || n_uctx_handles > 0) {
+ DRM_DEBUG("Context handle specified multiple
times\n");
+ err = -EINVAL;
+ goto error;
+ }
+ props->ctx_handles =
+ kmalloc_array(value,
+ sizeof(*props->ctx_handles),
+ GFP_KERNEL);
+ if (!props->ctx_handles) {
+ err = -ENOMEM;
+ goto error;
+ }
+ n_uctx_handles = value;
+ break;
case DRM_I915_PERF_PROP_MAX:
MISSING_CASE(id);
err = -EINVAL;
@@ -3883,6 +3916,21 @@ static int read_properties_unlocked(struct i915_perf
*perf,
uprop += 2;
}
+ if (n_uctx_handles > 0 && props->n_ctx_handles > 0) {
+ DRM_DEBUG("Context handle specified multiple times\n");
+ err = -EINVAL;
+ goto error;
+ }
+
+ for (i = 0; i < n_uctx_handles; i++) {
+ err = get_user(props->ctx_handles[i], uctx_handles);
+ if (err)
+ goto error;
+
+ uctx_handles++;
+ props->n_ctx_handles++;
+ }
+
return 0;
error:
@@ -4666,8 +4714,12 @@ int i915_perf_ioctl_version(void)
*
* 5: Add DRM_I915_PERF_PROP_POLL_OA_PERIOD parameter that controls the
*interval for the hrtimer used to check for OA data.
+*
+* 6: Add DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY &
+*DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY_LENGTH to allow an
+*application monitor/pin multiple contexts.
*/
- return 5;
+ return 6;
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 14b67cd6b54b..f80e7932d728 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1993,6 +1993,27 @@ enum drm_i915_perf_property_id {
*/
DRM_I915_PERF_PROP_POLL_OA_PERIOD,
+ /**
+* Specifies an arr
[Intel-gfx] [PATCH v10 1/4] drm/i915/perf: break OA config buffer object in 2
We want to enable performance monitoring on multiple contexts to cover
the Iris use case of using 2 GEM contexts (3D & compute).
So start by breaking the OA configuration BO which contains global &
per context register writes.
NOA muxes & OA configurations are global, while FLEXEU register
configurations are per context.
v2: Use an offset into the same VMA (Chris)
v3: Use a bitfield to select config parts to emit (Umesh)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 177 ---
1 file changed, 114 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c533f569dd42..c17696058c20 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -367,11 +367,18 @@ struct perf_open_properties {
u64 poll_oa_period;
};
+enum i915_oa_config_part {
+ I915_OA_CONFIG_PART_PER_CONTEXT,
+ I915_OA_CONFIG_PART_GLOBAL,
+ I915_OA_CONFIG_PART_MAX,
+};
+
struct i915_oa_config_bo {
struct llist_node node;
struct i915_oa_config *oa_config;
struct i915_vma *vma;
+ u32 per_context_offset;
};
static struct ctl_table_header *sysctl_header;
@@ -1824,37 +1831,43 @@ static struct i915_oa_config_bo *
alloc_oa_config_buffer(struct i915_perf_stream *stream,
struct i915_oa_config *oa_config)
{
- struct drm_i915_gem_object *obj;
struct i915_oa_config_bo *oa_bo;
+ struct drm_i915_gem_object *obj;
size_t config_length = 0;
- u32 *cs;
+ u32 *cs_start, *cs;
int err;
oa_bo = kzalloc(sizeof(*oa_bo), GFP_KERNEL);
if (!oa_bo)
return ERR_PTR(-ENOMEM);
+ /*
+* Global configuration requires a jump into the NOA wait BO for it to
+* apply.
+*/
config_length += num_lri_dwords(oa_config->mux_regs_len);
config_length += num_lri_dwords(oa_config->b_counter_regs_len);
- config_length += num_lri_dwords(oa_config->flex_regs_len);
config_length += 3; /* MI_BATCH_BUFFER_START */
+
+ config_length += num_lri_dwords(oa_config->flex_regs_len);
+ config_length += 1 /* MI_BATCH_BUFFER_END */;
+
config_length = ALIGN(sizeof(u32) * config_length, I915_GTT_PAGE_SIZE);
- obj = i915_gem_object_create_shmem(stream->perf->i915, config_length);
+ obj = i915_gem_object_create_shmem(stream->perf->i915,
+ config_length);
if (IS_ERR(obj)) {
err = PTR_ERR(obj);
goto err_free;
}
- cs = i915_gem_object_pin_map(obj, I915_MAP_WB);
- if (IS_ERR(cs)) {
- err = PTR_ERR(cs);
- goto err_oa_bo;
+ cs_start = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ if (IS_ERR(cs_start)) {
+ err = PTR_ERR(cs_start);
+ goto err_bo;
}
- cs = write_cs_mi_lri(cs,
-oa_config->mux_regs,
-oa_config->mux_regs_len);
+ cs = cs_start;
cs = write_cs_mi_lri(cs,
oa_config->b_counter_regs,
oa_config->b_counter_regs_len);
@@ -1869,6 +1882,14 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
*cs++ = i915_ggtt_offset(stream->noa_wait);
*cs++ = 0;
+ oa_bo->per_context_offset = 4 * (cs - cs_start);
+
+ cs = write_cs_mi_lri(cs,
+oa_config->mux_regs,
+oa_config->mux_regs_len);
+
+ *cs++ = MI_BATCH_BUFFER_END;
+
i915_gem_object_flush_map(obj);
i915_gem_object_unpin_map(obj);
@@ -1877,7 +1898,7 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
NULL);
if (IS_ERR(oa_bo->vma)) {
err = PTR_ERR(oa_bo->vma);
- goto err_oa_bo;
+ goto err_bo;
}
oa_bo->oa_config = i915_oa_config_get(oa_config);
@@ -1885,15 +1906,15 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
return oa_bo;
-err_oa_bo:
+err_bo:
i915_gem_object_put(obj);
err_free:
kfree(oa_bo);
return ERR_PTR(err);
}
-static struct i915_vma *
-get_oa_vma(struct i915_perf_stream *stream, struct i915_oa_config *oa_config)
+static struct i915_oa_config_bo *
+get_oa_bo(struct i915_perf_stream *stream, struct i915_oa_config *oa_config)
{
struct i915_oa_config_bo *oa_bo;
@@ -1906,34 +1927,31 @@ get_oa_vma(struct i915_perf_stream *stream, struct
i915_oa_config *oa_config)
memcmp(oa_bo->oa_config->uuid,
oa_config->uuid,
sizeof(oa_config->uuid)) == 0)
- goto out;
+ return oa_bo;
}
- oa_bo = alloc_oa_config_buffer(stream, oa_config);
- if (IS_ERR(
[Intel-gfx] [PATCH v10 2/4] drm/i915/perf: stop using the kernel context
Chris doesn't like that.
v2: Don't forget to configure the kernel so that periodic reports are
written appropriately (Lionel)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 153 +
drivers/gpu/drm/i915/i915_perf_types.h | 10 +-
2 files changed, 113 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c17696058c20..44148b705a5a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1354,9 +1354,31 @@ free_noa_wait(struct i915_perf_stream *stream)
i915_vma_unpin_and_release(&stream->noa_wait, 0);
}
+static int i915_perf_stream_sync(struct i915_perf_stream *stream,
+bool enable)
+{
+ struct i915_active *active;
+ int err = 0;
+
+ active = i915_active_create();
+ if (!active)
+ return -ENOMEM;
+
+ if (enable)
+ err = stream->perf->ops.enable_metric_set(stream, active);
+ else
+ stream->perf->ops.disable_metric_set(stream, active);
+ if (err == 0)
+ __i915_active_wait(active, TASK_UNINTERRUPTIBLE);
+
+ i915_active_put(active);
+ return err;
+}
+
static void i915_oa_stream_destroy(struct i915_perf_stream *stream)
{
struct i915_perf *perf = stream->perf;
+ int err;
BUG_ON(stream != perf->exclusive_stream);
@@ -1367,7 +1389,14 @@ static void i915_oa_stream_destroy(struct
i915_perf_stream *stream)
* See i915_oa_init_reg_state() and lrc_configure_all_contexts()
*/
WRITE_ONCE(perf->exclusive_stream, NULL);
- perf->ops.disable_metric_set(stream);
+ err = i915_perf_stream_sync(stream, false /* enable */);
+ if (err) {
+ drm_err(&perf->i915->drm,
+ "Error while disabling OA stream\n");
+ }
+
+ intel_context_unpin(stream->config_context);
+ intel_context_put(stream->config_context);
free_oa_buffer(stream);
@@ -2011,11 +2040,6 @@ emit_oa_config(struct i915_perf_stream *stream,
return err;
}
-static struct intel_context *oa_context(struct i915_perf_stream *stream)
-{
- return stream->pinned_ctx ?: stream->engine->kernel_context;
-}
-
static int
hsw_enable_metric_set(struct i915_perf_stream *stream,
struct i915_active *active)
@@ -2038,13 +2062,14 @@ hsw_enable_metric_set(struct i915_perf_stream *stream,
0, GEN6_CSUNIT_CLOCK_GATE_DISABLE);
return emit_oa_config(stream, stream->oa_config,
- oa_context(stream),
+ stream->config_context,
active,
BIT(I915_OA_CONFIG_PART_GLOBAL) |
BIT(I915_OA_CONFIG_PART_PER_CONTEXT));
}
-static void hsw_disable_metric_set(struct i915_perf_stream *stream)
+static void hsw_disable_metric_set(struct i915_perf_stream *stream,
+ struct i915_active *active)
{
struct intel_uncore *uncore = stream->uncore;
@@ -2169,13 +2194,14 @@ gen8_load_flex(struct i915_request *rq,
return 0;
}
-static int gen8_modify_context(struct intel_context *ce,
+static int gen8_modify_context(struct i915_perf_stream *stream,
+ struct intel_context *ce,
const struct flex *flex, unsigned int count)
{
struct i915_request *rq;
int err;
- rq = intel_engine_create_kernel_request(ce->engine);
+ rq = intel_context_create_request(stream->config_context);
if (IS_ERR(rq))
return PTR_ERR(rq);
@@ -2217,7 +2243,8 @@ gen8_modify_self(struct intel_context *ce,
return err;
}
-static int gen8_configure_context(struct i915_gem_context *ctx,
+static int gen8_configure_context(struct i915_perf_stream *stream,
+ struct i915_gem_context *ctx,
struct flex *flex, unsigned int count)
{
struct i915_gem_engines_iter it;
@@ -2235,7 +2262,7 @@ static int gen8_configure_context(struct i915_gem_context
*ctx,
continue;
flex->value = intel_sseu_make_rpcs(ctx->i915, &ce->sseu);
- err = gen8_modify_context(ce, flex, count);
+ err = gen8_modify_context(stream, ce, flex, count);
intel_context_unpin(ce);
if (err)
@@ -2285,7 +2312,7 @@ static int gen12_configure_oar_context(struct
i915_perf_stream *stream,
if (err)
return err;
- err = gen8_modify_context(ce, regs_context, ARRAY_SIZE(regs_context));
+ err = gen8_modify_context(stream, ce, regs_context,
ARRAY_SIZE(regs_context));
intel_context_unlock_pinned(ce);
if (err)
return err;
@@ -2328,6 +2355,7 @@ oa_configure_all_c
[Intel-gfx] [PATCH v10 0/4] drm/i915/perf: Add support for multi context perf queries
Hi all, Just adding Mesa MR links to the patches. Cheers, Lionel Landwerlin (4): drm/i915/perf: break OA config buffer object in 2 drm/i915/perf: stop using the kernel context drm/i915/perf: prepare driver to receive multiple ctx handles drm/i915/perf: enable filtering on multiple contexts drivers/gpu/drm/i915/i915_perf.c | 920 - drivers/gpu/drm/i915/i915_perf_types.h | 47 +- include/uapi/drm/i915_drm.h| 21 + 3 files changed, 656 insertions(+), 332 deletions(-) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes drm-intel-fixes-2020-04-30: - Fix selftest refcnt leak (Xiyu) - Fix gem vma lock (Chris) - Fix gt's i915_request.timeline acquire by checking if cacheline is valid (Chris) - Fix IRQ postinistall fault masks (Matt) Thanks, Rodrigo. The following changes since commit d082119f4277ff4a63e44d293864aa9f2112b217: drm/i915/dpcd_bl: Unbreak enable_dpcd_backlight modparam (2020-04-20 10:12:58 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-04-30 for you to fetch changes up to 8598eb781cf68fd6cb67c479f1479ae58bd54fb9: drm/i915: Use proper fault mask in interrupt postinstall too (2020-04-28 16:38:03 -0700) - Fix selftest refcnt leak (Xiyu) - Fix gem vma lock (Chris) - Fix gt's i915_request.timeline acquire by checking if cacheline is valid (Chris) - Fix IRQ postinistall fault masks (Matt) Chris Wilson (2): drm/i915/gem: Hold obj->vma.lock over for_each_ggtt_vma() drm/i915/gt: Check cacheline is valid before acquiring Matt Roper (1): drm/i915: Use proper fault mask in interrupt postinstall too Xiyu Yang (1): drm/i915/selftests: Fix i915_address_space refcnt leak drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 20 ++-- drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 drivers/gpu/drm/i915/gt/intel_timeline.c| 2 ++ drivers/gpu/drm/i915/i915_irq.c | 6 ++ drivers/gpu/drm/i915/i915_vma.c | 10 ++ 5 files changed, 36 insertions(+), 14 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm: make drm_file use keyed wakeups
On Wed, Apr 29, 2020 at 11:19:07AM +, k...@kl.wtf wrote: > April 28, 2020 5:14 PM, "Daniel Vetter" wrote: > > > On Fri, Apr 24, 2020 at 06:26:15PM +0200, Kenny Levinsen wrote: > > > >> Some processes, such as systemd, are only polling for EPOLLERR|EPOLLHUP. > >> As drm_file uses unkeyed wakeups, such a poll can receive many spurious > >> wakeups from uninteresting events if, for example, the file description > >> is subscribed to vblank events. This is the case with systemd, as it > >> polls a file description from logind that is shared with the users' > >> compositor. > >> > >> Use keyed wakeups to allow the wakeup target to more efficiently discard > >> these uninteresting events. > >> > >> Signed-off-by: Kenny Levinsen > > > > Hm I applied v1 and I'm not spotting what's different here, and there's no > > changelog explaining what changed ... > > > > Please send a fixup if there's anything important missing. > > -Daniel > > > > It's only the summary that differed as you and sravn requested in #dri-devel, > so it's probably fine. > > I should have explained the change. I'm still trying to get the hang of the > email-based workflow. :) Oops sorry, I generally run as a stateless maintainer so forgot :-/ And yes email based workflow is full of warts, it's a pain. -Daniel > > Best regards, > Kenny Levinsen > > >> --- > >> drivers/gpu/drm/drm_file.c | 6 -- > >> 1 file changed, 4 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > >> index c4c704e01961..ec25b3d979d9 100644 > >> --- a/drivers/gpu/drm/drm_file.c > >> +++ b/drivers/gpu/drm/drm_file.c > >> @@ -608,7 +608,8 @@ ssize_t drm_read(struct file *filp, char __user > >> *buffer, > >> file_priv->event_space -= length; > >> list_add(&e->link, &file_priv->event_list); > >> spin_unlock_irq(&dev->event_lock); > >> - wake_up_interruptible(&file_priv->event_wait); > >> + wake_up_interruptible_poll(&file_priv->event_wait, > >> + EPOLLIN | EPOLLRDNORM); > >> break; > >> } > >> > >> @@ -804,7 +805,8 @@ void drm_send_event_locked(struct drm_device *dev, > >> struct drm_pending_event *e) > >> list_del(&e->pending_link); > >> list_add_tail(&e->link, > >> &e->file_priv->event_list); > >> - wake_up_interruptible(&e->file_priv->event_wait); > >> + wake_up_interruptible_poll(&e->file_priv->event_wait, > >> + EPOLLIN | EPOLLRDNORM); > >> } > >> EXPORT_SYMBOL(drm_send_event_locked); > >> > >> -- > >> 2.26.1 > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: Add support for multi context perf queries (rev4)
== Series Details == Series: drm/i915/perf: Add support for multi context perf queries (rev4) URL : https://patchwork.freedesktop.org/series/76588/ State : warning == Summary == $ dim checkpatch origin/drm-tip a350ade77f42 drm/i915/perf: break OA config buffer object in 2 5845f5921ffd drm/i915/perf: stop using the kernel context -:190: CHECK:LINE_SPACING: Please don't use multiple blank lines #190: FILE: drivers/gpu/drm/i915/i915_perf.c:2534: + total: 0 errors, 0 warnings, 1 checks, 343 lines checked 23a516e1e12a drm/i915/perf: prepare driver to receive multiple ctx handles 097f8748f71f drm/i915/perf: enable filtering on multiple contexts ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/25] perf/core: Only copy-to-user after completely unlocking all locks, v3.
== Series Details == Series: series starting with [01/25] perf/core: Only copy-to-user after completely unlocking all locks, v3. URL : https://patchwork.freedesktop.org/series/76724/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8391_full -> Patchwork_17513_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17513_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17513_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_17513_full: ### IGT changes ### Possible regressions * igt@gem_close@many-handles-one-vma: - shard-glk: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8391/shard-glk2/igt@gem_cl...@many-handles-one-vma.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-glk5/igt@gem_cl...@many-handles-one-vma.html - shard-apl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8391/shard-apl8/igt@gem_cl...@many-handles-one-vma.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-apl8/igt@gem_cl...@many-handles-one-vma.html - shard-skl: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8391/shard-skl9/igt@gem_cl...@many-handles-one-vma.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-skl5/igt@gem_cl...@many-handles-one-vma.html - shard-tglb: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8391/shard-tglb8/igt@gem_cl...@many-handles-one-vma.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-tglb1/igt@gem_cl...@many-handles-one-vma.html - shard-kbl: [PASS][9] -> [FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8391/shard-kbl4/igt@gem_cl...@many-handles-one-vma.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-kbl1/igt@gem_cl...@many-handles-one-vma.html - shard-hsw: [PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8391/shard-hsw5/igt@gem_cl...@many-handles-one-vma.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-hsw6/igt@gem_cl...@many-handles-one-vma.html - shard-snb: [PASS][13] -> [FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8391/shard-snb6/igt@gem_cl...@many-handles-one-vma.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-snb6/igt@gem_cl...@many-handles-one-vma.html - shard-iclb: [PASS][15] -> [FAIL][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8391/shard-iclb8/igt@gem_cl...@many-handles-one-vma.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-iclb6/igt@gem_cl...@many-handles-one-vma.html * igt@i915_selftest@live@gt_pm: - shard-kbl: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8391/shard-kbl2/igt@i915_selftest@live@gt_pm.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-kbl3/igt@i915_selftest@live@gt_pm.html - shard-apl: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8391/shard-apl1/igt@i915_selftest@live@gt_pm.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-apl4/igt@i915_selftest@live@gt_pm.html - shard-iclb: [PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8391/shard-iclb4/igt@i915_selftest@live@gt_pm.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-iclb5/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@perf: - shard-hsw: NOTRUN -> [FAIL][23] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-hsw7/igt@i915_selft...@perf.html * igt@runner@aborted: - shard-hsw: NOTRUN -> ([FAIL][24], [FAIL][25], [FAIL][26]) ([k.org#204565]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-hsw7/igt@run...@aborted.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-hsw6/igt@run...@aborted.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-hsw6/igt@run...@aborted.html - shard-iclb: NOTRUN -> ([FAIL][27], [FAIL][28]) ([i915#1580]) [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-iclb7/igt@run...@aborted.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17513/shard-iclb5/igt@run...@aborted.html Suppressed The following results come from un
Re: [Intel-gfx] [RFC 06/17] drm: i915: fix sg_table nents vs. orig_nents misuse
Hi
On 28.04.2020 16:27, Tvrtko Ursulin wrote:
>
> On 28/04/2020 14:19, Marek Szyprowski wrote:
>> The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
>> numer of the created entries in the DMA address space. However the
>> subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg
>> must be
>> called with the original number of entries passed to dma_map_sg. The
>> sg_table->nents in turn holds the result of the dma_map_sg call as
>> stated
>> in include/linux/scatterlist.h. Adapt the code to obey those rules.
>>
>> Signed-off-by: Marek Szyprowski
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 13 +++--
>> drivers/gpu/drm/i915/gem/i915_gem_internal.c | 4 ++--
>> drivers/gpu/drm/i915/gem/i915_gem_region.c | 4 ++--
>> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 5 +++--
>> drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 10 +-
>> drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 5 +++--
>> drivers/gpu/drm/i915/gt/intel_ggtt.c | 12 ++--
>> drivers/gpu/drm/i915/i915_gem_gtt.c | 12 +++-
>> drivers/gpu/drm/i915/i915_scatterlist.c | 4 ++--
>> drivers/gpu/drm/i915/selftests/scatterlist.c | 8
>> 10 files changed, 41 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> index 7db5a79..d829852 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> @@ -36,21 +36,22 @@ static struct sg_table
>> *i915_gem_map_dma_buf(struct dma_buf_attachment *attachme
>> goto err_unpin_pages;
>> }
>> - ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
>> + ret = sg_alloc_table(st, obj->mm.pages->orig_nents, GFP_KERNEL);
>> if (ret)
>> goto err_free;
>> src = obj->mm.pages->sgl;
>> dst = st->sgl;
>> - for (i = 0; i < obj->mm.pages->nents; i++) {
>> + for (i = 0; i < obj->mm.pages->orig_nents; i++) {
>> sg_set_page(dst, sg_page(src), src->length, 0);
>> dst = sg_next(dst);
>> src = sg_next(src);
>> }
>> - if (!dma_map_sg_attrs(attachment->dev,
>> - st->sgl, st->nents, dir,
>> - DMA_ATTR_SKIP_CPU_SYNC)) {
>> + st->nents = dma_map_sg_attrs(attachment->dev,
>> + st->sgl, st->orig_nents, dir,
>> + DMA_ATTR_SKIP_CPU_SYNC);
>> + if (!st->nents) {
>> ret = -ENOMEM;
>> goto err_free_sg;
>> }
>> @@ -74,7 +75,7 @@ static void i915_gem_unmap_dma_buf(struct
>> dma_buf_attachment *attachment,
>> struct drm_i915_gem_object *obj =
>> dma_buf_to_obj(attachment->dmabuf);
>> dma_unmap_sg_attrs(attachment->dev,
>> - sg->sgl, sg->nents, dir,
>> + sg->sgl, sg->orig_nents, dir,
>> DMA_ATTR_SKIP_CPU_SYNC);
>> sg_free_table(sg);
>> kfree(sg);
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
>> index cbbff81..a8ebfdd 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
>> @@ -73,7 +73,7 @@ static int
>> i915_gem_object_get_pages_internal(struct drm_i915_gem_object *obj)
>> }
>> sg = st->sgl;
>> - st->nents = 0;
>> + st->nents = st->orig_nents = 0;
>> sg_page_sizes = 0;
>> do {
>> @@ -94,7 +94,7 @@ static int
>> i915_gem_object_get_pages_internal(struct drm_i915_gem_object *obj)
>> sg_set_page(sg, page, PAGE_SIZE << order, 0);
>> sg_page_sizes |= PAGE_SIZE << order;
>> - st->nents++;
>> + st->nents = st->orig_nents = st->nents + 1;
>> npages -= 1 << order;
>> if (!npages) {
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_region.c
>> index 1515384..58ca560 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
>> @@ -53,7 +53,7 @@
>> GEM_BUG_ON(list_empty(blocks));
>> sg = st->sgl;
>> - st->nents = 0;
>> + st->nents = st->orig_nents = 0;
>> sg_page_sizes = 0;
>> prev_end = (resource_size_t)-1;
>> @@ -78,7 +78,7 @@
>> sg->length = block_size;
>> - st->nents++;
>> + st->nents = st->orig_nents = st->nents + 1;
>> } else {
>> sg->length += block_size;
>> sg_dma_len(sg) += block_size;
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> index 5d5d7ee..851a732 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> @@ -80,7 +80,7 @@ static int shmem_get_pages(struct
>> drm_i915_gem_object *obj)
>> noreclaim |= __GFP_NORETRY |
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: Add support for multi context perf queries (rev4)
== Series Details ==
Series: drm/i915/perf: Add support for multi context perf queries (rev4)
URL : https://patchwork.freedesktop.org/series/76588/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8401 -> Patchwork_17528
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17528:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@debugfs_test@read_all_entries:
- fi-kbl-7500u: NOTRUN -> [{ABORT}][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/fi-kbl-7500u/igt@debugfs_test@read_all_entries.html
Known issues
Here are the changes found in Patchwork_17528 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@gem_contexts:
- fi-bwr-2160:[INCOMPLETE][2] ([i915#489]) -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/fi-bwr-2160/igt@i915_selftest@live@gem_contexts.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/fi-bwr-2160/igt@i915_selftest@live@gem_contexts.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][4] ([fdo#109271]) -> [FAIL][5] ([i915#62] /
[i915#95])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (50 -> 44)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8401 -> Patchwork_17528
CI-20190529: 20190529
CI_DRM_8401: 41fac0e3809be301af095c66e717eb9843b80212 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5617: 807b26292a3f21057ef7865a4028d22c512590df @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17528: 097f8748f71f25cfc31d4791a530d75908aae7a9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
097f8748f71f drm/i915/perf: enable filtering on multiple contexts
23a516e1e12a drm/i915/perf: prepare driver to receive multiple ctx handles
5845f5921ffd drm/i915/perf: stop using the kernel context
a350ade77f42 drm/i915/perf: break OA config buffer object in 2
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 3/4] drm/i915/perf: prepare driver to receive multiple ctx handles
Quoting Lionel Landwerlin (2020-04-30 14:55:35)
> @@ -1382,6 +1446,12 @@ static void i915_oa_stream_destroy(struct
> i915_perf_stream *stream)
>
> BUG_ON(stream != perf->exclusive_stream);
>
> + err = intel_context_pin(stream->config_context);
> + if (err) {
> + drm_err(&perf->i915->drm,
> + "Error pinning i915-perf context\n");
> + }
Reading through, this is the last thing that leapt out at me.
Taking an error here would be nasty, and we do allow the pin to be
interrupted (which would be a surprise for most people who call
close()).
The only suggestion I can make, is that the stream always keeps it
pinned.
>From the robustness point of view, it's better if we break
stream->config_context than if we break stream->engine->kernel_context,
but equally pinning another context image [about 80k in total] just for
safety? Probably worth it. [If we break the kernel_context, we cannot do
hang detection or pm/idle, the driver comes grinding to a halt.]
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 3/4] drm/i915/perf: prepare driver to receive multiple ctx handles
On 30/04/2020 17:55, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-30 14:55:35)
@@ -1382,6 +1446,12 @@ static void i915_oa_stream_destroy(struct
i915_perf_stream *stream)
BUG_ON(stream != perf->exclusive_stream);
+ err = intel_context_pin(stream->config_context);
+ if (err) {
+ drm_err(&perf->i915->drm,
+ "Error pinning i915-perf context\n");
+ }
Reading through, this is the last thing that leapt out at me.
Taking an error here would be nasty, and we do allow the pin to be
interrupted (which would be a surprise for most people who call
close()).
The only suggestion I can make, is that the stream always keeps it
pinned.
>From the robustness point of view, it's better if we break
stream->config_context than if we break stream->engine->kernel_context,
but equally pinning another context image [about 80k in total] just for
safety? Probably worth it. [If we break the kernel_context, we cannot do
hang detection or pm/idle, the driver comes grinding to a halt.]
-Chris
Yeah, I didn't like writing this error path there either.
-Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Add tiled blits selftest (rev2)
== Series Details == Series: drm/i915/selftests: Add tiled blits selftest (rev2) URL : https://patchwork.freedesktop.org/series/76746/ State : success == Summary == CI Bug Log - changes from CI_DRM_8399_full -> Patchwork_17525_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17525_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_dc@dc6-psr: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#454]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-skl4/igt@i915_pm...@dc6-psr.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/shard-skl6/igt@i915_pm...@dc6-psr.html * igt@kms_color@pipe-a-ctm-max: - shard-skl: [PASS][3] -> [FAIL][4] ([i915#168]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-skl7/igt@kms_co...@pipe-a-ctm-max.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/shard-skl5/igt@kms_co...@pipe-a-ctm-max.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-apl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/shard-apl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#72]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#52] / [i915#54]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-skl5/igt@kms_draw_...@draw-method-rgb565-mmap-wc-untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/shard-skl8/igt@kms_draw_...@draw-method-rgb565-mmap-wc-untiled.html * igt@kms_flip_tiling@flip-changes-tiling-yf: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#699] / [i915#93] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-kbl7/igt@kms_flip_til...@flip-changes-tiling-yf.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/shard-kbl7/igt@kms_flip_til...@flip-changes-tiling-yf.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-apl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-skl7/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/shard-skl5/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html Possible fixes * igt@gem_exec_params@invalid-bsd-ring: - shard-iclb: [SKIP][17] ([fdo#109276]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-iclb7/igt@gem_exec_par...@invalid-bsd-ring.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/shard-iclb2/igt@gem_exec_par...@invalid-bsd-ring.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [DMESG-WARN][19] ([i915#180]) -> [PASS][20] +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled: - shard-apl: [FAIL][21] ([i915#52] / [i915#54] / [i915#95]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-apl8/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/shard-apl7/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: [INCOMPLETE][23] ([i915#69]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8399/shard-skl6/igt@kms_fbcon_...@psr-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17525/shard-skl9/
Re: [Intel-gfx] [PATCH v10 1/4] drm/i915/perf: break OA config buffer object in 2
Quoting Lionel Landwerlin (2020-04-30 14:55:33) > We want to enable performance monitoring on multiple contexts to cover > the Iris use case of using 2 GEM contexts (3D & compute). > > So start by breaking the OA configuration BO which contains global & > per context register writes. > > NOA muxes & OA configurations are global, while FLEXEU register > configurations are per context. > > v2: Use an offset into the same VMA (Chris) > > v3: Use a bitfield to select config parts to emit (Umesh) > > Signed-off-by: Lionel Landwerlin Flashy bitfields, Batman. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers
On Wed, Apr 29, 2020 at 4:57 AM Jani Nikula wrote:
>
> On Tue, 28 Apr 2020, Michal Orzel wrote:
> > As suggested by the TODO list for the kernel DRM subsystem, replace
> > the deprecated functions that take/drop modeset locks with new helpers.
> >
> > Signed-off-by: Michal Orzel
> > ---
> > drivers/gpu/drm/drm_mode_object.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > b/drivers/gpu/drm/drm_mode_object.c
> > index 35c2719..901b078 100644
> > --- a/drivers/gpu/drm/drm_mode_object.c
> > +++ b/drivers/gpu/drm/drm_mode_object.c
> > @@ -402,12 +402,13 @@ int drm_mode_obj_get_properties_ioctl(struct
> > drm_device *dev, void *data,
> > {
> > struct drm_mode_obj_get_properties *arg = data;
> > struct drm_mode_object *obj;
> > + struct drm_modeset_acquire_ctx ctx;
> > int ret = 0;
> >
> > if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > return -EOPNOTSUPP;
> >
> > - drm_modeset_lock_all(dev);
> > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
>
> I cry a little every time I look at the DRM_MODESET_LOCK_ALL_BEGIN and
> DRM_MODESET_LOCK_ALL_END macros. :(
>
> Currently only six users... but there are ~60 calls to
> drm_modeset_lock_all{,_ctx} that I presume are to be replaced. I wonder
> if this will come back and haunt us.
>
What's the alternative? Seems like the options without the macros is
to use incorrect scope or have a bunch of retry/backoff cargo-cult
everywhere (and hope the copy source is done correctly).
Sean
> BR,
> Jani.
>
>
> >
> > obj = drm_mode_object_find(dev, file_priv, arg->obj_id,
> > arg->obj_type);
> > if (!obj) {
> > @@ -427,7 +428,7 @@ int drm_mode_obj_get_properties_ioctl(struct drm_device
> > *dev, void *data,
> > out_unref:
> > drm_mode_object_put(obj);
> > out:
> > - drm_modeset_unlock_all(dev);
> > + DRM_MODESET_LOCK_ALL_END(ctx, ret);
> > return ret;
> > }
> >
> > @@ -449,12 +450,13 @@ static int set_property_legacy(struct drm_mode_object
> > *obj,
> > {
> > struct drm_device *dev = prop->dev;
> > struct drm_mode_object *ref;
> > + struct drm_modeset_acquire_ctx ctx;
> > int ret = -EINVAL;
> >
> > if (!drm_property_change_valid_get(prop, prop_value, &ref))
> > return -EINVAL;
> >
> > - drm_modeset_lock_all(dev);
> > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
> > switch (obj->type) {
> > case DRM_MODE_OBJECT_CONNECTOR:
> > ret = drm_connector_set_obj_prop(obj, prop, prop_value);
> > @@ -468,7 +470,7 @@ static int set_property_legacy(struct drm_mode_object
> > *obj,
> > break;
> > }
> > drm_property_change_valid_put(prop, ref);
> > - drm_modeset_unlock_all(dev);
> > + DRM_MODESET_LOCK_ALL_END(ctx, ret);
> >
> > return ret;
> > }
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9] drm/i915/gen12: Flush AMFS
To ensure that we have global observation point wrt to all data, flush amfs. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 + drivers/gpu/drm/i915/gt/intel_lrc.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h index 98b39e65aed9..69979cc86caa 100644 --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h @@ -223,6 +223,7 @@ #define PIPE_CONTROL_COMMAND_CACHE_INVALIDATE(1<<29) /* gen11+ */ #define PIPE_CONTROL_TILE_CACHE_FLUSH(1<<28) /* gen11+ */ #define PIPE_CONTROL_FLUSH_L3(1<<27) +#define PIPE_CONTROL_FLUSH_AMFS (1<<25) /* gen12+ */ #define PIPE_CONTROL_GLOBAL_GTT_IVB (1<<24) /* gen7+ */ #define PIPE_CONTROL_MMIO_WRITE (1<<23) #define PIPE_CONTROL_STORE_DATA_INDEX(1<<21) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 0bbce218157f..b47230583494 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -4555,6 +4555,7 @@ static int gen12_emit_flush_render(struct i915_request *request, flags |= PIPE_CONTROL_L3_FABRIC_FLUSH; flags |= PIPE_CONTROL_TILE_CACHE_FLUSH; flags |= PIPE_CONTROL_FLUSH_L3; + flags |= PIPE_CONTROL_FLUSH_AMFS; flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH; flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH; /* Wa_1409600907:tgl */ @@ -4771,6 +4772,7 @@ gen12_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs) PIPE_CONTROL_L3_FABRIC_FLUSH | PIPE_CONTROL_TILE_CACHE_FLUSH | PIPE_CONTROL_FLUSH_L3 | + PIPE_CONTROL_FLUSH_AMFS | PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH | PIPE_CONTROL_DEPTH_CACHE_FLUSH | /* Wa_1409600907:tgl */ -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/9] drm/i915/gen12: Flush L3
Flush TDL and L3. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_lrc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index b3ddb928d231..0bbce218157f 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -4554,6 +4554,7 @@ static int gen12_emit_flush_render(struct i915_request *request, flags |= PIPE_CONTROL_L3_FABRIC_FLUSH; flags |= PIPE_CONTROL_TILE_CACHE_FLUSH; + flags |= PIPE_CONTROL_FLUSH_L3; flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH; flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH; /* Wa_1409600907:tgl */ @@ -4769,6 +4770,7 @@ gen12_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs) PIPE_CONTROL_CS_STALL | PIPE_CONTROL_L3_FABRIC_FLUSH | PIPE_CONTROL_TILE_CACHE_FLUSH | + PIPE_CONTROL_FLUSH_L3 | PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH | PIPE_CONTROL_DEPTH_CACHE_FLUSH | /* Wa_1409600907:tgl */ -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/9] drm/i915/gen12: Add L3 fabric flush
Do a l3 fabric flush when emitting flush. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 + drivers/gpu/drm/i915/gt/intel_lrc.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h index 534e435f20bc..98b39e65aed9 100644 --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h @@ -219,6 +219,7 @@ #define DISPLAY_PLANE_A (0<<20) #define DISPLAY_PLANE_B (1<<20) #define GFX_OP_PIPE_CONTROL(len) ((0x3<<29)|(0x3<<27)|(0x2<<24)|((len)-2)) +#define PIPE_CONTROL_L3_FABRIC_FLUSH (1<<30) /* gen12+ */ #define PIPE_CONTROL_COMMAND_CACHE_INVALIDATE(1<<29) /* gen11+ */ #define PIPE_CONTROL_TILE_CACHE_FLUSH(1<<28) /* gen11+ */ #define PIPE_CONTROL_FLUSH_L3(1<<27) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 3c5e55ad4f9f..b3ddb928d231 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -4552,6 +4552,7 @@ static int gen12_emit_flush_render(struct i915_request *request, u32 flags = 0; u32 *cs; + flags |= PIPE_CONTROL_L3_FABRIC_FLUSH; flags |= PIPE_CONTROL_TILE_CACHE_FLUSH; flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH; flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH; @@ -4766,6 +4767,7 @@ gen12_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs) i915_request_active_timeline(request)->hwsp_offset, PIPE_CONTROL0_HDC_PIPELINE_FLUSH, PIPE_CONTROL_CS_STALL | + PIPE_CONTROL_L3_FABRIC_FLUSH | PIPE_CONTROL_TILE_CACHE_FLUSH | PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH | PIPE_CONTROL_DEPTH_CACHE_FLUSH | -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915/gen12: Invalidate media state
Treat media state as any other state and invalidate it. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 789efece1fc0..859c901c8935 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -4583,6 +4583,7 @@ static int gen12_emit_flush_render(struct i915_request *request, flags |= PIPE_CONTROL_COMMAND_CACHE_INVALIDATE; flags |= PIPE_CONTROL_TLB_INVALIDATE; + flags |= PIPE_CONTROL_MEDIA_STATE_CLEAR; flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE; flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE; flags |= PIPE_CONTROL_INDIRECT_STATE_DISABLE; -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/9] drm/i915/gen12: Fix HDC pipeline flush
HDC pipeline flush is bit on the first dword of
the PIPE_CONTROL, not the second. Make it so.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine.h | 23 +++
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 30 ++--
3 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index d10e52ff059f..f449171ae808 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -241,19 +241,24 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine);
void intel_engine_print_breadcrumbs(struct intel_engine_cs *engine,
struct drm_printer *p);
-static inline u32 *gen8_emit_pipe_control(u32 *batch, u32 flags, u32 offset)
+static inline u32 *gen12_emit_pipe_control(u32 *batch, u32 flags0, u32 flags1,
u32 offset)
{
memset(batch, 0, 6 * sizeof(u32));
- batch[0] = GFX_OP_PIPE_CONTROL(6);
- batch[1] = flags;
+ batch[0] = GFX_OP_PIPE_CONTROL(6) | flags0;
+ batch[1] = flags1;
batch[2] = offset;
return batch + 6;
}
+static inline u32 *gen8_emit_pipe_control(u32 *batch, u32 flags, u32 offset)
+{
+ return gen12_emit_pipe_control(batch, 0, flags, offset);
+}
+
static inline u32 *
-gen8_emit_ggtt_write_rcs(u32 *cs, u32 value, u32 gtt_offset, u32 flags)
+gen12_emit_ggtt_write_rcs(u32 *cs, u32 value, u32 gtt_offset, u32 flags0, u32
flags1)
{
/* We're using qword write, offset should be aligned to 8 bytes. */
GEM_BUG_ON(!IS_ALIGNED(gtt_offset, 8));
@@ -262,8 +267,8 @@ gen8_emit_ggtt_write_rcs(u32 *cs, u32 value, u32
gtt_offset, u32 flags)
* need a prior CS_STALL, which is emitted by the flush
* following the batch.
*/
- *cs++ = GFX_OP_PIPE_CONTROL(6);
- *cs++ = flags | PIPE_CONTROL_QW_WRITE | PIPE_CONTROL_GLOBAL_GTT_IVB;
+ *cs++ = GFX_OP_PIPE_CONTROL(6) | flags0;
+ *cs++ = flags1 | PIPE_CONTROL_QW_WRITE | PIPE_CONTROL_GLOBAL_GTT_IVB;
*cs++ = gtt_offset;
*cs++ = 0;
*cs++ = value;
@@ -273,6 +278,12 @@ gen8_emit_ggtt_write_rcs(u32 *cs, u32 value, u32
gtt_offset, u32 flags)
return cs;
}
+static inline u32 *
+gen8_emit_ggtt_write_rcs(u32 *cs, u32 value, u32 gtt_offset, u32 flags)
+{
+ return gen12_emit_ggtt_write_rcs(cs, value, gtt_offset, 0, flags);
+}
+
static inline u32 *
gen8_emit_ggtt_write(u32 *cs, u32 value, u32 gtt_offset, u32 flags)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index b3cf09657fb2..534e435f20bc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -237,7 +237,7 @@
#define PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE(1<<11) /* MBZ on ILK */
#define PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE(1<<10) /*
GM45+ only */
#define PIPE_CONTROL_INDIRECT_STATE_DISABLE (1<<9)
-#define PIPE_CONTROL_HDC_PIPELINE_FLUSH REG_BIT(9) /* gen12 */
+#define PIPE_CONTROL0_HDC_PIPELINE_FLUSH REG_BIT(9) /* gen12 */
#define PIPE_CONTROL_NOTIFY (1<<8)
#define PIPE_CONTROL_FLUSH_ENABLE(1<<7) /* gen7+ */
#define PIPE_CONTROL_DC_FLUSH_ENABLE (1<<5)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 8f82b960f2a1..3c5e55ad4f9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4559,7 +4559,6 @@ static int gen12_emit_flush_render(struct i915_request
*request,
flags |= PIPE_CONTROL_DEPTH_STALL;
flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
flags |= PIPE_CONTROL_FLUSH_ENABLE;
- flags |= PIPE_CONTROL_HDC_PIPELINE_FLUSH;
flags |= PIPE_CONTROL_STORE_DATA_INDEX;
flags |= PIPE_CONTROL_QW_WRITE;
@@ -4570,7 +4569,8 @@ static int gen12_emit_flush_render(struct i915_request
*request,
if (IS_ERR(cs))
return PTR_ERR(cs);
- cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
+ cs = gen12_emit_pipe_control(cs,
PIPE_CONTROL0_HDC_PIPELINE_FLUSH,
+flags, LRC_PPHWSP_SCRATCH_ADDR);
intel_ring_advance(request, cs);
}
@@ -4602,7 +4602,7 @@ static int gen12_emit_flush_render(struct i915_request
*request,
*/
*cs++ = preparser_disable(true);
- cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
+ cs = gen12_emit_pipe_control(cs, 0, flags,
LRC_PPHWSP_SCRATCH_ADDR);
*cs++ = preparser_disable(false);
intel_ring_advance(request, cs);
@@ -47
[Intel-gfx] [PATCH 7/9] drm/i915/gen12: Wait on previous flush on invalidate
Flush enable bit is a sync point which makes this pipecontrol to wait that everything on a previous pipe control are flushed. Enable it to make sure that our invalidates doesn't overlap. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_lrc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 7807f53eae18..789efece1fc0 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -4590,6 +4590,8 @@ static int gen12_emit_flush_render(struct i915_request *request, flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE; flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE; + flags |= PIPE_CONTROL_FLUSH_ENABLE; + flags |= PIPE_CONTROL_STORE_DATA_INDEX; flags |= PIPE_CONTROL_QW_WRITE; -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/9] Revert "drm/i915/tgl: Include ro parts of l3 to invalidate"
This reverts commit 62037229b7d94f1db5ef8d2e2ec819832ef3. L3 ro cache invalidation is part of the dword0 of pipe control. Also it is not relevant to this gen. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 - drivers/gpu/drm/i915/gt/intel_lrc.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h index ee10122a511e..b3cf09657fb2 100644 --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h @@ -236,7 +236,6 @@ #define PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH (1<<12) /* gen6+ */ #define PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE(1<<11) /* MBZ on ILK */ #define PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE(1<<10) /* GM45+ only */ -#define PIPE_CONTROL_L3_RO_CACHE_INVALIDATE REG_BIT(10) /* gen12 */ #define PIPE_CONTROL_INDIRECT_STATE_DISABLE (1<<9) #define PIPE_CONTROL_HDC_PIPELINE_FLUSH REG_BIT(9) /* gen12 */ #define PIPE_CONTROL_NOTIFY (1<<8) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 4311b12542fb..8f82b960f2a1 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -4585,7 +4585,6 @@ static int gen12_emit_flush_render(struct i915_request *request, flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE; flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE; flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE; - flags |= PIPE_CONTROL_L3_RO_CACHE_INVALIDATE; flags |= PIPE_CONTROL_STORE_DATA_INDEX; flags |= PIPE_CONTROL_QW_WRITE; -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 9/9] drm/i915/gen12: Flush LLC
Request boundary is a global observation point for all operations. Thus flush the LLC too. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 + drivers/gpu/drm/i915/gt/intel_lrc.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h index 69979cc86caa..a7f4f0934508 100644 --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h @@ -223,6 +223,7 @@ #define PIPE_CONTROL_COMMAND_CACHE_INVALIDATE(1<<29) /* gen11+ */ #define PIPE_CONTROL_TILE_CACHE_FLUSH(1<<28) /* gen11+ */ #define PIPE_CONTROL_FLUSH_L3(1<<27) +#define PIPE_CONTROL_FLUSH_LLC (1<<26) /* gen12+ */ #define PIPE_CONTROL_FLUSH_AMFS (1<<25) /* gen12+ */ #define PIPE_CONTROL_GLOBAL_GTT_IVB (1<<24) /* gen7+ */ #define PIPE_CONTROL_MMIO_WRITE (1<<23) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 859c901c8935..2a4ef2ea042f 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -4555,6 +4555,7 @@ static int gen12_emit_flush_render(struct i915_request *request, flags |= PIPE_CONTROL_L3_FABRIC_FLUSH; flags |= PIPE_CONTROL_TILE_CACHE_FLUSH; flags |= PIPE_CONTROL_FLUSH_L3; + flags |= PIPE_CONTROL_FLUSH_LLC; flags |= PIPE_CONTROL_FLUSH_AMFS; flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH; flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH; @@ -4776,6 +4777,7 @@ gen12_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs) PIPE_CONTROL_L3_FABRIC_FLUSH | PIPE_CONTROL_TILE_CACHE_FLUSH | PIPE_CONTROL_FLUSH_L3 | + PIPE_CONTROL_FLUSH_LLC | PIPE_CONTROL_FLUSH_AMFS | PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH | PIPE_CONTROL_DEPTH_CACHE_FLUSH | -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/9] drm/i915/gen12: Invalidate indirect state pointers
Aim for completeness for invalidating everything and mark state pointers stale. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index b47230583494..7807f53eae18 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -4585,6 +4585,7 @@ static int gen12_emit_flush_render(struct i915_request *request, flags |= PIPE_CONTROL_TLB_INVALIDATE; flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE; flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE; + flags |= PIPE_CONTROL_INDIRECT_STATE_DISABLE; flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE; flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE; flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE; -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] Revert "drm/i915/tgl: Include ro parts of l3 to invalidate"
== Series Details == Series: series starting with [1/9] Revert "drm/i915/tgl: Include ro parts of l3 to invalidate" URL : https://patchwork.freedesktop.org/series/76777/ State : warning == Summary == $ dim checkpatch origin/drm-tip 53177bdb8662 Revert "drm/i915/tgl: Include ro parts of l3 to invalidate" 7e235ad6db72 drm/i915/gen12: Fix HDC pipeline flush 868476e157a0 drm/i915/gen12: Add L3 fabric flush -:18: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #18: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:222: +#define PIPE_CONTROL_L3_FABRIC_FLUSH (1<<30) /* gen12+ */ ^ total: 0 errors, 0 warnings, 1 checks, 21 lines checked 8411dc590177 drm/i915/gen12: Flush L3 abb852252bfa drm/i915/gen12: Flush AMFS -:19: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #19: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:226: +#define PIPE_CONTROL_FLUSH_AMFS (1<<25) /* gen12+ */ ^ total: 0 errors, 0 warnings, 1 checks, 21 lines checked cdb89beff0e2 drm/i915/gen12: Invalidate indirect state pointers 4289817480ba drm/i915/gen12: Wait on previous flush on invalidate dda90d2bdc6d drm/i915/gen12: Invalidate media state 987ed1f2f5ee drm/i915/gen12: Flush LLC -:19: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #19: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:226: +#define PIPE_CONTROL_FLUSH_LLC (1<<26) /* gen12+ */ ^ total: 0 errors, 0 warnings, 1 checks, 21 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] Revert "drm/i915/tgl: Include ro parts of l3 to invalidate"
== Series Details ==
Series: series starting with [1/9] Revert "drm/i915/tgl: Include ro parts of l3
to invalidate"
URL : https://patchwork.freedesktop.org/series/76777/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8401 -> Patchwork_17529
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17529/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17529:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@debugfs_test@read_all_entries:
- fi-kbl-7500u: NOTRUN -> [{ABORT}][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17529/fi-kbl-7500u/igt@debugfs_test@read_all_entries.html
Known issues
Here are the changes found in Patchwork_17529 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@gem_contexts:
- fi-bwr-2160:[INCOMPLETE][2] ([i915#489]) -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/fi-bwr-2160/igt@i915_selftest@live@gem_contexts.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17529/fi-bwr-2160/igt@i915_selftest@live@gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489
Participating hosts (50 -> 44)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8401 -> Patchwork_17529
CI-20190529: 20190529
CI_DRM_8401: 41fac0e3809be301af095c66e717eb9843b80212 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5617: 807b26292a3f21057ef7865a4028d22c512590df @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17529: 987ed1f2f5ee6841ef96e02808b35fd17dc72028 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
987ed1f2f5ee drm/i915/gen12: Flush LLC
dda90d2bdc6d drm/i915/gen12: Invalidate media state
4289817480ba drm/i915/gen12: Wait on previous flush on invalidate
cdb89beff0e2 drm/i915/gen12: Invalidate indirect state pointers
abb852252bfa drm/i915/gen12: Flush AMFS
8411dc590177 drm/i915/gen12: Flush L3
868476e157a0 drm/i915/gen12: Add L3 fabric flush
7e235ad6db72 drm/i915/gen12: Fix HDC pipeline flush
53177bdb8662 Revert "drm/i915/tgl: Include ro parts of l3 to invalidate"
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17529/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] Revert "drm/i915/tgl: Include ro parts of l3 to invalidate"
Quoting Patchwork (2020-04-30 17:25:55) > == Series Details == > > Series: series starting with [1/9] Revert "drm/i915/tgl: Include ro parts of > l3 to invalidate" > URL : https://patchwork.freedesktop.org/series/76777/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_8401 -> Patchwork_17529 > > > Summary > --- > > **SUCCESS** Coherency/pipecontrol are the worst. How do we design tests to even detect and probe for unknown missed flushes? I wonder if there are some debug [context] registers that can tell us the status of all caches? Set to nonzero for a dirty cache, and we're allowed to set, but is then cleared by pipecontrol. Seems worth asking. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/9] drm/i915/gt: Move the batch buffer pool from the engine to the gt
On 30/04/2020 12:18, Chris Wilson wrote:
Since the introduction of 'soft-rc6', we aim to park the device quickly
and that results in frequent idling of the whole device. Currently upon
idling we free the batch buffer pool, and so this renders the cache
ineffective for many workloads. If we want to have an effective cache of
recently allocated buffers available for reuse, we need to decouple that
cache from the engine powermanagement and make it timer based. As there
is no reason then to keep it within the engine (where it once made
retirement order easier to track), we can move it up the hierarchy to the
owner of the memory allocations.
v2: Hook up to debugfs/drop_caches to clear the cache on demand.
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 2 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 1 -
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 20 +--
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 18 +--
.../gpu/drm/i915/gem/i915_gem_object_blt.h| 1 -
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 -
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 -
drivers/gpu/drm/i915/gt/intel_engine_pool.h | 34 --
drivers/gpu/drm/i915/gt/intel_engine_types.h | 8 --
drivers/gpu/drm/i915/gt/intel_gt.c| 3 +
...l_engine_pool.c => intel_gt_buffer_pool.c} | 114 --
.../gpu/drm/i915/gt/intel_gt_buffer_pool.h| 37 ++
...l_types.h => intel_gt_buffer_pool_types.h} | 15 ++-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 11 ++
drivers/gpu/drm/i915/gt/mock_engine.c | 2 -
drivers/gpu/drm/i915/i915_debugfs.c | 4 +
16 files changed, 160 insertions(+), 116 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/gt/intel_engine_pool.h
rename drivers/gpu/drm/i915/gt/{intel_engine_pool.c =>
intel_gt_buffer_pool.c} (53%)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.h
rename drivers/gpu/drm/i915/gt/{intel_engine_pool_types.h =>
intel_gt_buffer_pool_types.h} (54%)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index caf00d92ea9d..5359c736c789 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -87,11 +87,11 @@ gt-y += \
gt/intel_engine_cs.o \
gt/intel_engine_heartbeat.o \
gt/intel_engine_pm.o \
- gt/intel_engine_pool.o \
gt/intel_engine_user.o \
gt/intel_ggtt.o \
gt/intel_ggtt_fencing.o \
gt/intel_gt.o \
+ gt/intel_gt_buffer_pool.o \
gt/intel_gt_clock_utils.o \
gt/intel_gt_irq.o \
gt/intel_gt_pm.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 0598e5382a1d..3a146aa2593b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -6,7 +6,6 @@
#include "i915_drv.h"
#include "gt/intel_context.h"
#include "gt/intel_engine_pm.h"
-#include "gt/intel_engine_pool.h"
#include "i915_gem_client_blt.h"
#include "i915_gem_object_blt.h"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 964f73f062c1..414859fa2673 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -15,8 +15,8 @@
#include "gem/i915_gem_ioctls.h"
#include "gt/intel_context.h"
-#include "gt/intel_engine_pool.h"
#include "gt/intel_gt.h"
+#include "gt/intel_gt_buffer_pool.h"
#include "gt/intel_gt_pm.h"
#include "gt/intel_ring.h"
@@ -1194,13 +1194,13 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
unsigned int len)
{
struct reloc_cache *cache = &eb->reloc_cache;
- struct intel_engine_pool_node *pool;
+ struct intel_gt_buffer_pool_node *pool;
struct i915_request *rq;
struct i915_vma *batch;
u32 *cmd;
int err;
- pool = intel_engine_get_pool(eb->engine, PAGE_SIZE);
+ pool = intel_gt_get_buffer_pool(eb->engine->gt, PAGE_SIZE);
if (IS_ERR(pool))
return PTR_ERR(pool);
@@ -1229,7 +1229,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
goto err_unpin;
}
- err = intel_engine_pool_mark_active(pool, rq);
+ err = intel_gt_buffer_pool_mark_active(pool, rq);
if (err)
goto err_request;
@@ -1270,7 +1270,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
err_unmap:
i915_gem_object_unpin_map(pool->obj);
out_pool:
- intel_engine_pool_put(pool);
+ intel_gt_buffer_pool_put(pool);
return err;
}
@@ -1887,7 +1887,7 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
static int eb_parse(struct i915_execbuffer *eb)
{
struct drm_i915_private *i915 = eb->i915;
- struct intel_engine
[Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Attempt to unload i915 while the PMU is active
If the PMU is active, it will be utilising the driver internals for its
sampling. Therefore we must not remove the driver while PMU is still
awake! Hence try to unload the module while the pmu is open.
Signed-off-by: Chris Wilson
---
tests/perf_pmu.c | 96 +++-
1 file changed, 94 insertions(+), 2 deletions(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index b9ca6a493..cc475a090 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -39,6 +40,8 @@
#include "igt.h"
#include "igt_core.h"
+#include "igt_device.h"
+#include "igt_kmod.h"
#include "igt_perf.h"
#include "igt_sysfs.h"
#include "igt_pm.h"
@@ -930,6 +933,7 @@ event_wait(int gem_fd, const struct intel_execution_engine2
*e)
igt_require(has_secure_batches(fd));
igt_skip_on(IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid));
+ igt_device_set_master(gem_fd);
kmstest_set_vt_graphics_mode();
igt_display_require(&data.display, gem_fd);
@@ -1860,6 +1864,85 @@ static void faulting_read(int gem_fd, const struct
mmap_offset *t)
munmap(ptr, 4096);
}
+static int unload_i915(void)
+{
+ /* unbind vt */
+ bind_fbcon(false);
+
+ if (igt_kmod_is_loaded("snd_hda_intel")) {
+ igt_terminate_process(SIGTERM, "alsactl");
+
+ /* unbind snd_hda_intel */
+ kick_snd_hda_intel();
+
+ if (igt_kmod_unload("snd_hda_intel", 0)) {
+ igt_info("Failed to unload snd_hda_intel\n");
+ return -EBUSY;
+ }
+ }
+
+ if (igt_kmod_is_loaded("snd_hdmi_lpe_audio")) {
+ igt_terminate_process(SIGTERM, "alsactl");
+
+ if (igt_kmod_unload("snd_hdmi_lpe_audio", 0)) {
+ igt_info("Failed to unload snd_hmdi_lpe_audio\n");
+ return -EBUSY;
+ }
+ }
+
+ if (igt_kmod_is_loaded("i915")) {
+ if (igt_kmod_unload("i915", 0)) {
+ igt_info("Failed to unload i915\n");
+ return -EBUSY;
+ }
+ }
+
+ return 0;
+}
+
+static void test_unload(void)
+{
+ const struct intel_execution_engine2 *e;
+ uint64_t *buf;
+ int count;
+ int i915;
+ int fd;
+
+ igt_require(unload_i915() == 0);
+ i915 = __drm_open_driver(DRIVER_INTEL);
+
+ fd = open_group(i915, I915_PMU_REQUESTED_FREQUENCY, -1);
+ open_group(fd, I915_PMU_ACTUAL_FREQUENCY, fd);
+ count = 2;
+
+ __for_each_physical_engine(i915, e) {
+ open_group(i915,
+ I915_PMU_ENGINE_BUSY(e->class, e->instance),
+ fd);
+ open_group(i915,
+ I915_PMU_ENGINE_SEMA(e->class, e->instance),
+ fd);
+ open_group(i915,
+ I915_PMU_ENGINE_WAIT(e->class, e->instance),
+ fd);
+ count += 3;
+ }
+
+ close(i915);
+
+ buf = calloc(count + 1, sizeof(uint64_t));
+ igt_assert(buf);
+
+ pmu_read_multi(fd, count, buf);
+ igt_assert_eq(unload_i915(), -EBUSY);
+ pmu_read_multi(fd, count, buf);
+
+ close(fd);
+ igt_assert_eq(unload_i915(), 0);
+
+ free(buf);
+}
+
#define test_each_engine(T, i915, e) \
igt_subtest_with_dynamic(T) __for_each_physical_engine(i915, e) \
igt_dynamic_f("%s", e->name)
@@ -1878,7 +1961,7 @@ igt_main
int fd = -1;
igt_fixture {
- fd = drm_open_driver_master(DRIVER_INTEL);
+ fd = __drm_open_driver(DRIVER_INTEL);
igt_require_gem(fd);
igt_require(i915_perf_type_id(fd) > 0);
@@ -2101,7 +2184,7 @@ igt_main
int render_fd = -1;
igt_fixture {
- render_fd = drm_open_driver_render(DRIVER_INTEL);
+ render_fd = __drm_open_driver_render(DRIVER_INTEL);
igt_require_gem(render_fd);
gem_quiescent_gpu(fd);
@@ -2116,4 +2199,13 @@ igt_main
close(render_fd);
}
}
+
+ igt_fixture {
+ close(fd);
+ }
+
+ igt_subtest("module-unload") {
+ for (int pass = 0; pass < 3; pass++)
+ test_unload();
+ }
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Attempt to unload i915 while the PMU is active
If the PMU is active, it will be utilising the driver internals for its
sampling. Therefore we must not remove the driver while PMU is still
awake! Hence try to unload the module while the pmu is open.
Signed-off-by: Chris Wilson
---
tests/perf_pmu.c | 96 +++-
1 file changed, 94 insertions(+), 2 deletions(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index b9ca6a493..e08c5635a 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -39,6 +40,8 @@
#include "igt.h"
#include "igt_core.h"
+#include "igt_device.h"
+#include "igt_kmod.h"
#include "igt_perf.h"
#include "igt_sysfs.h"
#include "igt_pm.h"
@@ -930,6 +933,7 @@ event_wait(int gem_fd, const struct intel_execution_engine2
*e)
igt_require(has_secure_batches(fd));
igt_skip_on(IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid));
+ igt_device_set_master(gem_fd);
kmstest_set_vt_graphics_mode();
igt_display_require(&data.display, gem_fd);
@@ -1860,6 +1864,85 @@ static void faulting_read(int gem_fd, const struct
mmap_offset *t)
munmap(ptr, 4096);
}
+static int unload_i915(void)
+{
+ bind_fbcon(false);
+
+ if (igt_kmod_is_loaded("snd_hda_intel")) {
+ igt_terminate_process(SIGTERM, "alsactl");
+ kick_snd_hda_intel();
+ if (igt_kmod_unload("snd_hda_intel", 0))
+ return -EAGAIN;
+ }
+
+ if (igt_kmod_is_loaded("snd_hdmi_lpe_audio")) {
+ igt_terminate_process(SIGTERM, "alsactl");
+ if (igt_kmod_unload("snd_hdmi_lpe_audio", 0))
+ return -EAGAIN;
+ }
+
+ if (igt_kmod_is_loaded("i915")) {
+ if (igt_kmod_unload("i915", 0))
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+static void test_unload(void)
+{
+ igt_fork(child, 1) {
+ const struct intel_execution_engine2 *e;
+ uint64_t *buf;
+ int count;
+ int i915;
+ int fd;
+
+ igt_debug("Unloading and then re-opening i915 device\n");
+ igt_require(unload_i915() == 0);
+ i915 = __drm_open_driver(DRIVER_INTEL);
+
+ igt_debug("Opening perf events\n");
+ fd = open_group(i915, I915_PMU_REQUESTED_FREQUENCY, -1);
+ open_group(fd, I915_PMU_ACTUAL_FREQUENCY, fd);
+ count = 2;
+
+ __for_each_physical_engine(i915, e) {
+ open_group(i915,
+ I915_PMU_ENGINE_BUSY(e->class,
e->instance),
+ fd);
+ open_group(i915,
+ I915_PMU_ENGINE_SEMA(e->class,
e->instance),
+ fd);
+ open_group(i915,
+ I915_PMU_ENGINE_WAIT(e->class,
e->instance),
+ fd);
+ count += 3;
+ }
+
+ close(i915);
+
+ buf = calloc(count + 1, sizeof(uint64_t));
+ igt_assert(buf);
+
+ igt_debug("Read %d events from perf and trial unload\n", count);
+ pmu_read_multi(fd, count, buf);
+ igt_assert_eq(unload_i915(), -EBUSY);
+ pmu_read_multi(fd, count, buf);
+ sleep(2);
+
+ igt_debug("Close perf\n");
+ close(fd);
+
+ free(buf);
+ }
+ igt_waitchildren();
+
+ igt_debug("Final unload\n");
+ sleep(5);
+ igt_assert_eq(unload_i915(), 0);
+}
+
#define test_each_engine(T, i915, e) \
igt_subtest_with_dynamic(T) __for_each_physical_engine(i915, e) \
igt_dynamic_f("%s", e->name)
@@ -1878,7 +1961,7 @@ igt_main
int fd = -1;
igt_fixture {
- fd = drm_open_driver_master(DRIVER_INTEL);
+ fd = __drm_open_driver(DRIVER_INTEL);
igt_require_gem(fd);
igt_require(i915_perf_type_id(fd) > 0);
@@ -2101,7 +2184,7 @@ igt_main
int render_fd = -1;
igt_fixture {
- render_fd = drm_open_driver_render(DRIVER_INTEL);
+ render_fd = __drm_open_driver_render(DRIVER_INTEL);
igt_require_gem(render_fd);
gem_quiescent_gpu(fd);
@@ -2116,4 +2199,13 @@ igt_main
close(render_fd);
}
}
+
+ igt_fixture {
+ close(fd);
+ }
+
+ igt_subtest("module-unload") {
+ for (int pass = 0; pass < 3; pass++)
+ test_unload();
+ }
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx
Re: [Intel-gfx] [PATCH] drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers
On Thu, Apr 30, 2020 at 5:38 PM Sean Paul wrote:
>
> On Wed, Apr 29, 2020 at 4:57 AM Jani Nikula
> wrote:
> >
> > On Tue, 28 Apr 2020, Michal Orzel wrote:
> > > As suggested by the TODO list for the kernel DRM subsystem, replace
> > > the deprecated functions that take/drop modeset locks with new helpers.
> > >
> > > Signed-off-by: Michal Orzel
> > > ---
> > > drivers/gpu/drm/drm_mode_object.c | 10 ++
> > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > > b/drivers/gpu/drm/drm_mode_object.c
> > > index 35c2719..901b078 100644
> > > --- a/drivers/gpu/drm/drm_mode_object.c
> > > +++ b/drivers/gpu/drm/drm_mode_object.c
> > > @@ -402,12 +402,13 @@ int drm_mode_obj_get_properties_ioctl(struct
> > > drm_device *dev, void *data,
> > > {
> > > struct drm_mode_obj_get_properties *arg = data;
> > > struct drm_mode_object *obj;
> > > + struct drm_modeset_acquire_ctx ctx;
> > > int ret = 0;
> > >
> > > if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > > return -EOPNOTSUPP;
> > >
> > > - drm_modeset_lock_all(dev);
> > > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
> >
> > I cry a little every time I look at the DRM_MODESET_LOCK_ALL_BEGIN and
> > DRM_MODESET_LOCK_ALL_END macros. :(
> >
> > Currently only six users... but there are ~60 calls to
> > drm_modeset_lock_all{,_ctx} that I presume are to be replaced. I wonder
> > if this will come back and haunt us.
> >
>
> What's the alternative? Seems like the options without the macros is
> to use incorrect scope or have a bunch of retry/backoff cargo-cult
> everywhere (and hope the copy source is done correctly).
Yeah Sean & me had a bunch of bikesheds and this is the least worst
option we could come up with. You can't make it a function because of
the control flow. You don't want to open code this because it's tricky
to get right, if all you want is to just grab all locks. But it is
magic hidden behind a macro, which occasionally ends up hurting.
-Daniel
> Sean
>
> > BR,
> > Jani.
> >
> >
> > >
> > > obj = drm_mode_object_find(dev, file_priv, arg->obj_id,
> > > arg->obj_type);
> > > if (!obj) {
> > > @@ -427,7 +428,7 @@ int drm_mode_obj_get_properties_ioctl(struct
> > > drm_device *dev, void *data,
> > > out_unref:
> > > drm_mode_object_put(obj);
> > > out:
> > > - drm_modeset_unlock_all(dev);
> > > + DRM_MODESET_LOCK_ALL_END(ctx, ret);
> > > return ret;
> > > }
> > >
> > > @@ -449,12 +450,13 @@ static int set_property_legacy(struct
> > > drm_mode_object *obj,
> > > {
> > > struct drm_device *dev = prop->dev;
> > > struct drm_mode_object *ref;
> > > + struct drm_modeset_acquire_ctx ctx;
> > > int ret = -EINVAL;
> > >
> > > if (!drm_property_change_valid_get(prop, prop_value, &ref))
> > > return -EINVAL;
> > >
> > > - drm_modeset_lock_all(dev);
> > > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
> > > switch (obj->type) {
> > > case DRM_MODE_OBJECT_CONNECTOR:
> > > ret = drm_connector_set_obj_prop(obj, prop, prop_value);
> > > @@ -468,7 +470,7 @@ static int set_property_legacy(struct drm_mode_object
> > > *obj,
> > > break;
> > > }
> > > drm_property_change_valid_put(prop, ref);
> > > - drm_modeset_unlock_all(dev);
> > > + DRM_MODESET_LOCK_ALL_END(ctx, ret);
> > >
> > > return ret;
> > > }
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Attempt to unload i915 while the PMU is active
Quoting Chris Wilson (2020-04-30 19:28:59)
> +static void test_unload(void)
> +{
> + igt_fork(child, 1) {
...
> + igt_debug("Read %d events from perf and trial unload\n",
> count);
> + pmu_read_multi(fd, count, buf);
> + igt_assert_eq(unload_i915(), -EBUSY);
> + pmu_read_multi(fd, count, buf);
> + sleep(2);
> +
> + igt_debug("Close perf\n");
> + close(fd);
> +
> + free(buf);
> + }
> + igt_waitchildren();
> +
> + igt_debug("Final unload\n");
> + sleep(5);
> + igt_assert_eq(unload_i915(), 0);
The sleeps are not required, the child process is enough to kick the
perf_event_destroy.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/pmu: Keep a reference to module while active
While a perf event is open, keep a reference to the module so we don't
remove the driver internals mid-sampling.
Testcase: igt/perf_pmu/module-unload
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_pmu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 83c6a8ccd2cb..e991a707bdb7 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -442,6 +442,7 @@ static u64 count_interrupts(struct drm_i915_private *i915)
static void i915_pmu_event_destroy(struct perf_event *event)
{
WARN_ON(event->parent);
+ module_put(THIS_MODULE);
}
static int
@@ -533,8 +534,10 @@ static int i915_pmu_event_init(struct perf_event *event)
if (ret)
return ret;
- if (!event->parent)
+ if (!event->parent) {
+ __module_get(THIS_MODULE);
event->destroy = i915_pmu_event_destroy;
+ }
return 0;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v26 2/9] drm/i915: Use bw state for per crtc SAGV evaluation
Future platforms require per-crtc SAGV evaluation
and serializing global state when those are changed
from different commits.
v2: - Add has_sagv check to intel_crtc_can_enable_sagv
so that it sets bit in reject mask.
- Use bw_state in intel_pre/post_plane_enable_sagv
instead of atomic state
v3: - Fixed rebase conflict, now using
intel_atomic_crtc_state_for_each_plane_state in
order to call it from atomic check
v4: - Use fb modifier from plane state
v5: - Make intel_has_sagv static again(Ville)
- Removed unnecessary NULL assignments(Ville)
- Removed unnecessary SAGV debug(Ville)
- Call intel_compute_sagv_mask only for modesets(Ville)
- Serialize global state only if sagv results change, but
not mask itself(Ville)
v6: - use lock global state instead of serialize(Ville)
v7: - use both global state lock and serialize depending on
if we need to change only global state or access hw
(Ville)
Signed-off-by: Stanislav Lisovskiy
Cc: Ville Syrjälä
Cc: James Ausmus
---
drivers/gpu/drm/i915/display/intel_bw.h | 6 ++
drivers/gpu/drm/i915/intel_pm.c | 117 ++--
drivers/gpu/drm/i915/intel_pm.h | 3 +-
3 files changed, 97 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
b/drivers/gpu/drm/i915/display/intel_bw.h
index ac004d6f4276..d6df91058223 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -18,6 +18,12 @@ struct intel_crtc_state;
struct intel_bw_state {
struct intel_global_state base;
+ /*
+* Contains a bit mask, used to determine, whether correspondent
+* pipe allows SAGV or not.
+*/
+ u8 pipe_sagv_reject;
+
unsigned int data_rate[I915_MAX_PIPES];
u8 num_active_planes[I915_MAX_PIPES];
};
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 338a82577b76..8d458cf0333d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -43,6 +43,7 @@
#include "i915_fixed.h"
#include "i915_irq.h"
#include "i915_trace.h"
+#include "display/intel_bw.h"
#include "intel_pm.h"
#include "intel_sideband.h"
#include "../../../platform/x86/intel_ips.h"
@@ -3760,34 +3761,75 @@ intel_disable_sagv(struct drm_i915_private *dev_priv)
void intel_sagv_pre_plane_update(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ const struct intel_bw_state *new_bw_state;
- if (!intel_can_enable_sagv(state))
+ /*
+* Just return if we can't control SAGV or don't have it.
+* This is different from situation when we have SAGV but just can't
+* afford it due to DBuf limitation - in case if SAGV is completely
+* disabled in a BIOS, we are not even allowed to send a PCode request,
+* as it will throw an error. So have to check it here.
+*/
+ if (!intel_has_sagv(dev_priv))
+ return;
+
+ new_bw_state = intel_atomic_get_new_bw_state(state);
+ if (!new_bw_state)
+ return;
+
+ if (!intel_can_enable_sagv(new_bw_state))
intel_disable_sagv(dev_priv);
}
void intel_sagv_post_plane_update(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ const struct intel_bw_state *new_bw_state;
+
+ /*
+* Just return if we can't control SAGV or don't have it.
+* This is different from situation when we have SAGV but just can't
+* afford it due to DBuf limitation - in case if SAGV is completely
+* disabled in a BIOS, we are not even allowed to send a PCode request,
+* as it will throw an error. So have to check it here.
+*/
+ if (!intel_has_sagv(dev_priv))
+ return;
- if (intel_can_enable_sagv(state))
+ new_bw_state = intel_atomic_get_new_bw_state(state);
+ if (!new_bw_state)
+ return;
+
+ if (intel_can_enable_sagv(new_bw_state))
intel_enable_sagv(dev_priv);
}
static bool intel_crtc_can_enable_sagv(const struct intel_crtc_state
*crtc_state)
{
- struct drm_device *dev = crtc_state->uapi.crtc->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_atomic_state *state =
to_intel_atomic_state(crtc_state->uapi.state);
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_plane *plane;
+ const struct intel_plane_state *plane_state;
int level, latency;
+ if (!intel_has_sagv(dev_priv))
+ return false;
+
if (!crtc_state->hw.active)
return true;
+ /*
+* SKL+ workaround: bspec recommends we disable SAGV when we have
+* more then one pipe enabled
+*/
+
[Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
We need to calculate SAGV mask also in a non-modeset
commit, however currently active_pipes are only calculated
for modesets in global atomic state, thus now we will be
tracking those also in bw_state in order to be able to
properly access global data.
v2: - Removed pre/post plane SAGV updates from modeset(Ville)
- Now tracking active pipes in intel_can_enable_sagv(Ville)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_bw.h | 3 +++
drivers/gpu/drm/i915/display/intel_display.c | 9
drivers/gpu/drm/i915/intel_pm.c | 22
3 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
b/drivers/gpu/drm/i915/display/intel_bw.h
index d6df91058223..898b4a85ccab 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -26,6 +26,9 @@ struct intel_bw_state {
unsigned int data_rate[I915_MAX_PIPES];
u8 num_active_planes[I915_MAX_PIPES];
+
+ /* bitmask of active pipes */
+ u8 active_pipes;
};
#define to_intel_bw_state(x) container_of((x), struct intel_bw_state, base)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index adb08a00bb57..136826edaf49 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15365,11 +15365,11 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_set_cdclk_pre_plane_update(state);
- intel_sagv_pre_plane_update(state);
-
intel_modeset_verify_disabled(dev_priv, state);
}
+ intel_sagv_pre_plane_update(state);
+
/* Complete the events for pipes that have now been disabled */
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
bool modeset = needs_modeset(new_crtc_state);
@@ -15462,11 +15462,10 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_check_cpu_fifo_underruns(dev_priv);
intel_check_pch_fifo_underruns(dev_priv);
- if (state->modeset) {
+ if (state->modeset)
intel_verify_planes(state);
- intel_sagv_post_plane_update(state);
- }
+ intel_sagv_post_plane_update(state);
drm_atomic_helper_commit_hw_done(&state->base);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8d458cf0333d..14689a2efb20 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3806,7 +3806,6 @@ void intel_sagv_post_plane_update(struct
intel_atomic_state *state)
static bool intel_crtc_can_enable_sagv(const struct intel_crtc_state
*crtc_state)
{
- struct intel_atomic_state *state =
to_intel_atomic_state(crtc_state->uapi.state);
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_plane *plane;
@@ -3819,13 +3818,6 @@ static bool intel_crtc_can_enable_sagv(const struct
intel_crtc_state *crtc_state
if (!crtc_state->hw.active)
return true;
- /*
-* SKL+ workaround: bspec recommends we disable SAGV when we have
-* more then one pipe enabled
-*/
- if (hweight8(state->active_pipes) > 1)
- return false;
-
if (crtc_state->hw.adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE)
return false;
@@ -3863,6 +3855,9 @@ static bool intel_crtc_can_enable_sagv(const struct
intel_crtc_state *crtc_state
bool intel_can_enable_sagv(const struct intel_bw_state *bw_state)
{
+ if (bw_state->active_pipes && !is_power_of_2(bw_state->active_pipes))
+ return false;
+
return bw_state->pipe_sagv_reject == 0;
}
@@ -3892,6 +3887,9 @@ static int intel_compute_sagv_mask(struct
intel_atomic_state *state)
if (!new_bw_state)
return 0;
+ new_bw_state->active_pipes =
+ intel_calc_active_pipes(state, old_bw_state->active_pipes);
+
if (intel_can_enable_sagv(new_bw_state) !=
intel_can_enable_sagv(old_bw_state)) {
ret = intel_atomic_serialize_global_state(&new_bw_state->base);
if (ret)
@@ -5915,11 +5913,9 @@ skl_compute_wm(struct intel_atomic_state *state)
if (ret)
return ret;
- if (state->modeset) {
- ret = intel_compute_sagv_mask(state);
- if (ret)
- return ret;
- }
+ ret = intel_compute_sagv_mask(state);
+ if (ret)
+ return ret;
/*
* skl_compute_ddb() will have adjusted the final watermarks
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/inte
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Keep a reference to module while active
== Series Details == Series: drm/i915/pmu: Keep a reference to module while active URL : https://patchwork.freedesktop.org/series/76779/ State : success == Summary == CI Bug Log - changes from CI_DRM_8402 -> Patchwork_17530 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17530/index.html Known issues Here are the changes found in Patchwork_17530 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_pm: - fi-bwr-2160:[PASS][1] -> [INCOMPLETE][2] ([i915#489]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8402/fi-bwr-2160/igt@i915_selftest@live@gt_pm.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17530/fi-bwr-2160/igt@i915_selftest@live@gt_pm.html Possible fixes * igt@kms_chamelium@dp-edid-read: - fi-cml-u2: [FAIL][3] ([i915#976]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8402/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17530/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][5] ([fdo#109271]) -> [FAIL][6] ([i915#62]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8402/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17530/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976 Participating hosts (51 -> 44) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8402 -> Patchwork_17530 CI-20190529: 20190529 CI_DRM_8402: b34c04ed51b63716e7491db86c83aab4e095 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5618: 9a94fb4b5ebb82185fb52a1709366458597a62ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17530: 18e8c538bd2efa06a6622a012dd2eb86d823c2a5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 18e8c538bd2e drm/i915/pmu: Keep a reference to module while active == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17530/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Implement vm_ops->access for gdb access into mmaps
gdb uses ptrace() to peek and poke bytes of the target's address space.
The driver must implement an vm_ops->access() handler or else gdb will
be unable to inspect the pointer and report it as out-of-bounds.
Worse than useless as it causes immediate suspicion of the valid GTT
pointer, distracting the poor programmer trying to find his bug.
Testcase: igt/gem_mmap_gtt/ptrace
Testcase: igt/gem_mmap_offset/ptrace
Suggested-by: Kristian H. Kristensen
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Joonas Lahtinen
Cc: Maciej Patelczyk
Cc: Kristian H. Kristensen
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 31
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..aef917b7f168 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -396,6 +396,35 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
return i915_error_to_vmf_fault(ret);
}
+static int
+vm_access(struct vm_area_struct *area, unsigned long addr,
+ void *buf, int len, int write)
+{
+ struct i915_mmap_offset *mmo = area->vm_private_data;
+ struct drm_i915_gem_object *obj = mmo->obj;
+ void *vaddr;
+
+ addr -= area->vm_start;
+ if (addr >= obj->base.size)
+ return -EINVAL;
+
+ /* As this is primarily for debugging, let's focus on simplicity */
+ vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
+ if (IS_ERR(vaddr))
+ return PTR_ERR(vaddr);
+
+ if (write) {
+ memcpy(vaddr + addr, buf, len);
+ __i915_gem_object_flush_map(obj, addr, len);
+ } else {
+ memcpy(buf, vaddr + addr, len);
+ }
+
+ i915_gem_object_unpin_map(obj);
+
+ return len;
+}
+
void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
{
struct i915_vma *vma;
@@ -745,12 +774,14 @@ static void vm_close(struct vm_area_struct *vma)
static const struct vm_operations_struct vm_ops_gtt = {
.fault = vm_fault_gtt,
+ .access = vm_access,
.open = vm_open,
.close = vm_close,
};
static const struct vm_operations_struct vm_ops_cpu = {
.fault = vm_fault_cpu,
+ .access = vm_access,
.open = vm_open,
.close = vm_close,
};
--
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] i915/gem_mmap_gtt: Simulate gdb inspecting a GTT mmap using ptrace()
gdb uses ptrace() to peek and poke bytes of the target's address space.
The kernel must implement an vm_ops->access() handler or else gdb will
be unable to inspect the pointer and report it as out-of-bounds. Worse
than useless as it causes immediate suspicion of the valid GTT pointer.
Signed-off-by: Chris Wilson
---
tests/i915/gem_mmap_gtt.c | 79 ++-
1 file changed, 78 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
index 1f4655af4..38b4d02d7 100644
--- a/tests/i915/gem_mmap_gtt.c
+++ b/tests/i915/gem_mmap_gtt.c
@@ -34,8 +34,11 @@
#include
#include
#include
-#include
+#include
#include
+#include
+#include
+#include
#include "drm.h"
#include "igt.h"
@@ -501,6 +504,78 @@ test_write_gtt(int fd)
munmap(src, OBJECT_SIZE);
}
+static void *memchr_inv(const void *s, int c, size_t n)
+{
+ const uint8_t *us = s;
+ const uint8_t uc = c;
+
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wcast-qual"
+ while (n--) {
+ if (*us != uc)
+ return (void *) us;
+ us++;
+ }
+#pragma GCC diagnostic pop
+
+ return NULL;
+}
+
+static void
+test_ptrace(int fd)
+{
+ unsigned long AA, CC;
+ unsigned long *gtt, *cpy;
+ uint32_t bo;
+ pid_t pid;
+
+ memset(&AA, 0xaa, sizeof(AA));
+ memset(&CC, 0x55, sizeof(CC));
+
+ cpy = malloc(OBJECT_SIZE);
+ memset(cpy, AA, OBJECT_SIZE);
+
+ bo = gem_create(fd, OBJECT_SIZE);
+ gtt = mmap_bo(fd, bo, OBJECT_SIZE);
+ memset(gtt, CC, OBJECT_SIZE);
+ gem_close(fd, bo);
+
+ igt_assert(!memchr_inv(gtt, CC, OBJECT_SIZE));
+ igt_assert(!memchr_inv(cpy, AA, OBJECT_SIZE));
+
+ igt_fork(child, 1) {
+ ptrace(PTRACE_TRACEME, 0, NULL, NULL);
+ raise(SIGSTOP);
+ }
+
+ /* Wait for the child to ready themselves [SIGSTOP] */
+ pid = wait(NULL);
+
+ ptrace(PTRACE_ATTACH, pid, NULL, NULL);
+ for (int i = 0; i < OBJECT_SIZE / sizeof(long); i++) {
+ long ret;
+
+ ret = ptrace(PTRACE_PEEKDATA, pid, gtt + i);
+ igt_assert_eq_u64(ret, CC);
+ cpy[i] = ret;
+
+ ret = ptrace(PTRACE_POKEDATA, pid, gtt + i, AA);
+ igt_assert_eq(ret, 0l);
+ }
+ ptrace(PTRACE_DETACH, pid, NULL, NULL);
+
+ /* Wakeup the child for it to exit */
+ kill(SIGCONT, pid);
+ igt_waitchildren();
+
+ /* The contents of the two buffers should now be swapped */
+ igt_assert(!memchr_inv(gtt, AA, OBJECT_SIZE));
+ igt_assert(!memchr_inv(cpy, CC, OBJECT_SIZE));
+
+ munmap(gtt, OBJECT_SIZE);
+ free(cpy);
+}
+
static bool is_coherent(int i915)
{
int val = 1; /* by default, we assume GTT is coherent, hence the test */
@@ -1084,6 +1159,8 @@ igt_main
test_write(fd);
igt_subtest("basic-write-gtt")
test_write_gtt(fd);
+ igt_subtest("ptrace")
+ test_ptrace(fd);
igt_subtest("coherency")
test_coherency(fd);
igt_subtest("clflush")
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt/gem_mmap_offset: Simulate gdb inspecting any mmap using ptrace()
gdb uses ptrace() to peek and poke bytes of the target's address space.
The kernel must implement an vm_ops->access() handler or else gdb will
be unable to inspect the pointer and report it as out-of-bounds. Worse
than useless as it causes immediate suspicion of the valid GPU pointer.
Signed-off-by: Chris Wilson
---
tests/i915/gem_mmap_offset.c | 91 +++-
1 file changed, 90 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_mmap_offset.c b/tests/i915/gem_mmap_offset.c
index 1ec963b25..c10cf606f 100644
--- a/tests/i915/gem_mmap_offset.c
+++ b/tests/i915/gem_mmap_offset.c
@@ -23,9 +23,12 @@
#include
#include
+#include
#include
-#include
#include
+#include
+#include
+#include
#include "drm.h"
#include "igt.h"
@@ -265,6 +268,89 @@ static void pf_nonblock(int i915)
igt_spin_free(i915, spin);
}
+static void *memchr_inv(const void *s, int c, size_t n)
+{
+ const uint8_t *us = s;
+ const uint8_t uc = c;
+
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wcast-qual"
+ while (n--) {
+ if (*us != uc)
+ return (void *) us;
+ us++;
+ }
+#pragma GCC diagnostic pop
+
+ return NULL;
+}
+
+static void test_ptrace(int i915)
+{
+ const unsigned int SZ = 3 * 4096;
+ unsigned long *ptr, *cpy;
+ unsigned long AA, CC;
+ uint32_t bo;
+
+ memset(&AA, 0xaa, sizeof(AA));
+ memset(&CC, 0x55, sizeof(CC));
+
+ cpy = malloc(SZ);
+ bo = gem_create(i915, SZ);
+
+ for_each_mmap_offset_type(i915, t) {
+ igt_dynamic_f("%s", t->name) {
+ pid_t pid;
+
+ ptr = __mmap_offset(i915, bo, 0, SZ,
+ PROT_READ | PROT_WRITE,
+ t->type);
+ if (!ptr)
+ continue;
+
+ memset(cpy, AA, SZ);
+ memset(ptr, CC, SZ);
+
+ igt_assert(!memchr_inv(ptr, CC, SZ));
+ igt_assert(!memchr_inv(cpy, AA, SZ));
+
+ igt_fork(child, 1) {
+ ptrace(PTRACE_TRACEME, 0, NULL, NULL);
+ raise(SIGSTOP);
+ }
+
+ /* Wait for the child to ready themselves [SIGSTOP] */
+ pid = wait(NULL);
+
+ ptrace(PTRACE_ATTACH, pid, NULL, NULL);
+ for (int i = 0; i < SZ / sizeof(long); i++) {
+ long ret;
+
+ ret = ptrace(PTRACE_PEEKDATA, pid, ptr + i);
+ igt_assert_eq_u64(ret, CC);
+ cpy[i] = ret;
+
+ ret = ptrace(PTRACE_POKEDATA, pid, ptr + i, AA);
+ igt_assert_eq(ret, 0l);
+ }
+ ptrace(PTRACE_DETACH, pid, NULL, NULL);
+
+ /* Wakeup the child for it to exit */
+ kill(SIGCONT, pid);
+ igt_waitchildren();
+
+ /* The two buffers should now be swapped */
+ igt_assert(!memchr_inv(ptr, AA, SZ));
+ igt_assert(!memchr_inv(cpy, CC, SZ));
+
+ munmap(ptr, SZ);
+ }
+ }
+
+ gem_close(i915, bo);
+ free(cpy);
+}
+
static void close_race(int i915, int timeout)
{
const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
@@ -530,6 +616,9 @@ igt_main
igt_subtest_f("pf-nonblock")
pf_nonblock(i915);
+ igt_subtest_with_dynamic("ptrace")
+ test_ptrace(i915);
+
igt_describe("Check race between close and mmap offset between
threads");
igt_subtest_f("close-race")
close_race(i915, 20);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
We need to calculate SAGV mask also in a non-modeset
commit, however currently active_pipes are only calculated
for modesets in global atomic state, thus now we will be
tracking those also in bw_state in order to be able to
properly access global data.
v2: - Removed pre/post plane SAGV updates from modeset(Ville)
- Now tracking active pipes in intel_can_enable_sagv(Ville)
v3: - lock global state if active_pipes change as well(Ville)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_bw.h | 3 +++
drivers/gpu/drm/i915/display/intel_display.c | 9 +++
drivers/gpu/drm/i915/intel_pm.c | 27 ++--
3 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
b/drivers/gpu/drm/i915/display/intel_bw.h
index d6df91058223..898b4a85ccab 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -26,6 +26,9 @@ struct intel_bw_state {
unsigned int data_rate[I915_MAX_PIPES];
u8 num_active_planes[I915_MAX_PIPES];
+
+ /* bitmask of active pipes */
+ u8 active_pipes;
};
#define to_intel_bw_state(x) container_of((x), struct intel_bw_state, base)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index adb08a00bb57..136826edaf49 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15365,11 +15365,11 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_set_cdclk_pre_plane_update(state);
- intel_sagv_pre_plane_update(state);
-
intel_modeset_verify_disabled(dev_priv, state);
}
+ intel_sagv_pre_plane_update(state);
+
/* Complete the events for pipes that have now been disabled */
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
bool modeset = needs_modeset(new_crtc_state);
@@ -15462,11 +15462,10 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_check_cpu_fifo_underruns(dev_priv);
intel_check_pch_fifo_underruns(dev_priv);
- if (state->modeset) {
+ if (state->modeset)
intel_verify_planes(state);
- intel_sagv_post_plane_update(state);
- }
+ intel_sagv_post_plane_update(state);
drm_atomic_helper_commit_hw_done(&state->base);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8d458cf0333d..005549d0b778 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3806,7 +3806,6 @@ void intel_sagv_post_plane_update(struct
intel_atomic_state *state)
static bool intel_crtc_can_enable_sagv(const struct intel_crtc_state
*crtc_state)
{
- struct intel_atomic_state *state =
to_intel_atomic_state(crtc_state->uapi.state);
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_plane *plane;
@@ -3819,13 +3818,6 @@ static bool intel_crtc_can_enable_sagv(const struct
intel_crtc_state *crtc_state
if (!crtc_state->hw.active)
return true;
- /*
-* SKL+ workaround: bspec recommends we disable SAGV when we have
-* more then one pipe enabled
-*/
- if (hweight8(state->active_pipes) > 1)
- return false;
-
if (crtc_state->hw.adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE)
return false;
@@ -3863,6 +3855,9 @@ static bool intel_crtc_can_enable_sagv(const struct
intel_crtc_state *crtc_state
bool intel_can_enable_sagv(const struct intel_bw_state *bw_state)
{
+ if (bw_state->active_pipes && !is_power_of_2(bw_state->active_pipes))
+ return false;
+
return bw_state->pipe_sagv_reject == 0;
}
@@ -3892,6 +3887,14 @@ static int intel_compute_sagv_mask(struct
intel_atomic_state *state)
if (!new_bw_state)
return 0;
+ new_bw_state->active_pipes =
+ intel_calc_active_pipes(state, old_bw_state->active_pipes);
+ if (new_bw_state->active_pipes != old_bw_state->active_pipes) {
+ ret = intel_atomic_lock_global_state(&new_bw_state->base);
+ if (ret)
+ return ret;
+ }
+
if (intel_can_enable_sagv(new_bw_state) !=
intel_can_enable_sagv(old_bw_state)) {
ret = intel_atomic_serialize_global_state(&new_bw_state->base);
if (ret)
@@ -5915,11 +5918,9 @@ skl_compute_wm(struct intel_atomic_state *state)
if (ret)
return ret;
- if (state->modeset) {
- ret = intel_compute_sagv_mask(state);
- if (ret)
- return ret;
- }
+ ret = intel_compute_sagv_mask(state);
+ if (ret)
+
[Intel-gfx] [PATCH v26 4/9] drm/i915: Separate icl and skl SAGV checking
Introduce platform dependent SAGV checking in
combination with bandwidth state pipe SAGV mask.
v2, v3, v4, v5, v6: Fix rebase conflict
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 005549d0b778..700ec80c40fb 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3853,6 +3853,24 @@ static bool intel_crtc_can_enable_sagv(const struct
intel_crtc_state *crtc_state
return true;
}
+static bool skl_crtc_can_enable_sagv(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_atomic_state *state =
to_intel_atomic_state(crtc_state->uapi.state);
+ /*
+* SKL+ workaround: bspec recommends we disable SAGV when we have
+* more then one pipe enabled
+*/
+ if (hweight8(state->active_pipes) > 1)
+ return false;
+
+ return intel_crtc_can_enable_sagv(crtc_state);
+}
+
+static bool icl_crtc_can_enable_sagv(const struct intel_crtc_state *crtc_state)
+{
+ return intel_crtc_can_enable_sagv(crtc_state);
+}
+
bool intel_can_enable_sagv(const struct intel_bw_state *bw_state)
{
if (bw_state->active_pipes && !is_power_of_2(bw_state->active_pipes))
@@ -3863,22 +3881,30 @@ bool intel_can_enable_sagv(const struct intel_bw_state
*bw_state)
static int intel_compute_sagv_mask(struct intel_atomic_state *state)
{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
int ret;
struct intel_crtc *crtc;
- struct intel_crtc_state *new_crtc_state;
+ const struct intel_crtc_state *new_crtc_state;
struct intel_bw_state *new_bw_state = NULL;
const struct intel_bw_state *old_bw_state = NULL;
int i;
for_each_new_intel_crtc_in_state(state, crtc,
new_crtc_state, i) {
+ bool can_sagv;
+
new_bw_state = intel_atomic_get_bw_state(state);
if (IS_ERR(new_bw_state))
return PTR_ERR(new_bw_state);
old_bw_state = intel_atomic_get_old_bw_state(state);
- if (intel_crtc_can_enable_sagv(new_crtc_state))
+ if (INTEL_GEN(dev_priv) >= 11)
+ can_sagv = icl_crtc_can_enable_sagv(new_crtc_state);
+ else
+ can_sagv = skl_crtc_can_enable_sagv(new_crtc_state);
+
+ if (can_sagv)
new_bw_state->pipe_sagv_reject &= ~BIT(crtc->pipe);
else
new_bw_state->pipe_sagv_reject |= BIT(crtc->pipe);
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v26 5/9] drm/i915: Add TGL+ SAGV support
Starting from TGL we need to have a separate wm0
values for SAGV and non-SAGV which affects
how calculations are done.
v2: Remove long lines
v3: Removed COLOR_PLANE enum references
v4, v5, v6: Fixed rebase conflict
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_display.c | 8 +-
.../drm/i915/display/intel_display_types.h| 3 +
drivers/gpu/drm/i915/intel_pm.c | 128 +-
3 files changed, 130 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 136826edaf49..aeaa78f9fc18 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13948,7 +13948,9 @@ static void verify_wm_state(struct intel_crtc *crtc,
/* Watermarks */
for (level = 0; level <= max_level; level++) {
if (skl_wm_level_equals(&hw_plane_wm->wm[level],
- &sw_plane_wm->wm[level]))
+ &sw_plane_wm->wm[level]) ||
+ (level == 0 &&
skl_wm_level_equals(&hw_plane_wm->wm[level],
+
&sw_plane_wm->sagv_wm0)))
continue;
drm_err(&dev_priv->drm,
@@ -14003,7 +14005,9 @@ static void verify_wm_state(struct intel_crtc *crtc,
/* Watermarks */
for (level = 0; level <= max_level; level++) {
if (skl_wm_level_equals(&hw_plane_wm->wm[level],
- &sw_plane_wm->wm[level]))
+ &sw_plane_wm->wm[level]) ||
+ (level == 0 &&
skl_wm_level_equals(&hw_plane_wm->wm[level],
+
&sw_plane_wm->sagv_wm0)))
continue;
drm_err(&dev_priv->drm,
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ba8c08145c88..23a425e565a8 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -688,11 +688,14 @@ struct skl_plane_wm {
struct skl_wm_level wm[8];
struct skl_wm_level uv_wm[8];
struct skl_wm_level trans_wm;
+ struct skl_wm_level sagv_wm0;
+ struct skl_wm_level uv_sagv_wm0;
bool is_planar;
};
struct skl_pipe_wm {
struct skl_plane_wm planes[I915_MAX_PLANES];
+ bool can_sagv;
};
enum vlv_wm_level {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 700ec80c40fb..76fc852d4b96 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3871,6 +3871,9 @@ static bool icl_crtc_can_enable_sagv(const struct
intel_crtc_state *crtc_state)
return intel_crtc_can_enable_sagv(crtc_state);
}
+static bool
+tgl_crtc_can_enable_sagv(const struct intel_crtc_state *crtc_state);
+
bool intel_can_enable_sagv(const struct intel_bw_state *bw_state)
{
if (bw_state->active_pipes && !is_power_of_2(bw_state->active_pipes))
@@ -3884,7 +3887,7 @@ static int intel_compute_sagv_mask(struct
intel_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
int ret;
struct intel_crtc *crtc;
- const struct intel_crtc_state *new_crtc_state;
+ struct intel_crtc_state *new_crtc_state;
struct intel_bw_state *new_bw_state = NULL;
const struct intel_bw_state *old_bw_state = NULL;
int i;
@@ -3899,7 +3902,9 @@ static int intel_compute_sagv_mask(struct
intel_atomic_state *state)
old_bw_state = intel_atomic_get_old_bw_state(state);
- if (INTEL_GEN(dev_priv) >= 11)
+ if (INTEL_GEN(dev_priv) >= 12)
+ can_sagv = tgl_crtc_can_enable_sagv(new_crtc_state);
+ else if (INTEL_GEN(dev_priv) >= 11)
can_sagv = icl_crtc_can_enable_sagv(new_crtc_state);
else
can_sagv = skl_crtc_can_enable_sagv(new_crtc_state);
@@ -3921,6 +3926,24 @@ static int intel_compute_sagv_mask(struct
intel_atomic_state *state)
return ret;
}
+ for_each_new_intel_crtc_in_state(state, crtc,
+new_crtc_state, i) {
+ struct skl_pipe_wm *pipe_wm = &new_crtc_state->wm.skl.optimal;
+
+ /*
+* Due to drm limitation at commit state, when
+* changes are written the whole atomic state is
+* zeroed away => which prevents from using it,
+* so just sticking it into pipe wm state for
+* keeping it simple - anyway this is rel
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/9] drm/i915/gt: Stop holding onto the pinned_default_state
== Series Details ==
Series: series starting with [1/9] drm/i915/gt: Stop holding onto the
pinned_default_state
URL : https://patchwork.freedesktop.org/series/76771/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8401_full -> Patchwork_17526_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17526_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_params@invalid-bsd-ring:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb1/igt@gem_exec_par...@invalid-bsd-ring.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/shard-iclb3/igt@gem_exec_par...@invalid-bsd-ring.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][3] -> [FAIL][4] ([fdo#108145] / [i915#265]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109642] / [fdo#111068])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb2/igt@kms_psr2...@frontbuffer.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/shard-iclb6/igt@kms_psr2...@frontbuffer.html
* igt@kms_psr@psr2_basic:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109441]) +2 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb2/igt@kms_psr@psr2_basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/shard-iclb6/igt@kms_psr@psr2_basic.html
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-apl8/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/shard-apl4/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
Possible fixes
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [FAIL][11] ([i915#454]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb4/igt@i915_pm...@dc6-psr.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/shard-iclb4/igt@i915_pm...@dc6-psr.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [DMESG-WARN][13] ([i915#180]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/shard-kbl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* {igt@kms_flip@flip-vs-expired-vblank@c-edp1}:
- shard-skl: [FAIL][15] ([i915#79]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-skl7/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/shard-skl4/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html
* {igt@kms_flip@flip-vs-suspend-interruptible@a-dp1}:
- shard-apl: [DMESG-WARN][17] ([i915#180]) -> [PASS][18] +2
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-apl8/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/shard-apl4/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [FAIL][19] ([i915#1188]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-skl10/igt@kms_...@bpc-switch-dpms.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/shard-skl1/igt@kms_...@bpc-switch-dpms.html
* igt@kms_psr@no_drrs:
- shard-iclb: [FAIL][21] ([i915#173]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb1/igt@kms_psr@no_drrs.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/shard-iclb3/igt@kms_psr@no_drrs.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [SKIP][23] ([fdo#109441]) -> [PASS][24] +2 similar
issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb7/igt@kms_psr@psr2_primary_page_flip.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17526/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_setmode@basic:
- shard-hsw: [FAIL][25] ([i915#31]) -> [PASS][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-hsw7/igt@kms_setm...@basic.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-ti
[Intel-gfx] [PATCH] drm/i915: Implement vm_ops->access for gdb access into mmaps
gdb uses ptrace() to peek and poke bytes of the target's address space.
The driver must implement an vm_ops->access() handler or else gdb will
be unable to inspect the pointer and report it as out-of-bounds.
Worse than useless as it causes immediate suspicion of the valid GTT
pointer, distracting the poor programmer trying to find his bug.
Testcase: igt/gem_mmap_gtt/ptrace
Testcase: igt/gem_mmap_offset/ptrace
Suggested-by: Kristian H. Kristensen
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Joonas Lahtinen
Cc: Maciej Patelczyk
Cc: Kristian H. Kristensen
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 31 +
.../drm/i915/gem/selftests/i915_gem_mman.c| 120 ++
2 files changed, 151 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..aef917b7f168 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -396,6 +396,35 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
return i915_error_to_vmf_fault(ret);
}
+static int
+vm_access(struct vm_area_struct *area, unsigned long addr,
+ void *buf, int len, int write)
+{
+ struct i915_mmap_offset *mmo = area->vm_private_data;
+ struct drm_i915_gem_object *obj = mmo->obj;
+ void *vaddr;
+
+ addr -= area->vm_start;
+ if (addr >= obj->base.size)
+ return -EINVAL;
+
+ /* As this is primarily for debugging, let's focus on simplicity */
+ vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
+ if (IS_ERR(vaddr))
+ return PTR_ERR(vaddr);
+
+ if (write) {
+ memcpy(vaddr + addr, buf, len);
+ __i915_gem_object_flush_map(obj, addr, len);
+ } else {
+ memcpy(buf, vaddr + addr, len);
+ }
+
+ i915_gem_object_unpin_map(obj);
+
+ return len;
+}
+
void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
{
struct i915_vma *vma;
@@ -745,12 +774,14 @@ static void vm_close(struct vm_area_struct *vma)
static const struct vm_operations_struct vm_ops_gtt = {
.fault = vm_fault_gtt,
+ .access = vm_access,
.open = vm_open,
.close = vm_close,
};
static const struct vm_operations_struct vm_ops_cpu = {
.fault = vm_fault_cpu,
+ .access = vm_access,
.open = vm_open,
.close = vm_close,
};
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index ef7abcb3f4ee..401724403cda 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -952,6 +952,125 @@ static int igt_mmap(void *arg)
return 0;
}
+static const char *repr_mmap_type(enum i915_mmap_type type)
+{
+ switch (type) {
+ case I915_MMAP_TYPE_GTT: return "gtt";
+ case I915_MMAP_TYPE_WB: return "wb";
+ case I915_MMAP_TYPE_WC: return "wc";
+ case I915_MMAP_TYPE_UC: return "uc";
+ default: return "unknown";
+ }
+}
+
+static bool can_access(const struct drm_i915_gem_object *obj)
+{
+ unsigned int flags =
+ I915_GEM_OBJECT_HAS_STRUCT_PAGE | I915_GEM_OBJECT_HAS_IOMEM;
+
+ return i915_gem_object_type_has(obj, flags);
+}
+
+static int __igt_mmap_access(struct drm_i915_private *i915,
+struct drm_i915_gem_object *obj,
+enum i915_mmap_type type)
+{
+ struct i915_mmap_offset *mmo;
+ unsigned long __user *ptr;
+ unsigned long A, B;
+ unsigned long x, y;
+ u64 addr;
+ int err;
+
+ memset(&A, 0xAA, sizeof(A));
+ memset(&B, 0xBB, sizeof(B));
+
+ if (!can_mmap(obj, type) || !can_access(obj))
+ return 0;
+
+ mmo = mmap_offset_attach(obj, type, NULL);
+ if (IS_ERR(mmo))
+ return PTR_ERR(mmo);
+
+ addr = igt_mmap_node(i915, &mmo->vma_node, 0, PROT_WRITE, MAP_SHARED);
+ if (IS_ERR_VALUE(addr))
+ return addr;
+ ptr = u64_to_user_ptr(addr);
+
+ err = __put_user(A, ptr);
+ if (err) {
+ pr_err("%s(%s): failed to write into user mmap\n",
+ obj->mm.region->name, repr_mmap_type(type));
+ goto out_unmap;
+ }
+
+ err = access_process_vm(current, addr, &x, sizeof(x), 0);
+ if (err < 0) {
+ pr_err("%s(%s): access_process_vm() read failed\n",
+ obj->mm.region->name, repr_mmap_type(type));
+ goto out_unmap;
+ }
+
+ err = access_process_vm(current, addr, &B, sizeof(B), FOLL_WRITE);
+ if (err < 0) {
+ pr_err("%s(%s): access_process_vm() write failed\n",
+ obj->mm.region->name, repr_mmap_type(type));
+ goto out_unmap;
+ }
+
+ err = __get_user(y, ptr);
+ if (err) {
+
[Intel-gfx] [PATCH] drm/i915: Implement vm_ops->access for gdb access into mmaps
gdb uses ptrace() to peek and poke bytes of the target's address space.
The driver must implement an vm_ops->access() handler or else gdb will
be unable to inspect the pointer and report it as out-of-bounds.
Worse than useless as it causes immediate suspicion of the valid GTT
pointer, distracting the poor programmer trying to find his bug.
Testcase: igt/gem_mmap_gtt/ptrace
Testcase: igt/gem_mmap_offset/ptrace
Suggested-by: Kristian H. Kristensen
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Joonas Lahtinen
Cc: Maciej Patelczyk
Cc: Kristian H. Kristensen
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 31 +
.../drm/i915/gem/selftests/i915_gem_mman.c| 120 ++
2 files changed, 151 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..aef917b7f168 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -396,6 +396,35 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
return i915_error_to_vmf_fault(ret);
}
+static int
+vm_access(struct vm_area_struct *area, unsigned long addr,
+ void *buf, int len, int write)
+{
+ struct i915_mmap_offset *mmo = area->vm_private_data;
+ struct drm_i915_gem_object *obj = mmo->obj;
+ void *vaddr;
+
+ addr -= area->vm_start;
+ if (addr >= obj->base.size)
+ return -EINVAL;
+
+ /* As this is primarily for debugging, let's focus on simplicity */
+ vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
+ if (IS_ERR(vaddr))
+ return PTR_ERR(vaddr);
+
+ if (write) {
+ memcpy(vaddr + addr, buf, len);
+ __i915_gem_object_flush_map(obj, addr, len);
+ } else {
+ memcpy(buf, vaddr + addr, len);
+ }
+
+ i915_gem_object_unpin_map(obj);
+
+ return len;
+}
+
void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
{
struct i915_vma *vma;
@@ -745,12 +774,14 @@ static void vm_close(struct vm_area_struct *vma)
static const struct vm_operations_struct vm_ops_gtt = {
.fault = vm_fault_gtt,
+ .access = vm_access,
.open = vm_open,
.close = vm_close,
};
static const struct vm_operations_struct vm_ops_cpu = {
.fault = vm_fault_cpu,
+ .access = vm_access,
.open = vm_open,
.close = vm_close,
};
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index ef7abcb3f4ee..903022ee6083 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -952,6 +952,125 @@ static int igt_mmap(void *arg)
return 0;
}
+static const char *repr_mmap_type(enum i915_mmap_type type)
+{
+ switch (type) {
+ case I915_MMAP_TYPE_GTT: return "gtt";
+ case I915_MMAP_TYPE_WB: return "wb";
+ case I915_MMAP_TYPE_WC: return "wc";
+ case I915_MMAP_TYPE_UC: return "uc";
+ default: return "unknown";
+ }
+}
+
+static bool can_access(const struct drm_i915_gem_object *obj)
+{
+ unsigned int flags =
+ I915_GEM_OBJECT_HAS_STRUCT_PAGE | I915_GEM_OBJECT_HAS_IOMEM;
+
+ return i915_gem_object_type_has(obj, flags);
+}
+
+static int __igt_mmap_access(struct drm_i915_private *i915,
+struct drm_i915_gem_object *obj,
+enum i915_mmap_type type)
+{
+ struct i915_mmap_offset *mmo;
+ unsigned long __user *ptr;
+ unsigned long A, B;
+ unsigned long x, y;
+ u64 addr;
+ int err;
+
+ memset(&A, 0xAA, sizeof(A));
+ memset(&B, 0xBB, sizeof(B));
+
+ if (!can_mmap(obj, type) || !can_access(obj))
+ return 0;
+
+ mmo = mmap_offset_attach(obj, type, NULL);
+ if (IS_ERR(mmo))
+ return PTR_ERR(mmo);
+
+ addr = igt_mmap_node(i915, &mmo->vma_node, 0, PROT_WRITE, MAP_SHARED);
+ if (IS_ERR_VALUE(addr))
+ return addr;
+ ptr = u64_to_user_ptr(addr);
+
+ err = __put_user(A, ptr);
+ if (err) {
+ pr_err("%s(%s): failed to write into user mmap\n",
+ obj->mm.region->name, repr_mmap_type(type));
+ goto out_unmap;
+ }
+
+ err = access_process_vm(current, addr, &x, sizeof(x), 0);
+ if (err != sizeof(x)) {
+ pr_err("%s(%s): access_process_vm() read failed\n",
+ obj->mm.region->name, repr_mmap_type(type));
+ goto out_unmap;
+ }
+
+ err = access_process_vm(current, addr, &B, sizeof(B), FOLL_WRITE);
+ if (err != sizeof(B)) {
+ pr_err("%s(%s): access_process_vm() write failed\n",
+ obj->mm.region->name, repr_mmap_type(type));
+ goto out_unmap;
+ }
+
+ err = __get_user(y, ptr);
+
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Fix glk watermark calculations
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix glk watermark calculations
URL : https://patchwork.freedesktop.org/series/76774/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8401_full -> Patchwork_17527_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17527_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_params@invalid-bsd-ring:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb1/igt@gem_exec_par...@invalid-bsd-ring.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/shard-iclb8/igt@gem_exec_par...@invalid-bsd-ring.html
* igt@i915_pm_rpm@system-suspend:
- shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#151] / [i915#69])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-skl10/igt@i915_pm_...@system-suspend.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/shard-skl9/igt@i915_pm_...@system-suspend.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +2 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-apl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/shard-apl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][9] -> [FAIL][10] ([fdo#108145] / [i915#265])
+1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#899])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-glk1/igt@kms_plane_low...@pipe-a-tiling-x.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/shard-glk4/igt@kms_plane_low...@pipe-a-tiling-x.html
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109642] / [fdo#111068])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb2/igt@kms_psr2...@frontbuffer.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/shard-iclb1/igt@kms_psr2...@frontbuffer.html
* igt@kms_psr@psr2_basic:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb2/igt@kms_psr@psr2_basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/shard-iclb5/igt@kms_psr@psr2_basic.html
Possible fixes
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [DMESG-WARN][17] ([i915#716]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-apl2/igt@gen9_exec_pa...@allowed-all.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/shard-apl7/igt@gen9_exec_pa...@allowed-all.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [FAIL][19] ([i915#454]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb4/igt@i915_pm...@dc6-psr.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/shard-iclb4/igt@i915_pm...@dc6-psr.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [DMESG-WARN][21] ([i915#180]) -> [PASS][22] +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* {igt@kms_flip@flip-vs-expired-vblank@c-edp1}:
- shard-skl: [FAIL][23] ([i915#79]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-skl7/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17527/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html
* {igt@kms_flip@flip-vs-suspend-interruptible@a-dp1}:
- shard-apl: [DMESG-WARN][25] ([i915#180]) -> [PASS][26] +2
similar issues
[25]:
https://intel-gfx-ci.01.org
[Intel-gfx] [PULL] drm-misc-fixes
Hi! Here's this week drm-misc-fixes PR Thanks! Maxime drm-misc-fixes-2020-04-30: A few resources-related fixes for qxl, some doc build warnings and ioctl fixes for dma-buf, an off-by-one fix in edid, and a return code fix in DP-MST The following changes since commit 9da67433f64eb89e5a7b47977507806c6ea026e7: drm/tidss: fix crash related to accessing freed memory (2020-04-20 10:07:35 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-04-30 for you to fetch changes up to 6f49c2515e2258f08f2b905c9772dbf729610415: dma-buf: fix documentation build warnings (2020-04-30 19:47:39 +0530) A few resources-related fixes for qxl, some doc build warnings and ioctl fixes for dma-buf, an off-by-one fix in edid, and a return code fix in DP-MST Daniel Vetter (1): dma-buf: Fix SET_NAME ioctl uapi Gurchetan Singh (1): drm/virtio: only destroy created contexts Lyude Paul (1): drm/dp_mst: Fix drm_dp_send_dpcd_write() return code Randy Dunlap (1): dma-buf: fix documentation build warnings Vasily Averin (4): drm/qxl: qxl_release leak in qxl_draw_dirty_fb() drm/qxl: qxl_release leak in qxl_hw_surface_alloc() drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper() drm/qxl: qxl_release use after free Ville Syrjälä (1): drm/edid: Fix off-by-one in DispID DTD pixel clock drivers/dma-buf/dma-buf.c | 7 --- drivers/gpu/drm/drm_dp_mst_topology.c | 8 ++-- drivers/gpu/drm/drm_edid.c| 2 +- drivers/gpu/drm/qxl/qxl_cmd.c | 10 +- drivers/gpu/drm/qxl/qxl_display.c | 6 +++--- drivers/gpu/drm/qxl/qxl_draw.c| 7 --- drivers/gpu/drm/qxl/qxl_image.c | 3 ++- drivers/gpu/drm/qxl/qxl_ioctl.c | 5 + drivers/gpu/drm/virtio/virtgpu_kms.c | 17 ++--- include/linux/dma-buf.h | 3 +-- include/uapi/linux/dma-buf.h | 6 ++ 11 files changed, 39 insertions(+), 35 deletions(-) signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for SAGV support for Gen12+ (rev32)
== Series Details == Series: SAGV support for Gen12+ (rev32) URL : https://patchwork.freedesktop.org/series/75129/ State : success == Summary == CI Bug Log - changes from CI_DRM_8403 -> Patchwork_17531 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17531/index.html Known issues Here are the changes found in Patchwork_17531 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@sanitycheck: - fi-bwr-2160:[PASS][1] -> [INCOMPLETE][2] ([i915#489]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8403/fi-bwr-2160/igt@i915_selftest@l...@sanitycheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17531/fi-bwr-2160/igt@i915_selftest@l...@sanitycheck.html [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 Participating hosts (51 -> 43) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-8809g fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8403 -> Patchwork_17531 CI-20190529: 20190529 CI_DRM_8403: 09978e99929f6e5acfe1e959f6499a134f210887 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5619: 94de923ca8d4cc8f532b8062d87aaad9da6ef956 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17531: d476c016bc161fca38b14532185fe96d7cab1e04 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d476c016bc16 drm/i915: Enable SAGV support for Gen12 d4948b0fe076 drm/i915: Restrict qgv points which don't have enough bandwidth. 41c561f0dc26 drm/i915: Rename bw_state to new_bw_state ce75f7bbf7e7 drm/i915: Added required new PCode commands f2b4f78b7f22 drm/i915: Add TGL+ SAGV support 0cbc47e3c84c drm/i915: Separate icl and skl SAGV checking c9d261232770 drm/i915: Track active_pipes in bw_state 9942ef866255 drm/i915: Use bw state for per crtc SAGV evaluation bca922b59afd drm/i915: Introduce skl_plane_wm_level accessor. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17531/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: Add support for multi context perf queries (rev4)
== Series Details == Series: drm/i915/perf: Add support for multi context perf queries (rev4) URL : https://patchwork.freedesktop.org/series/76588/ State : success == Summary == CI Bug Log - changes from CI_DRM_8401_full -> Patchwork_17528_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17528_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_params@invalid-bsd-ring: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb1/igt@gem_exec_par...@invalid-bsd-ring.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/shard-iclb8/igt@gem_exec_par...@invalid-bsd-ring.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-kbl3/igt@gem_workarou...@suspend-resume-fd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/shard-kbl3/igt@gem_workarou...@suspend-resume-fd.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-apl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/shard-apl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@all-pipes-torture-move: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#128]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-kbl4/igt@kms_cursor_leg...@all-pipes-torture-move.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/shard-kbl6/igt@kms_cursor_leg...@all-pipes-torture-move.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-skl: [PASS][9] -> [FAIL][10] ([IGT#5]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/shard-skl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic: - shard-glk: [PASS][11] -> [FAIL][12] ([IGT#5]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-glk7/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/shard-glk4/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-atomic.html * igt@kms_draw_crc@draw-method-rgb565-render-xtiled: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#52] / [i915#54]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-glk8/igt@kms_draw_...@draw-method-rgb565-render-xtiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/shard-glk5/igt@kms_draw_...@draw-method-rgb565-render-xtiled.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109642] / [fdo#111068]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb2/igt@kms_psr2...@frontbuffer.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/shard-iclb3/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb2/igt@kms_psr@psr2_basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/shard-iclb3/igt@kms_psr@psr2_basic.html Possible fixes * igt@i915_pm_dc@dc6-psr: - shard-iclb: [FAIL][21] ([i915#454]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-iclb4/igt@i915_pm...@dc6-psr.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [DMESG-WARN][23] ([i915#180]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8401/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17528/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [SKIP][25] ([fdo#109349]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Implement vm_ops->access for gdb access into mmaps (rev3)
== Series Details == Series: drm/i915: Implement vm_ops->access for gdb access into mmaps (rev3) URL : https://patchwork.freedesktop.org/series/76783/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8403 -> Patchwork_17532 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17532 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17532, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17532/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17532: ### IGT changes ### Possible regressions * igt@i915_selftest@live@mman: - fi-gdg-551: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8403/fi-gdg-551/igt@i915_selftest@l...@mman.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17532/fi-gdg-551/igt@i915_selftest@l...@mman.html Known issues Here are the changes found in Patchwork_17532 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_selftest@live@gt_engines: - fi-bwr-2160:[INCOMPLETE][3] ([i915#489]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8403/fi-bwr-2160/igt@i915_selftest@live@gt_engines.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17532/fi-bwr-2160/igt@i915_selftest@live@gt_engines.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][5] ([fdo#109271]) -> [FAIL][6] ([i915#62] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8403/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17532/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (51 -> 43) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8403 -> Patchwork_17532 CI-20190529: 20190529 CI_DRM_8403: 09978e99929f6e5acfe1e959f6499a134f210887 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5619: 94de923ca8d4cc8f532b8062d87aaad9da6ef956 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17532: 8b2069a8f7f0bc73c387787f6f3b31a5dc53ad50 @ git://anongit.freedesktop.org/gfx-ci/linux == Kernel 32bit build == Warning: Kernel 32bit buildtest failed: https://intel-gfx-ci.01.org/Patchwork_17532/build_32bit.log CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gem/i915_gem_mman.o In file included from ./include/asm-generic/bug.h:5:0, from ./arch/x86/include/asm/bug.h:83, from ./include/linux/bug.h:5, from ./include/linux/mmdebug.h:5, from ./include/linux/mm.h:9, from ./include/linux/mman.h:5, from drivers/gpu/drm/i915/gem/i915_gem_mman.c:8: drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c: In function ‘__igt_mmap_access’: ./include/linux/err.h:22:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO) ^ ./include/linux/compiler.h:78:42: note: in definition of macro ‘unlikely’ # define unlikely(x) __builtin_expect(!!(x), 0) ^ drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:996:6: note: in expansion of macro ‘IS_ERR_VALUE’ if (IS_ERR_VALUE(addr)) ^~~~ cc1: all warnings being treated as errors scripts/Makefile.build:266: recipe for target 'drivers/gpu/drm/i915/gem/i915_gem_mman.o' failed make[4]: *** [drivers/gpu/drm/i915/gem/i915_gem_mman.o] Error 1 scripts/Makefile.build:488: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:488: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:488: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1722: recipe for target 'drivers' failed make: *** [drivers] Error 2 == Linux commits == 8b2069a8f7f0 drm/i915: Implement vm_ops->access for gdb
[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915: Implement vm_ops->access for gdb access into mmaps (rev3)
== Series Details == Series: drm/i915: Implement vm_ops->access for gdb access into mmaps (rev3) URL : https://patchwork.freedesktop.org/series/76783/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gem/i915_gem_mman.o In file included from ./include/asm-generic/bug.h:5:0, from ./arch/x86/include/asm/bug.h:83, from ./include/linux/bug.h:5, from ./include/linux/mmdebug.h:5, from ./include/linux/mm.h:9, from ./include/linux/mman.h:5, from drivers/gpu/drm/i915/gem/i915_gem_mman.c:8: drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c: In function ‘__igt_mmap_access’: ./include/linux/err.h:22:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO) ^ ./include/linux/compiler.h:78:42: note: in definition of macro ‘unlikely’ # define unlikely(x) __builtin_expect(!!(x), 0) ^ drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:996:6: note: in expansion of macro ‘IS_ERR_VALUE’ if (IS_ERR_VALUE(addr)) ^~~~ cc1: all warnings being treated as errors scripts/Makefile.build:266: recipe for target 'drivers/gpu/drm/i915/gem/i915_gem_mman.o' failed make[4]: *** [drivers/gpu/drm/i915/gem/i915_gem_mman.o] Error 1 scripts/Makefile.build:488: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:488: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:488: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1722: recipe for target 'drivers' failed make: *** [drivers] Error 2 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17532/build_32bit.log ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 03/11] drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split
From: Maarten Lankhorst
v2:
* Manual Rebase (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 61 ---
.../drm/i915/display/intel_display_types.h| 11 ++-
drivers/gpu/drm/i915/intel_pm.c | 76 +--
3 files changed, 79 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5d9a19f6fcfe..3269b3f4691d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -151,7 +151,7 @@ static void ilk_pch_clock_get(struct intel_crtc *crtc,
static int intel_framebuffer_init(struct intel_framebuffer *ifb,
struct drm_i915_gem_object *obj,
struct drm_mode_fb_cmd2 *mode_cmd);
-static void intel_set_pipe_timings(const struct intel_crtc_state *crtc_state);
+static void intel_set_transcoder_timings(const struct intel_crtc_state
*crtc_state);
static void intel_set_pipe_src_size(const struct intel_crtc_state *crtc_state);
static void intel_cpu_transcoder_set_m_n(const struct intel_crtc_state
*crtc_state,
const struct intel_link_m_n *m_n,
@@ -6091,18 +6091,16 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
static int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state)
{
- const struct drm_display_mode *adjusted_mode =
- &crtc_state->hw.adjusted_mode;
+ const struct drm_display_mode *pipe_mode = &state->hw.pipe_mode;
int width, height;
if (crtc_state->pch_pfit.enabled) {
width = drm_rect_width(&crtc_state->pch_pfit.dst);
height = drm_rect_height(&crtc_state->pch_pfit.dst);
} else {
- width = adjusted_mode->crtc_hdisplay;
- height = adjusted_mode->crtc_vdisplay;
+ width = pipe_mode->crtc_hdisplay;
+ height = pipe_mode->crtc_vdisplay;
}
-
return skl_update_scaler(crtc_state, !crtc_state->hw.active,
SKL_CRTC_INDEX,
&crtc_state->scaler_state.scaler_id,
@@ -6883,7 +6881,7 @@ static void ilk_crtc_enable(struct intel_atomic_state
*state,
if (intel_crtc_has_dp_encoder(new_crtc_state))
intel_dp_set_m_n(new_crtc_state, M1_N1);
- intel_set_pipe_timings(new_crtc_state);
+ intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
if (new_crtc_state->has_pch_encoder)
@@ -7028,7 +7026,7 @@ static void hsw_crtc_enable(struct intel_atomic_state
*state,
intel_encoders_pre_enable(state, crtc);
if (!transcoder_is_dsi(cpu_transcoder))
- intel_set_pipe_timings(new_crtc_state);
+ intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
@@ -7408,7 +7406,7 @@ static void valleyview_crtc_enable(struct
intel_atomic_state *state,
if (intel_crtc_has_dp_encoder(new_crtc_state))
intel_dp_set_m_n(new_crtc_state, M1_N1);
- intel_set_pipe_timings(new_crtc_state);
+ intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B) {
@@ -7476,7 +7474,7 @@ static void i9xx_crtc_enable(struct intel_atomic_state
*state,
if (intel_crtc_has_dp_encoder(new_crtc_state))
intel_dp_set_m_n(new_crtc_state, M1_N1);
- intel_set_pipe_timings(new_crtc_state);
+ intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
i9xx_set_pipeconf(new_crtc_state);
@@ -7942,7 +7940,7 @@ static bool intel_crtc_supports_double_wide(const struct
intel_crtc *crtc)
static u32 ilk_pipe_pixel_rate(const struct intel_crtc_state *crtc_state)
{
- u32 pixel_rate = crtc_state->hw.adjusted_mode.crtc_clock;
+ u32 pixel_rate = crtc_state->hw.pipe_mode.crtc_clock;
unsigned int pipe_w, pipe_h, pfit_w, pfit_h;
/*
@@ -7979,7 +7977,7 @@ static void intel_crtc_compute_pixel_rate(struct
intel_crtc_state *crtc_state)
if (HAS_GMCH(dev_priv))
/* FIXME calculate proper pipe pixel rate for GMCH pfit */
crtc_state->pixel_rate =
- crtc_state->hw.adjusted_mode.crtc_clock;
+ crtc_state->hw.pipe_mode.crtc_clock;
else
crtc_state->pixel_rate =
ilk_pipe_pixel_rate(crtc_state);
@@ -7989,7 +7987,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- const struct drm_display_mode *adjusted_mo
