Re: [Intel-gfx] [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On Tue, Sep 06, 2022 at 09:18:09PM +0200, Daniel Vetter wrote: > On Fri, Aug 12, 2022 at 08:03:47AM +0200, Greg KH wrote: > > On Thu, Aug 11, 2022 at 06:52:40PM +0200, Daniel Vetter wrote: > > > On Wed, Aug 03, 2022 at 04:13:05PM -0400, Jason Baron wrote: > > > > > > > > > > > > On 8/3/22 15:56, jim.cro...@gmail.com wrote: > > > > > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie > > > > > wrote: > > > > >> > > > > > > > > > >> Hi Jason, Greg, DRM-folk, > > > > >> > > > > >> This adds 'typed' "class FOO" support to dynamic-debug, where 'typed' > > > > >> means either DISJOINT (like drm debug categories), or VERBOSE (like > > > > >> nouveau debug-levels). Use it in DRM modules: core, helpers, and in > > > > >> drivers i915, amdgpu, nouveau. > > > > >> > > > > > > > > > > This revision fell over, on a conflict with something in drm-MUMBLE > > > > > > > > > > Error: patch > > > > > https://urldefense.com/v3/__https://patchwork.freedesktop.org/api/1.0/series/106427/revisions/2/mbox/__;!!GjvTz_vk!UCPl5Uf32cDVwwysMTfaLwoGLWomargFXuR8HjBA3xsUOjxXHXC5hneAkP4iWK91yc-LjjJxWW89-51Z$ > > > > > > > > > > not applied > > > > > Applying: dyndbg: fix static_branch manipulation > > > > > Applying: dyndbg: fix module.dyndbg handling > > > > > Applying: dyndbg: show both old and new in change-info > > > > > Applying: dyndbg: reverse module walk in cat control > > > > > Applying: dyndbg: reverse module.callsite walk in cat control > > > > > Applying: dyndbg: use ESCAPE_SPACE for cat control > > > > > Applying: dyndbg: let query-modname override actual module name > > > > > Applying: dyndbg: add test_dynamic_debug module > > > > > Applying: dyndbg: drop EXPORTed dynamic_debug_exec_queries > > > > > > > > > > Jason, > > > > > those above are decent maintenance patches, particularly the drop > > > > > export. > > > > > It would be nice to trim this unused api this cycle. > > > > > > > > Hi Jim, > > > > > > > > Agreed - I was thinking the same thing. Feel free to add > > > > Acked-by: Jason Baron to those first 9. > > > > > > Does Greg KH usually pick up dyndbg patches or someone else or do I need > > > to do something? Would be great to get some movement here since -rc1 goes > > > out and merging will restart next week. > > > > Yes, I can take these into my tree after -rc1 is out. > > [uncovering from an absolutely impressive cascade of holes :-(] > > Did this happen and I can stop worrying here? I'd like to make sure these > drm debug infra improvements keep moving. I didn't take these, and I think I saw a 6th series sent: https://lore.kernel.org/r/20220904214134.408619-1-jim.cro...@gmail.com If you ack them, I will pick them up. thanks, greg k-h
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Add "standalone media" support for MTL (rev4)
On Wed, Sep 07, 2022 at 04:06:23AM +, Patchwork wrote: > == Series Details == > > Series: i915: Add "standalone media" support for MTL (rev4) > URL : https://patchwork.freedesktop.org/series/107908/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_12083_full -> Patchwork_107908v4_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_107908v4_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_107908v4_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Participating hosts (11 -> 12) > -- > > Additional (1): shard-rkl > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_107908v4_full: > > ### IGT changes ### > > Possible regressions > > * igt@gem_ctx_exec@basic-close-race: > - shard-tglb: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-tglb1/igt@gem_ctx_e...@basic-close-race.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb5/igt@gem_ctx_e...@basic-close-race.html Unexpected incomplete with no errors. Does not appear to be related to this series. Matt > > > Known issues > > > Here are the changes found in Patchwork_107908v4_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_eio@unwedge-stress: > - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#3063]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-tglb5/igt@gem_...@unwedge-stress.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb3/igt@gem_...@unwedge-stress.html > > * igt@gem_exec_balancer@parallel-out-fence: > - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) +2 similar > issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-iclb4/igt@gem_exec_balan...@parallel-out-fence.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-iclb3/igt@gem_exec_balan...@parallel-out-fence.html > > * igt@gem_exec_fair@basic-deadline: > - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2846]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk2/igt@gem_exec_f...@basic-deadline.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-glk1/igt@gem_exec_f...@basic-deadline.html > > * igt@gem_exec_fair@basic-none-solo@rcs0: > - shard-apl: [PASS][9] -> [FAIL][10] ([i915#2842]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-apl2/igt@gem_exec_fair@basic-none-s...@rcs0.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html > > * igt@gem_exec_fair@basic-pace@vcs1: > - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html > > * igt@gem_lmem_swapping@verify-random-ccs: > - shard-tglb: NOTRUN -> [SKIP][12] ([i915#4613]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb2/igt@gem_lmem_swapp...@verify-random-ccs.html > > * igt@gem_pxp@create-regular-context-1: > - shard-tglb: NOTRUN -> [SKIP][13] ([i915#4270]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb2/igt@gem_...@create-regular-context-1.html > > * igt@gen3_render_mixed_blits: > - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#109289]) +1 similar issue >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-iclb5/igt@gen3_render_mixed_blits.html > > * igt@gen7_exec_parse@basic-allocation: > - shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109289]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb2/igt@gen7_exec_pa...@basic-allocation.html > > * igt@gen9_exec_parse@bb-start-cmd: > - shard-tglb: NOTRUN -> [SKIP][16] ([i915#2527] / [i915#2856]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb2/igt@gen9_exec_pa...@bb-start-cmd.html > > * igt@i915_pm_freq_mult@media-freq@gt0: > - shard-tglb: NOTRUN -> [SKIP][17] ([i915#6590]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb2/igt@i915_pm_freq_mult@media-f...@gt0.html > > * igt@kms_atomic_transition@plane-all-modeset-transition: > - shard-tglb: NOTRUN -> [SKIP][18] ([i915#1769]) >[18]: >
[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Add "standalone media" support for MTL (rev4)
== Series Details == Series: i915: Add "standalone media" support for MTL (rev4) URL : https://patchwork.freedesktop.org/series/107908/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12083_full -> Patchwork_107908v4_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_107908v4_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_107908v4_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 12) -- Additional (1): shard-rkl Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_107908v4_full: ### IGT changes ### Possible regressions * igt@gem_ctx_exec@basic-close-race: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-tglb1/igt@gem_ctx_e...@basic-close-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb5/igt@gem_ctx_e...@basic-close-race.html Known issues Here are the changes found in Patchwork_107908v4_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#3063]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-tglb5/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb3/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@parallel-out-fence: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-iclb4/igt@gem_exec_balan...@parallel-out-fence.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-iclb3/igt@gem_exec_balan...@parallel-out-fence.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk2/igt@gem_exec_f...@basic-deadline.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-glk1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-apl2/igt@gem_exec_fair@basic-none-s...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_lmem_swapping@verify-random-ccs: - shard-tglb: NOTRUN -> [SKIP][12] ([i915#4613]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb2/igt@gem_lmem_swapp...@verify-random-ccs.html * igt@gem_pxp@create-regular-context-1: - shard-tglb: NOTRUN -> [SKIP][13] ([i915#4270]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb2/igt@gem_...@create-regular-context-1.html * igt@gen3_render_mixed_blits: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#109289]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-iclb5/igt@gen3_render_mixed_blits.html * igt@gen7_exec_parse@basic-allocation: - shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109289]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb2/igt@gen7_exec_pa...@basic-allocation.html * igt@gen9_exec_parse@bb-start-cmd: - shard-tglb: NOTRUN -> [SKIP][16] ([i915#2527] / [i915#2856]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb2/igt@gen9_exec_pa...@bb-start-cmd.html * igt@i915_pm_freq_mult@media-freq@gt0: - shard-tglb: NOTRUN -> [SKIP][17] ([i915#6590]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb2/igt@i915_pm_freq_mult@media-f...@gt0.html * igt@kms_atomic_transition@plane-all-modeset-transition: - shard-tglb: NOTRUN -> [SKIP][18] ([i915#1769]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-tglb2/igt@kms_atomic_transit...@plane-all-modeset-transition.html * igt@kms_big_fb@4-tiled-8bpp-rotate-180: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#5286]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/shard-iclb5/igt@kms_big...@4-tiled-8bpp-rotate-180.html * igt@kms_big_fb@4-tiled-addfb-size-overflow: - shard-tglb:
Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/gvt: Use the new device life cycle helpers
On 2022.09.01 22:37:40 +0800, Kevin Tian wrote:
> Move vfio_device to the start of intel_vgpu as required by the new
> helpers.
>
> Change intel_gvt_create_vgpu() to use intel_vgpu as the first param
> as other vgpu helpers do.
>
> Signed-off-by: Kevin Tian
> Reviewed-by: Jason Gunthorpe
> ---
Looks good to me.
Reviewed-by: Zhenyu Wang
> drivers/gpu/drm/i915/gvt/gvt.h | 5 ++-
> drivers/gpu/drm/i915/gvt/kvmgt.c | 52 ++--
> drivers/gpu/drm/i915/gvt/vgpu.c | 33
> 3 files changed, 50 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
> index 705689e64011..89fab7896fc6 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.h
> +++ b/drivers/gpu/drm/i915/gvt/gvt.h
> @@ -172,6 +172,7 @@ struct intel_vgpu_submission {
> #define KVMGT_DEBUGFS_FILENAME "kvmgt_nr_cache_entries"
>
> struct intel_vgpu {
> + struct vfio_device vfio_device;
> struct intel_gvt *gvt;
> struct mutex vgpu_lock;
> int id;
> @@ -211,7 +212,6 @@ struct intel_vgpu {
>
> u32 scan_nonprivbb;
>
> - struct vfio_device vfio_device;
> struct vfio_region *region;
> int num_regions;
> struct eventfd_ctx *intx_trigger;
> @@ -494,8 +494,7 @@ void intel_gvt_clean_vgpu_types(struct intel_gvt *gvt);
>
> struct intel_vgpu *intel_gvt_create_idle_vgpu(struct intel_gvt *gvt);
> void intel_gvt_destroy_idle_vgpu(struct intel_vgpu *vgpu);
> -struct intel_vgpu *intel_gvt_create_vgpu(struct intel_gvt *gvt,
> - struct intel_vgpu_type *type);
> +int intel_gvt_create_vgpu(struct intel_vgpu *vgpu, struct intel_vgpu_type
> *type);
> void intel_gvt_destroy_vgpu(struct intel_vgpu *vgpu);
> void intel_gvt_release_vgpu(struct intel_vgpu *vgpu);
> void intel_gvt_reset_vgpu_locked(struct intel_vgpu *vgpu, bool dmlr,
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index e3cd58946477..41bba40feef8 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1546,7 +1546,33 @@ static const struct attribute_group
> *intel_vgpu_groups[] = {
> NULL,
> };
>
> +static int intel_vgpu_init_dev(struct vfio_device *vfio_dev)
> +{
> + struct mdev_device *mdev = to_mdev_device(vfio_dev->dev);
> + struct device *pdev = mdev_parent_dev(mdev);
> + struct intel_gvt *gvt = kdev_to_i915(pdev)->gvt;
> + struct intel_vgpu_type *type;
> + struct intel_vgpu *vgpu = vfio_dev_to_vgpu(vfio_dev);
> +
> + type = >types[mdev_get_type_group_id(mdev)];
> + if (!type)
> + return -EINVAL;
> +
> + vgpu->gvt = gvt;
> + return intel_gvt_create_vgpu(vgpu, type);
> +}
> +
> +static void intel_vgpu_release_dev(struct vfio_device *vfio_dev)
> +{
> + struct intel_vgpu *vgpu = vfio_dev_to_vgpu(vfio_dev);
> +
> + intel_gvt_destroy_vgpu(vgpu);
> + vfio_free_device(vfio_dev);
> +}
> +
> static const struct vfio_device_ops intel_vgpu_dev_ops = {
> + .init = intel_vgpu_init_dev,
> + .release= intel_vgpu_release_dev,
> .open_device= intel_vgpu_open_device,
> .close_device = intel_vgpu_close_device,
> .read = intel_vgpu_read,
> @@ -1558,35 +1584,28 @@ static const struct vfio_device_ops
> intel_vgpu_dev_ops = {
>
> static int intel_vgpu_probe(struct mdev_device *mdev)
> {
> - struct device *pdev = mdev_parent_dev(mdev);
> - struct intel_gvt *gvt = kdev_to_i915(pdev)->gvt;
> - struct intel_vgpu_type *type;
> struct intel_vgpu *vgpu;
> int ret;
>
> - type = >types[mdev_get_type_group_id(mdev)];
> - if (!type)
> - return -EINVAL;
> -
> - vgpu = intel_gvt_create_vgpu(gvt, type);
> + vgpu = vfio_alloc_device(intel_vgpu, vfio_device, >dev,
> + _vgpu_dev_ops);
> if (IS_ERR(vgpu)) {
> gvt_err("failed to create intel vgpu: %ld\n", PTR_ERR(vgpu));
> return PTR_ERR(vgpu);
> }
>
> - vfio_init_group_dev(>vfio_device, >dev,
> - _vgpu_dev_ops);
> -
> dev_set_drvdata(>dev, vgpu);
> ret = vfio_register_emulated_iommu_dev(>vfio_device);
> - if (ret) {
> - intel_gvt_destroy_vgpu(vgpu);
> - return ret;
> - }
> + if (ret)
> + goto out_put_vdev;
>
> gvt_dbg_core("intel_vgpu_create succeeded for mdev: %s\n",
>dev_name(mdev_dev(mdev)));
> return 0;
> +
> +out_put_vdev:
> + vfio_put_device(>vfio_device);
> + return ret;
> }
>
> static void intel_vgpu_remove(struct mdev_device *mdev)
> @@ -1595,7 +1614,8 @@ static void intel_vgpu_remove(struct mdev_device *mdev)
>
> if (WARN_ON_ONCE(vgpu->attached))
> return;
> - intel_gvt_destroy_vgpu(vgpu);
> +
> + vfio_put_device(>vfio_device);
> }
>
> static struct mdev_driver
Re: [Intel-gfx] [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
On 2022.09.06 19:36:56 +0800, Zheng Hacker wrote:
> Hi Greg,
>
> Alex has explained how we figured out the patch. We did analyze the
> code and found it possible to reach the vulnerability code. But we
> have no physical device in hand to test the driver. So we'd like to
> discuss with developers to see if the issue exists or not.
>
> Best regards,
> Zheng Wang.
>
> Greg KH ???2022???9???5? 16:04?
> >
> > On Mon, Sep 05, 2022 at 03:46:09PM +0800, Zheng Hacker wrote:
> > > I rewrote the letter. Hope it works.
> > >
> > > There is a double-free security bug in split_2MB_gtt_entry.
> > >
> > > Here is a calling chain :
> > > ppgtt_populate_spt->ppgtt_populate_shadow_entry->split_2MB_gtt_entry.
> > > If intel_gvt_dma_map_guest_page failed, it will call
> > > ppgtt_invalidate_spt, which will finally call ppgtt_free_spt and
> > > kfree(spt). But the caller does not notice that, and it will call
> > > ppgtt_free_spt again in error path.
> > >
It's a little mess in code so in theory it might be possible but
intel_gvt_dma_map_guest_page won't fail in practise...
> > > Fix this by returning the result of ppgtt_invalidate_spt to
> > > split_2MB_gtt_entry.
> > >
I don't see why changing ret value can fix this issue, as it doesn't change
any behavior e.g caller of ppgtt_populate_spt to handle possible different
error return.
As current code looks assuming that ppgtt_invalidate_spt would free spt in good
case,
I think the real cleanup should split that assumption and handle free in error
case properly.
> > > Signed-off-by: Zheng Wang
This misses proper email address.
thanks
> > >
> > > ---
> > > drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c
> > > b/drivers/gpu/drm/i915/gvt/gtt.c
> > > index ce0eb03709c3..9f14fded8c0c 100644
> > > --- a/drivers/gpu/drm/i915/gvt/gtt.c
> > > +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> > > @@ -1215,7 +1215,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu
> > > *vgpu,
> > > ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn +
> > > sub_index,
> > >PAGE_SIZE, _addr);
> > > if (ret) {
> > > - ppgtt_invalidate_spt(spt);
> > > + ret = ppgtt_invalidate_spt(spt);
> > > return ret;
> >
> > But now you just lost the original error, shouldn't this succeed even if
> > intel_gvt_dma_map_guest_page() failed?
> >
> > And how are you causing intel_gvt_dma_map_guest_page() to fail in a real
> > system?
> >
> > thanks,
> >
> > greg k-h
signature.asc
Description: PGP signature
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915/uc: Support for version reduced and multiple firmware files
== Series Details == Series: series starting with [CI,1/2] drm/i915/uc: Support for version reduced and multiple firmware files URL : https://patchwork.freedesktop.org/series/108212/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12083_full -> Patchwork_108212v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108212v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108212v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 12) -- Additional (1): shard-rkl Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108212v1_full: ### IGT changes ### Possible regressions * igt@gem_exec_whisper@basic-queues-priority-all: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-iclb7/igt@gem_exec_whis...@basic-queues-priority-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/shard-iclb4/igt@gem_exec_whis...@basic-queues-priority-all.html * igt@kms_panel_fitting@atomic-fastset@pipe-b-edp-1: - shard-iclb: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-iclb2/igt@kms_panel_fitting@atomic-fast...@pipe-b-edp-1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/shard-iclb2/igt@kms_panel_fitting@atomic-fast...@pipe-b-edp-1.html Known issues Here are the changes found in Patchwork_108212v1_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29]) -> ([PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [FAIL][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54]) ([i915#4392]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk8/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk1/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk1/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk1/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk2/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk2/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk2/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk3/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk3/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk3/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk6/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk6/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk6/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk7/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk7/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk7/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk8/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk8/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk9/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk9/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk9/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/shard-glk9/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/shard-glk1/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/shard-glk1/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/shard-glk1/boot.html [33]:
Re: [Intel-gfx] [PATCH v2 01/15] vfio: Add helpers for unifying vfio_device life cycle
> From: Christoph Hellwig > Sent: Tuesday, September 6, 2022 5:42 PM > > What is the point? This adds indirect calls, and actually creates > more boilerplate code in the drivers. i.g. when using this code there > is more, and harder to read code. The point is to align with struct device life cycle when it's introduced to vfio_device. The object is released via put_device() then what would be the alternative if the driver doesn't provide a @release callback? and with @release then naturally @init is also expected. Most added code is in patch1 for implementing new helpers and patch15 for introducing struct device. Remaining addition is relatively small when scattered in each driver and most is due to creating new functions hence new local variables. and IMHO the readability is improved as it clearly contains the init/release logic around the device object. Thanks Kevin
[Intel-gfx] ✓ Fi.CI.BAT: success for i915: Add "standalone media" support for MTL (rev4)
== Series Details ==
Series: i915: Add "standalone media" support for MTL (rev4)
URL : https://patchwork.freedesktop.org/series/107908/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12083 -> Patchwork_107908v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/index.html
Participating hosts (43 -> 40)
--
Missing(3): fi-kbl-soraka fi-icl-u2 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_107908v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][1] -> [INCOMPLETE][2] ([i915#4785])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-pnv-d510:NOTRUN -> [SKIP][3] ([fdo#109271])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][4] ([fdo#109271] / [i915#4312] /
[i915#5594] / [i915#6246])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-rplp-1}: [DMESG-WARN][5] ([i915#2867]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [INCOMPLETE][7] ([i915#5153]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][9] ([i915#4528]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [DMESG-FAIL][11] ([i915#4983]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/bat-rpls-1/igt@i915_selftest@l...@reset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][13] ([i915#6298]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107908v4/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.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
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5153]: https://gitlab.freedesktop.org/drm/intel/issues/5153
[i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594
[i915#6246]: https://gitlab.freedesktop.org/drm/intel/issues/6246
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6730]: https://gitlab.freedesktop.org/drm/intel/issues/6730
Build changes
-
* Linux: CI_DRM_12083 -> Patchwork_107908v4
CI-20190529: 20190529
CI_DRM_12083: 6d9507979ab2eb2f0f4a57e491410eae49b330d0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6646: c1f420ae84b76079cd32ac014cfdf95b5f2922f7 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_107908v4: 6d9507979ab2eb2f0f4a57e491410eae49b330d0 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
e06bebed706e drm/i915/mtl: Hook up interrupts for standalone media
3b7856b9961b drm/i915/mtl: Use primary GT's irq lock for media GT
15933a8548af drm/i915/xelpmp: Expose media as another GT
2d5e6dd0fa51 drm/i915/mtl: Add gsi_offset when
Re: [Intel-gfx] [PATCH v3 04/14] drm/i915: Drop intel_gt_tile_cleanup()
On Tue, Sep 06, 2022 at 04:49:24PM -0700, Matt Roper wrote: Unmapping of the MMIO range can be done as a DRM-managed action, which will take care of the unmapping on device teardown and error paths. This will also ensure proper ordering with respect to other DRM-managed actions that we'll be using to clean up non-primary GTs in upcoming patches. We have not yet enabled any non-root GTs in the driver yet, so the kfree() of the GT structure is effectively dead code. When we do start enabling non-root GTs in upcoming patches, those are going to be using DRM-managed allocations tied to the device lifetime, so we don't need to explicitly free them (and kfree would be incorrect anyway). Signed-off-by: Matt Roper Reviewed-by: Lucas De Marchi Lucas De Marchi
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: Add "standalone media" support for MTL (rev4)
== Series Details == Series: i915: Add "standalone media" support for MTL (rev4) URL : https://patchwork.freedesktop.org/series/107908/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: Add "standalone media" support for MTL (rev4)
== Series Details ==
Series: i915: Add "standalone media" support for MTL (rev4)
URL : https://patchwork.freedesktop.org/series/107908/
State : warning
== Summary ==
Error: dim checkpatch failed
c661b3282c5a drm/i915: Move locking and unclaimed check into
mmio_debug_{suspend, resume}
4c204c08be6f drm/i915: Only hook up uncore->debug for primary uncore
010f263f4b04 drm/i915: Use managed allocations for extra uncore objects
a16b305625aa drm/i915: Drop intel_gt_tile_cleanup()
bbded340bce5 drm/i915: Prepare more multi-GT initialization
-:20: WARNING:TYPO_SPELLING: 'forseeable' may be misspelled - perhaps
'foreseeable'?
#20:
forseeable future. (Jani)
^^
-:75: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"gtdef->name"
#75: FILE: drivers/gpu/drm/i915/gt/intel_gt.c:839:
+gtdef->name != NULL;
total: 0 errors, 1 warnings, 1 checks, 154 lines checked
f741cc27d52c drm/i915: Rename and expose common GT early init routine
21b959602cb9 drm/i915: Use a DRM-managed action to release the PCI bridge device
32733d6164a6 drm/i915: Initialize MMIO access for each GT
5dd04650b127 drm/i915: Handle each GT on init/release and suspend/resume
681cf57bc1a1 drm/i915/uncore: Add GSI offset to uncore
c0008bff7ae6 drm/i915/mtl: Add gsi_offset when emitting aux table invalidation
3c57ee4c6106 drm/i915/xelpmp: Expose media as another GT
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in
import git
ModuleNotFoundError: No module named 'git'
-:85: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#85:
new file mode 100644
-:121: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"!uncore->regs"
#121: FILE: drivers/gpu/drm/i915/gt/intel_sa_media.c:32:
+ if (drm_WARN_ON(>drm, uncore->regs == NULL))
total: 0 errors, 1 warnings, 1 checks, 130 lines checked
da4f6c934628 drm/i915/mtl: Use primary GT's irq lock for media GT
-:85: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#85: FILE: drivers/gpu/drm/i915/gt/intel_gt.c:791:
+ spinlock_t *irq_lock;
-:231: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#231: FILE: drivers/gpu/drm/i915/gt/intel_gt_types.h:166:
+ spinlock_t *irq_lock;
total: 0 errors, 0 warnings, 2 checks, 477 lines checked
b6f222748eb1 drm/i915/mtl: Hook up interrupts for standalone media
[Intel-gfx] [PATCH v3 09/14] drm/i915: Handle each GT on init/release and suspend/resume
In preparation for enabling a second GT, there are a number of GT/uncore
operations that happen during initialization or suspend flows that need
to be performed on each GT, not just the primary,
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 59 +-
1 file changed, 42 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index bb9ba1aed1bb..e5c3cf5045d4 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -310,8 +310,13 @@ static void intel_detect_preproduction_hw(struct
drm_i915_private *dev_priv)
static void sanitize_gpu(struct drm_i915_private *i915)
{
- if (!INTEL_INFO(i915)->gpu_reset_clobbers_display)
- __intel_gt_reset(to_gt(i915), ALL_ENGINES);
+ if (!INTEL_INFO(i915)->gpu_reset_clobbers_display) {
+ struct intel_gt *gt;
+ unsigned int i;
+
+ for_each_gt(gt, i915, i)
+ __intel_gt_reset(gt, ALL_ENGINES);
+ }
}
/**
@@ -730,6 +735,8 @@ static void i915_driver_hw_remove(struct drm_i915_private
*dev_priv)
static void i915_driver_register(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = _priv->drm;
+ struct intel_gt *gt;
+ unsigned int i;
i915_gem_driver_register(dev_priv);
i915_pmu_register(dev_priv);
@@ -749,7 +756,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
/* Depends on sysfs having been initialized */
i915_perf_register(dev_priv);
- intel_gt_driver_register(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_driver_register(gt);
intel_display_driver_register(dev_priv);
@@ -768,6 +776,9 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
*/
static void i915_driver_unregister(struct drm_i915_private *dev_priv)
{
+ struct intel_gt *gt;
+ unsigned int i;
+
i915_switcheroo_unregister(dev_priv);
intel_unregister_dsm_handler();
@@ -777,7 +788,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
intel_display_driver_unregister(dev_priv);
- intel_gt_driver_unregister(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_driver_unregister(gt);
i915_perf_unregister(dev_priv);
i915_pmu_unregister(dev_priv);
@@ -799,6 +811,8 @@ static void i915_welcome_messages(struct drm_i915_private
*dev_priv)
{
if (drm_debug_enabled(DRM_UT_DRIVER)) {
struct drm_printer p = drm_debug_printer("i915 device info:");
+ struct intel_gt *gt;
+ unsigned int i;
drm_printf(, "pciid=0x%04x rev=0x%02x platform=%s
(subplatform=0x%x) gen=%i\n",
INTEL_DEVID(dev_priv),
@@ -811,7 +825,8 @@ static void i915_welcome_messages(struct drm_i915_private
*dev_priv)
intel_device_info_print(INTEL_INFO(dev_priv),
RUNTIME_INFO(dev_priv), );
i915_print_iommu_status(dev_priv, );
- intel_gt_info_print(_gt(dev_priv)->info, );
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_info_print(>info, );
}
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
@@ -1230,13 +1245,15 @@ static int i915_drm_suspend_late(struct drm_device
*dev, bool hibernation)
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
struct intel_runtime_pm *rpm = _priv->runtime_pm;
- int ret;
+ struct intel_gt *gt;
+ int ret, i;
disable_rpm_wakeref_asserts(rpm);
i915_gem_suspend_late(dev_priv);
- intel_uncore_suspend(_priv->uncore);
+ for_each_gt(gt, dev_priv, i)
+ intel_uncore_suspend(gt->uncore);
intel_power_domains_suspend(dev_priv,
get_suspend_mode(dev_priv, hibernation));
@@ -1368,7 +1385,8 @@ static int i915_drm_resume_early(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
- int ret;
+ struct intel_gt *gt;
+ int ret, i;
/*
* We have a resume ordering issue with the snd-hda driver also
@@ -1422,9 +1440,10 @@ static int i915_drm_resume_early(struct drm_device *dev)
drm_err(_priv->drm,
"Resume prepare failed: %d, continuing anyway\n", ret);
- intel_uncore_resume_early(_priv->uncore);
-
- intel_gt_check_and_clear_faults(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i) {
+ intel_uncore_resume_early(gt->uncore);
+ intel_gt_check_and_clear_faults(gt);
+ }
[Intel-gfx] [PATCH v3 14/14] drm/i915/mtl: Hook up interrupts for standalone media
Top-level handling of standalone media interrupts will be processed as
part of the primary GT's interrupt handler (since primary and media GTs
share an MMIO space, unlike remote tile setups). When we get down to
the point of handling engine interrupts, we need to take care to lookup
VCS and VECS engines in the media GT rather than the primary.
There are also a couple of additional "other" instance bits that
correspond to the media GT's GuC and media GT's power management
interrupts; we need to direct those to the media GT instance as well.
Bspec: 45605
Cc: Anusha Srivatsa
Signed-off-by: Matt Roper
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 19 +++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
drivers/gpu/drm/i915/gt/intel_sa_media.c | 7 +++
drivers/gpu/drm/i915/i915_drv.h | 3 +++
4 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 0dfd0c42d00d..f26882fdc24c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -59,11 +59,17 @@ static void
gen11_other_irq_handler(struct intel_gt *gt, const u8 instance,
const u16 iir)
{
+ struct intel_gt *media_gt = gt->i915->media_gt;
+
if (instance == OTHER_GUC_INSTANCE)
return guc_irq_handler(>uc.guc, iir);
+ if (instance == OTHER_MEDIA_GUC_INSTANCE && media_gt)
+ return guc_irq_handler(_gt->uc.guc, iir);
if (instance == OTHER_GTPM_INSTANCE)
return gen11_rps_irq_handler(>rps, iir);
+ if (instance == OTHER_MEDIA_GTPM_INSTANCE && media_gt)
+ return gen11_rps_irq_handler(_gt->rps, iir);
if (instance == OTHER_KCR_INSTANCE)
return intel_pxp_irq_handler(>pxp, iir);
@@ -81,6 +87,18 @@ gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
{
struct intel_engine_cs *engine;
+ /*
+* Platforms with standalone media have their media engines in another
+* GT.
+*/
+ if (MEDIA_VER(gt->i915) >= 13 &&
+ (class == VIDEO_DECODE_CLASS || class == VIDEO_ENHANCEMENT_CLASS)) {
+ if (!gt->i915->media_gt)
+ goto err;
+
+ gt = gt->i915->media_gt;
+ }
+
if (instance <= MAX_ENGINE_INSTANCE)
engine = gt->engine_class[class][instance];
else
@@ -89,6 +107,7 @@ gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
if (likely(engine))
return intel_engine_cs_irq(engine, iir);
+err:
WARN_ONCE(1, "unhandled engine interrupt class=0x%x, instance=0x%x\n",
class, instance);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index fb2c56777480..2275ee47da95 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1554,6 +1554,8 @@
#define OTHER_GTPM_INSTANCE 1
#define OTHER_KCR_INSTANCE 4
#define OTHER_GSC_INSTANCE 6
+#define OTHER_MEDIA_GUC_INSTANCE 16
+#define OTHER_MEDIA_GTPM_INSTANCE17
#define GEN11_IIR_REG_SELECTOR(x) _MMIO(0x190070 + ((x) * 4))
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.c
b/drivers/gpu/drm/i915/gt/intel_sa_media.c
index 5516e9c363a4..e8f3d18c12b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_sa_media.c
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.c
@@ -36,5 +36,12 @@ int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t
phys_addr,
gt->uncore = uncore;
gt->phys_addr = phys_addr;
+ /*
+* For current platforms we can assume there's only a single
+* media GT and cache it for quick lookup.
+*/
+ drm_WARN_ON(>drm, i915->media_gt);
+ i915->media_gt = gt;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f010be8df851..5aff92e106ef 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -365,6 +365,9 @@ struct drm_i915_private {
struct kobject *sysfs_gt;
+ /* Quick lookup of media GT (current platforms only have one) */
+ struct intel_gt *media_gt;
+
struct {
struct i915_gem_contexts {
spinlock_t lock; /* locks list */
--
2.37.2
[Intel-gfx] [PATCH v3 13/14] drm/i915/mtl: Use primary GT's irq lock for media GT
When we hook up interrupts (in the next patch), interrupts for the media
GT are still processed as part of the primary GT's interrupt flow. As
such, we should share the same IRQ lock with the primary GT. Let's
convert gt->irq_lock into a pointer and just point the media GT's
instance at the same lock the primary GT is using.
v2:
- Point media's gt->irq_lock at the primary GT lock properly. (Daniele)
- Fix jump target for intel_root_gt_init_early errors. (Daniele)
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +++---
drivers/gpu/drm/i915/gt/intel_gt.c| 15 +--
drivers/gpu/drm/i915/gt/intel_gt.h| 2 +-
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 16 ++--
drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 8 +++---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 26 +--
drivers/gpu/drm/i915/gt/intel_sa_media.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 24 -
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +--
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +--
drivers/gpu/drm/i915/i915_driver.c| 5 +++-
drivers/gpu/drm/i915/i915_irq.c | 4 +--
drivers/gpu/drm/i915/pxp/intel_pxp.c | 4 +--
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 4 +--
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 14 +-
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 4 +--
17 files changed, 80 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 41acc285e8bf..6e0122b3dca2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1688,9 +1688,9 @@ bool intel_engine_irq_enable(struct intel_engine_cs
*engine)
return false;
/* Caller disables interrupts */
- spin_lock(>gt->irq_lock);
+ spin_lock(engine->gt->irq_lock);
engine->irq_enable(engine);
- spin_unlock(>gt->irq_lock);
+ spin_unlock(engine->gt->irq_lock);
return true;
}
@@ -1701,9 +1701,9 @@ void intel_engine_irq_disable(struct intel_engine_cs
*engine)
return;
/* Caller disables interrupts */
- spin_lock(>gt->irq_lock);
+ spin_lock(engine->gt->irq_lock);
engine->irq_disable(engine);
- spin_unlock(>gt->irq_lock);
+ spin_unlock(engine->gt->irq_lock);
}
void intel_engines_reset_default_submission(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 9b9c0ea73b7f..b59fb03ed274 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -38,7 +38,7 @@
void intel_gt_common_init_early(struct intel_gt *gt)
{
- spin_lock_init(>irq_lock);
+ spin_lock_init(gt->irq_lock);
INIT_LIST_HEAD(>closed_vma);
spin_lock_init(>closed_lock);
@@ -59,14 +59,19 @@ void intel_gt_common_init_early(struct intel_gt *gt)
}
/* Preliminary initialization of Tile 0 */
-void intel_root_gt_init_early(struct drm_i915_private *i915)
+int intel_root_gt_init_early(struct drm_i915_private *i915)
{
struct intel_gt *gt = to_gt(i915);
gt->i915 = i915;
gt->uncore = >uncore;
+ gt->irq_lock = drmm_kzalloc(>drm, sizeof(*gt->irq_lock),
GFP_KERNEL);
+ if (!gt->irq_lock)
+ return -ENOMEM;
intel_gt_common_init_early(gt);
+
+ return 0;
}
static int intel_gt_probe_lmem(struct intel_gt *gt)
@@ -783,12 +788,18 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
if (!gt_is_root(gt)) {
struct intel_uncore *uncore;
+ spinlock_t *irq_lock;
uncore = drmm_kzalloc(>i915->drm, sizeof(*uncore),
GFP_KERNEL);
if (!uncore)
return -ENOMEM;
+ irq_lock = drmm_kzalloc(>i915->drm, sizeof(*irq_lock),
GFP_KERNEL);
+ if (!irq_lock)
+ return -ENOMEM;
+
gt->uncore = uncore;
+ gt->irq_lock = irq_lock;
intel_gt_common_init_early(gt);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index c9a359f35d0f..2ee582e287c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -45,7 +45,7 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc
*gsc)
}
void intel_gt_common_init_early(struct intel_gt *gt);
-void intel_root_gt_init_early(struct drm_i915_private *i915);
+int intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
int intel_gt_init_mmio(struct intel_gt *gt);
int __must_check intel_gt_init_hw(struct intel_gt *gt);
diff --git
[Intel-gfx] [PATCH v3 10/14] drm/i915/uncore: Add GSI offset to uncore
GT non-engine registers (referred to as "GSI" registers by the spec)
have the same relative offsets on standalone media as they do on the
primary GT, just with an additional "GSI offset" added to their MMIO
address. If we store this GSI offset in the standalone media's
intel_uncore structure, it can be automatically applied to all GSI reg
reads/writes that happen on that GT, allowing us to re-use our existing
GT code with minimal changes.
Forcewake and shadowed register tables for the media GT (which will be
added in a future patch) are listed as final addresses that already
include the GSI offset, so we also need to add the GSI offset before
doing lookups of registers in one of those tables.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 1 +
drivers/gpu/drm/i915/intel_uncore.c | 10 --
drivers/gpu/drm/i915/intel_uncore.h | 22 --
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 0e139f7d75ed..82dc28643572 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -274,6 +274,7 @@ struct intel_gt_definition {
enum intel_gt_type type;
char *name;
u32 mapping_base;
+ u32 gsi_offset;
intel_engine_mask_t engine_mask;
};
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 452b3a31e965..5cd423c7b646 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -928,6 +928,9 @@ find_fw_domain(struct intel_uncore *uncore, u32 offset)
{
const struct intel_forcewake_range *entry;
+ if (IS_GSI_REG(offset))
+ offset += uncore->gsi_offset;
+
entry = BSEARCH(offset,
uncore->fw_domains_table,
uncore->fw_domains_table_entries,
@@ -1143,6 +1146,9 @@ static bool is_shadowed(struct intel_uncore *uncore, u32
offset)
if (drm_WARN_ON(>i915->drm, !uncore->shadowed_reg_table))
return false;
+ if (IS_GSI_REG(offset))
+ offset += uncore->gsi_offset;
+
return BSEARCH(offset,
uncore->shadowed_reg_table,
uncore->shadowed_reg_table_entries,
@@ -1995,8 +2001,8 @@ static int __fw_domain_init(struct intel_uncore *uncore,
d->uncore = uncore;
d->wake_count = 0;
- d->reg_set = uncore->regs + i915_mmio_reg_offset(reg_set);
- d->reg_ack = uncore->regs + i915_mmio_reg_offset(reg_ack);
+ d->reg_set = uncore->regs + i915_mmio_reg_offset(reg_set) +
uncore->gsi_offset;
+ d->reg_ack = uncore->regs + i915_mmio_reg_offset(reg_ack) +
uncore->gsi_offset;
d->id = domain_id;
diff --git a/drivers/gpu/drm/i915/intel_uncore.h
b/drivers/gpu/drm/i915/intel_uncore.h
index 4acb78a03233..7f1d7903a8f3 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -136,6 +136,16 @@ struct intel_uncore {
spinlock_t lock; /** lock is also taken in irq contexts. */
+ /*
+* Do we need to apply an additional offset to reach the beginning
+* of the basic non-engine GT registers (referred to as "GSI" on
+* newer platforms, or "GT block" on older platforms)? If so, we'll
+* track that here and apply it transparently to registers in the
+* appropriate range to maintain compatibility with our existing
+* register definitions and GT code.
+*/
+ u32 gsi_offset;
+
unsigned int flags;
#define UNCORE_HAS_FORCEWAKE BIT(0)
#define UNCORE_HAS_FPGA_DBG_UNCLAIMED BIT(1)
@@ -294,19 +304,27 @@ intel_wait_for_register_fw(struct intel_uncore *uncore,
2, timeout_ms, NULL);
}
+#define IS_GSI_REG(reg) ((reg) < 0x4)
+
/* register access functions */
#define __raw_read(x__, s__) \
static inline u##x__ __raw_uncore_read##x__(const struct intel_uncore *uncore,
\
i915_reg_t reg) \
{ \
- return read##s__(uncore->regs + i915_mmio_reg_offset(reg)); \
+ u32 offset = i915_mmio_reg_offset(reg); \
+ if (IS_GSI_REG(offset)) \
+ offset += uncore->gsi_offset; \
+ return read##s__(uncore->regs + offset); \
}
#define __raw_write(x__, s__) \
static inline void __raw_uncore_write##x__(const struct intel_uncore *uncore, \
i915_reg_t reg, u##x__ val) \
{ \
- write##s__(val, uncore->regs + i915_mmio_reg_offset(reg)); \
+ u32 offset = i915_mmio_reg_offset(reg); \
+ if (IS_GSI_REG(offset)) \
+ offset += uncore->gsi_offset; \
+ write##s__(val, uncore->regs + offset); \
}
__raw_read(8, b)
__raw_read(16, w)
--
2.37.2
[Intel-gfx] [PATCH v3 05/14] drm/i915: Prepare more multi-GT initialization
We're going to introduce an additional intel_gt for MTL's media unit
soon. Let's provide a bit more multi-GT initialization framework in
preparation for that. The initialization will pull the list of GTs for
a platform from the device info structure. Although necessary for the
immediate MTL media enabling, this same framework will also be used
farther down the road when we enable remote tiles on xehpsdv and pvc.
v2:
- Re-add missing test for !HAS_EXTRA_GT_LIST in intel_gt_probe_all().
v3:
- Move intel_gt_definition struct to intel_gt_types.h. (Jani)
- Drop gtdef->setup(). For now we'll just use a switch() based on GT
type since we don't have too many different handlers for the
forseeable future. (Jani)
Cc: Aravind Iddamsetty
Cc: Jani Nikula
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 59 ++-
drivers/gpu/drm/i915/gt/intel_gt.h| 1 -
drivers/gpu/drm/i915/gt/intel_gt_types.h | 15 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_device_info.h | 3 +
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
7 files changed, 80 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 275ad72940c1..41acc285e8bf 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -736,7 +736,7 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt
*gt)
u16 vdbox_mask;
u16 vebox_mask;
- info->engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
+ GEM_BUG_ON(!info->engine_mask);
if (GRAPHICS_VER(i915) < 11)
return info->engine_mask;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 663a4798fb2e..85c75375391c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -807,8 +807,10 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
{
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
struct intel_gt *gt = >gt0;
+ const struct intel_gt_definition *gtdef;
phys_addr_t phys_addr;
unsigned int mmio_bar;
+ unsigned int i;
int ret;
mmio_bar = GRAPHICS_VER(i915) == 2 ? GEN2_GTTMMADR_BAR : GTTMMADR_BAR;
@@ -819,14 +821,69 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
* and it has been already initialized early during probe
* in i915_driver_probe()
*/
+ gt->i915 = i915;
+ gt->name = "Primary GT";
+ gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
+
+ drm_dbg(>drm, "Setting up %s\n", gt->name);
ret = intel_gt_tile_setup(gt, phys_addr);
if (ret)
return ret;
i915->gt[0] = gt;
- /* TODO: add more tiles */
+ if (!HAS_EXTRA_GT_LIST(i915))
+ return 0;
+
+ for (i = 1, gtdef = _INFO(i915)->extra_gt_list[i - 1];
+gtdef->name != NULL;
+i++, gtdef = _INFO(i915)->extra_gt_list[i - 1]) {
+ gt = drmm_kzalloc(>drm, sizeof(*gt), GFP_KERNEL);
+ if (!gt) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ gt->i915 = i915;
+ gt->name = gtdef->name;
+ gt->type = gtdef->type;
+ gt->info.engine_mask = gtdef->engine_mask;
+ gt->info.id = i;
+
+ drm_dbg(>drm, "Setting up %s\n", gt->name);
+ if (GEM_WARN_ON(range_overflows_t(resource_size_t,
+ gtdef->mapping_base,
+ SZ_16M,
+ pci_resource_len(pdev,
mmio_bar {
+ ret = -ENODEV;
+ goto err;
+ }
+
+ switch (gtdef->type) {
+ case GT_TILE:
+ ret = intel_gt_tile_setup(gt, phys_addr +
gtdef->mapping_base);
+ break;
+
+ case GT_PRIMARY:
+ /* Primary GT should not appear in extra GT list */
+ default:
+ MISSING_CASE(gtdef->type);
+ ret = -ENODEV;
+ }
+
+ if (ret)
+ goto err;
+
+ i915->gt[i] = gt;
+ }
+
return 0;
+
+err:
+ i915_probe_error(i915, "Failed to initialize %s! (%d)\n", gtdef->name,
ret);
+ intel_gt_release_all(i915);
+
+ return ret;
}
int intel_gt_tiles_init(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 40b06adf509a..4d8779529cc2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
[Intel-gfx] [PATCH v3 02/14] drm/i915: Only hook up uncore->debug for primary uncore
The original intent of intel_uncore_mmio_debug as described in commit
0a9b26306d6a ("drm/i915: split out uncore_mmio_debug") was to be a
singleton structure that could be shared between multiple GTs' uncore
objects in a multi-tile system. Somehow we went off track and
started allocating separate instances of this structure for each GT,
which defeats that original goal.
But in reality, there isn't even a need to share the mmio_debug between
multiple GTs; on all modern platforms (i.e., everything after gen7)
unclaimed register accesses are something that can only be detected for
display registers. There's no point in grabbing the debug spinlock and
checking for unclaimed accesses on an uncore used by an xehpsdv or pvc
remote tile GT, or the uncore used by a mtl standalone media GT since
all of the display accesses go through the primary intel_uncore.
The simplest solution is to simply leave uncore->debug NULL on all
intel_uncore instances except for the primary one. This will allow us
to avoid the pointless debug spinlock acquisition we've been doing on
MMIO accesses coming in through these intel_uncores.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt.c | 9 -
drivers/gpu/drm/i915/i915_driver.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 23 ++-
drivers/gpu/drm/i915/intel_uncore.h | 3 +--
4 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index e4bac2431e41..a82b5e2e0d83 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -781,21 +781,13 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
int ret;
if (!gt_is_root(gt)) {
- struct intel_uncore_mmio_debug *mmio_debug;
struct intel_uncore *uncore;
uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
if (!uncore)
return -ENOMEM;
- mmio_debug = kzalloc(sizeof(*mmio_debug), GFP_KERNEL);
- if (!mmio_debug) {
- kfree(uncore);
- return -ENOMEM;
- }
-
gt->uncore = uncore;
- gt->uncore->debug = mmio_debug;
__intel_gt_init_early(gt);
}
@@ -817,7 +809,6 @@ intel_gt_tile_cleanup(struct intel_gt *gt)
intel_uncore_cleanup_mmio(gt->uncore);
if (!gt_is_root(gt)) {
- kfree(gt->uncore->debug);
kfree(gt->uncore);
kfree(gt);
}
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 56a2bcddb2af..18acba1bc3b0 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -326,7 +326,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
intel_device_info_subplatform_init(dev_priv);
intel_step_init(dev_priv);
- intel_uncore_mmio_debug_init_early(_priv->mmio_debug);
+ intel_uncore_mmio_debug_init_early(dev_priv);
spin_lock_init(_priv->irq_lock);
spin_lock_init(_priv->gpu_error.lock);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e717ea55484a..6841f76533f9 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -44,14 +44,19 @@ fw_domains_get(struct intel_uncore *uncore, enum
forcewake_domains fw_domains)
}
void
-intel_uncore_mmio_debug_init_early(struct intel_uncore_mmio_debug *mmio_debug)
+intel_uncore_mmio_debug_init_early(struct drm_i915_private *i915)
{
- spin_lock_init(_debug->lock);
- mmio_debug->unclaimed_mmio_check = 1;
+ spin_lock_init(>mmio_debug.lock);
+ i915->mmio_debug.unclaimed_mmio_check = 1;
+
+ i915->uncore.debug = >mmio_debug;
}
static void mmio_debug_suspend(struct intel_uncore *uncore)
{
+ if (!uncore->debug)
+ return;
+
spin_lock(>debug->lock);
/* Save and disable mmio debugging for the user bypass */
@@ -67,6 +72,9 @@ static bool check_for_unclaimed_mmio(struct intel_uncore
*uncore);
static void mmio_debug_resume(struct intel_uncore *uncore)
{
+ if (!uncore->debug)
+ return;
+
spin_lock(>debug->lock);
if (!--uncore->debug->suspend_count)
@@ -1705,7 +1713,7 @@ unclaimed_reg_debug(struct intel_uncore *uncore,
const bool read,
const bool before)
{
- if (likely(!uncore->i915->params.mmio_debug))
+ if (likely(!uncore->i915->params.mmio_debug) || !uncore->debug)
return;
/* interrupts are disabled and re-enabled around uncore->lock usage */
@@ -2267,7 +2275,6 @@ void intel_uncore_init_early(struct intel_uncore *uncore,
uncore->i915 = gt->i915;
uncore->gt = gt;
uncore->rpm =
[Intel-gfx] [PATCH v3 08/14] drm/i915: Initialize MMIO access for each GT
In a multi-GT system we need to initialize MMIO access for each GT, not
just the primary GT.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 27 ++-
drivers/gpu/drm/i915/intel_uncore.c | 5 -
drivers/gpu/drm/i915/intel_uncore.h | 3 ++-
3 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 1f46dd1ffaf7..bb9ba1aed1bb 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -431,7 +431,8 @@ static void i915_driver_late_release(struct
drm_i915_private *dev_priv)
*/
static int i915_driver_mmio_probe(struct drm_i915_private *dev_priv)
{
- int ret;
+ struct intel_gt *gt;
+ int ret, i;
if (i915_inject_probe_failure(dev_priv))
return -ENODEV;
@@ -440,17 +441,27 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
if (ret < 0)
return ret;
- ret = intel_uncore_init_mmio(_priv->uncore);
- if (ret)
- return ret;
+ for_each_gt(gt, dev_priv, i) {
+ ret = intel_uncore_init_mmio(gt->uncore);
+ if (ret)
+ return ret;
+
+ ret = drmm_add_action_or_reset(_priv->drm,
+ intel_uncore_fini_mmio,
+ gt->uncore);
+ if (ret)
+ return ret;
+ }
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev_priv);
intel_device_info_runtime_init(dev_priv);
- ret = intel_gt_init_mmio(to_gt(dev_priv));
- if (ret)
- goto err_uncore;
+ for_each_gt(gt, dev_priv, i) {
+ ret = intel_gt_init_mmio(gt);
+ if (ret)
+ goto err_uncore;
+ }
/* As early as possible, scrub existing GPU state before clobbering */
sanitize_gpu(dev_priv);
@@ -459,7 +470,6 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
err_uncore:
intel_teardown_mchbar(dev_priv);
- intel_uncore_fini_mmio(_priv->uncore);
return ret;
}
@@ -471,7 +481,6 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
static void i915_driver_mmio_release(struct drm_i915_private *dev_priv)
{
intel_teardown_mchbar(dev_priv);
- intel_uncore_fini_mmio(_priv->uncore);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 2a32f8a65f34..452b3a31e965 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2455,8 +2455,11 @@ void intel_uncore_prune_engine_fw_domains(struct
intel_uncore *uncore,
}
}
-void intel_uncore_fini_mmio(struct intel_uncore *uncore)
+/* Called via drm-managed action */
+void intel_uncore_fini_mmio(struct drm_device *dev, void *data)
{
+ struct intel_uncore *uncore = data;
+
if (intel_uncore_has_forcewake(uncore)) {
iosf_mbi_punit_acquire();
iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
diff --git a/drivers/gpu/drm/i915/intel_uncore.h
b/drivers/gpu/drm/i915/intel_uncore.h
index 6100d0f4498a..4acb78a03233 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -33,6 +33,7 @@
#include "i915_reg_defs.h"
+struct drm_device;
struct drm_i915_private;
struct intel_runtime_pm;
struct intel_uncore;
@@ -220,7 +221,7 @@ void intel_uncore_prune_engine_fw_domains(struct
intel_uncore *uncore,
bool intel_uncore_unclaimed_mmio(struct intel_uncore *uncore);
bool intel_uncore_arm_unclaimed_mmio_detection(struct intel_uncore *uncore);
void intel_uncore_cleanup_mmio(struct intel_uncore *uncore);
-void intel_uncore_fini_mmio(struct intel_uncore *uncore);
+void intel_uncore_fini_mmio(struct drm_device *dev, void *data);
void intel_uncore_suspend(struct intel_uncore *uncore);
void intel_uncore_resume_early(struct intel_uncore *uncore);
void intel_uncore_runtime_resume(struct intel_uncore *uncore);
--
2.37.2
[Intel-gfx] [PATCH v3 04/14] drm/i915: Drop intel_gt_tile_cleanup()
Unmapping of the MMIO range can be done as a DRM-managed action, which
will take care of the unmapping on device teardown and error paths.
This will also ensure proper ordering with respect to other DRM-managed
actions that we'll be using to clean up non-primary GTs in upcoming
patches.
We have not yet enabled any non-root GTs in the driver yet, so the
kfree() of the GT structure is effectively dead code. When we do start
enabling non-root GTs in upcoming patches, those are going to be using
DRM-managed allocations tied to the device lifetime, so we don't need to
explicitly free them (and kfree would be incorrect anyway).
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 13 +
drivers/gpu/drm/i915/intel_uncore.c | 13 +++--
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index cf7aab7adb30..663a4798fb2e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -803,15 +803,6 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
return 0;
}
-static void
-intel_gt_tile_cleanup(struct intel_gt *gt)
-{
- intel_uncore_cleanup_mmio(gt->uncore);
-
- if (!gt_is_root(gt))
- kfree(gt);
-}
-
int intel_gt_probe_all(struct drm_i915_private *i915)
{
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
@@ -858,10 +849,8 @@ void intel_gt_release_all(struct drm_i915_private *i915)
struct intel_gt *gt;
unsigned int id;
- for_each_gt(gt, i915, id) {
- intel_gt_tile_cleanup(gt);
+ for_each_gt(gt, i915, id)
i915->gt[id] = NULL;
- }
}
void intel_gt_info_print(const struct intel_gt_info *info,
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 6841f76533f9..2a32f8a65f34 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -21,6 +21,7 @@
* IN THE SOFTWARE.
*/
+#include
#include
#include "gt/intel_engine_regs.h"
@@ -2232,6 +2233,11 @@ static int i915_pmic_bus_access_notifier(struct
notifier_block *nb,
return NOTIFY_OK;
}
+static void uncore_unmap_mmio(struct drm_device *drm, void *regs)
+{
+ iounmap(regs);
+}
+
int intel_uncore_setup_mmio(struct intel_uncore *uncore, phys_addr_t phys_addr)
{
struct drm_i915_private *i915 = uncore->i915;
@@ -2260,12 +2266,7 @@ int intel_uncore_setup_mmio(struct intel_uncore *uncore,
phys_addr_t phys_addr)
return -EIO;
}
- return 0;
-}
-
-void intel_uncore_cleanup_mmio(struct intel_uncore *uncore)
-{
- iounmap(uncore->regs);
+ return drmm_add_action_or_reset(>drm, uncore_unmap_mmio,
uncore->regs);
}
void intel_uncore_init_early(struct intel_uncore *uncore,
--
2.37.2
[Intel-gfx] [PATCH v3 03/14] drm/i915: Use managed allocations for extra uncore objects
We're slowly transitioning the init-time kzalloc's of the driver over to
DRM-managed allocations; let's make sure the uncore objects allocated
for non-root GTs are thus allocated.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index a82b5e2e0d83..cf7aab7adb30 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -783,7 +783,7 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
if (!gt_is_root(gt)) {
struct intel_uncore *uncore;
- uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
+ uncore = drmm_kzalloc(>i915->drm, sizeof(*uncore),
GFP_KERNEL);
if (!uncore)
return -ENOMEM;
@@ -808,10 +808,8 @@ intel_gt_tile_cleanup(struct intel_gt *gt)
{
intel_uncore_cleanup_mmio(gt->uncore);
- if (!gt_is_root(gt)) {
- kfree(gt->uncore);
+ if (!gt_is_root(gt))
kfree(gt);
- }
}
int intel_gt_probe_all(struct drm_i915_private *i915)
--
2.37.2
[Intel-gfx] [PATCH v3 07/14] drm/i915: Use a DRM-managed action to release the PCI bridge device
As we start supporting multiple uncore structures in future patches, the
MMIO cleanup (which make also get called mid-init if there's a failure)
will become more complicated. Moving to DRM-managed actions will help
keep things simple.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 18acba1bc3b0..1f46dd1ffaf7 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -105,6 +105,12 @@ static const char irst_name[] = "INT3392";
static const struct drm_driver i915_drm_driver;
+static void i915_release_bridge_dev(struct drm_device *dev,
+ void *bridge)
+{
+ pci_dev_put(bridge);
+}
+
static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
{
int domain = pci_domain_nr(to_pci_dev(dev_priv->drm.dev)->bus);
@@ -115,7 +121,9 @@ static int i915_get_bridge_dev(struct drm_i915_private
*dev_priv)
drm_err(_priv->drm, "bridge device not found\n");
return -EIO;
}
- return 0;
+
+ return drmm_add_action_or_reset(_priv->drm, i915_release_bridge_dev,
+ dev_priv->bridge_dev);
}
/* Allocate space for the MCH regs if needed, return nonzero on error */
@@ -452,7 +460,6 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
err_uncore:
intel_teardown_mchbar(dev_priv);
intel_uncore_fini_mmio(_priv->uncore);
- pci_dev_put(dev_priv->bridge_dev);
return ret;
}
@@ -465,7 +472,6 @@ static void i915_driver_mmio_release(struct
drm_i915_private *dev_priv)
{
intel_teardown_mchbar(dev_priv);
intel_uncore_fini_mmio(_priv->uncore);
- pci_dev_put(dev_priv->bridge_dev);
}
/**
--
2.37.2
[Intel-gfx] [PATCH v3 11/14] drm/i915/mtl: Add gsi_offset when emitting aux table invalidation
The aux table invalidation registers are a bit unique --- they're
engine-centric registers that reside in the GSI register space rather
than within the engines' regular MMIO ranges. That means that when
issuing invalidation on engines in the standalone media GT, the GSI
offset must be added to the regular MMIO offset for the invalidation
registers.
Cc: Aravind Iddamsetty
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 15 ++-
drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 3 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 ++---
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 98645797962f..e49fa6fa6aee 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -165,10 +165,12 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
-u32 *gen12_emit_aux_table_inv(u32 *cs, const i915_reg_t inv_reg)
+u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t
inv_reg)
{
+ u32 gsi_offset = gt->uncore->gsi_offset;
+
*cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
- *cs++ = i915_mmio_reg_offset(inv_reg);
+ *cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
*cs++ = AUX_INV;
*cs++ = MI_NOOP;
@@ -254,7 +256,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
if (!HAS_FLAT_CCS(rq->engine->i915)) {
/* hsdes: 1809175790 */
- cs = gen12_emit_aux_table_inv(cs, GEN12_GFX_CCS_AUX_NV);
+ cs = gen12_emit_aux_table_inv(rq->engine->gt,
+ cs, GEN12_GFX_CCS_AUX_NV);
}
*cs++ = preparser_disable(false);
@@ -313,9 +316,11 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (aux_inv) { /* hsdes: 1809175790 */
if (rq->engine->class == VIDEO_DECODE_CLASS)
- cs = gen12_emit_aux_table_inv(cs, GEN12_VD0_AUX_NV);
+ cs = gen12_emit_aux_table_inv(rq->engine->gt,
+ cs, GEN12_VD0_AUX_NV);
else
- cs = gen12_emit_aux_table_inv(cs, GEN12_VE0_AUX_NV);
+ cs = gen12_emit_aux_table_inv(rq->engine->gt,
+ cs, GEN12_VE0_AUX_NV);
}
if (mode & EMIT_INVALIDATE)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index 32e3d2b831bb..e4d24c811dd6 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -13,6 +13,7 @@
#include "intel_gt_regs.h"
#include "intel_gpu_commands.h"
+struct intel_gt;
struct i915_request;
int gen8_emit_flush_rcs(struct i915_request *rq, u32 mode);
@@ -45,7 +46,7 @@ u32 *gen8_emit_fini_breadcrumb_rcs(struct i915_request *rq,
u32 *cs);
u32 *gen11_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs);
u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs);
-u32 *gen12_emit_aux_table_inv(u32 *cs, const i915_reg_t inv_reg);
+u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t
inv_reg);
static inline u32 *
__gen8_emit_pipe_control(u32 *batch, u32 flags0, u32 flags1, u32 offset)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 070cec4ff8a4..08214683e130 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1278,7 +1278,8 @@ gen12_emit_indirect_ctx_rcs(const struct intel_context
*ce, u32 *cs)
/* hsdes: 1809175790 */
if (!HAS_FLAT_CCS(ce->engine->i915))
- cs = gen12_emit_aux_table_inv(cs, GEN12_GFX_CCS_AUX_NV);
+ cs = gen12_emit_aux_table_inv(ce->engine->gt,
+ cs, GEN12_GFX_CCS_AUX_NV);
/* Wa_16014892111 */
if (IS_DG2(ce->engine->i915))
@@ -1304,9 +1305,11 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context
*ce, u32 *cs)
/* hsdes: 1809175790 */
if (!HAS_FLAT_CCS(ce->engine->i915)) {
if (ce->engine->class == VIDEO_DECODE_CLASS)
- cs = gen12_emit_aux_table_inv(cs, GEN12_VD0_AUX_NV);
+ cs = gen12_emit_aux_table_inv(ce->engine->gt,
+ cs, GEN12_VD0_AUX_NV);
else if (ce->engine->class == VIDEO_ENHANCEMENT_CLASS)
- cs = gen12_emit_aux_table_inv(cs, GEN12_VE0_AUX_NV);
+ cs = gen12_emit_aux_table_inv(ce->engine->gt,
+ cs, GEN12_VE0_AUX_NV);
}
return cs;
--
2.37.2
[Intel-gfx] [PATCH v3 06/14] drm/i915: Rename and expose common GT early init routine
The common early GT init is needed for initialization of all GT types
(root/primary, remote tile, standalone media). Since standalone media
(coming in a future patch) will be implemented in a separate file,
rename and expose the function for use.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt.c | 6 +++---
drivers/gpu/drm/i915/gt/intel_gt.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 85c75375391c..aa0e40987798 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -35,7 +35,7 @@
#include "intel_uncore.h"
#include "shmem_utils.h"
-static void __intel_gt_init_early(struct intel_gt *gt)
+void intel_gt_common_init_early(struct intel_gt *gt)
{
spin_lock_init(>irq_lock);
@@ -65,7 +65,7 @@ void intel_root_gt_init_early(struct drm_i915_private *i915)
gt->i915 = i915;
gt->uncore = >uncore;
- __intel_gt_init_early(gt);
+ intel_gt_common_init_early(gt);
}
static int intel_gt_probe_lmem(struct intel_gt *gt)
@@ -789,7 +789,7 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
gt->uncore = uncore;
- __intel_gt_init_early(gt);
+ intel_gt_common_init_early(gt);
}
intel_uncore_init_early(gt->uncore, gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 4d8779529cc2..c9a359f35d0f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -44,6 +44,7 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc
*gsc)
return container_of(gsc, struct intel_gt, gsc);
}
+void intel_gt_common_init_early(struct intel_gt *gt);
void intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
int intel_gt_init_mmio(struct intel_gt *gt);
--
2.37.2
[Intel-gfx] [PATCH v3 12/14] drm/i915/xelpmp: Expose media as another GT
Xe_LPM+ platforms have "standalone media." I.e., the media unit is
designed as an additional GT with its own engine list, GuC, forcewake,
etc. Let's allow platforms to include media GTs in their device info.
v2:
- Simplify GSI register handling and split it out to a separate patch
for ease of review. (Daniele)
Cc: Aravind Iddamsetty
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gt/intel_gt.c | 6
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_sa_media.c | 39
drivers/gpu/drm/i915/gt/intel_sa_media.h | 15 +
drivers/gpu/drm/i915/i915_pci.c | 14 +
7 files changed, 84 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..e83e4cd46968 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -123,6 +123,7 @@ gt-y += \
gt/intel_ring.o \
gt/intel_ring_submission.o \
gt/intel_rps.o \
+ gt/intel_sa_media.o \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index aa0e40987798..9b9c0ea73b7f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -31,6 +31,7 @@
#include "intel_rc6.h"
#include "intel_renderstate.h"
#include "intel_rps.h"
+#include "intel_sa_media.h"
#include "intel_gt_sysfs.h"
#include "intel_uncore.h"
#include "shmem_utils.h"
@@ -864,6 +865,11 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
ret = intel_gt_tile_setup(gt, phys_addr +
gtdef->mapping_base);
break;
+ case GT_MEDIA:
+ ret = intel_sa_mediagt_setup(gt, phys_addr +
gtdef->mapping_base,
+gtdef->gsi_offset);
+ break;
+
case GT_PRIMARY:
/* Primary GT should not appear in extra GT list */
default:
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index d414785003cc..fb2c56777480 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1578,4 +1578,12 @@
#define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000)
+/*
+ * Standalone Media's non-engine GT registers are located at their regular GT
+ * offsets plus 0x38. This extra offset is stored inside the intel_uncore
+ * structure so that the existing code can be used for both GTs without
+ * modification.
+ */
+#define MTL_MEDIA_GSI_BASE 0x38
+
#endif /* __INTEL_GT_REGS__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 82dc28643572..726695936a79 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -84,6 +84,7 @@ struct gt_defaults {
enum intel_gt_type {
GT_PRIMARY,
GT_TILE,
+ GT_MEDIA,
};
struct intel_gt {
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.c
b/drivers/gpu/drm/i915/gt/intel_sa_media.c
new file mode 100644
index ..8c5c519457cc
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+
+#include "i915_drv.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_sa_media.h"
+
+int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t phys_addr,
+ u32 gsi_offset)
+{
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_uncore *uncore;
+
+ uncore = drmm_kzalloc(>drm, sizeof(*uncore), GFP_KERNEL);
+ if (!uncore)
+ return -ENOMEM;
+
+ uncore->gsi_offset = gsi_offset;
+
+ intel_gt_common_init_early(gt);
+ intel_uncore_init_early(uncore, gt);
+
+ /*
+* Standalone media shares the general MMIO space with the primary
+* GT. We'll re-use the primary GT's mapping.
+*/
+ uncore->regs = i915->uncore.regs;
+ if (drm_WARN_ON(>drm, uncore->regs == NULL))
+ return -EIO;
+
+ gt->uncore = uncore;
+ gt->phys_addr = phys_addr;
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.h
b/drivers/gpu/drm/i915/gt/intel_sa_media.h
new file mode 100644
index ..3afb310de932
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+#ifndef
[Intel-gfx] [PATCH v3 01/14] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
Moving the locking for MMIO debug (and the final check for unclaimed
accesses when resuming debug after a userspace-initiated forcewake) will
make it simpler to completely skip MMIO debug handling on uncores that
don't support it in future patches.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_uncore.c | 41 +++--
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 9b81b2543ce2..e717ea55484a 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
intel_uncore_mmio_debug *mmio_debug)
mmio_debug->unclaimed_mmio_check = 1;
}
-static void mmio_debug_suspend(struct intel_uncore_mmio_debug *mmio_debug)
+static void mmio_debug_suspend(struct intel_uncore *uncore)
{
- lockdep_assert_held(_debug->lock);
+ spin_lock(>debug->lock);
/* Save and disable mmio debugging for the user bypass */
- if (!mmio_debug->suspend_count++) {
- mmio_debug->saved_mmio_check = mmio_debug->unclaimed_mmio_check;
- mmio_debug->unclaimed_mmio_check = 0;
+ if (!uncore->debug->suspend_count++) {
+ uncore->debug->saved_mmio_check =
uncore->debug->unclaimed_mmio_check;
+ uncore->debug->unclaimed_mmio_check = 0;
}
+
+ spin_unlock(>debug->lock);
}
-static void mmio_debug_resume(struct intel_uncore_mmio_debug *mmio_debug)
+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
+
+static void mmio_debug_resume(struct intel_uncore *uncore)
{
- lockdep_assert_held(_debug->lock);
+ spin_lock(>debug->lock);
+
+ if (!--uncore->debug->suspend_count)
+ uncore->debug->unclaimed_mmio_check =
uncore->debug->saved_mmio_check;
- if (!--mmio_debug->suspend_count)
- mmio_debug->unclaimed_mmio_check = mmio_debug->saved_mmio_check;
+ if (check_for_unclaimed_mmio(uncore))
+ drm_info(>i915->drm,
+"Invalid mmio detected during user access\n");
+
+ spin_unlock(>debug->lock);
}
static const char * const forcewake_domain_names[] = {
@@ -677,9 +687,7 @@ void intel_uncore_forcewake_user_get(struct intel_uncore
*uncore)
spin_lock_irq(>lock);
if (!uncore->user_forcewake_count++) {
intel_uncore_forcewake_get__locked(uncore, FORCEWAKE_ALL);
- spin_lock(>debug->lock);
- mmio_debug_suspend(uncore->debug);
- spin_unlock(>debug->lock);
+ mmio_debug_suspend(uncore);
}
spin_unlock_irq(>lock);
}
@@ -695,14 +703,7 @@ void intel_uncore_forcewake_user_put(struct intel_uncore
*uncore)
{
spin_lock_irq(>lock);
if (!--uncore->user_forcewake_count) {
- spin_lock(>debug->lock);
- mmio_debug_resume(uncore->debug);
-
- if (check_for_unclaimed_mmio(uncore))
- drm_info(>i915->drm,
-"Invalid mmio detected during user access\n");
- spin_unlock(>debug->lock);
-
+ mmio_debug_resume(uncore);
intel_uncore_forcewake_put__locked(uncore, FORCEWAKE_ALL);
}
spin_unlock_irq(>lock);
--
2.37.2
[Intel-gfx] [PATCH v3 00/14] i915: Add "standalone media" support for MTL
Starting with MTL, media functionality has moved into a new, second GT
at the hardware level. This new GT, referred to as "standalone media"
in the spec, has its own GuC, power management/forcewake, etc. The
general non-engine GT registers for standalone media start at 0x38,
but otherwise use the same MMIO offsets as the primary GT.
Standalone media has a lot of similarity to the remote tiles
present on platforms like xehpsdv and pvc, and our i915 implementation
can share much of the general "multi GT" infrastructure between the two
types of platforms. However there are a few notable differences
we must deal with:
- The 0x38 offset only applies to the non-engine GT registers
(which the specs refer to as "GSI" registers). The engine registers
remain at their usual locations (e.g., 0x1C for VCS0).
- Unlike platforms with remote tiles, all interrupt handling for
standalone media still happens via the primary GT.
v2:
- Added new patches to ensure each GT, not just the primary, is
handled properly during various init/suspend/resume/teardown flows.
(Daniele)
- Simplified GSI offset handling and split it into its own patch.
- Correct gt->irq_lock assignment for media GT. (Daniele)
- Fix jump target for intel_root_gt_init_early() errors. (Daniele)
v3:
- Move intel_gt_definition struct to intel_gt_types.h. (Jani)
- Drop gtdef->setup() and just switch() on type. (Jani)
- Honor GSI offset during AUX table invalidation. (Aravind)
- Drop intel_gt_tile_cleanup() through more intelligent use
of DRM-managed actions. This also fixes the fault-injection
failures reported by CI.
Cc: Radhakrishna Sripada
Cc: Daniele Ceraolo Spurio
Cc: Aravind Iddamsetty
Cc: Jani Nikula
Matt Roper (12):
drm/i915: Move locking and unclaimed check into
mmio_debug_{suspend,resume}
drm/i915: Only hook up uncore->debug for primary uncore
drm/i915: Use managed allocations for extra uncore objects
drm/i915: Drop intel_gt_tile_cleanup()
drm/i915: Prepare more multi-GT initialization
drm/i915: Rename and expose common GT early init routine
drm/i915: Use a DRM-managed action to release the PCI bridge device
drm/i915: Initialize MMIO access for each GT
drm/i915: Handle each GT on init/release and suspend/resume
drm/i915/uncore: Add GSI offset to uncore
drm/i915/mtl: Add gsi_offset when emitting aux table invalidation
drm/i915/xelpmp: Expose media as another GT
drm/i915/mtl: Use primary GT's irq lock for media GT
drm/i915/mtl: Hook up interrupts for standalone media
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 15 ++-
drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 3 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 10 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 108 +-
drivers/gpu/drm/i915/gt/intel_gt.h| 4 +-
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 35 --
drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 8 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 10 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 19 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 26 ++---
drivers/gpu/drm/i915/gt/intel_sa_media.c | 47
drivers/gpu/drm/i915/gt/intel_sa_media.h | 15 +++
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 24 ++--
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/i915_driver.c| 105 -
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_irq.c | 4 +-
drivers/gpu/drm/i915/i915_pci.c | 14 +++
drivers/gpu/drm/i915/intel_device_info.h | 3 +
drivers/gpu/drm/i915/intel_uncore.c | 92 +--
drivers/gpu/drm/i915/intel_uncore.h | 28 -
drivers/gpu/drm/i915/pxp/intel_pxp.c | 4 +-
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 4 +-
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 14 +--
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 4 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
29 files changed, 449 insertions(+), 171 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.h
--
2.37.2
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/uc: Support for version reduced and multiple firmware files
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/uc: Support for version reduced
and multiple firmware files
URL : https://patchwork.freedesktop.org/series/108212/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12083 -> Patchwork_108212v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/index.html
Participating hosts (43 -> 42)
--
Missing(1): fi-bdw-samus
Known issues
Here are the changes found in Patchwork_108212v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u: [PASS][1] -> [INCOMPLETE][2] ([i915#146] /
[i915#6598] / [i915#6712])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-pnv-d510:NOTRUN -> [SKIP][3] ([fdo#109271])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][4] ([i915#2867]) -> [PASS][5] +1 similar
issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [INCOMPLETE][6] ([i915#5153]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@mman:
- {bat-rpls-2}: [INCOMPLETE][8] ([i915#6637]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/bat-rpls-2/igt@i915_selftest@l...@mman.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/bat-rpls-2/igt@i915_selftest@l...@mman.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][10] ([i915#4528]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [DMESG-FAIL][12] ([i915#4983]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/bat-rpls-1/igt@i915_selftest@l...@reset.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-rpls-2}: [INCOMPLETE][14] -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12083/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108212v1/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.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
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5153]: https://gitlab.freedesktop.org/drm/intel/issues/5153
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6598]: https://gitlab.freedesktop.org/drm/intel/issues/6598
[i915#6637]: https://gitlab.freedesktop.org/drm/intel/issues/6637
[i915#6712]: https://gitlab.freedesktop.org/drm/intel/issues/6712
Build changes
-
* Linux: CI_DRM_12083 -> Patchwork_108212v1
CI-20190529: 20190529
CI_DRM_12083: 6d9507979ab2eb2f0f4a57e491410eae49b330d0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6646: c1f420ae84b76079cd32ac014cfdf95b5f2922f7 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_108212v1: 6d9507979ab2eb2f0f4a57e491410eae49b330d0 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
683961122de4
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/2] drm/i915/uc: Support for version reduced and multiple firmware files
== Series Details == Series: series starting with [CI,1/2] drm/i915/uc: Support for version reduced and multiple firmware files URL : https://patchwork.freedesktop.org/series/108212/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915/uc: Support for version reduced and multiple firmware files
== Series Details == Series: series starting with [CI,1/2] drm/i915/uc: Support for version reduced and multiple firmware files URL : https://patchwork.freedesktop.org/series/108212/ State : warning == Summary == Error: dim checkpatch failed fdfd920aaef7 drm/i915/uc: Support for version reduced and multiple firmware files -:172: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #172: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:74: +#define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ + fw_def(DG2, 0, guc_mmp(dg2, 70, 4, 1)) \ + fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ + fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 69, 0, 3)) \ + fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 70, 1, 1)) \ + fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 69, 0, 3)) \ + fw_def(DG1, 0, guc_mmp(dg1, 70, 1, 1)) \ + fw_def(ROCKETLAKE, 0, guc_mmp(tgl, 70, 1, 1)) \ + fw_def(TIGERLAKE,0, guc_mmp(tgl, 70, 1, 1)) \ + fw_def(JASPERLAKE, 0, guc_mmp(ehl, 70, 1, 1)) \ + fw_def(ELKHARTLAKE, 0, guc_mmp(ehl, 70, 1, 1)) \ + fw_def(ICELAKE, 0, guc_mmp(icl, 70, 1, 1)) \ + fw_def(COMETLAKE,5, guc_mmp(cml, 70, 1, 1)) \ + fw_def(COMETLAKE,0, guc_mmp(kbl, 70, 1, 1)) \ + fw_def(COFFEELAKE, 0, guc_mmp(kbl, 70, 1, 1)) \ + fw_def(GEMINILAKE, 0, guc_mmp(glk, 70, 1, 1)) \ + fw_def(KABYLAKE, 0, guc_mmp(kbl, 70, 1, 1)) \ + fw_def(BROXTON, 0, guc_mmp(bxt, 70, 1, 1)) \ + fw_def(SKYLAKE, 0, guc_mmp(skl, 70, 1, 1)) -:172: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fw_def' - possible side-effects? #172: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:74: +#define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ + fw_def(DG2, 0, guc_mmp(dg2, 70, 4, 1)) \ + fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ + fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 69, 0, 3)) \ + fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 70, 1, 1)) \ + fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 69, 0, 3)) \ + fw_def(DG1, 0, guc_mmp(dg1, 70, 1, 1)) \ + fw_def(ROCKETLAKE, 0, guc_mmp(tgl, 70, 1, 1)) \ + fw_def(TIGERLAKE,0, guc_mmp(tgl, 70, 1, 1)) \ + fw_def(JASPERLAKE, 0, guc_mmp(ehl, 70, 1, 1)) \ + fw_def(ELKHARTLAKE, 0, guc_mmp(ehl, 70, 1, 1)) \ + fw_def(ICELAKE, 0, guc_mmp(icl, 70, 1, 1)) \ + fw_def(COMETLAKE,5, guc_mmp(cml, 70, 1, 1)) \ + fw_def(COMETLAKE,0, guc_mmp(kbl, 70, 1, 1)) \ + fw_def(COFFEELAKE, 0, guc_mmp(kbl, 70, 1, 1)) \ + fw_def(GEMINILAKE, 0, guc_mmp(glk, 70, 1, 1)) \ + fw_def(KABYLAKE, 0, guc_mmp(kbl, 70, 1, 1)) \ + fw_def(BROXTON, 0, guc_mmp(bxt, 70, 1, 1)) \ + fw_def(SKYLAKE, 0, guc_mmp(skl, 70, 1, 1)) -:172: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'guc_mmp' - possible side-effects? #172: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:74: +#define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ + fw_def(DG2, 0, guc_mmp(dg2, 70, 4, 1)) \ + fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ + fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 69, 0, 3)) \ + fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 70, 1, 1)) \ + fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 69, 0, 3)) \ + fw_def(DG1, 0, guc_mmp(dg1, 70, 1, 1)) \ + fw_def(ROCKETLAKE, 0, guc_mmp(tgl, 70, 1, 1)) \ + fw_def(TIGERLAKE,0, guc_mmp(tgl, 70, 1, 1)) \ + fw_def(JASPERLAKE, 0, guc_mmp(ehl, 70, 1, 1)) \ + fw_def(ELKHARTLAKE, 0, guc_mmp(ehl, 70, 1, 1)) \ + fw_def(ICELAKE, 0, guc_mmp(icl, 70, 1, 1)) \ + fw_def(COMETLAKE,5, guc_mmp(cml, 70, 1, 1)) \ + fw_def(COMETLAKE,0, guc_mmp(kbl, 70, 1, 1)) \ + fw_def(COFFEELAKE, 0, guc_mmp(kbl, 70, 1, 1)) \ + fw_def(GEMINILAKE, 0, guc_mmp(glk, 70, 1, 1)) \ + fw_def(KABYLAKE, 0, guc_mmp(kbl, 70, 1, 1)) \ + fw_def(BROXTON, 0, guc_mmp(bxt, 70, 1, 1)) \ + fw_def(SKYLAKE, 0, guc_mmp(skl, 70, 1, 1)) -:192: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #192: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:94: +#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_raw, huc_mmp) \ + fw_def(ALDERLAKE_P, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(ALDERLAKE_S, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(DG1, 0, huc_mmp(dg1, 7, 9, 3)) \ + fw_def(ROCKETLAKE, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(TIGERLAKE,0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(JASPERLAKE, 0, huc_mmp(ehl, 9, 0, 0)) \ + fw_def(ELKHARTLAKE, 0, huc_mmp(ehl, 9, 0, 0)) \ + fw_def(ICELAKE, 0, huc_mmp(icl, 9, 0, 0)) \ + fw_def(COMETLAKE,5, huc_mmp(cml, 4, 0, 0)) \ + fw_def(COMETLAKE,0, huc_mmp(kbl, 4, 0, 0)) \ + fw_def(COFFEELAKE, 0, huc_mmp(kbl, 4, 0, 0)) \ +
Re: [Intel-gfx] [PATCH] drm/i915: Let's avoid even early init if SLPC is used.
On Tue, 06 Sep 2022 13:33:49 -0700, Rodrigo Vivi wrote:
>
Hi Rodrigo,
> void intel_rps_init_early(struct intel_rps *rps)
> {
> + if (rps_wants_slpc(rps))
> + return;
> +
So what happens if we "want" SLPC but finally could not enable it (switch
slpc to "in use") and have to fall back to host turbo? If that's a valid
possibility then we can't do the above.
From drivers/gpu/drm/i915/gt/uc/intel_uc.h
* - Not supported: not available in HW and/or firmware not defined.
* - Supported: available in HW and firmware defined.
* - Wanted: supported + enabled in modparam.
* - In use: wanted + firmware found on the system and successfully fetched.
Thanks.
--
Ashutosh
[Intel-gfx] [CI 2/2] drm/i915/uc: Add patch level version number support
From: John Harrison
With the move to un-versioned filenames, it becomes more difficult to
know exactly what version of a given firmware is being used. So add
the patch level version number to the debugfs output.
Also, support matching by patch level when selecting code paths for
firmware compatibility. While a patch level change cannot be backwards
breaking, it is potentially possible that a new feature only works
from a given patch level onwards (even though it was theoretically
added in an earlier version that bumped the major or minor version).
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 36 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 6
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 8 +++--
5 files changed, 47 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 04393932623c..64c4e83153f4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1868,7 +1868,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
if (guc->submission_initialized)
return 0;
- if (guc->fw.file_selected.major_ver < 70) {
+ if (GET_UC_VER(guc) < MAKE_UC_VER(70, 0, 0)) {
ret = guc_lrc_desc_pool_create_v69(guc);
if (ret)
return ret;
@@ -2303,7 +2303,7 @@ static int register_context(struct intel_context *ce,
bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
- if (guc->fw.file_selected.major_ver >= 70)
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0))
ret = register_context_v70(guc, ce, loop);
else
ret = register_context_v69(guc, ce, loop);
@@ -2315,7 +2315,7 @@ static int register_context(struct intel_context *ce,
bool loop)
set_context_registered(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
- if (guc->fw.file_selected.major_ver >= 70)
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0))
guc_context_policy_init_v70(ce, loop);
}
@@ -2921,7 +2921,7 @@ static void __guc_context_set_preemption_timeout(struct
intel_guc *guc,
u16 guc_id,
u32 preemption_timeout)
{
- if (guc->fw.file_selected.major_ver >= 70) {
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0)) {
struct context_policy policy;
__guc_context_policy_start_klv(, guc_id);
@@ -3186,7 +3186,7 @@ static int guc_context_alloc(struct intel_context *ce)
static void __guc_context_set_prio(struct intel_guc *guc,
struct intel_context *ce)
{
- if (guc->fw.file_selected.major_ver >= 70) {
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0)) {
struct context_policy policy;
__guc_context_policy_start_klv(, ce->guc_id.id);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index d965ac4832d6..abf4e142596d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -435,9 +435,11 @@ static void print_fw_ver(struct intel_uc *uc, struct
intel_uc_fw *fw)
{
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
- drm_info(>drm, "%s firmware %s version %u.%u\n",
+ drm_info(>drm, "%s firmware %s version %u.%u.%u\n",
intel_uc_fw_type_repr(fw->type), fw->file_selected.path,
-fw->file_selected.major_ver, fw->file_selected.minor_ver);
+fw->file_selected.major_ver,
+fw->file_selected.minor_ver,
+fw->file_selected.patch_ver);
}
static int __uc_init_hw(struct intel_uc *uc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 610f36f1b989..af425916cdf6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -447,10 +447,12 @@ static int check_gsc_manifest(const struct firmware *fw,
struct intel_uc_fw *uc_fw)
{
u32 *dw = (u32 *)fw->data;
- u32 version = dw[HUC_GSC_VERSION_DW];
+ u32 version_hi = dw[HUC_GSC_VERSION_HI_DW];
+ u32 version_lo = dw[HUC_GSC_VERSION_LO_DW];
- uc_fw->file_selected.major_ver = FIELD_GET(HUC_GSC_MAJOR_VER_MASK,
version);
- uc_fw->file_selected.minor_ver = FIELD_GET(HUC_GSC_MINOR_VER_MASK,
version);
+ uc_fw->file_selected.major_ver = FIELD_GET(HUC_GSC_MAJOR_VER_HI_MASK,
version_hi);
+ uc_fw->file_selected.minor_ver =
[Intel-gfx] [CI 1/2] drm/i915/uc: Support for version reduced and multiple firmware files
From: John Harrison
There was a misunderstanding in how firmware file compatibility should
be managed within i915. This has been clarified as:
i915 must support all existing firmware releases forever
new minor firmware releases should replace prior versions
only backwards compatibility breaking releases should be a new file
This patch cleans up the single fallback file support that was added
as a quick fix emergency effort. That is now removed in preference to
supporting arbitrary numbers of firmware files per platform.
The patch also adds support for having GuC firmware files that are
named by major version only (because the major version indicates
backwards breaking changes that affect the KMD) and for having HuC
firmware files with no version number at all (because the KMD has no
interface requirements with the HuC).
For GuC, the driver will report via dmesg if the found file is older than
expected. For HuC, the KMD will no longer require updating for any new
HuC release so will not be able to report what the latest expected
version is.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 442 --
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 33 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 16 +-
5 files changed, 319 insertions(+), 186 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0d56b615bf78..04393932623c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1868,7 +1868,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
if (guc->submission_initialized)
return 0;
- if (guc->fw.major_ver_found < 70) {
+ if (guc->fw.file_selected.major_ver < 70) {
ret = guc_lrc_desc_pool_create_v69(guc);
if (ret)
return ret;
@@ -2303,7 +2303,7 @@ static int register_context(struct intel_context *ce,
bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
- if (guc->fw.major_ver_found >= 70)
+ if (guc->fw.file_selected.major_ver >= 70)
ret = register_context_v70(guc, ce, loop);
else
ret = register_context_v69(guc, ce, loop);
@@ -2315,7 +2315,7 @@ static int register_context(struct intel_context *ce,
bool loop)
set_context_registered(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
- if (guc->fw.major_ver_found >= 70)
+ if (guc->fw.file_selected.major_ver >= 70)
guc_context_policy_init_v70(ce, loop);
}
@@ -2921,7 +2921,7 @@ static void __guc_context_set_preemption_timeout(struct
intel_guc *guc,
u16 guc_id,
u32 preemption_timeout)
{
- if (guc->fw.major_ver_found >= 70) {
+ if (guc->fw.file_selected.major_ver >= 70) {
struct context_policy policy;
__guc_context_policy_start_klv(, guc_id);
@@ -3186,7 +3186,7 @@ static int guc_context_alloc(struct intel_context *ce)
static void __guc_context_set_prio(struct intel_guc *guc,
struct intel_context *ce)
{
- if (guc->fw.major_ver_found >= 70) {
+ if (guc->fw.file_selected.major_ver >= 70) {
struct context_policy policy;
__guc_context_policy_start_klv(, ce->guc_id.id);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index f2e7c82985ef..d965ac4832d6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -436,8 +436,8 @@ static void print_fw_ver(struct intel_uc *uc, struct
intel_uc_fw *fw)
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
drm_info(>drm, "%s firmware %s version %u.%u\n",
-intel_uc_fw_type_repr(fw->type), fw->path,
-fw->major_ver_found, fw->minor_ver_found);
+intel_uc_fw_type_repr(fw->type), fw->file_selected.path,
+fw->file_selected.major_ver, fw->file_selected.minor_ver);
}
static int __uc_init_hw(struct intel_uc *uc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 58547292efa0..610f36f1b989 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -41,7 +41,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
"%s firmware -> %s\n",
intel_uc_fw_type_repr(uc_fw->type),
status == INTEL_UC_FIRMWARE_SELECTED ?
- uc_fw->path :
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Kick rcu harder to free objects
== Series Details == Series: drm/i915: Kick rcu harder to free objects URL : https://patchwork.freedesktop.org/series/108196/ State : success == Summary == CI Bug Log - changes from CI_DRM_12080_full -> Patchwork_108196v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 11) -- Missing(1): shard-dg1 Known issues Here are the changes found in Patchwork_108196v1_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-apl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [FAIL][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) ([i915#4386]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl8/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl8/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl8/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl6/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl4/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl4/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl4/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl4/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl3/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl3/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl3/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl2/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl2/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl1/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl1/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/shard-apl1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl4/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl4/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl4/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl4/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl3/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl3/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl3/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl3/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl2/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl1/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl1/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl1/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl1/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl8/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl8/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/shard-apl8/boot.html [43]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Let's avoid even early init if SLPC is used.
== Series Details ==
Series: drm/i915: Let's avoid even early init if SLPC is used.
URL : https://patchwork.freedesktop.org/series/108209/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12082 -> Patchwork_108209v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_108209v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_108209v1, 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_108209v1/index.html
Participating hosts (42 -> 38)
--
Missing(4): fi-kbl-soraka bat-adln-1 fi-icl-u2 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108209v1:
### IGT changes ###
Possible regressions
* igt@i915_module_load@load:
- fi-rkl-guc: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12082/fi-rkl-guc/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/fi-rkl-guc/igt@i915_module_l...@load.html
- bat-adlp-4: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12082/bat-adlp-4/igt@i915_module_l...@load.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/bat-adlp-4/igt@i915_module_l...@load.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@load:
- {bat-rpls-1}: [PASS][5] -> [DMESG-WARN][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12082/bat-rpls-1/igt@i915_module_l...@load.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/bat-rpls-1/igt@i915_module_l...@load.html
- {bat-dg2-11}: [PASS][7] -> [DMESG-WARN][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12082/bat-dg2-11/igt@i915_module_l...@load.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/bat-dg2-11/igt@i915_module_l...@load.html
- {bat-rplp-1}: [PASS][9] -> [DMESG-WARN][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12082/bat-rplp-1/igt@i915_module_l...@load.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/bat-rplp-1/igt@i915_module_l...@load.html
- {bat-dg2-9}:[PASS][11] -> [DMESG-WARN][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12082/bat-dg2-9/igt@i915_module_l...@load.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/bat-dg2-9/igt@i915_module_l...@load.html
- {bat-rpls-2}: [PASS][13] -> [DMESG-WARN][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12082/bat-rpls-2/igt@i915_module_l...@load.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/bat-rpls-2/igt@i915_module_l...@load.html
- {bat-dg2-8}:[PASS][15] -> [DMESG-WARN][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12082/bat-dg2-8/igt@i915_module_l...@load.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/bat-dg2-8/igt@i915_module_l...@load.html
Known issues
Here are the changes found in Patchwork_108209v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][17] -> [DMESG-FAIL][18] ([i915#4528])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12082/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@runner@aborted:
- bat-adlp-4: NOTRUN -> [FAIL][19] ([i915#4312] / [i915#6641])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/bat-adlp-4/igt@run...@aborted.html
- fi-blb-e6850: NOTRUN -> [FAIL][20] ([fdo#109271] / [i915#2403] /
[i915#4312])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/fi-blb-e6850/igt@run...@aborted.html
- fi-rkl-guc: NOTRUN -> [FAIL][21] ([i915#4312] / [i915#6599])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/fi-rkl-guc/igt@run...@aborted.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u: [DMESG-FAIL][22] ([i915#62]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12082/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108209v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@ring_submission:
- fi-cfl-8109u: [DMESG-WARN][24] ([i915#5904]) -> [PASS][25] +30
Re: [Intel-gfx] [PATCH v4 1/3] drm: Use XArray instead of IDR for minors
On Tue, Sep 06, 2022 at 10:16:27PM +0200, Michał Winiarski wrote:
> IDR is deprecated, and since XArray manages its own state with internal
> locking, it simplifies the locking on DRM side.
> Additionally, don't use the IRQ-safe variant, since operating on drm
> minor is not done in IRQ context.
>
> Signed-off-by: Michał Winiarski
> Suggested-by: Matthew Wilcox
I have a few questions, but I like where you're going.
> @@ -98,21 +98,18 @@ static struct drm_minor **drm_minor_get_slot(struct
> drm_device *dev,
> static void drm_minor_alloc_release(struct drm_device *dev, void *data)
> {
> struct drm_minor *minor = data;
> - unsigned long flags;
>
> WARN_ON(dev != minor->dev);
>
> put_device(minor->kdev);
>
> - spin_lock_irqsave(_minor_lock, flags);
> - idr_remove(_minors_idr, minor->index);
> - spin_unlock_irqrestore(_minor_lock, flags);
> + xa_release(_minors_xa, minor->index);
Has it definitely been unused at this point? I would think that
xa_erase() (an unconditional store) would be the correct function to
call.
> @@ -122,20 +119,12 @@ static int drm_minor_alloc(struct drm_device *dev,
> unsigned int type)
> minor->type = type;
> minor->dev = dev;
>
> - idr_preload(GFP_KERNEL);
> - spin_lock_irqsave(_minor_lock, flags);
> - r = idr_alloc(_minors_idr,
> - NULL,
> - 64 * type,
> - 64 * (type + 1),
> - GFP_NOWAIT);
> - spin_unlock_irqrestore(_minor_lock, flags);
> - idr_preload_end();
> -
> + r = xa_alloc(_minors_xa, , NULL,
> + XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL);
> if (r < 0)
> return r;
>
> - minor->index = r;
> + minor->index = id;
Wouldn't it be better to call:
r = xa_alloc(_minors_xa, >index, NULL,
XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL);
I might also prefer a little syntactic sugar like:
#define DRM_MINOR_LIMIT(type) XA_LIMIT(64 * (type), 64 * (type) + 63)
but that's definitely a matter of taste.
> @@ -172,9 +161,12 @@ static int drm_minor_register(struct drm_device *dev,
> unsigned int type)
> goto err_debugfs;
>
> /* replace NULL with @minor so lookups will succeed from now on */
> - spin_lock_irqsave(_minor_lock, flags);
> - idr_replace(_minors_idr, minor, minor->index);
> - spin_unlock_irqrestore(_minor_lock, flags);
> + entry = xa_store(_minors_xa, minor->index, , GFP_KERNEL);
> + if (xa_is_err(entry)) {
> + ret = xa_err(entry);
> + goto err_debugfs;
> + }
> + WARN_ON(entry);
Might be better as an xa_cmpxchg()?
> @@ -187,16 +179,13 @@ static int drm_minor_register(struct drm_device *dev,
> unsigned int type)
> static void drm_minor_unregister(struct drm_device *dev, unsigned int type)
> {
> struct drm_minor *minor;
> - unsigned long flags;
>
> minor = *drm_minor_get_slot(dev, type);
> if (!minor || !device_is_registered(minor->kdev))
> return;
>
> /* replace @minor with NULL so lookups will fail from now on */
> - spin_lock_irqsave(_minor_lock, flags);
> - idr_replace(_minors_idr, NULL, minor->index);
> - spin_unlock_irqrestore(_minor_lock, flags);
> + xa_erase(_minors_xa, minor->index);
This isn't an exact replacement, but I'm not sure whether that makes a
difference. xa_erase() allows allocation of this ID again while
idr_replace() means that lookups return NULL, but the ID remains in
use. The equivalent of idr_replace() is:
xa_store(_minors_xa, minor->index, NULL, GFP_KERNEL);
> @@ -215,13 +204,10 @@ static void drm_minor_unregister(struct drm_device
> *dev, unsigned int type)
> struct drm_minor *drm_minor_acquire(unsigned int minor_id)
> {
> struct drm_minor *minor;
> - unsigned long flags;
>
> - spin_lock_irqsave(_minor_lock, flags);
> - minor = idr_find(_minors_idr, minor_id);
> + minor = xa_load(_minors_xa, minor_id);
> if (minor)
> drm_dev_get(minor->dev);
> - spin_unlock_irqrestore(_minor_lock, flags);
This is also not an exact equivalent as the dev_drm_get() is now outside
the lock. Does that matter in this case? I don't know the code well
enough to say. If you want it to be equivalent, then:
xa_lock(_minors_xa);
minor = xa_load(_minors_xa, minor_id);
if (minor)
drm_dev_get(minor->dev);
xa_unlock(_minors_xa);
would be the code to use.
> @@ -1037,7 +1023,7 @@ static void drm_core_exit(void)
> unregister_chrdev(DRM_MAJOR, "drm");
> debugfs_remove(drm_debugfs_root);
> drm_sysfs_destroy();
> - idr_destroy(_minors_idr);
> + xa_destroy(_minors_xa);
I don't know if this is the right call. xa_destroy() is the exact
replacement, but if the xarray should already be empty (and it should,
right?) then asserting the xa_empty() is true may
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Use full allocated minor range for DRM
== Series Details == Series: drm: Use full allocated minor range for DRM URL : https://patchwork.freedesktop.org/series/108206/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12081 -> Patchwork_108206v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108206v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108206v1, 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_108206v1/index.html Participating hosts (41 -> 41) -- Additional (2): fi-rkl-11600 fi-snb-2520m Missing(2): fi-icl-u2 fi-bdw-samus Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108206v1: ### IGT changes ### Possible regressions * igt@i915_module_load@load: - fi-ilk-650: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-ilk-650/igt@i915_module_l...@load.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-ilk-650/igt@i915_module_l...@load.html - fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-blb-e6850/igt@i915_module_l...@load.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-blb-e6850/igt@i915_module_l...@load.html - fi-rkl-11600: NOTRUN -> [INCOMPLETE][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-rkl-11600/igt@i915_module_l...@load.html - fi-skl-6600u: [PASS][6] -> [INCOMPLETE][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-skl-6600u/igt@i915_module_l...@load.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-skl-6600u/igt@i915_module_l...@load.html - fi-bdw-gvtdvm: [PASS][8] -> [INCOMPLETE][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-bdw-gvtdvm/igt@i915_module_l...@load.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-bdw-gvtdvm/igt@i915_module_l...@load.html - fi-pnv-d510:[PASS][10] -> [INCOMPLETE][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-pnv-d510/igt@i915_module_l...@load.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-pnv-d510/igt@i915_module_l...@load.html - fi-snb-2520m: NOTRUN -> [INCOMPLETE][12] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-snb-2520m/igt@i915_module_l...@load.html - fi-glk-j4005: [PASS][13] -> [INCOMPLETE][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-glk-j4005/igt@i915_module_l...@load.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-glk-j4005/igt@i915_module_l...@load.html - fi-rkl-guc: [PASS][15] -> [INCOMPLETE][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-rkl-guc/igt@i915_module_l...@load.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-rkl-guc/igt@i915_module_l...@load.html - fi-skl-6700k2: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-skl-6700k2/igt@i915_module_l...@load.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-skl-6700k2/igt@i915_module_l...@load.html - fi-kbl-7567u: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-kbl-7567u/igt@i915_module_l...@load.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-kbl-7567u/igt@i915_module_l...@load.html - fi-cfl-8700k: [PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-cfl-8700k/igt@i915_module_l...@load.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-cfl-8700k/igt@i915_module_l...@load.html - fi-elk-e7500: [PASS][23] -> [INCOMPLETE][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-elk-e7500/igt@i915_module_l...@load.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-elk-e7500/igt@i915_module_l...@load.html - fi-bsw-nick:[PASS][25] -> [INCOMPLETE][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-bsw-nick/igt@i915_module_l...@load.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108206v1/fi-bsw-nick/igt@i915_module_l...@load.html - fi-hsw-g3258: [PASS][27] -> [INCOMPLETE][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12081/fi-hsw-g3258/igt@i915_module_l...@load.html [28]:
Re: [Intel-gfx] [PATCH 04/19] drm/i915/perf: Determine gen12 oa ctx offset at runtime
On Tue, Sep 06, 2022 at 10:48:50PM +0300, Lionel Landwerlin wrote:
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
Some SKUs of same gen12 platform may have different oactxctrl
offsets. For gen12, determine oactxctrl offsets at runtime.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 149 ++-
drivers/gpu/drm/i915/i915_perf_oa_regs.h | 2 +-
2 files changed, 120 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3526693d64fa..efa7eda83edd 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1363,6 +1363,67 @@ static int gen12_get_render_context_id(struct
i915_perf_stream *stream)
return 0;
}
+#define MI_OPCODE(x) (((x) >> 23) & 0x3f)
+#define IS_MI_LRI_CMD(x) (MI_OPCODE(x) == MI_OPCODE(MI_INSTR(0x22, 0)))
+#define MI_LRI_LEN(x) (((x) & 0xff) + 1)
Maybe you want to put this in intel_gpu_commands.h
+#define __valid_oactxctrl_offset(x) ((x) && (x) != U32_MAX)
+static bool __find_reg_in_lri(u32 *state, u32 reg, u32 *offset)
+{
+ u32 idx = *offset;
+ u32 len = MI_LRI_LEN(state[idx]) + idx;
+
+ idx++;
+ for (; idx < len; idx += 2)
+ if (state[idx] == reg)
+ break;
+
+ *offset = idx;
+ return state[idx] == reg;
+}
+
+static u32 __context_image_offset(struct intel_context *ce, u32 reg)
+{
+ u32 offset, len = (ce->engine->context_size - PAGE_SIZE) / 4;
+ u32 *state = ce->lrc_reg_state;
+
+ for (offset = 0; offset < len; ) {
+ if (IS_MI_LRI_CMD(state[offset])) {
I'm a bit concerned you might find other matches with this.
Because let's say you run into a 3DSTATE_SUBSLICE_HASH_TABLE
instruction, you'll iterate the instruction dword by dword because you
don't know how to read its length and skip to the next one.
Now some of the fields can be programmed from userspace to look like
an MI_LRI header, so you start to read data in the wrong way.
Unfortunately I don't have a better solution. My only ask is that you
make __find_reg_in_lri() take the context image size in parameter so
it NEVER goes over the the context image.
To limit the risk you should run this function only one at driver
initialization and store the found offset.
Hmm, didn't know that there may be non-LRI commands in the context image
or user could add to the context image somehow. Does using the context
image size alone address these issues?
Even after including the size in the logic, any reason you think we
would be much more safer to do this from init? Is it because context
image is not touched by user yet?
Thanks,
Umesh
Thanks,
-Lionel
+ if (__find_reg_in_lri(state, reg, ))
+ break;
+ } else {
+ offset++;
+ }
+ }
+
+ return offset < len ? offset : U32_MAX;
+}
+
+static int __set_oa_ctx_ctrl_offset(struct intel_context *ce)
+{
+ i915_reg_t reg = GEN12_OACTXCONTROL(ce->engine->mmio_base);
+ struct i915_perf *perf = >engine->i915->perf;
+ u32 saved_offset = perf->ctx_oactxctrl_offset;
+ u32 offset;
+
+ /* Do this only once. Failure is stored as offset of U32_MAX */
+ if (saved_offset)
+ return 0;
+
+ offset = __context_image_offset(ce, i915_mmio_reg_offset(reg));
+ perf->ctx_oactxctrl_offset = offset;
+
+ drm_dbg(>engine->i915->drm,
+ "%s oa ctx control at 0x%08x dword offset\n",
+ ce->engine->name, offset);
+
+ return __valid_oactxctrl_offset(offset) ? 0 : -ENODEV;
+}
+
+static bool engine_supports_mi_query(struct intel_engine_cs *engine)
+{
+ return engine->class == RENDER_CLASS;
+}
+
/**
* oa_get_render_ctx_id - determine and hold ctx hw id
* @stream: An i915-perf stream opened for OA metrics
@@ -1382,6 +1443,17 @@ static int oa_get_render_ctx_id(struct i915_perf_stream
*stream)
if (IS_ERR(ce))
return PTR_ERR(ce);
+ if (engine_supports_mi_query(stream->engine)) {
+ ret = __set_oa_ctx_ctrl_offset(ce);
+ if (ret && !(stream->sample_flags & SAMPLE_OA_REPORT)) {
+ intel_context_unpin(ce);
+ drm_err(>perf->i915->drm,
+ "Enabling perf query failed for %s\n",
+ stream->engine->name);
+ return ret;
+ }
+ }
+
switch (GRAPHICS_VER(ce->engine->i915)) {
case 7: {
/*
@@ -2412,10 +2484,11 @@ static int gen12_configure_oar_context(struct
i915_perf_stream *stream,
int err;
struct intel_context *ce = stream->pinned_ctx;
u32 format = stream->oa_buffer.format;
+ u32 offset = stream->perf->ctx_oactxctrl_offset;
struct flex regs_context[] = {
{
[Intel-gfx] [PATCH] drm/i915: Let's avoid even early init if SLPC is used.
SLPC has its own waiboost variables and lock mechanism.
No need for these extra stuff, in special no need for the
timer.
v2: At early stages we can't use uc's 'uses' function, but the
'wants' ones in order to make those decisions.
Cc: Ashutosh Dixit
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_rps.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 28b399fa1abe..f0c75f088c88 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -57,6 +57,13 @@ static bool rps_uses_slpc(struct intel_rps *rps)
return intel_uc_uses_guc_slpc(>uc);
}
+static bool rps_wants_slpc(struct intel_rps *rps)
+{
+ struct intel_gt *gt = rps_to_gt(rps);
+
+ return intel_uc_wants_guc_slpc(>uc);
+}
+
static u32 rps_pm_sanitize_mask(struct intel_rps *rps, u32 mask)
{
return mask & ~rps->pm_intrmsk_mbz;
@@ -1955,6 +1962,9 @@ void gen5_rps_irq_handler(struct intel_rps *rps)
void intel_rps_init_early(struct intel_rps *rps)
{
+ if (rps_wants_slpc(rps))
+ return;
+
mutex_init(>lock);
mutex_init(>power.mutex);
--
2.37.2
Re: [Intel-gfx] [PATCH 10/19] drm/i915/perf: Use gt-specific ggtt for OA and noa-wait buffers
On 06/09/2022 23:28, Umesh Nerlige Ramappa wrote:
On Tue, Sep 06, 2022 at 10:56:13PM +0300, Lionel Landwerlin wrote:
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
User passes uabi engine class and instance to the perf OA interface.
Use
gt corresponding to the engine to pin the buffers to the right ggtt.
Signed-off-by: Umesh Nerlige Ramappa
I didn't know there was a GGTT per engine.
Do I understand this correct?
No, GGTT is still per-gt. We just derive the gt from engine class
instance passed (as in engine->gt).
Oh thanks I understand now.
Reviewed-by: Lionel Landwerlin
Thanks,
-Lionel
---
drivers/gpu/drm/i915/i915_perf.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c
b/drivers/gpu/drm/i915/i915_perf.c
index 87b92d2946f4..f7621b45966c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1765,6 +1765,7 @@ static void gen12_init_oa_buffer(struct
i915_perf_stream *stream)
static int alloc_oa_buffer(struct i915_perf_stream *stream)
{
struct drm_i915_private *i915 = stream->perf->i915;
+ struct intel_gt *gt = stream->engine->gt;
struct drm_i915_gem_object *bo;
struct i915_vma *vma;
int ret;
@@ -1784,11 +1785,22 @@ static int alloc_oa_buffer(struct
i915_perf_stream *stream)
i915_gem_object_set_cache_coherency(bo, I915_CACHE_LLC);
/* PreHSW required 512K alignment, HSW requires 16M */
- vma = i915_gem_object_ggtt_pin(bo, NULL, 0, SZ_16M, 0);
+ vma = i915_vma_instance(bo, >ggtt->vm, NULL);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
goto err_unref;
}
+
+ /*
+ * PreHSW required 512K alignment.
+ * HSW and onwards, align to requested size of OA buffer.
+ */
+ ret = i915_vma_pin(vma, 0, SZ_16M, PIN_GLOBAL | PIN_HIGH);
+ if (ret) {
+ drm_err(>i915->drm, "Failed to pin OA buffer %d\n", ret);
+ goto err_unref;
+ }
+
stream->oa_buffer.vma = vma;
stream->oa_buffer.vaddr =
@@ -1838,6 +1850,7 @@ static u32 *save_restore_register(struct
i915_perf_stream *stream, u32 *cs,
static int alloc_noa_wait(struct i915_perf_stream *stream)
{
struct drm_i915_private *i915 = stream->perf->i915;
+ struct intel_gt *gt = stream->engine->gt;
struct drm_i915_gem_object *bo;
struct i915_vma *vma;
const u64 delay_ticks = 0x -
@@ -1878,12 +1891,16 @@ static int alloc_noa_wait(struct
i915_perf_stream *stream)
* multiple OA config BOs will have a jump to this address and it
* needs to be fixed during the lifetime of the i915/perf stream.
*/
- vma = i915_gem_object_ggtt_pin_ww(bo, , NULL, 0, 0, PIN_HIGH);
+ vma = i915_vma_instance(bo, >ggtt->vm, NULL);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
goto out_ww;
}
+ ret = i915_vma_pin_ww(vma, , 0, 0, PIN_GLOBAL | PIN_HIGH);
+ if (ret)
+ goto out_ww;
+
batch = cs = i915_gem_object_pin_map(bo, I915_MAP_WB);
if (IS_ERR(batch)) {
ret = PTR_ERR(batch);
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/uc: Enable version reduced firmware files for newest platforms
On 8/26/2022 6:17 PM, john.c.harri...@intel.com wrote: From: John Harrison Going forwards, the intention is for GuC firmware files to be named for their major version only and HuC firmware files to have no version number in the name at all. This patch adds those entries for DG1/2 and ADL-P/S. Signed-off-by: John Harrison Reviewed-by: Daniele Ceraolo Spurio However, looks like a new GuC minor version might land in the next couple of days, so IMO better wait until that is confirmed before merging this so we can do a single pull request to linux-firmware. Daniele --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index af425916cdf64..78b1198bcf39b 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -72,11 +72,14 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ - fw_def(DG2, 0, guc_mmp(dg2, 70, 4, 1)) \ + fw_def(DG2, 0, guc_maj(dg2, 70, 4)) \ + fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 1)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 69, 0, 3)) \ + fw_def(ALDERLAKE_S, 0, guc_maj(tgl, 70, 1)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 69, 0, 3)) \ + fw_def(DG1, 0, guc_maj(dg1, 70, 1)) \ fw_def(DG1, 0, guc_mmp(dg1, 70, 1, 1)) \ fw_def(ROCKETLAKE, 0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(TIGERLAKE,0, guc_mmp(tgl, 70, 1, 1)) \ @@ -92,8 +95,11 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, fw_def(SKYLAKE, 0, guc_mmp(skl, 70, 1, 1)) #define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_raw, huc_mmp) \ + fw_def(ALDERLAKE_P, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_P, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(ALDERLAKE_S, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_S, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(DG1, 0, huc_raw(dg1)) \ fw_def(DG1, 0, huc_mmp(dg1, 7, 9, 3)) \ fw_def(ROCKETLAKE, 0, huc_mmp(tgl, 7, 9, 3)) \ fw_def(TIGERLAKE,0, huc_mmp(tgl, 7, 9, 3)) \
Re: [Intel-gfx] [PATCH 10/19] drm/i915/perf: Use gt-specific ggtt for OA and noa-wait buffers
On Tue, Sep 06, 2022 at 10:56:13PM +0300, Lionel Landwerlin wrote:
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
User passes uabi engine class and instance to the perf OA interface. Use
gt corresponding to the engine to pin the buffers to the right ggtt.
Signed-off-by: Umesh Nerlige Ramappa
I didn't know there was a GGTT per engine.
Do I understand this correct?
No, GGTT is still per-gt. We just derive the gt from engine class
instance passed (as in engine->gt).
Thanks,
-Lionel
---
drivers/gpu/drm/i915/i915_perf.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 87b92d2946f4..f7621b45966c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1765,6 +1765,7 @@ static void gen12_init_oa_buffer(struct i915_perf_stream
*stream)
static int alloc_oa_buffer(struct i915_perf_stream *stream)
{
struct drm_i915_private *i915 = stream->perf->i915;
+ struct intel_gt *gt = stream->engine->gt;
struct drm_i915_gem_object *bo;
struct i915_vma *vma;
int ret;
@@ -1784,11 +1785,22 @@ static int alloc_oa_buffer(struct i915_perf_stream
*stream)
i915_gem_object_set_cache_coherency(bo, I915_CACHE_LLC);
/* PreHSW required 512K alignment, HSW requires 16M */
- vma = i915_gem_object_ggtt_pin(bo, NULL, 0, SZ_16M, 0);
+ vma = i915_vma_instance(bo, >ggtt->vm, NULL);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
goto err_unref;
}
+
+ /*
+* PreHSW required 512K alignment.
+* HSW and onwards, align to requested size of OA buffer.
+*/
+ ret = i915_vma_pin(vma, 0, SZ_16M, PIN_GLOBAL | PIN_HIGH);
+ if (ret) {
+ drm_err(>i915->drm, "Failed to pin OA buffer %d\n", ret);
+ goto err_unref;
+ }
+
stream->oa_buffer.vma = vma;
stream->oa_buffer.vaddr =
@@ -1838,6 +1850,7 @@ static u32 *save_restore_register(struct i915_perf_stream
*stream, u32 *cs,
static int alloc_noa_wait(struct i915_perf_stream *stream)
{
struct drm_i915_private *i915 = stream->perf->i915;
+ struct intel_gt *gt = stream->engine->gt;
struct drm_i915_gem_object *bo;
struct i915_vma *vma;
const u64 delay_ticks = 0x -
@@ -1878,12 +1891,16 @@ static int alloc_noa_wait(struct i915_perf_stream
*stream)
* multiple OA config BOs will have a jump to this address and it
* needs to be fixed during the lifetime of the i915/perf stream.
*/
- vma = i915_gem_object_ggtt_pin_ww(bo, , NULL, 0, 0, PIN_HIGH);
+ vma = i915_vma_instance(bo, >ggtt->vm, NULL);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
goto out_ww;
}
+ ret = i915_vma_pin_ww(vma, , 0, 0, PIN_GLOBAL | PIN_HIGH);
+ if (ret)
+ goto out_ww;
+
batch = cs = i915_gem_object_pin_map(bo, I915_MAP_WB);
if (IS_ERR(batch)) {
ret = PTR_ERR(batch);
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/uc: Add patch level version number support
On 8/26/2022 6:17 PM, john.c.harri...@intel.com wrote:
From: John Harrison
With the move to un-versioned filenames, it becomes more difficult to
know exactly what version of a given firmware is being used. So add
the patch level version number to the debugfs output.
Also, support matching by patch level when selecting code paths for
firmware compatibility. While a patch level change cannot be backwards
breaking, it is potentially possible that a new feature only works
from a given patch level onwards (even though it was theoretically
added in an earlier version that bumped the major or minor version).
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 36 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 6
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 8 +++--
5 files changed, 47 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 04393932623c7..64c4e83153f47 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1868,7 +1868,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
if (guc->submission_initialized)
return 0;
- if (guc->fw.file_selected.major_ver < 70) {
+ if (GET_UC_VER(guc) < MAKE_UC_VER(70, 0, 0)) {
ret = guc_lrc_desc_pool_create_v69(guc);
if (ret)
return ret;
@@ -2303,7 +2303,7 @@ static int register_context(struct intel_context *ce,
bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
- if (guc->fw.file_selected.major_ver >= 70)
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0))
ret = register_context_v70(guc, ce, loop);
else
ret = register_context_v69(guc, ce, loop);
@@ -2315,7 +2315,7 @@ static int register_context(struct intel_context *ce,
bool loop)
set_context_registered(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
- if (guc->fw.file_selected.major_ver >= 70)
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0))
guc_context_policy_init_v70(ce, loop);
}
@@ -2921,7 +2921,7 @@ static void __guc_context_set_preemption_timeout(struct intel_guc *guc,
u16 guc_id,
u32 preemption_timeout)
{
- if (guc->fw.file_selected.major_ver >= 70) {
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0)) {
struct context_policy policy;
__guc_context_policy_start_klv(, guc_id);
@@ -3186,7 +3186,7 @@ static int guc_context_alloc(struct intel_context *ce)
static void __guc_context_set_prio(struct intel_guc *guc,
struct intel_context *ce)
{
- if (guc->fw.file_selected.major_ver >= 70) {
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0)) {
struct context_policy policy;
__guc_context_policy_start_klv(, ce->guc_id.id);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index d965ac4832d60..abf4e142596d0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -435,9 +435,11 @@ static void print_fw_ver(struct intel_uc *uc, struct
intel_uc_fw *fw)
{
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
- drm_info(>drm, "%s firmware %s version %u.%u\n",
+ drm_info(>drm, "%s firmware %s version %u.%u.%u\n",
intel_uc_fw_type_repr(fw->type), fw->file_selected.path,
-fw->file_selected.major_ver, fw->file_selected.minor_ver);
+fw->file_selected.major_ver,
+fw->file_selected.minor_ver,
+fw->file_selected.patch_ver);
}
static int __uc_init_hw(struct intel_uc *uc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 610f36f1b989a..af425916cdf64 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -447,10 +447,12 @@ static int check_gsc_manifest(const struct firmware *fw,
struct intel_uc_fw *uc_fw)
{
u32 *dw = (u32 *)fw->data;
- u32 version = dw[HUC_GSC_VERSION_DW];
+ u32 version_hi = dw[HUC_GSC_VERSION_HI_DW];
+ u32 version_lo = dw[HUC_GSC_VERSION_LO_DW];
- uc_fw->file_selected.major_ver = FIELD_GET(HUC_GSC_MAJOR_VER_MASK, version);
- uc_fw->file_selected.minor_ver = FIELD_GET(HUC_GSC_MINOR_VER_MASK,
version);
+ uc_fw->file_selected.major_ver = FIELD_GET(HUC_GSC_MAJOR_VER_HI_MASK,
version_hi);
+
[Intel-gfx] [PATCH v4 2/3] drm: Expand max DRM device number to full MINORBITS
Having a limit of 64 DRM devices is not good enough for modern world where we have multi-GPU servers, SR-IOV virtual functions and virtual devices used for testing. Let's utilize full minor range for DRM devices. To avoid regressing the existing userspace, we're still maintaining the numbering scheme where 0-63 is used for primary, 64-127 is reserved (formerly for control) and 128-191 is used for render. For minors >= 192, we're allocating minors dynamically on a first-come, first-served basis. Signed-off-by: Michał Winiarski --- drivers/gpu/drm/drm_drv.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 41799e4d0432..2c6e0b8d3b7a 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -119,8 +119,17 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned int type) minor->type = type; minor->dev = dev; + /* +* DRM used to support 64 devices, for backwards compatibility we need to maintain the +* minor allocation scheme where minors 0-63 are primary nodes, 64-127 are control nodes, +* and 128-191 are render nodes. +* After reaching the limit, we're allocating minors dynamically - first-come, first-serve. +*/ r = xa_alloc(_minors_xa, , NULL, XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL); + if (r == -EBUSY) + r = xa_alloc(_minors_xa, , NULL, +XA_LIMIT(192, (1 << MINORBITS) - 1), GFP_KERNEL); if (r < 0) return r; -- 2.37.3
[Intel-gfx] [PATCH v4 3/3] drm: Introduce skip_legacy_minors modparam
While there is support for >64 DRM devices on kernel side, existing
userspace may still have some hardcoded assumptions and it's possible
that it will require changes to be able to use more than 64 devices.
Add a modparam to simplify testing and development of >64 devices
support on userspace side by allocating minors from the >=192 range
(without the need of having >64 physical devices connected).
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_drv.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 2c6e0b8d3b7a..11c691543fec 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -56,6 +56,11 @@ MODULE_LICENSE("GPL and additional rights");
static DEFINE_XARRAY_ALLOC(drm_minors_xa);
+static bool skip_legacy_minors;
+module_param_unsafe(skip_legacy_minors, bool, 0400);
+MODULE_PARM_DESC(skip_legacy_minors,
+"Don't allocate minors in 0-192 range. This can be used for
testing userspace support for >64 drm devices (default: false)");
+
/*
* If the drm core fails to init for whatever reason,
* we should prevent any drivers from registering with it.
@@ -110,7 +115,7 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned
int type)
{
struct drm_minor *minor;
u32 id;
- int r;
+ int r = -EBUSY;
minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
if (!minor)
@@ -125,8 +130,9 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned
int type)
* and 128-191 are render nodes.
* After reaching the limit, we're allocating minors dynamically -
first-come, first-serve.
*/
- r = xa_alloc(_minors_xa, , NULL,
-XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL);
+ if (!skip_legacy_minors)
+ r = xa_alloc(_minors_xa, , NULL,
+XA_LIMIT(64 * type, 64 * (type + 1) - 1),
GFP_KERNEL);
if (r == -EBUSY)
r = xa_alloc(_minors_xa, , NULL,
XA_LIMIT(192, (1 << MINORBITS) - 1), GFP_KERNEL);
--
2.37.3
[Intel-gfx] [PATCH v4 1/3] drm: Use XArray instead of IDR for minors
IDR is deprecated, and since XArray manages its own state with internal
locking, it simplifies the locking on DRM side.
Additionally, don't use the IRQ-safe variant, since operating on drm
minor is not done in IRQ context.
Signed-off-by: Michał Winiarski
Suggested-by: Matthew Wilcox
---
drivers/gpu/drm/drm_drv.c | 49 ++-
1 file changed, 17 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 8214a0b1ab7f..41799e4d0432 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
@@ -53,8 +54,7 @@ MODULE_AUTHOR("Gareth Hughes, Leif Delgass, José Fonseca, Jon
Smirl");
MODULE_DESCRIPTION("DRM shared core routines");
MODULE_LICENSE("GPL and additional rights");
-static DEFINE_SPINLOCK(drm_minor_lock);
-static struct idr drm_minors_idr;
+static DEFINE_XARRAY_ALLOC(drm_minors_xa);
/*
* If the drm core fails to init for whatever reason,
@@ -98,21 +98,18 @@ static struct drm_minor **drm_minor_get_slot(struct
drm_device *dev,
static void drm_minor_alloc_release(struct drm_device *dev, void *data)
{
struct drm_minor *minor = data;
- unsigned long flags;
WARN_ON(dev != minor->dev);
put_device(minor->kdev);
- spin_lock_irqsave(_minor_lock, flags);
- idr_remove(_minors_idr, minor->index);
- spin_unlock_irqrestore(_minor_lock, flags);
+ xa_release(_minors_xa, minor->index);
}
static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
{
struct drm_minor *minor;
- unsigned long flags;
+ u32 id;
int r;
minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
@@ -122,20 +119,12 @@ static int drm_minor_alloc(struct drm_device *dev,
unsigned int type)
minor->type = type;
minor->dev = dev;
- idr_preload(GFP_KERNEL);
- spin_lock_irqsave(_minor_lock, flags);
- r = idr_alloc(_minors_idr,
- NULL,
- 64 * type,
- 64 * (type + 1),
- GFP_NOWAIT);
- spin_unlock_irqrestore(_minor_lock, flags);
- idr_preload_end();
-
+ r = xa_alloc(_minors_xa, , NULL,
+XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL);
if (r < 0)
return r;
- minor->index = r;
+ minor->index = id;
r = drmm_add_action_or_reset(dev, drm_minor_alloc_release, minor);
if (r)
@@ -152,7 +141,7 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned
int type)
static int drm_minor_register(struct drm_device *dev, unsigned int type)
{
struct drm_minor *minor;
- unsigned long flags;
+ void *entry;
int ret;
DRM_DEBUG("\n");
@@ -172,9 +161,12 @@ static int drm_minor_register(struct drm_device *dev,
unsigned int type)
goto err_debugfs;
/* replace NULL with @minor so lookups will succeed from now on */
- spin_lock_irqsave(_minor_lock, flags);
- idr_replace(_minors_idr, minor, minor->index);
- spin_unlock_irqrestore(_minor_lock, flags);
+ entry = xa_store(_minors_xa, minor->index, , GFP_KERNEL);
+ if (xa_is_err(entry)) {
+ ret = xa_err(entry);
+ goto err_debugfs;
+ }
+ WARN_ON(entry);
DRM_DEBUG("new minor registered %d\n", minor->index);
return 0;
@@ -187,16 +179,13 @@ static int drm_minor_register(struct drm_device *dev,
unsigned int type)
static void drm_minor_unregister(struct drm_device *dev, unsigned int type)
{
struct drm_minor *minor;
- unsigned long flags;
minor = *drm_minor_get_slot(dev, type);
if (!minor || !device_is_registered(minor->kdev))
return;
/* replace @minor with NULL so lookups will fail from now on */
- spin_lock_irqsave(_minor_lock, flags);
- idr_replace(_minors_idr, NULL, minor->index);
- spin_unlock_irqrestore(_minor_lock, flags);
+ xa_erase(_minors_xa, minor->index);
device_del(minor->kdev);
dev_set_drvdata(minor->kdev, NULL); /* safety belt */
@@ -215,13 +204,10 @@ static void drm_minor_unregister(struct drm_device *dev,
unsigned int type)
struct drm_minor *drm_minor_acquire(unsigned int minor_id)
{
struct drm_minor *minor;
- unsigned long flags;
- spin_lock_irqsave(_minor_lock, flags);
- minor = idr_find(_minors_idr, minor_id);
+ minor = xa_load(_minors_xa, minor_id);
if (minor)
drm_dev_get(minor->dev);
- spin_unlock_irqrestore(_minor_lock, flags);
if (!minor) {
return ERR_PTR(-ENODEV);
@@ -1037,7 +1023,7 @@ static void drm_core_exit(void)
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
- idr_destroy(_minors_idr);
+
[Intel-gfx] [PATCH v4 0/3] drm: Use full allocated minor range for DRM
64 DRM device nodes is not enough for everyone. Upgrade it to ~512K (which definitely is more than enough). To allow testing userspace support for >64 devices, add additional DRM modparam (skip_legacy_minors) which causes DRM to skip allocating minors in 0-192 range. Additionally - convert minors to use XArray instead of IDR to simplify the locking. v1 -> v2: Don't touch DRM_MINOR_CONTROL and its range (Simon Ser) v2 -> v3: Don't use legacy scheme for >=192 minor range (Dave Airlie) Add modparam for testing (Dave Airlie) Add lockdep annotation for IDR (Daniel Vetter) v3 -> v4: Convert from IDR to XArray (Matthew Wilcox) Michał Winiarski (3): drm: Use XArray instead of IDR for minors drm: Expand max DRM device number to full MINORBITS drm: Introduce skip_legacy_minors modparam drivers/gpu/drm/drm_drv.c | 66 +++ 1 file changed, 33 insertions(+), 33 deletions(-) -- 2.37.3
Re: [Intel-gfx] [PATCH 02/19] drm/i915/perf: Add OA formats for DG2
On 06/09/2022 22:46, Umesh Nerlige Ramappa wrote:
On Tue, Sep 06, 2022 at 10:35:16PM +0300, Lionel Landwerlin wrote:
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
Add new OA formats for DG2. Some of the newer OA formats are not
multples of 64 bytes and are not powers of 2. For those formats, adjust
hw_tail accordingly when checking for new reports.
Signed-off-by: Umesh Nerlige Ramappa
Apart from the coding style issue :
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 63
include/uapi/drm/i915_drm.h | 6 +++
2 files changed, 46 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c
b/drivers/gpu/drm/i915/i915_perf.c
index 735244a3aedd..c8331b549d31 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -306,7 +306,8 @@ static u32 i915_oa_max_sample_rate = 10;
/* XXX: beware if future OA HW adds new report formats that the
current
* code assumes all reports have a power-of-two size and ~(size -
1) can
- * be used as a mask to align the OA tail pointer.
+ * be used as a mask to align the OA tail pointer. In some of the
+ * formats, R is used to denote reserved field.
*/
static const struct i915_oa_format oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A13] = { 0, 64 },
@@ -320,6 +321,10 @@ static const struct i915_oa_format
oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A12] = { 0, 64 },
[I915_OA_FORMAT_A12_B8_C8] = { 2, 128 },
[I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
+ [I915_OAR_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
+ [I915_OA_FORMAT_A24u40_A14u32_B8_C8] = { 5, 256 },
+ [I915_OAR_FORMAT_A36u64_B8_C8] = { 1, 384 },
+ [I915_OA_FORMAT_A38u64_R2u64_B8_C8] = { 1, 448 },
};
#define SAMPLE_OA_REPORT (1<<0)
@@ -467,6 +472,7 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
bool pollin;
u32 hw_tail;
u64 now;
+ u32 partial_report_size;
/* We have to consider the (unlikely) possibility that read()
errors
* could result in an OA buffer reset which might reset the
head and
@@ -476,10 +482,16 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
hw_tail = stream->perf->ops.oa_hw_tail_read(stream);
- /* The tail pointer increases in 64 byte increments,
- * not in report_size steps...
+ /* The tail pointer increases in 64 byte increments, whereas
report
+ * sizes need not be integral multiples or 64 or powers of 2.
+ * Compute potentially partially landed report in the OA buffer
*/
- hw_tail &= ~(report_size - 1);
+ partial_report_size = OA_TAKEN(hw_tail, stream->oa_buffer.tail);
+ partial_report_size %= report_size;
+
+ /* Subtract partial amount off the tail */
+ hw_tail = gtt_offset + ((hw_tail - partial_report_size) &
+ (stream->oa_buffer.vma->size - 1));
now = ktime_get_mono_fast_ns();
@@ -601,6 +613,8 @@ static int append_oa_sample(struct
i915_perf_stream *stream,
{
int report_size = stream->oa_buffer.format_size;
struct drm_i915_perf_record_header header;
+ int report_size_partial;
+ u8 *oa_buf_end;
header.type = DRM_I915_PERF_RECORD_SAMPLE;
header.pad = 0;
@@ -614,7 +628,19 @@ static int append_oa_sample(struct
i915_perf_stream *stream,
return -EFAULT;
buf += sizeof(header);
- if (copy_to_user(buf, report, report_size))
+ oa_buf_end = stream->oa_buffer.vaddr +
+ stream->oa_buffer.vma->size;
+ report_size_partial = oa_buf_end - report;
+
+ if (report_size_partial < report_size) {
+ if(copy_to_user(buf, report, report_size_partial))
+ return -EFAULT;
+ buf += report_size_partial;
+
+ if(copy_to_user(buf, stream->oa_buffer.vaddr,
+ report_size - report_size_partial))
+ return -EFAULT;
I think the coding style requires you to use if () not if()
Will fix.
Just a suggestion : you could make this code deal with the partial
bit as the main bit of the function :
oa_buf_end = stream->oa_buffer.vaddr +
stream->oa_buffer.vma->size;
report_size_partial = oa_buf_end - report;
if (copy_to_user(buf, report, report_size_partial))
return -EFAULT;
buf += report_size_partial;
This ^ may not work because append_oa_sample is appending exactly one
report to the user buffer, whereas the above may append more than one.
Thanks,
Umesh
Ah I see, thanks for pointing this out.
-Lionel
if (report_size_partial < report_size &&
copy_to_user(buf, stream->oa_buffer.vaddr,
report_size - report_size_partial))
return -EFAULT;
buf += report_size - report_size_partial;
+ } else if (copy_to_user(buf, report, report_size))
return -EFAULT;
(*offset) += header.size;
@@ -684,8 +710,8 @@ static int gen8_append_oa_reports(struct
i915_perf_stream *stream,
* all a
Re: [Intel-gfx] [PATCH v6 1/6] drm/ttm: Add new callbacks to ttm res mgr
On Tue, Aug 16, 2022 at 10:33:16AM +0530, Arunpravin Paneer Selvam wrote:
>
>
> On 8/15/2022 4:35 PM, Christian König wrote:
> > Am 12.08.22 um 15:30 schrieb Arunpravin Paneer Selvam:
> > > We are adding two new callbacks to ttm resource manager
> > > function to handle intersection and compatibility of
> > > placement and resources.
> > >
> > > v2: move the amdgpu and ttm_range_manager changes to
> > > separate patches (Christian)
> > > v3: rename "intersect" to "intersects" (Matthew)
> > > v4: move !place check to the !res if and return false
> > > in ttm_resource_compatible() function (Christian)
> > > v5: move bits of code from patch number 6 to avoid
> > > temporary driver breakup (Christian)
> > >
> > > Signed-off-by: Christian König
> > > Signed-off-by: Arunpravin Paneer Selvam
> > >
> >
> > Patch #6 could still be cleaned up more now that we have the workaround
> > code in patch #1, but that not really a must have.
> >
> > Reviewed-by: Christian König for the entire
> > series.
> >
> > Do you already have commit rights?
>
> Hi Christian,
> I applied for drm-misc commit rights, waiting for the project maintainers to
> approve my request.
Why do all drivers have to implement the current behaviour? Can we have a
default implementation, which gets called if nothing is set instead?
I'm a bit confused why the bloat here ...
Also please document new callbacks precisely with inline kerneldoc. I know
ttm docs aren't great yet, but they don't get better if we don't start
somewhere. I think the in-depth comments for modeset vfuncs (e.g. in
drm_modeset_helper_vtables.h) are a good standard here.
-Daniel
>
> Thanks,
> Arun
> >
> > Regards,
> > Christian.
> >
> > > ---
> > > drivers/gpu/drm/ttm/ttm_bo.c | 9 ++--
> > > drivers/gpu/drm/ttm/ttm_resource.c | 77 +-
> > > include/drm/ttm/ttm_resource.h | 40
> > > 3 files changed, 119 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > > index c1bd006a5525..f066e8124c50 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > > @@ -518,6 +518,9 @@ static int ttm_bo_evict(struct ttm_buffer_object
> > > *bo,
> > > bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
> > > const struct ttm_place *place)
> > > {
> > > + struct ttm_resource *res = bo->resource;
> > > + struct ttm_device *bdev = bo->bdev;
> > > +
> > > dma_resv_assert_held(bo->base.resv);
> > > if (bo->resource->mem_type == TTM_PL_SYSTEM)
> > > return true;
> > > @@ -525,11 +528,7 @@ bool ttm_bo_eviction_valuable(struct
> > > ttm_buffer_object *bo,
> > > /* Don't evict this BO if it's outside of the
> > > * requested placement range
> > > */
> > > - if (place->fpfn >= (bo->resource->start +
> > > bo->resource->num_pages) ||
> > > - (place->lpfn && place->lpfn <= bo->resource->start))
> > > - return false;
> > > -
> > > - return true;
> > > + return ttm_resource_intersects(bdev, res, place, bo->base.size);
> > > }
> > > EXPORT_SYMBOL(ttm_bo_eviction_valuable);
> > > diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
> > > b/drivers/gpu/drm/ttm/ttm_resource.c
> > > index 20f9adcc3235..0d1f862a582b 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_resource.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_resource.c
> > > @@ -253,10 +253,84 @@ void ttm_resource_free(struct
> > > ttm_buffer_object *bo, struct ttm_resource **res)
> > > }
> > > EXPORT_SYMBOL(ttm_resource_free);
> > > +/**
> > > + * ttm_resource_intersects - test for intersection
> > > + *
> > > + * @bdev: TTM device structure
> > > + * @res: The resource to test
> > > + * @place: The placement to test
> > > + * @size: How many bytes the new allocation needs.
> > > + *
> > > + * Test if @res intersects with @place and @size. Used for testing
> > > if evictions
> > > + * are valueable or not.
> > > + *
> > > + * Returns true if the res placement intersects with @place and @size.
> > > + */
> > > +bool ttm_resource_intersects(struct ttm_device *bdev,
> > > + struct ttm_resource *res,
> > > + const struct ttm_place *place,
> > > + size_t size)
> > > +{
> > > + struct ttm_resource_manager *man;
> > > +
> > > + if (!res)
> > > + return false;
> > > +
> > > + if (!place)
> > > + return true;
> > > +
> > > + man = ttm_manager_type(bdev, res->mem_type);
> > > + if (!man->func->intersects) {
> > > + if (place->fpfn >= (res->start + res->num_pages) ||
> > > + (place->lpfn && place->lpfn <= res->start))
> > > + return false;
> > > +
> > > + return true;
> > > + }
> > > +
> > > + return man->func->intersects(man, res, place, size);
> > > +}
> > > +
> > > +/**
> > > + * ttm_resource_compatible - test for compatibility
> > > + *
> > > + * @bdev: TTM device
Re: [Intel-gfx] [PATCH 11/19] drm/i915/perf: Store a pointer to oa_format in oa_buffer
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
DG2 introduces OA reports with 64 bit report header fields. Perf OA
would need more information about the OA format in order to process such
reports. Store all OA format info in oa_buffer instead of just the size
and format-id.
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 23 ++-
drivers/gpu/drm/i915/i915_perf_types.h | 3 +--
2 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index f7621b45966c..9e455bd3bce5 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -483,7 +483,7 @@ static u32 gen7_oa_hw_tail_read(struct i915_perf_stream
*stream)
static bool oa_buffer_check_unlocked(struct i915_perf_stream *stream)
{
u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma);
- int report_size = stream->oa_buffer.format_size;
+ int report_size = stream->oa_buffer.format->size;
unsigned long flags;
bool pollin;
u32 hw_tail;
@@ -630,7 +630,7 @@ static int append_oa_sample(struct i915_perf_stream *stream,
size_t *offset,
const u8 *report)
{
- int report_size = stream->oa_buffer.format_size;
+ int report_size = stream->oa_buffer.format->size;
struct drm_i915_perf_record_header header;
int report_size_partial;
u8 *oa_buf_end;
@@ -694,7 +694,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
size_t *offset)
{
struct intel_uncore *uncore = stream->uncore;
- int report_size = stream->oa_buffer.format_size;
+ int report_size = stream->oa_buffer.format->size;
u8 *oa_buf_base = stream->oa_buffer.vaddr;
u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma);
size_t start_offset = *offset;
@@ -970,7 +970,7 @@ static int gen7_append_oa_reports(struct i915_perf_stream
*stream,
size_t *offset)
{
struct intel_uncore *uncore = stream->uncore;
- int report_size = stream->oa_buffer.format_size;
+ int report_size = stream->oa_buffer.format->size;
u8 *oa_buf_base = stream->oa_buffer.vaddr;
u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma);
u32 mask = (OA_BUFFER_SIZE - 1);
@@ -2517,7 +2517,7 @@ static int gen12_configure_oar_context(struct
i915_perf_stream *stream,
{
int err;
struct intel_context *ce = stream->pinned_ctx;
- u32 format = stream->oa_buffer.format;
+ u32 format = stream->oa_buffer.format->format;
u32 offset = stream->perf->ctx_oactxctrl_offset;
struct flex regs_context[] = {
{
@@ -2890,7 +2890,7 @@ static void gen7_oa_enable(struct i915_perf_stream
*stream)
u32 ctx_id = stream->specific_ctx_id;
bool periodic = stream->periodic;
u32 period_exponent = stream->period_exponent;
- u32 report_format = stream->oa_buffer.format;
+ u32 report_format = stream->oa_buffer.format->format;
/*
* Reset buf pointers so we don't forward reports from before now.
@@ -2916,7 +2916,7 @@ static void gen7_oa_enable(struct i915_perf_stream
*stream)
static void gen8_oa_enable(struct i915_perf_stream *stream)
{
struct intel_uncore *uncore = stream->uncore;
- u32 report_format = stream->oa_buffer.format;
+ u32 report_format = stream->oa_buffer.format->format;
/*
* Reset buf pointers so we don't forward reports from before now.
@@ -2942,7 +2942,7 @@ static void gen8_oa_enable(struct i915_perf_stream
*stream)
static void gen12_oa_enable(struct i915_perf_stream *stream)
{
struct intel_uncore *uncore = stream->uncore;
- u32 report_format = stream->oa_buffer.format;
+ u32 report_format = stream->oa_buffer.format->format;
/*
* If we don't want OA reports from the OA buffer, then we don't even
@@ -3184,15 +3184,12 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
stream->sample_flags = props->sample_flags;
stream->sample_size += format_size;
- stream->oa_buffer.format_size = format_size;
- if (drm_WARN_ON(>drm, stream->oa_buffer.format_size == 0))
+ stream->oa_buffer.format = >oa_formats[props->oa_format];
+ if (drm_WARN_ON(>drm, stream->oa_buffer.format->size == 0))
return -EINVAL;
stream->hold_preemption = props->hold_preemption;
- stream->oa_buffer.format =
- perf->oa_formats[props->oa_format].format;
-
stream->periodic = props->oa_periodic;
if (stream->periodic)
stream->period_exponent = props->oa_period_exponent;
diff --git a/drivers/gpu/drm/i915/i915_perf_types.h
b/drivers/gpu/drm/i915/i915_perf_types.h
index dc9bfd8086cf..e0c96b44eda8
Re: [Intel-gfx] [PATCH 10/19] drm/i915/perf: Use gt-specific ggtt for OA and noa-wait buffers
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
User passes uabi engine class and instance to the perf OA interface. Use
gt corresponding to the engine to pin the buffers to the right ggtt.
Signed-off-by: Umesh Nerlige Ramappa
I didn't know there was a GGTT per engine.
Do I understand this correct?
Thanks,
-Lionel
---
drivers/gpu/drm/i915/i915_perf.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 87b92d2946f4..f7621b45966c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1765,6 +1765,7 @@ static void gen12_init_oa_buffer(struct i915_perf_stream
*stream)
static int alloc_oa_buffer(struct i915_perf_stream *stream)
{
struct drm_i915_private *i915 = stream->perf->i915;
+ struct intel_gt *gt = stream->engine->gt;
struct drm_i915_gem_object *bo;
struct i915_vma *vma;
int ret;
@@ -1784,11 +1785,22 @@ static int alloc_oa_buffer(struct i915_perf_stream
*stream)
i915_gem_object_set_cache_coherency(bo, I915_CACHE_LLC);
/* PreHSW required 512K alignment, HSW requires 16M */
- vma = i915_gem_object_ggtt_pin(bo, NULL, 0, SZ_16M, 0);
+ vma = i915_vma_instance(bo, >ggtt->vm, NULL);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
goto err_unref;
}
+
+ /*
+* PreHSW required 512K alignment.
+* HSW and onwards, align to requested size of OA buffer.
+*/
+ ret = i915_vma_pin(vma, 0, SZ_16M, PIN_GLOBAL | PIN_HIGH);
+ if (ret) {
+ drm_err(>i915->drm, "Failed to pin OA buffer %d\n", ret);
+ goto err_unref;
+ }
+
stream->oa_buffer.vma = vma;
stream->oa_buffer.vaddr =
@@ -1838,6 +1850,7 @@ static u32 *save_restore_register(struct i915_perf_stream
*stream, u32 *cs,
static int alloc_noa_wait(struct i915_perf_stream *stream)
{
struct drm_i915_private *i915 = stream->perf->i915;
+ struct intel_gt *gt = stream->engine->gt;
struct drm_i915_gem_object *bo;
struct i915_vma *vma;
const u64 delay_ticks = 0x -
@@ -1878,12 +1891,16 @@ static int alloc_noa_wait(struct i915_perf_stream
*stream)
* multiple OA config BOs will have a jump to this address and it
* needs to be fixed during the lifetime of the i915/perf stream.
*/
- vma = i915_gem_object_ggtt_pin_ww(bo, , NULL, 0, 0, PIN_HIGH);
+ vma = i915_vma_instance(bo, >ggtt->vm, NULL);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
goto out_ww;
}
+ ret = i915_vma_pin_ww(vma, , 0, 0, PIN_GLOBAL | PIN_HIGH);
+ if (ret)
+ goto out_ww;
+
batch = cs = i915_gem_object_pin_map(bo, I915_MAP_WB);
if (IS_ERR(batch)) {
ret = PTR_ERR(batch);
Re: [Intel-gfx] [PATCH 08/19] drm/i915/perf: Move gt-specific data from i915->perf to gt->perf
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
Make perf part of gt as the OAG buffer is specific to a gt. The refactor
eventually simplifies programming the right OA buffer and the right HW
registers when supporting multiple gts.
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +
drivers/gpu/drm/i915/gt/intel_sseu.c | 4 +-
drivers/gpu/drm/i915/i915_perf.c | 75 +-
drivers/gpu/drm/i915/i915_perf_types.h | 39 +--
drivers/gpu/drm/i915/selftests/i915_perf.c | 16 +++--
5 files changed, 80 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 4d56f7d5a3be..3d079d206cec 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -20,6 +20,7 @@
#include "intel_gsc.h"
#include "i915_vma.h"
+#include "i915_perf_types.h"
#include "intel_engine_types.h"
#include "intel_gt_buffer_pool_types.h"
#include "intel_hwconfig.h"
@@ -260,6 +261,8 @@ struct intel_gt {
/* sysfs defaults per gt */
struct gt_defaults defaults;
struct kobject *sysfs_defaults;
+
+ struct i915_perf_gt perf;
};
enum intel_gt_scratch_field {
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index c6d3050604c8..fcaf3c58b554 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -678,8 +678,8 @@ u32 intel_sseu_make_rpcs(struct intel_gt *gt,
* If i915/perf is active, we want a stable powergating configuration
* on the system. Use the configuration pinned by i915/perf.
*/
- if (i915->perf.exclusive_stream)
- req_sseu = >perf.sseu;
+ if (gt->perf.exclusive_stream)
+ req_sseu = >perf.sseu;
slices = hweight8(req_sseu->slice_mask);
subslices = hweight8(req_sseu->subslice_mask);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3e3bda147c48..5dccb3c5 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1577,8 +1577,9 @@ free_noa_wait(struct i915_perf_stream *stream)
static void i915_oa_stream_destroy(struct i915_perf_stream *stream)
{
struct i915_perf *perf = stream->perf;
+ struct intel_gt *gt = stream->engine->gt;
- BUG_ON(stream != perf->exclusive_stream);
+ BUG_ON(stream != gt->perf.exclusive_stream);
/*
* Unset exclusive_stream first, it will be checked while disabling
@@ -1586,7 +1587,7 @@ 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);
+ WRITE_ONCE(gt->perf.exclusive_stream, NULL);
perf->ops.disable_metric_set(stream);
free_oa_buffer(stream);
@@ -2579,10 +2580,11 @@ oa_configure_all_contexts(struct i915_perf_stream
*stream,
{
struct drm_i915_private *i915 = stream->perf->i915;
struct intel_engine_cs *engine;
+ struct intel_gt *gt = stream->engine->gt;
struct i915_gem_context *ctx, *cn;
int err;
- lockdep_assert_held(>perf->lock);
+ lockdep_assert_held(>perf.lock);
/*
* The OA register config is setup through the context image. This image
@@ -3103,6 +3105,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
{
struct drm_i915_private *i915 = stream->perf->i915;
struct i915_perf *perf = stream->perf;
+ struct intel_gt *gt;
int format_size;
int ret;
@@ -3111,6 +3114,7 @@ static int i915_oa_stream_init(struct i915_perf_stream *stream,
"OA engine not specified\n");
return -EINVAL;
}
+ gt = props->engine->gt;
/*
* If the sysfs metrics/ directory wasn't registered for some
@@ -3141,7 +3145,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
* counter reports and marshal to the appropriate client
* we currently only allow exclusive access
*/
- if (perf->exclusive_stream) {
+ if (gt->perf.exclusive_stream) {
drm_dbg(>perf->i915->drm,
"OA unit already in use\n");
return -EBUSY;
@@ -3221,8 +3225,8 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
stream->ops = _oa_stream_ops;
- perf->sseu = props->sseu;
- WRITE_ONCE(perf->exclusive_stream, stream);
+ stream->engine->gt->perf.sseu = props->sseu;
+ WRITE_ONCE(gt->perf.exclusive_stream, stream);
ret = i915_perf_stream_enable_sync(stream);
if (ret) {
@@ -3244,7 +3248,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
return 0;
err_enable:
-
Re: [Intel-gfx] [PATCH 07/19] drm/i915/perf: Simply use stream->ctx
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
Earlier code used exclusive_stream to check for user passed context.
Simplify this by accessing stream->ctx.
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index bbf1c574f393..3e3bda147c48 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -801,7 +801,7 @@ 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 ||
+ if (!stream->ctx ||
stream->specific_ctx_id == ctx_id ||
stream->oa_buffer.last_ctx_id == stream->specific_ctx_id ||
reason & OAREPORT_REASON_CTX_SWITCH) {
@@ -810,7 +810,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* While filtering for a single context we avoid
* leaking the IDs of other contexts.
*/
- if (stream->perf->exclusive_stream->ctx &&
+ if (stream->ctx &&
stream->specific_ctx_id != ctx_id) {
report32[2] = INVALID_CTX_ID;
}
Re: [Intel-gfx] [PATCH v2 35/39] docs: gpu: i915.rst: add the remaining kernel-doc markup files
On Tue, 9 Aug 2022 06:20:57 -0400 Rodrigo Vivi wrote: > On Wed, Jul 13, 2022 at 09:12:23AM +0100, Mauro Carvalho Chehab wrote: > > There are other files with kernel-doc markups: > > > > $ git grep -l "/\*\*" $(git ls-files|grep drivers/gpu/drm/i915/) > > >kernel-doc-files > > $ for i in $(cat kernel-doc-files); do if [ "$(git grep $i > > Documentation/)" == "" ]; then echo "$i"; fi; done >aaa > > > > Add them to i915.rst as well. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > > > To avoid mailbombing on a large number of people, only mailing lists were > > C/C on the cover. > > See [PATCH v2 00/39] at: > > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > > > Documentation/gpu/i915.rst | 87 ++ > > 1 file changed, 87 insertions(+) > > > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > > index 974754586be8..6bb50edc6d79 100644 > > --- a/Documentation/gpu/i915.rst > > +++ b/Documentation/gpu/i915.rst > > @@ -13,6 +13,11 @@ Core Driver Infrastructure > > This section covers core driver infrastructure used by both the display > > and the GEM parts of the driver. > > > > +Core driver > > +--- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_driver.c > > + > > Runtime Power Management > > > > > > @@ -29,6 +34,10 @@ Runtime Power Management > > > > .. kernel-doc:: drivers/gpu/drm/i915/intel_pm.c > > > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_wakeref.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_active.h > > not sure if this belongs to this group... > > > + > > Interrupt Handling > > -- > > > > @@ -44,6 +53,28 @@ Interrupt Handling > > .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c > > :functions: intel_runtime_pm_enable_interrupts > > > > +Error handling > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_gpu_error.c > > not sure if this gt hang stuff deserves a separated section > alone and if the name is the best one > > > + > > +Memory Handling > > +--- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_mm.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_memory_region.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_memcpy.c > > + > > Intel GVT-g Guest Support(vGPU) > > ^ missing space > > > --- > > > > @@ -109,6 +140,54 @@ Workarounds > > .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c > > :doc: Hardware workarounds > > > > +32-bits compatible ioctl Logic > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ioc32.c > > + > > +Scatterlist handling > > + > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.c > > + > > +i915 request > > + > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.c > > + > > +Ancillary routines > > maybe simply have an "Others" section and put everything > that has only one item like the gpu hang one? OK! > > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_device_info.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_params.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_sw_fence_work.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_syncmap.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_pcode.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_reg_defs.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.h > > + > > + > > +PXP > > Protected Xe Path (PXP) > > > > +--- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_irq.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_tee.c > > + > > Display Hardware Handling > > = > > > > @@ -618,6 +697,12 @@ Protected Objects > > Table Manager (TTM) > > --- > > > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ttm_buddy_manager.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ttm_buddy_manager.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_region_ttm.c > > + > > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.h > > @@ -627,6 +712,8 @@ Table Manager (TTM) > > Graphics Execution Manager (GEM) > > > > > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_gem.c > >
Re: [Intel-gfx] [PATCH v2 30/39] docs: gpu: i915.rst: gt: add more kernel-doc markups
On Tue, 9 Aug 2022 06:01:53 -0400 Rodrigo Vivi wrote: > On Wed, Jul 13, 2022 at 09:12:18AM +0100, Mauro Carvalho Chehab wrote: > > There are several documented GT kAPI that aren't currently part > > of the docs. Add them, as this allows identifying issues with > > badly-formatted tags. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > > > To avoid mailbombing on a large number of people, only mailing lists were > > C/C on the cover. > > See [PATCH v2 00/39] at: > > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > > > Documentation/gpu/i915.rst | 43 +- > > 1 file changed, 42 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > > index 2ad7941a79f2..afd8c0e3c689 100644 > > --- a/Documentation/gpu/i915.rst > > +++ b/Documentation/gpu/i915.rst > > @@ -149,7 +149,6 @@ Misc display functions > > > > .. kernel-doc:: drivers/gpu/drm/i915/display/skl_scaler.c > > > > - > > Plane Configuration > > --- > > > > @@ -308,6 +307,48 @@ Multicast/Replicated (MCR) Registers > > .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c > > :internal: > > > > +GT engine > > +- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_types.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_cs.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_pm.c > > + > > +GT context > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_context.h > > why does the context deserves a separated section and the > many others below no? Good question. The patches adding stuff to i915.rst are the hardest ones to produce, in the sense that it is not easy to have a common criteria about when creating or not a new section. I tried to follow the same as other things for the same type, but it is hard to classify. The main point is that they should be somewhere there, in order to start producing errors when building the docs. Reorganizing those markups should be easily done once all files with kernel-docs gets added there. Anyway, I'll keep this under: Other GT functionality Section. We can shift things later on as needed. > > + > > +Graphics Translation Tables > > +--- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_ggtt.c > > + > > +Other GT functionality > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gsc.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.h > > Why aren't these gtt ones in the above block? why only > having the global gtt there? Makes sense. I'll place GTT together with GGTT. > > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_migrate.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_mocs.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rc6.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_reset.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps_types.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_sseu.c > > + > > Memory Management and Command Submission > > > > > > -- > > 2.36.1 > >
Re: [Intel-gfx] [PATCH v2 18/39] drm/i915: intel_pm.c: fix some ascii artwork at kernel-doc
On Tue, 9 Aug 2022 05:55:10 -0400
Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:12:06AM +0100, Mauro Carvalho Chehab wrote:
> > Preserving ascii artwork on kernel-docs is tricky, as it needs
> > to respect both the Sphinx rules and be properly parsed by
> > kernel-doc script.
> >
> > The Sphinx syntax require code-blocks, which is:
> >
> > ::
> >
> > followed by a blank line and indented lines.
> >
> > But kernel-doc only works fine if the first and the last line
> > are indented with the same amount of spaces.
> >
> > Also, a "\" at the end means that the next line should be merged
> > with the first one.
>
> my first reaction was: "do we really need those new empty ( ) blocks?"
>
> Then I read this ;)
Yeah, it is tricky to get it right, due to kernel-doc + Sphinx here.
Also, I bet that this would be needed even for ReST files with
C code on it, as it is likely the C domain encoding at Sphinx that
handles continuation lines with "\" at the end...
>
> Reviewed-by: Rodrigo Vivi
>
> >
> > Change the ascii artwork to be on code-blocks, starting all
> > lines at the same characters and not ending with a backslash.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> >
> > To avoid mailbombing on a large number of people, only mailing lists were
> > C/C on the cover.
> > See [PATCH v2 00/39] at:
> > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> >
> > drivers/gpu/drm/i915/intel_pm.c | 33 ++---
> > 1 file changed, 18 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index f06babdb3a8c..d3393752b04b 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -684,18 +684,20 @@ static const struct intel_watermark_params
> > i845_wm_info = {
> > * FIFO is relatively small compared to the amount of data
> > * fetched.
> > *
> > - * The FIFO level vs. time graph might look something like:
> > + * The FIFO level vs. time graph might look something like::
> > *
> > - * |\ |\
> > - * | \ | \
> > - * __---__---__ (- plane active, _ blanking)
> > - * -> time
> > + * ^
> > + * | |\ |\ ( )
> > + * | | \ | \ ( )
> > + * | __---__---__ (- plane active, _ blanking)
> > + * +---> time
> > *
> > - * or perhaps like this:
> > + * or perhaps like this::
> > *
> > - * |\|\ |\|\
> > - * ______ (- plane active, _ blanking)
> > - * -> time
> > + * ^
> > + * | |\|\ |\|\ ( )
> > + * | ______ (- plane active, _ blanking)
> > + * +---> time
> > *
> > * Returns:
> > * The watermark in bytes
> > @@ -731,13 +733,14 @@ static unsigned int intel_wm_method1(unsigned int
> > pixel_rate,
> > * FIFO is relatively large compared to the amount of data
> > * fetched.
> > *
> > - * The FIFO level vs. time graph might look something like:
> > + * The FIFO level vs. time graph might look something like::
> > *
> > - *|\___ |\___
> > - *|\___ |\___
> > - *|\ |\
> > - * __ --__--__--__--__--__--__ (- plane active, _ blanking)
> > - * -> time
> > + * ^
> > + * | |\___ |\___( )
> > + * | |\___ |\___( )
> > + * | |\ |\ ( )
> > + * | __ --__--__--__--__--__--__ (- plane active, _ blanking)
> > + * +-> time
> > *
> > * Returns:
> > * The watermark in bytes
> > --
> > 2.36.1
> >
Re: [Intel-gfx] [PATCH v2 16/39] drm/i915: intel_fb: fix a kernel-doc issue with Sphinx
On Fri, 15 Jul 2022 17:40:25 -0400 Rodrigo Vivi wrote: > On Wed, Jul 13, 2022 at 09:12:04AM +0100, Mauro Carvalho Chehab wrote: > > We can't use %foo[] as this produces a bad markup. > > Use instead, the emphasis markup directly. > > > > Fix this issue: > > Documentation/gpu/i915:136: > > ./drivers/gpu/drm/i915/display/intel_fb.c:280: WARNING: Inline strong > > start-string without end-string. > > > > Signed-off-by: Mauro Carvalho Chehab > > Just trying to understand as well on why in a few you had chosen ```foo``` > and here **foo**. why? > No particular reason. I'll use ``foo`` here too, keeping your reviewed-by. > anyway, not a blocker: > > Reviewed-by: Rodrigo Vivi > > > > > --- > > > > To avoid mailbombing on a large number of people, only mailing lists were > > C/C on the cover. > > See [PATCH v2 00/39] at: > > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > > > drivers/gpu/drm/i915/display/intel_fb.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c > > b/drivers/gpu/drm/i915/display/intel_fb.c > > index b191915ab351..fe72c75a9c79 100644 > > --- a/drivers/gpu/drm/i915/display/intel_fb.c > > +++ b/drivers/gpu/drm/i915/display/intel_fb.c > > @@ -276,7 +276,7 @@ lookup_format_info(const struct drm_format_info > > formats[], > > * @cmd: FB add command structure > > * > > * Returns: > > - * Returns the format information for @cmd->pixel_format specific to > > @cmd->modifier[0], > > + * Returns the format information for @cmd->pixel_format specific to > > **cmd->modifier[0]**, > > * or %NULL if the modifier doesn't override the format. > > */ > > const struct drm_format_info * > > -- > > 2.36.1 > >
Re: [Intel-gfx] [PATCH v2 15/39] drm/i915: intel_dp_link_training.c: fix kernel-doc markup
On Tue, 9 Aug 2022 05:51:39 -0400
Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:12:03AM +0100, Mauro Carvalho Chehab wrote:
> > The return code table is not properly marked, causing warnings
> > and being badly parsed by Sphinx:
> >
> > Documentation/gpu/i915:130:
> > ./drivers/gpu/drm/i915/display/intel_dp_link_training.c:183: WARNING: Block
> > quote ends without a blank line; unexpected unindent.
> > Documentation/gpu/i915:130:
> > ./drivers/gpu/drm/i915/display/intel_dp_link_training.c:186: WARNING:
> > Definition list ends without a blank line; unexpected unindent.
> >
> > Use table markups to fix it.
>
> cool, I didn't know that
Yeah, you can use almost all Sphinx tags inside a kernel-doc markup,
taking some care with indents and not conflicting with the things
that kernel-doc itself parses.
The same is also valid for uAPI stuff inside Documentation/ABI.
Regards,
Mauro
>
> Reviewed-by: Rodrigo Vivi
>
>
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> >
> > To avoid mailbombing on a large number of people, only mailing lists were
> > C/C on the cover.
> > See [PATCH v2 00/39] at:
> > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> >
> > drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index 9feaf1a589f3..23a269fcf6ca 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -177,12 +177,14 @@ static int intel_dp_init_lttpr(struct intel_dp
> > *intel_dp, const u8 dpcd[DP_RECEI
> > * transparent mode link training mode.
> > *
> > * Returns:
> > + *
> > =
> > * >0 if LTTPRs were detected and the non-transparent LT mode was set.
> > The
> > * DPRX capabilities are read out.
> > *0 if no LTTPRs or more than 8 LTTPRs were detected or in case of a
> > * detection failure and the transparent LT mode was set. The DPRX
> > * capabilities are read out.
> > * <0 Reading out the DPRX capabilities failed.
> > + *
> > =
> > */
> > int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
> > {
> > --
> > 2.36.1
> >
Re: [Intel-gfx] [PATCH v2 38/39] drm/i915: add descriptions for some RPM macros at intel_gt_pm.h
On Tue, 9 Aug 2022 06:12:06 -0400
Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:12:26AM +0100, Mauro Carvalho Chehab wrote:
> > The intel_gt_pm.h file contains some convenient macros to be used
> > in GT code in order to get/put runtime PM references and for
> > checking them.
> >
> > Add descriptions based on the ones at intel_wakeref.h and
> > intel_runtime_pm.c.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> >
> > To avoid mailbombing on a large number of people, only mailing lists were
> > C/C on the cover.
> > See [PATCH v2 00/39] at:
> > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> >
> > Documentation/gpu/i915.rst| 2 +
> > drivers/gpu/drm/i915/gt/intel_gt_pm.h | 62 +++
> > 2 files changed, 64 insertions(+)
> >
> > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> > index 6bb50edc6d79..9862d504df4d 100644
> > --- a/Documentation/gpu/i915.rst
> > +++ b/Documentation/gpu/i915.rst
> > @@ -709,6 +709,8 @@ Table Manager (TTM)
> >
> > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> >
> > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_pm.h
>
> I don't believe this is the right placement for this.
I'll add it then at:
Other GT functionality
Section.
Regards,
Mauro
>
> the rest lgtm
>
> > +
> > Graphics Execution Manager (GEM)
> >
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > index bc898df7a48c..a8ea6846980a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > @@ -11,21 +11,57 @@
> > #include "intel_gt_types.h"
> > #include "intel_wakeref.h"
> >
> > +/**
> > + * intel_gt_pm_is_awake: Query whether the runtime PM is awake held
> > + *
> > + * @gt: pointer to the graphics engine
> > + *
> > + * Returns: true if a runtime pm reference is currently held and the GT is
> > + * awake.
> > + */
> > static inline bool intel_gt_pm_is_awake(const struct intel_gt *gt)
> > {
> > return intel_wakeref_is_active(>wakeref);
> > }
> >
> > +/**
> > + * intel_gt_pm_get: grab a runtime PM reference ensuring that GT is
> > powered up
> > + * @gt: pointer to the graphics engine
> > + *
> > + * Any runtime pm reference obtained by this function must have a symmetric
> > + * call to intel_gt_pm_put() to release the reference again.
> > + *
> > + * Note that this is allowed to fail, in which case the runtime-pm wakeref
> > + * will be released and the acquisition unwound.
> > + */
> > static inline void intel_gt_pm_get(struct intel_gt *gt)
> > {
> > intel_wakeref_get(>wakeref);
> > }
> >
> > +/**
> > + * __intel_gt_pm_get: Acquire the runtime PM reference again
> > + * @gt: pointer to the graphics engine which contains the wakeref
> > + *
> > + * Increment the PM reference counter, only valid if it is already held by
> > + * the caller.
> > + *
> > + * See intel_gt_pm_get().
> > + */
> > static inline void __intel_gt_pm_get(struct intel_gt *gt)
> > {
> > __intel_wakeref_get(>wakeref);
> > }
> >
> > +/**
> > + * intel_gt_pm_get_if_awake: Acquire the runtime PM reference if active
> > + * @gt: pointer to the graphics engine which contains the PM reference
> > + *
> > + * Acquire a hold on the PM reference, but only if the GT is already
> > + * active.
> > + *
> > + * Returns: true if the wakeref was acquired, false otherwise.
> > + */
> > static inline bool intel_gt_pm_get_if_awake(struct intel_gt *gt)
> > {
> > return intel_wakeref_get_if_active(>wakeref);
> > @@ -36,6 +72,14 @@ static inline void intel_gt_pm_might_get(struct intel_gt
> > *gt)
> > intel_wakeref_might_get(>wakeref);
> > }
> >
> > +/**
> > + * intel_gt_pm_put: Release the runtime PM reference
> > + * @gt: pointer to the graphics engine which contains the PM reference
> > + *
> > + * Release our hold on the runtime PM for GT.
> > + *
> > + * It might power down the GT right away if this is the last reference.
> > + */
> > static inline void intel_gt_pm_put(struct intel_gt *gt)
> > {
> > intel_wakeref_put(>wakeref);
> > @@ -51,10 +95,28 @@ static inline void intel_gt_pm_might_put(struct
> > intel_gt *gt)
> > intel_wakeref_might_put(>wakeref);
> > }
> >
> > +/**
> > + * with_intel_gt_pm - get a GT reference ensuring that GT is powered up,
> > + * run some code and then put the reference away.
> > + *
> > + * @gt: pointer to the gt
> > + * @tmp: pointer to a temporary wakeref.
> > + */
> > #define with_intel_gt_pm(gt, tmp) \
> > for (tmp = 1, intel_gt_pm_get(gt); tmp; \
> > intel_gt_pm_put(gt), tmp = 0)
> >
> > +/**
> > + * intel_gt_pm_wait_for_idle: Wait until the runtime PM reference is idle
> > + * @gt: pointer to the graphics engine which contains the PM reference
> > + *
> > + * Wait for the earlier asynchronous release of the runtime PM reference.
> > Note
> > + * this will wait for any third
Re: [Intel-gfx] [PATCH 05/19] drm/i915/perf: Enable commands per clock reporting in OA
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
XEHPSDV and DG2 provide a way to configure bytes per clock vs commands
per clock reporting. Enable command per clock setting on enabling OA.
Signed-off-by: Umesh Nerlige Ramappa
Acked-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/i915_perf.c | 20
drivers/gpu/drm/i915/i915_perf_oa_regs.h | 4
drivers/gpu/drm/i915/intel_device_info.h | 1 +
5 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b4733c5a01da..b2e8a44bd976 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1287,6 +1287,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_RUNTIME_PM(dev_priv) (INTEL_INFO(dev_priv)->has_runtime_pm)
#define HAS_64BIT_RELOC(dev_priv) (INTEL_INFO(dev_priv)->has_64bit_reloc)
+#define HAS_OA_BPC_REPORTING(dev_priv) \
+ (INTEL_INFO(dev_priv)->has_oa_bpc_reporting)
+
/*
* Set this flag, when platform requires 64K GTT page sizes or larger for
* device local memory access.
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index d8446bb25d5e..bd0b8502b91e 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1019,6 +1019,7 @@ static const struct intel_device_info adl_p_info = {
.has_logical_ring_contexts = 1, \
.has_logical_ring_elsq = 1, \
.has_mslice_steering = 1, \
+ .has_oa_bpc_reporting = 1, \
.has_rc6 = 1, \
.has_reset_engine = 1, \
.has_rps = 1, \
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index efa7eda83edd..6fc4f0d8fc5a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2745,10 +2745,12 @@ static int
gen12_enable_metric_set(struct i915_perf_stream *stream,
struct i915_active *active)
{
+ struct drm_i915_private *i915 = stream->perf->i915;
struct intel_uncore *uncore = stream->uncore;
struct i915_oa_config *oa_config = stream->oa_config;
bool periodic = stream->periodic;
u32 period_exponent = stream->period_exponent;
+ u32 sqcnt1;
int ret;
intel_uncore_write(uncore, GEN12_OAG_OA_DEBUG,
@@ -2767,6 +2769,16 @@ gen12_enable_metric_set(struct i915_perf_stream *stream,
(period_exponent <<
GEN12_OAG_OAGLBCTXCTRL_TIMER_PERIOD_SHIFT))
: 0);
+ /*
+* Initialize Super Queue Internal Cnt Register
+* Set PMON Enable in order to collect valid metrics.
+* Enable commands per clock reporting in OA for XEHPSDV onward.
+*/
+ sqcnt1 = GEN12_SQCNT1_PMON_ENABLE |
+(HAS_OA_BPC_REPORTING(i915) ? GEN12_SQCNT1_OABPC : 0);
+
+ intel_uncore_rmw(uncore, GEN12_SQCNT1, 0, sqcnt1);
+
/*
* Update all contexts prior writing the mux configurations as we need
* to make sure all slices/subslices are ON before writing to NOA
@@ -2816,6 +2828,8 @@ static void gen11_disable_metric_set(struct
i915_perf_stream *stream)
static void gen12_disable_metric_set(struct i915_perf_stream *stream)
{
struct intel_uncore *uncore = stream->uncore;
+ struct drm_i915_private *i915 = stream->perf->i915;
+ u32 sqcnt1;
/* Reset all contexts' slices/subslices configurations. */
gen12_configure_all_contexts(stream, NULL, NULL);
@@ -2826,6 +2840,12 @@ static void gen12_disable_metric_set(struct
i915_perf_stream *stream)
/* Make sure we disable noa to save power. */
intel_uncore_rmw(uncore, RPM_CONFIG1, GEN10_GT_NOA_ENABLE, 0);
+
+ sqcnt1 = GEN12_SQCNT1_PMON_ENABLE |
+(HAS_OA_BPC_REPORTING(i915) ? GEN12_SQCNT1_OABPC : 0);
+
+ /* Reset PMON Enable to save power. */
+ intel_uncore_rmw(uncore, GEN12_SQCNT1, sqcnt1, 0);
}
static void gen7_oa_enable(struct i915_perf_stream *stream)
diff --git a/drivers/gpu/drm/i915/i915_perf_oa_regs.h
b/drivers/gpu/drm/i915/i915_perf_oa_regs.h
index 0ef3562ff4aa..381d94101610 100644
--- a/drivers/gpu/drm/i915/i915_perf_oa_regs.h
+++ b/drivers/gpu/drm/i915/i915_perf_oa_regs.h
@@ -134,4 +134,8 @@
#define GDT_CHICKEN_BITS_MMIO(0x9840)
#define GT_NOA_ENABLE 0x0080
+#define GEN12_SQCNT1_MMIO(0x8718)
+#define GEN12_SQCNT1_PMON_ENABLE REG_BIT(30)
+#define GEN12_SQCNT1_OABPC REG_BIT(29)
+
#endif /* __INTEL_PERF_OA_REGS__ */
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 23bf230aa104..fc2a0660426e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -163,6 +163,7 @@ enum intel_ppgtt_type {
func(has_logical_ring_elsq); \
Re: [Intel-gfx] [PATCH 04/19] drm/i915/perf: Determine gen12 oa ctx offset at runtime
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
Some SKUs of same gen12 platform may have different oactxctrl
offsets. For gen12, determine oactxctrl offsets at runtime.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 149 ++-
drivers/gpu/drm/i915/i915_perf_oa_regs.h | 2 +-
2 files changed, 120 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3526693d64fa..efa7eda83edd 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1363,6 +1363,67 @@ static int gen12_get_render_context_id(struct
i915_perf_stream *stream)
return 0;
}
+#define MI_OPCODE(x) (((x) >> 23) & 0x3f)
+#define IS_MI_LRI_CMD(x) (MI_OPCODE(x) == MI_OPCODE(MI_INSTR(0x22, 0)))
+#define MI_LRI_LEN(x) (((x) & 0xff) + 1)
Maybe you want to put this in intel_gpu_commands.h
+#define __valid_oactxctrl_offset(x) ((x) && (x) != U32_MAX)
+static bool __find_reg_in_lri(u32 *state, u32 reg, u32 *offset)
+{
+ u32 idx = *offset;
+ u32 len = MI_LRI_LEN(state[idx]) + idx;
+
+ idx++;
+ for (; idx < len; idx += 2)
+ if (state[idx] == reg)
+ break;
+
+ *offset = idx;
+ return state[idx] == reg;
+}
+
+static u32 __context_image_offset(struct intel_context *ce, u32 reg)
+{
+ u32 offset, len = (ce->engine->context_size - PAGE_SIZE) / 4;
+ u32 *state = ce->lrc_reg_state;
+
+ for (offset = 0; offset < len; ) {
+ if (IS_MI_LRI_CMD(state[offset])) {
I'm a bit concerned you might find other matches with this.
Because let's say you run into a 3DSTATE_SUBSLICE_HASH_TABLE
instruction, you'll iterate the instruction dword by dword because you
don't know how to read its length and skip to the next one.
Now some of the fields can be programmed from userspace to look like an
MI_LRI header, so you start to read data in the wrong way.
Unfortunately I don't have a better solution. My only ask is that you
make __find_reg_in_lri() take the context image size in parameter so it
NEVER goes over the the context image.
To limit the risk you should run this function only one at driver
initialization and store the found offset.
Thanks,
-Lionel
+ if (__find_reg_in_lri(state, reg, ))
+ break;
+ } else {
+ offset++;
+ }
+ }
+
+ return offset < len ? offset : U32_MAX;
+}
+
+static int __set_oa_ctx_ctrl_offset(struct intel_context *ce)
+{
+ i915_reg_t reg = GEN12_OACTXCONTROL(ce->engine->mmio_base);
+ struct i915_perf *perf = >engine->i915->perf;
+ u32 saved_offset = perf->ctx_oactxctrl_offset;
+ u32 offset;
+
+ /* Do this only once. Failure is stored as offset of U32_MAX */
+ if (saved_offset)
+ return 0;
+
+ offset = __context_image_offset(ce, i915_mmio_reg_offset(reg));
+ perf->ctx_oactxctrl_offset = offset;
+
+ drm_dbg(>engine->i915->drm,
+ "%s oa ctx control at 0x%08x dword offset\n",
+ ce->engine->name, offset);
+
+ return __valid_oactxctrl_offset(offset) ? 0 : -ENODEV;
+}
+
+static bool engine_supports_mi_query(struct intel_engine_cs *engine)
+{
+ return engine->class == RENDER_CLASS;
+}
+
/**
* oa_get_render_ctx_id - determine and hold ctx hw id
* @stream: An i915-perf stream opened for OA metrics
@@ -1382,6 +1443,17 @@ static int oa_get_render_ctx_id(struct i915_perf_stream
*stream)
if (IS_ERR(ce))
return PTR_ERR(ce);
+ if (engine_supports_mi_query(stream->engine)) {
+ ret = __set_oa_ctx_ctrl_offset(ce);
+ if (ret && !(stream->sample_flags & SAMPLE_OA_REPORT)) {
+ intel_context_unpin(ce);
+ drm_err(>perf->i915->drm,
+ "Enabling perf query failed for %s\n",
+ stream->engine->name);
+ return ret;
+ }
+ }
+
switch (GRAPHICS_VER(ce->engine->i915)) {
case 7: {
/*
@@ -2412,10 +2484,11 @@ static int gen12_configure_oar_context(struct
i915_perf_stream *stream,
int err;
struct intel_context *ce = stream->pinned_ctx;
u32 format = stream->oa_buffer.format;
+ u32 offset = stream->perf->ctx_oactxctrl_offset;
struct flex regs_context[] = {
{
GEN8_OACTXCONTROL,
- stream->perf->ctx_oactxctrl_offset + 1,
+ offset + 1,
active ? GEN8_OA_COUNTER_RESUME : 0,
},
};
@@ -2440,15 +2513,18 @@ static int gen12_configure_oar_context(struct
i915_perf_stream *stream,
},
};
- /* Modify the context image of pinned context with regs_context*/
-
Re: [Intel-gfx] [PATCH 02/19] drm/i915/perf: Add OA formats for DG2
On Tue, Sep 06, 2022 at 10:35:16PM +0300, Lionel Landwerlin wrote:
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
Add new OA formats for DG2. Some of the newer OA formats are not
multples of 64 bytes and are not powers of 2. For those formats, adjust
hw_tail accordingly when checking for new reports.
Signed-off-by: Umesh Nerlige Ramappa
Apart from the coding style issue :
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 63
include/uapi/drm/i915_drm.h | 6 +++
2 files changed, 46 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 735244a3aedd..c8331b549d31 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -306,7 +306,8 @@ static u32 i915_oa_max_sample_rate = 10;
/* XXX: beware if future OA HW adds new report formats that the current
* code assumes all reports have a power-of-two size and ~(size - 1) can
- * be used as a mask to align the OA tail pointer.
+ * be used as a mask to align the OA tail pointer. In some of the
+ * formats, R is used to denote reserved field.
*/
static const struct i915_oa_format oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A13]= { 0, 64 },
@@ -320,6 +321,10 @@ static const struct i915_oa_format
oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A12]= { 0, 64 },
[I915_OA_FORMAT_A12_B8_C8] = { 2, 128 },
[I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
+ [I915_OAR_FORMAT_A32u40_A4u32_B8_C8]= { 5, 256 },
+ [I915_OA_FORMAT_A24u40_A14u32_B8_C8]= { 5, 256 },
+ [I915_OAR_FORMAT_A36u64_B8_C8] = { 1, 384 },
+ [I915_OA_FORMAT_A38u64_R2u64_B8_C8] = { 1, 448 },
};
#define SAMPLE_OA_REPORT (1<<0)
@@ -467,6 +472,7 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
bool pollin;
u32 hw_tail;
u64 now;
+ u32 partial_report_size;
/* We have to consider the (unlikely) possibility that read() errors
* could result in an OA buffer reset which might reset the head and
@@ -476,10 +482,16 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
hw_tail = stream->perf->ops.oa_hw_tail_read(stream);
- /* The tail pointer increases in 64 byte increments,
-* not in report_size steps...
+ /* The tail pointer increases in 64 byte increments, whereas report
+* sizes need not be integral multiples or 64 or powers of 2.
+* Compute potentially partially landed report in the OA buffer
*/
- hw_tail &= ~(report_size - 1);
+ partial_report_size = OA_TAKEN(hw_tail, stream->oa_buffer.tail);
+ partial_report_size %= report_size;
+
+ /* Subtract partial amount off the tail */
+ hw_tail = gtt_offset + ((hw_tail - partial_report_size) &
+ (stream->oa_buffer.vma->size - 1));
now = ktime_get_mono_fast_ns();
@@ -601,6 +613,8 @@ static int append_oa_sample(struct i915_perf_stream *stream,
{
int report_size = stream->oa_buffer.format_size;
struct drm_i915_perf_record_header header;
+ int report_size_partial;
+ u8 *oa_buf_end;
header.type = DRM_I915_PERF_RECORD_SAMPLE;
header.pad = 0;
@@ -614,7 +628,19 @@ static int append_oa_sample(struct i915_perf_stream
*stream,
return -EFAULT;
buf += sizeof(header);
- if (copy_to_user(buf, report, report_size))
+ oa_buf_end = stream->oa_buffer.vaddr +
+stream->oa_buffer.vma->size;
+ report_size_partial = oa_buf_end - report;
+
+ if (report_size_partial < report_size) {
+ if(copy_to_user(buf, report, report_size_partial))
+ return -EFAULT;
+ buf += report_size_partial;
+
+ if(copy_to_user(buf, stream->oa_buffer.vaddr,
+ report_size - report_size_partial))
+ return -EFAULT;
I think the coding style requires you to use if () not if()
Will fix.
Just a suggestion : you could make this code deal with the partial bit
as the main bit of the function :
oa_buf_end = stream->oa_buffer.vaddr +
stream->oa_buffer.vma->size;
report_size_partial = oa_buf_end - report;
if (copy_to_user(buf, report, report_size_partial))
return -EFAULT;
buf += report_size_partial;
This ^ may not work because append_oa_sample is appending exactly one
report to the user buffer, whereas the above may append more than one.
Thanks,
Umesh
if (report_size_partial < report_size &&
copy_to_user(buf, stream->oa_buffer.vaddr,
report_size - report_size_partial))
return -EFAULT;
buf += report_size - report_size_partial;
+ } else if (copy_to_user(buf, report, report_size))
return -EFAULT;
(*offset)
Re: [Intel-gfx] [PATCH 02/19] drm/i915/perf: Add OA formats for DG2
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
Add new OA formats for DG2. Some of the newer OA formats are not
multples of 64 bytes and are not powers of 2. For those formats, adjust
hw_tail accordingly when checking for new reports.
Signed-off-by: Umesh Nerlige Ramappa
Apart from the coding style issue :
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 63
include/uapi/drm/i915_drm.h | 6 +++
2 files changed, 46 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 735244a3aedd..c8331b549d31 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -306,7 +306,8 @@ static u32 i915_oa_max_sample_rate = 10;
/* XXX: beware if future OA HW adds new report formats that the current
* code assumes all reports have a power-of-two size and ~(size - 1) can
- * be used as a mask to align the OA tail pointer.
+ * be used as a mask to align the OA tail pointer. In some of the
+ * formats, R is used to denote reserved field.
*/
static const struct i915_oa_format oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A13]= { 0, 64 },
@@ -320,6 +321,10 @@ static const struct i915_oa_format
oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A12]= { 0, 64 },
[I915_OA_FORMAT_A12_B8_C8] = { 2, 128 },
[I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
+ [I915_OAR_FORMAT_A32u40_A4u32_B8_C8]= { 5, 256 },
+ [I915_OA_FORMAT_A24u40_A14u32_B8_C8]= { 5, 256 },
+ [I915_OAR_FORMAT_A36u64_B8_C8] = { 1, 384 },
+ [I915_OA_FORMAT_A38u64_R2u64_B8_C8] = { 1, 448 },
};
#define SAMPLE_OA_REPORT (1<<0)
@@ -467,6 +472,7 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
bool pollin;
u32 hw_tail;
u64 now;
+ u32 partial_report_size;
/* We have to consider the (unlikely) possibility that read() errors
* could result in an OA buffer reset which might reset the head and
@@ -476,10 +482,16 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
hw_tail = stream->perf->ops.oa_hw_tail_read(stream);
- /* The tail pointer increases in 64 byte increments,
-* not in report_size steps...
+ /* The tail pointer increases in 64 byte increments, whereas report
+* sizes need not be integral multiples or 64 or powers of 2.
+* Compute potentially partially landed report in the OA buffer
*/
- hw_tail &= ~(report_size - 1);
+ partial_report_size = OA_TAKEN(hw_tail, stream->oa_buffer.tail);
+ partial_report_size %= report_size;
+
+ /* Subtract partial amount off the tail */
+ hw_tail = gtt_offset + ((hw_tail - partial_report_size) &
+ (stream->oa_buffer.vma->size - 1));
now = ktime_get_mono_fast_ns();
@@ -601,6 +613,8 @@ static int append_oa_sample(struct i915_perf_stream *stream,
{
int report_size = stream->oa_buffer.format_size;
struct drm_i915_perf_record_header header;
+ int report_size_partial;
+ u8 *oa_buf_end;
header.type = DRM_I915_PERF_RECORD_SAMPLE;
header.pad = 0;
@@ -614,7 +628,19 @@ static int append_oa_sample(struct i915_perf_stream
*stream,
return -EFAULT;
buf += sizeof(header);
- if (copy_to_user(buf, report, report_size))
+ oa_buf_end = stream->oa_buffer.vaddr +
+stream->oa_buffer.vma->size;
+ report_size_partial = oa_buf_end - report;
+
+ if (report_size_partial < report_size) {
+ if(copy_to_user(buf, report, report_size_partial))
+ return -EFAULT;
+ buf += report_size_partial;
+
+ if(copy_to_user(buf, stream->oa_buffer.vaddr,
+ report_size - report_size_partial))
+ return -EFAULT;
I think the coding style requires you to use if () not if()
Just a suggestion : you could make this code deal with the partial bit
as the main bit of the function :
oa_buf_end = stream->oa_buffer.vaddr +
stream->oa_buffer.vma->size;
report_size_partial = oa_buf_end - report;
if (copy_to_user(buf, report, report_size_partial))
return -EFAULT;
buf += report_size_partial;
if (report_size_partial < report_size &&
copy_to_user(buf, stream->oa_buffer.vaddr,
report_size - report_size_partial))
return -EFAULT;
buf += report_size - report_size_partial;
+ } else if (copy_to_user(buf, report, report_size))
return -EFAULT;
(*offset) += header.size;
@@ -684,8 +710,8 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* all a power of two).
*/
if (drm_WARN_ONCE(>i915->drm,
- head >
Re: [Intel-gfx] [PATCH v2 09/12] drm/i915/uncore: Add GSI offset to uncore
On Tue, Sep 06, 2022 at 04:14:21PM +0530, Iddamsetty, Aravind wrote:
>
>
> On 03-09-2022 05:02, Matt Roper wrote:
> > GT non-engine registers (referred to as "GSI" registers by the spec)
> > have the same relative offsets on standalone media as they do on the
> > primary GT, just with an additional "GSI offset" added to their MMIO
> > address. If we store this GSI offset in the standalone media's
> > intel_uncore structure, it can be automatically applied to all GSI reg
> > reads/writes that happen on that GT, allowing us to re-use our existing
> > GT code with minimal changes.
> >
> > Forcewake and shadowed register tables for the media GT (which will be
> > added in a future patch) are listed as final addresses that already
> > include the GSI offset, so we also need to add the GSI offset before
> > doing lookups of registers in one of those tables.
> >
> > Cc: Daniele Ceraolo Spurio
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt.c | 17 ++---
> > drivers/gpu/drm/i915/intel_device_info.h | 4 +++-
> > drivers/gpu/drm/i915/intel_uncore.c | 10 --
> > drivers/gpu/drm/i915/intel_uncore.h | 22 --
> > 4 files changed, 45 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > index fbb5e32979a4..a6ed11b933eb 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > @@ -776,10 +776,20 @@ void intel_gt_driver_late_release_all(struct
> > drm_i915_private *i915)
> > }
> > }
> >
> > -static int intel_gt_tile_setup(struct intel_gt *gt, phys_addr_t phys_addr)
> > +/*
> > + * Note: the gsi_offset parameter here isn't used, but we want to keep the
> > + * function signature equivalent to gtdef->setup() so that it can be
> > plugged
> > + * in when we enabled remote tiles in the future.
> > + */
> > +static int intel_gt_tile_setup(struct intel_gt *gt,
> > + phys_addr_t phys_addr,
> > + u32 gsi_offset)
> > {
> > int ret;
> >
> > + /* GSI offset is only applicable for media GTs */
> > + drm_WARN_ON(>i915->drm, gsi_offset);
> > +
> > if (!gt_is_root(gt)) {
> > struct intel_uncore *uncore;
> >
> > @@ -832,7 +842,7 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
> > gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
> >
> > drm_dbg(>drm, "Setting up %s\n", gt->name);
> > - ret = intel_gt_tile_setup(gt, phys_addr);
> > + ret = intel_gt_tile_setup(gt, phys_addr, 0);
> > if (ret)
> > return ret;
> >
> > @@ -865,7 +875,8 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
> > goto err;
> > }
> >
> > - ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);
> > + ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base,
> > + gtdef->gsi_offset);
> > if (ret)
> > goto err;
> >
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> > b/drivers/gpu/drm/i915/intel_device_info.h
> > index b408ce384cd7..85e0ef0e91b1 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > @@ -254,8 +254,10 @@ struct intel_gt_definition {
> > enum intel_gt_type type;
> > char *name;
> > int (*setup)(struct intel_gt *gt,
> > -phys_addr_t phys_addr);
> > +phys_addr_t phys_addr,
> > +u32 gsi_offset);
> > u32 mapping_base;
> > + u32 gsi_offset;
> > intel_engine_mask_t engine_mask;
> > };
> >
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index 33bdcbc77ab2..ecb02421502d 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -927,6 +927,9 @@ find_fw_domain(struct intel_uncore *uncore, u32 offset)
> > {
> > const struct intel_forcewake_range *entry;
> >
> > + if (IS_GSI_REG(offset))
> > + offset += uncore->gsi_offset;
> > +
> > entry = BSEARCH(offset,
> > uncore->fw_domains_table,
> > uncore->fw_domains_table_entries,
> > @@ -1142,6 +1145,9 @@ static bool is_shadowed(struct intel_uncore *uncore,
> > u32 offset)
> > if (drm_WARN_ON(>i915->drm, !uncore->shadowed_reg_table))
> > return false;
> >
> > + if (IS_GSI_REG(offset))
> > + offset += uncore->gsi_offset;
> > +
> > return BSEARCH(offset,
> >uncore->shadowed_reg_table,
> >uncore->shadowed_reg_table_entries,
> > @@ -1994,8 +2000,8 @@ static int __fw_domain_init(struct intel_uncore
> > *uncore,
> >
> > d->uncore = uncore;
> > d->wake_count = 0;
> > - d->reg_set = uncore->regs + i915_mmio_reg_offset(reg_set);
> > - d->reg_ack = uncore->regs +
Re: [Intel-gfx] [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On Fri, Aug 12, 2022 at 08:03:47AM +0200, Greg KH wrote: > On Thu, Aug 11, 2022 at 06:52:40PM +0200, Daniel Vetter wrote: > > On Wed, Aug 03, 2022 at 04:13:05PM -0400, Jason Baron wrote: > > > > > > > > > On 8/3/22 15:56, jim.cro...@gmail.com wrote: > > > > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie wrote: > > > >> > > > > > > > >> Hi Jason, Greg, DRM-folk, > > > >> > > > >> This adds 'typed' "class FOO" support to dynamic-debug, where 'typed' > > > >> means either DISJOINT (like drm debug categories), or VERBOSE (like > > > >> nouveau debug-levels). Use it in DRM modules: core, helpers, and in > > > >> drivers i915, amdgpu, nouveau. > > > >> > > > > > > > > This revision fell over, on a conflict with something in drm-MUMBLE > > > > > > > > Error: patch > > > > https://urldefense.com/v3/__https://patchwork.freedesktop.org/api/1.0/series/106427/revisions/2/mbox/__;!!GjvTz_vk!UCPl5Uf32cDVwwysMTfaLwoGLWomargFXuR8HjBA3xsUOjxXHXC5hneAkP4iWK91yc-LjjJxWW89-51Z$ > > > > > > > > not applied > > > > Applying: dyndbg: fix static_branch manipulation > > > > Applying: dyndbg: fix module.dyndbg handling > > > > Applying: dyndbg: show both old and new in change-info > > > > Applying: dyndbg: reverse module walk in cat control > > > > Applying: dyndbg: reverse module.callsite walk in cat control > > > > Applying: dyndbg: use ESCAPE_SPACE for cat control > > > > Applying: dyndbg: let query-modname override actual module name > > > > Applying: dyndbg: add test_dynamic_debug module > > > > Applying: dyndbg: drop EXPORTed dynamic_debug_exec_queries > > > > > > > > Jason, > > > > those above are decent maintenance patches, particularly the drop > > > > export. > > > > It would be nice to trim this unused api this cycle. > > > > > > Hi Jim, > > > > > > Agreed - I was thinking the same thing. Feel free to add > > > Acked-by: Jason Baron to those first 9. > > > > Does Greg KH usually pick up dyndbg patches or someone else or do I need > > to do something? Would be great to get some movement here since -rc1 goes > > out and merging will restart next week. > > Yes, I can take these into my tree after -rc1 is out. [uncovering from an absolutely impressive cascade of holes :-(] Did this happen and I can stop worrying here? I'd like to make sure these drm debug infra improvements keep moving. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Kick rcu harder to free objects
== Series Details ==
Series: drm/i915: Kick rcu harder to free objects
URL : https://patchwork.freedesktop.org/series/108196/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12080 -> Patchwork_108196v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/index.html
Participating hosts (40 -> 41)
--
Additional (1): fi-icl-u2
Known issues
Here are the changes found in Patchwork_108196v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-icl-u2: NOTRUN -> [SKIP][1] ([i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-bdw-5557u/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-blb-e6850: NOTRUN -> [SKIP][4] ([fdo#109271])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-blb-e6850/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][6] ([fdo#111827]) +8 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-icl-u2: NOTRUN -> [SKIP][7] ([i915#4103])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [PASS][8] -> [FAIL][9] ([i915#6298])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-icl-u2: NOTRUN -> [WARN][10] ([i915#6008])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][11] ([fdo#109285])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2: NOTRUN -> [SKIP][12] ([i915#3555])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][13] ([fdo#109295] / [i915#3301])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-icl-u2/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u: [INCOMPLETE][14] ([i915#146] / [i915#6598]) ->
[PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gem:
- fi-blb-e6850: [DMESG-FAIL][16] ([i915#4528]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/fi-blb-e6850/igt@i915_selftest@l...@gem.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-blb-e6850/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][18] ([i915#4528]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12080/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108196v1/fi-pnv-d510/igt@i915_selftest@l...@requests.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
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Kick rcu harder to free objects
== Series Details == Series: drm/i915: Kick rcu harder to free objects URL : https://patchwork.freedesktop.org/series/108196/ State : warning == Summary == Error: dim checkpatch failed 9c3f8d76c799 drm/i915: Kick rcu harder to free objects -:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #11: <4> [383.822546] WARNING: CPU: 2 PID: 3560 at drivers/gpu/drm/i915/i915_gem.c:1223 i915_gem_cleanup_early+0x96/0xb0 [i915] total: 0 errors, 1 warnings, 0 checks, 7 lines checked
Re: [Intel-gfx] [PATCH 01/19] drm/i915/perf: Fix OA filtering logic for GuC mode
On 06/09/2022 20:39, Umesh Nerlige Ramappa wrote:
On Tue, Sep 06, 2022 at 05:33:00PM +0300, Lionel Landwerlin wrote:
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
With GuC mode of submission, GuC is in control of defining the
context id field
that is part of the OA reports. To filter reports, UMD and KMD must
know what sw
context id was chosen by GuC. There is not interface between KMD and
GuC to
determine this, so read the upper-dword of EXECLIST_STATUS to
filter/squash OA
reports for the specific context.
Signed-off-by: Umesh Nerlige Ramappa
I assume you checked with GuC that this doesn't change as the context
is running?
Correct.
With i915/execlist submission mode, we had to ask i915 to pin the
sw_id/ctx_id.
From GuC perspective, the context id can change once KMD de-registers
the context and that will not happen while the context is in use.
Thanks,
Umesh
Thanks Umesh,
Maybe I should have been more precise in my question :
Can the ID change while the i915-perf stream is opened?
Because the ID not changing while the context is running makes sense.
But since the number of available IDs is limited to 2k or something on
Gfx12, it's possible the GuC has to reuse IDs if too many apps want to
run during the period of time while i915-perf is active and filtering.
-Lionel
If that's not the case then filtering is broken.
-Lionel
---
drivers/gpu/drm/i915/gt/intel_lrc.h | 2 +
drivers/gpu/drm/i915/i915_perf.c | 141
2 files changed, 124 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.h
b/drivers/gpu/drm/i915/gt/intel_lrc.h
index a390f0813c8b..7111bae759f3 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.h
@@ -110,6 +110,8 @@ enum {
#define XEHP_SW_CTX_ID_WIDTH 16
#define XEHP_SW_COUNTER_SHIFT 58
#define XEHP_SW_COUNTER_WIDTH 6
+#define GEN12_GUC_SW_CTX_ID_SHIFT 39
+#define GEN12_GUC_SW_CTX_ID_WIDTH 16
static inline void lrc_runtime_start(struct intel_context *ce)
{
diff --git a/drivers/gpu/drm/i915/i915_perf.c
b/drivers/gpu/drm/i915/i915_perf.c
index f3c23fe9ad9c..735244a3aedd 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1233,6 +1233,125 @@ static struct intel_context
*oa_pin_context(struct i915_perf_stream *stream)
return stream->pinned_ctx;
}
+static int
+__store_reg_to_mem(struct i915_request *rq, i915_reg_t reg, u32
ggtt_offset)
+{
+ u32 *cs, cmd;
+
+ cmd = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
+ if (GRAPHICS_VER(rq->engine->i915) >= 8)
+ cmd++;
+
+ cs = intel_ring_begin(rq, 4);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ *cs++ = cmd;
+ *cs++ = i915_mmio_reg_offset(reg);
+ *cs++ = ggtt_offset;
+ *cs++ = 0;
+
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
+static int
+__read_reg(struct intel_context *ce, i915_reg_t reg, u32 ggtt_offset)
+{
+ struct i915_request *rq;
+ int err;
+
+ rq = i915_request_create(ce);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ i915_request_get(rq);
+
+ err = __store_reg_to_mem(rq, reg, ggtt_offset);
+
+ i915_request_add(rq);
+ if (!err && i915_request_wait(rq, 0, HZ / 2) < 0)
+ err = -ETIME;
+
+ i915_request_put(rq);
+
+ return err;
+}
+
+static int
+gen12_guc_sw_ctx_id(struct intel_context *ce, u32 *ctx_id)
+{
+ struct i915_vma *scratch;
+ u32 *val;
+ int err;
+
+ scratch =
__vm_create_scratch_for_read_pinned(>engine->gt->ggtt->vm, 4);
+ if (IS_ERR(scratch))
+ return PTR_ERR(scratch);
+
+ err = i915_vma_sync(scratch);
+ if (err)
+ goto err_scratch;
+
+ err = __read_reg(ce,
RING_EXECLIST_STATUS_HI(ce->engine->mmio_base),
+ i915_ggtt_offset(scratch));
+ if (err)
+ goto err_scratch;
+
+ val = i915_gem_object_pin_map_unlocked(scratch->obj, I915_MAP_WB);
+ if (IS_ERR(val)) {
+ err = PTR_ERR(val);
+ goto err_scratch;
+ }
+
+ *ctx_id = *val;
+ i915_gem_object_unpin_map(scratch->obj);
+
+err_scratch:
+ i915_vma_unpin_and_release(, 0);
+ return err;
+}
+
+/*
+ * For execlist mode of submission, pick an unused context id
+ * 0 - (NUM_CONTEXT_TAG -1) are used by other contexts
+ * XXX_MAX_CONTEXT_HW_ID is used by idle context
+ *
+ * For GuC mode of submission read context id from the upper dword
of the
+ * EXECLIST_STATUS register.
+ */
+static int gen12_get_render_context_id(struct i915_perf_stream
*stream)
+{
+ u32 ctx_id, mask;
+ int ret;
+
+ if (intel_engine_uses_guc(stream->engine)) {
+ ret = gen12_guc_sw_ctx_id(stream->pinned_ctx, _id);
+ if (ret)
+ return ret;
+
+ mask = ((1U << GEN12_GUC_SW_CTX_ID_WIDTH) - 1) <<
+ (GEN12_GUC_SW_CTX_ID_SHIFT - 32);
+ } else if (GRAPHICS_VER_FULL(stream->engine->i915) >=
IP_VER(12, 50)) {
+ ctx_id = (XEHP_MAX_CONTEXT_HW_ID
Re: [Intel-gfx] [RFC PATCH 2/2] Fix per client busyness locking
On Thu, Sep 01, 2022 at 04:55:22PM -0700, Dixit, Ashutosh wrote:
On Wed, 31 Aug 2022 15:45:49 -0700, Umesh Nerlige Ramappa wrote:
Hi Umesh,
I have updated my RFC patch based on your feedback so we can discuss again.
On Wed, Aug 31, 2022 at 12:33:55PM -0700, Ashutosh Dixit wrote:
> 1. Do all ce->stats updates and reads under guc->timestamp.lock
Other than the question about READ_ONCE/WRITE_ONCE, I am not sure I
understand what's broken in the locking logic here. Can you please add some
description? thanks
Basically ce->stats.runtime.total and ce->stats.active are tied together so
should be accessed/updated atomically. Also just the update of
ce->stats.runtime.total (via lrc_update_runtime()) can have multiple
concurrent writers so even that has to be protected (since that update is
not atomic).
These was the reason for:
* Introducing lrc_update_runtime_locked
* Returning early from intel_context_get_total_runtime_ns otherwise we'll
need to introduce the same locking there
* Enforcing locking in guc_context_update_stats (which was there in your
original patch too)
(I think execlists code didn't have this issue because there
lrc_update_runtime is called from a tasklet (which iirc is like a single
thread/cpu). I am not sure how 'active' is updated in execlist mode so
there may or may not be a problem in intel_context_get_total_runtime_ns).
I have another question: what about that GPU vs. GuC race mentioned in the
comment? What is the sequence of events there between GPU updating the
timestamp in the context image vs. GuC setting engine_id to -1 (at least
what is the sequence in which GPU and GuC supposed to do these updates
though it may not matter to i915 due to scheduling delays)?
With GPU, KMD and GuC running concurrently, after a context is done,
this is the sequence.
GPU) updates context image (total_runtime)
KMD) reads total_runtime.
KMD) sees engine_id is valid. KMD uses start_time from pphwsp to
calculate active_time.
KMD) returns total_runtime + active_time (double accounted busyness!!)
GuC) gets ctxt switchout event and sets engine_id and start_time to ~0
This is not rare when running the IGT tests, so the total runtime is
updated in the query only if engine_id is idle. continued below ...
> 2. Pin context image before reading
> 3. Merge __guc_context_update_clks and guc_context_update_stats into a
> single function
> 4. Call lrc_update_runtime() unconditionally in guc_context_update_stats
> 5. Seems no need to update ce->stats.active with this approach
>
> Some of the above steps may not be correct or complete but the idea is to
> discuss/improve the original patch.
>
> Cc: Umesh Nerlige Ramappa
> Signed-off-by: Ashutosh Dixit
> ---
> drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +-
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 41 ++-
> 3 files changed, 24 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
> index e2d70a9fdac0..c004f676de27 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -581,7 +581,7 @@ u64 intel_context_get_total_runtime_ns(struct
intel_context *ce)
>u64 total, active;
>
>if (ce->ops->update_stats)
> - ce->ops->update_stats(ce);
> + return ce->ops->update_stats(ce);
This is an improvement that we can add and eventually, we can make this a
GuC specific vfunc. Doing so may also remove the COPS_RUNTIME_ACTIVE_TOTAL
option that I added to GuC specific context ops.
I went ahead and did this in v2 of the RFC patch.
>
>total = ce->stats.runtime.total;
>if (ce->ops->flags & COPS_RUNTIME_CYCLES)
> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
> index f7ff4c7d81c7..699435bfff99 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> @@ -59,7 +59,7 @@ struct intel_context_ops {
>
>void (*sched_disable)(struct intel_context *ce);
>
> - void (*update_stats)(struct intel_context *ce);
> + u64 (*update_stats)(struct intel_context *ce);
>
>void (*reset)(struct intel_context *ce);
>void (*destroy)(struct kref *kref);
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index bee8cf10f749..40d0edaf2e0a 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -1376,7 +1376,6 @@ static void __update_guc_busyness_stats(struct
intel_guc *guc)
>spin_unlock_irqrestore(>timestamp.lock, flags);
> }
>
> -static void __guc_context_update_clks(struct intel_context *ce);
> static void guc_timestamp_ping(struct work_struct *wrk)
> {
>struct intel_guc *guc = container_of(wrk, typeof(*guc),
> @@ -1401,7 +1400,8 @@ static void
[Intel-gfx] ✓ Fi.CI.IGT: success for Fixes for damage clips handling (rev3)
== Series Details ==
Series: Fixes for damage clips handling (rev3)
URL : https://patchwork.freedesktop.org/series/106388/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12066_full -> Patchwork_106388v3_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (11 -> 13)
--
Additional (2): shard-rkl shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106388v3_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_pipe_crc_basic@hang-read-crc@pipe-a-hdmi-a-1:
- {shard-dg1}:NOTRUN -> [SKIP][1] +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106388v3/shard-dg1-13/igt@kms_pipe_crc_basic@hang-read-...@pipe-a-hdmi-a-1.html
New tests
-
New tests have been introduced between CI_DRM_12066_full and
Patchwork_106388v3_full:
### New IGT tests (16) ###
* igt@kms_cursor_crc@cursor-offscreen-128x42@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [2.50] s
* igt@kms_cursor_crc@cursor-offscreen-128x42@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [2.40] s
* igt@kms_cursor_crc@cursor-offscreen-128x42@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [2.39] s
* igt@kms_cursor_crc@cursor-offscreen-128x42@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [2.39] s
* igt@kms_cursor_crc@cursor-random-128x128@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [5.95] s
* igt@kms_cursor_crc@cursor-random-128x128@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [5.79] s
* igt@kms_cursor_crc@cursor-random-128x128@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [5.68] s
* igt@kms_cursor_crc@cursor-random-128x128@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [5.80] s
* igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.38] s
* igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s
* igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.23] s
* igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.24] s
* igt@kms_flip@basic-flip-vs-dpms@a-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.73] s
* igt@kms_flip@basic-flip-vs-dpms@b-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.64] s
* igt@kms_flip@basic-flip-vs-dpms@c-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.69] s
* igt@kms_flip@basic-flip-vs-dpms@d-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.67] s
Known issues
Here are the changes found in Patchwork_106388v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][2] -> [SKIP][3] ([i915#658])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12066/shard-iclb2/igt@feature_discov...@psr2.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106388v3/shard-iclb3/igt@feature_discov...@psr2.html
* igt@gem_eio@kms:
- shard-tglb: [PASS][4] -> [FAIL][5] ([i915#5784])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12066/shard-tglb6/igt@gem_...@kms.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106388v3/shard-tglb3/igt@gem_...@kms.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#3070])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12066/shard-iclb1/igt@gem_...@unwedge-stress.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106388v3/shard-iclb3/igt@gem_...@unwedge-stress.html
* igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12066/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106388v3/shard-iclb7/igt@gem_exec_balan...@parallel-balancer.html
* igt@gem_userptr_blits@input-checking:
- shard-apl: NOTRUN -> [DMESG-WARN][10] ([i915#4991])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106388v3/shard-apl8/igt@gem_userptr_bl...@input-checking.html
* igt@gem_workarounds@suspend-resume-context:
- shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +2
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12066/shard-apl2/igt@gem_workarou...@suspend-resume-context.html
[12]:
[Intel-gfx] [PATCH] drm/i915: Kick rcu harder to free objects
From: Ville Syrjälä On gen3 the selftests are pretty much always tripping this: <4> [383.822424] pci :00:02.0: drm_WARN_ON(dev_priv->mm.shrink_count) <4> [383.822546] WARNING: CPU: 2 PID: 3560 at drivers/gpu/drm/i915/i915_gem.c:1223 i915_gem_cleanup_early+0x96/0xb0 [i915] Looks to be due to the status page object lingering on the purge_list. Call synchronize_rcu() ahead of it to make more sure all objects have been freed. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_gem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 0f49ec9d494a..5b61f7ad6473 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1098,6 +1098,7 @@ void i915_gem_drain_freed_objects(struct drm_i915_private *i915) flush_delayed_work(>bdev.wq); rcu_barrier(); } + synchronize_rcu(); } /* -- 2.35.1
Re: [Intel-gfx] [PATCH 01/19] drm/i915/perf: Fix OA filtering logic for GuC mode
On Tue, Sep 06, 2022 at 05:33:00PM +0300, Lionel Landwerlin wrote:
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
With GuC mode of submission, GuC is in control of defining the context id field
that is part of the OA reports. To filter reports, UMD and KMD must know what sw
context id was chosen by GuC. There is not interface between KMD and GuC to
determine this, so read the upper-dword of EXECLIST_STATUS to filter/squash OA
reports for the specific context.
Signed-off-by: Umesh Nerlige Ramappa
I assume you checked with GuC that this doesn't change as the context
is running?
Correct.
With i915/execlist submission mode, we had to ask i915 to pin the
sw_id/ctx_id.
From GuC perspective, the context id can change once KMD de-registers
the context and that will not happen while the context is in use.
Thanks,
Umesh
If that's not the case then filtering is broken.
-Lionel
---
drivers/gpu/drm/i915/gt/intel_lrc.h | 2 +
drivers/gpu/drm/i915/i915_perf.c| 141
2 files changed, 124 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.h
b/drivers/gpu/drm/i915/gt/intel_lrc.h
index a390f0813c8b..7111bae759f3 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.h
@@ -110,6 +110,8 @@ enum {
#define XEHP_SW_CTX_ID_WIDTH 16
#define XEHP_SW_COUNTER_SHIFT 58
#define XEHP_SW_COUNTER_WIDTH 6
+#define GEN12_GUC_SW_CTX_ID_SHIFT 39
+#define GEN12_GUC_SW_CTX_ID_WIDTH 16
static inline void lrc_runtime_start(struct intel_context *ce)
{
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index f3c23fe9ad9c..735244a3aedd 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1233,6 +1233,125 @@ static struct intel_context *oa_pin_context(struct
i915_perf_stream *stream)
return stream->pinned_ctx;
}
+static int
+__store_reg_to_mem(struct i915_request *rq, i915_reg_t reg, u32 ggtt_offset)
+{
+ u32 *cs, cmd;
+
+ cmd = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
+ if (GRAPHICS_VER(rq->engine->i915) >= 8)
+ cmd++;
+
+ cs = intel_ring_begin(rq, 4);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ *cs++ = cmd;
+ *cs++ = i915_mmio_reg_offset(reg);
+ *cs++ = ggtt_offset;
+ *cs++ = 0;
+
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
+static int
+__read_reg(struct intel_context *ce, i915_reg_t reg, u32 ggtt_offset)
+{
+ struct i915_request *rq;
+ int err;
+
+ rq = i915_request_create(ce);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ i915_request_get(rq);
+
+ err = __store_reg_to_mem(rq, reg, ggtt_offset);
+
+ i915_request_add(rq);
+ if (!err && i915_request_wait(rq, 0, HZ / 2) < 0)
+ err = -ETIME;
+
+ i915_request_put(rq);
+
+ return err;
+}
+
+static int
+gen12_guc_sw_ctx_id(struct intel_context *ce, u32 *ctx_id)
+{
+ struct i915_vma *scratch;
+ u32 *val;
+ int err;
+
+ scratch =
__vm_create_scratch_for_read_pinned(>engine->gt->ggtt->vm, 4);
+ if (IS_ERR(scratch))
+ return PTR_ERR(scratch);
+
+ err = i915_vma_sync(scratch);
+ if (err)
+ goto err_scratch;
+
+ err = __read_reg(ce, RING_EXECLIST_STATUS_HI(ce->engine->mmio_base),
+i915_ggtt_offset(scratch));
+ if (err)
+ goto err_scratch;
+
+ val = i915_gem_object_pin_map_unlocked(scratch->obj, I915_MAP_WB);
+ if (IS_ERR(val)) {
+ err = PTR_ERR(val);
+ goto err_scratch;
+ }
+
+ *ctx_id = *val;
+ i915_gem_object_unpin_map(scratch->obj);
+
+err_scratch:
+ i915_vma_unpin_and_release(, 0);
+ return err;
+}
+
+/*
+ * For execlist mode of submission, pick an unused context id
+ * 0 - (NUM_CONTEXT_TAG -1) are used by other contexts
+ * XXX_MAX_CONTEXT_HW_ID is used by idle context
+ *
+ * For GuC mode of submission read context id from the upper dword of the
+ * EXECLIST_STATUS register.
+ */
+static int gen12_get_render_context_id(struct i915_perf_stream *stream)
+{
+ u32 ctx_id, mask;
+ int ret;
+
+ if (intel_engine_uses_guc(stream->engine)) {
+ ret = gen12_guc_sw_ctx_id(stream->pinned_ctx, _id);
+ if (ret)
+ return ret;
+
+ mask = ((1U << GEN12_GUC_SW_CTX_ID_WIDTH) - 1) <<
+ (GEN12_GUC_SW_CTX_ID_SHIFT - 32);
+ } else if (GRAPHICS_VER_FULL(stream->engine->i915) >= IP_VER(12, 50)) {
+ ctx_id = (XEHP_MAX_CONTEXT_HW_ID - 1) <<
+ (XEHP_SW_CTX_ID_SHIFT - 32);
+
+ mask = ((1U << XEHP_SW_CTX_ID_WIDTH) - 1) <<
+ (XEHP_SW_CTX_ID_SHIFT - 32);
+ } else {
+ ctx_id =
Re: [Intel-gfx] [PATCH 1/4] drm: Add missing DP DSC extended capability definitions.
On Tue, 06 Sep 2022, "Lisovskiy, Stanislav" wrote: > On Tue, Sep 06, 2022 at 06:43:22PM +0300, Jani Nikula wrote: >> On Tue, 06 Sep 2022, Jani Nikula wrote: >> > On Mon, 05 Sep 2022, Stanislav Lisovskiy >> > wrote: >> >> Adding DP DSC register definitions, we might need for further >> >> DSC implementation, supporting MST and DP branch pass-through mode. >> >> >> >> v2: - Fixed checkpatch comment warning >> >> v3: - Removed function which is not yet used(Jani Nikula) >> >> >> >> Reviewed-by: Vinod Govindapillai >> >> >> >> Signed-off-by: Stanislav Lisovskiy >> > >> > Maarten, Maxime, Thomas - >> > >> > So this got pushed to drm-intel-next without your acks. Apologies. Can >> > we live with it, or want a revert? >> >> I've reverted anyway for other reasons. But can we have an ack for the >> future? :) >> >> BR, >> Jani. > > I've resolved the conflict properly now(not the best way of learning about > drm-rerere) but I guess its too late now. Sorry for the hassle. Yeah, I'm sorry too. The conflict looked too involved for us to figure out right now, with the diverged baselines between drm-misc-next and drm-intel-next, so Rodrigo and I decided to go for the revert. We needed to get drm-tip building again. And really, the patches as applied on top of current drm-intel-next weren't tested, because they were changed on the fly. > But what am I supposed to do now? Should proceed with merge again or > wait for some acks? > Patches basically would be the same anyway. The patches will be the same, but we'll need to get the baseline resolved first. drm-misc-next and drm-intel-next have diverged on intel_dp_mst.c, due to Lyude's DP MST changes, and we'll need to get them in sync in drm-intel-next before applying the patches. It'll be the easiest for everyone. In practice this means a drm-misc-next pull request to drm-next, and then a backmerge from drm-next to drm-intel-next. There was a drm-misc-next pull request merged today, but only up to tag drm-misc-next-2022-08-20-1, and there's 88 commits in drm-misc-next since. Including Lyude's changes. BR, Jani. > > Stan > >> >> > >> > >> > BR, >> > Jani. >> > >> > >> >> --- >> >> include/drm/display/drm_dp.h | 10 +- >> >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h >> >> index 6c0871164771..02c4b6f20478 100644 >> >> --- a/include/drm/display/drm_dp.h >> >> +++ b/include/drm/display/drm_dp.h >> >> @@ -239,6 +239,9 @@ >> >> >> >> #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ >> >> # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) >> >> +# define DP_DSC_PASS_THROUGH_IS_SUPPORTED (1 << 1) >> >> +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_COMP_TO_COMP(1 << 2) >> >> +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_UNCOMP_TO_COMP (1 << 3) >> >> >> >> #define DP_DSC_REV 0x061 >> >> # define DP_DSC_MAJOR_MASK (0xf << 0) >> >> @@ -277,12 +280,15 @@ >> >> >> >> #define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 >> >> # define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) >> >> +# define DP_DSC_RGB_COLOR_CONV_BYPASS_SUPPORT (1 << 1) >> >> >> >> #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ >> >> >> >> #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ >> >> # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) >> >> # define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 >> >> +# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK 0x06 >> >> +# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY 0x08 >> >> >> >> #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 >> >> # define DP_DSC_RGB (1 << 0) >> >> @@ -344,11 +350,13 @@ >> >> # define DP_DSC_24_PER_DP_DSC_SINK (1 << 2) >> >> >> >> #define DP_DSC_BITS_PER_PIXEL_INC 0x06F >> >> +# define DP_DSC_RGB_YCbCr444_MAX_BPP_DELTA_MASK 0x1f >> >> +# define DP_DSC_RGB_YCbCr420_MAX_BPP_DELTA_MASK 0xe0 >> >> # define DP_DSC_BITS_PER_PIXEL_1_16 0x0 >> >> # define DP_DSC_BITS_PER_PIXEL_1_8 0x1 >> >> # define DP_DSC_BITS_PER_PIXEL_1_4 0x2 >> >> # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 >> >> -# define DP_DSC_BITS_PER_PIXEL_10x4 >> >> +# define DP_DSC_BITS_PER_PIXEL_1_1 0x4 >> >> >> >> #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ >> >> # define DP_PSR_IS_SUPPORTED1 >> >> -- >> Jani Nikula, Intel Open Source Graphics Center -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 2/2] drm/i915/pps: Enabled 2nd pps for dual EDP scenario
On Tue, 06 Sep 2022, Animesh Manna wrote:
> From display gen12 onwards to support dual EDP two instances of pps added.
> Currently backlight controller and pps instance can be mapped together
> for a specific panel. Extended support for gen12 for dual EDP usage.
>
> TODO: For dual EDP scenario and panel type invalid (=255), special condition
> check to be added to reject or initialize the panel specific stuff earlier.
>
> Signed-off-by: Animesh Manna
So this is no worse than it already is for GLK and BXT... but they're
actually already broken. :(
As I tried to explain before, since commit 3cf050762534 ("drm/i915/bios:
Split VBT data into per-panel vs. global parts") the VBT
connector->panel.vbt.backlight.controller member gets initialized via
intel_bios_init_panel(). But intel_pps_init() uses that *before*
intel_bios_init_panel() gets called.
Mind you, I don't think the dual backlight controller thing worked
before that either, but the controller field was more likely to be
correct for the first panel. Now, it's only correct by coincidence, as
it's uninitialized.
So it's not only about PNPID panel identification (panel type 255). But
that's related, since we can't move the PNPID identification earlier,
because that needs EDID, and EDID needs panel power, and panel power
needs the PPS index. Which needs PNPID panel identification.
We'll need to do something like:
- intel_bios_panel_init w/o PNPID
- intel_pps_init
- EDID read
- intel_bios_panel_init w/ PNPID
I don't know how exactly this is supposed to work, but I'm also kind of
not tasked to figure it out either right now. ;)
HTH,
Jani.
> ---
> drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index 4e770218e29f..a9ed1214a167 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -1427,7 +1427,7 @@ void intel_pps_init(struct intel_dp *intel_dp)
> intel_dp->pps.initializing = true;
> INIT_DELAYED_WORK(_dp->pps.panel_vdd_work, edp_panel_vdd_work);
>
> - if (IS_GEMINILAKE(i915) || IS_BROXTON(i915))
> + if (IS_GEMINILAKE(i915) || IS_BROXTON(i915) || DISPLAY_VER(i915) >= 12)
> intel_dp->get_pps_idx = bxt_power_sequencer_idx;
> else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> intel_dp->get_pps_idx = vlv_power_sequencer_pipe;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
>-Original Message-
>From: Roper, Matthew D
>Sent: Tuesday, September 6, 2022 1:09 PM
>To: Ruhl, Michael J
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Sripada,
>Radhakrishna
>Subject: Re: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check
>into mmio_debug_{suspend, resume}
>
>On Tue, Sep 06, 2022 at 06:39:14AM -0700, Ruhl, Michael J wrote:
>> >-Original Message-
>> >From: dri-devel On Behalf Of
>> >Matt Roper
>> >Sent: Friday, September 2, 2022 7:33 PM
>> >To: intel-gfx@lists.freedesktop.org
>> >Cc: dri-de...@lists.freedesktop.org; Sripada, Radhakrishna
>> >
>> >Subject: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check
>into
>> >mmio_debug_{suspend, resume}
>> >
>> >Moving the locking for MMIO debug (and the final check for unclaimed
>> >accesses when resuming debug after a userspace-initiated forcewake) will
>> >make it simpler to completely skip MMIO debug handling on uncores that
>> >don't support it in future patches.
>> >
>> >Signed-off-by: Matt Roper
>> >Reviewed-by: Radhakrishna Sripada
>> >---
>> > drivers/gpu/drm/i915/intel_uncore.c | 41 +++--
>> > 1 file changed, 21 insertions(+), 20 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/intel_uncore.c
>> >b/drivers/gpu/drm/i915/intel_uncore.c
>> >index 9b81b2543ce2..e717ea55484a 100644
>> >--- a/drivers/gpu/drm/i915/intel_uncore.c
>> >+++ b/drivers/gpu/drm/i915/intel_uncore.c
>> >@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
>> >intel_uncore_mmio_debug *mmio_debug)
>> >mmio_debug->unclaimed_mmio_check = 1;
>> > }
>> >
>> >-static void mmio_debug_suspend(struct intel_uncore_mmio_debug
>> >*mmio_debug)
>> >+static void mmio_debug_suspend(struct intel_uncore *uncore)
>>
>> /bike-shedding...
>>
>> It seems like there has been a tend to name functions with the
>>
>> _unlocked
>>
>> postfix when the lock is being taken within the function.
>>
>> Would this be a reasonable name update for these changes?
>
>I think foo_unlocked() naming is usually used when there's also a
>separate foo() that can be called if/when locks are already held (or
>sometimes it's foo() and foo_locked() if the situation is the other way
>around). In this case we still only have one version of the function,
>and it's only called from a single place in the code
>(intel_uncore_forcewake_user_get) so I don't think the special naming is
>necessary. It might actually add confusion here since there's a
>different lock (the general uncore lock) that is still held by the
>caller. It's just the mmio_debug-specific lock that's been moved into
>the mmio-debug specific function here.
Got it. That makes sense.
Thanks,
Mike
>
>Matt
>
>>
>> M
>>
>> > {
>> >- lockdep_assert_held(_debug->lock);
>> >+ spin_lock(>debug->lock);
>> >
>> >/* Save and disable mmio debugging for the user bypass */
>> >- if (!mmio_debug->suspend_count++) {
>> >- mmio_debug->saved_mmio_check = mmio_debug-
>> >>unclaimed_mmio_check;
>> >- mmio_debug->unclaimed_mmio_check = 0;
>> >+ if (!uncore->debug->suspend_count++) {
>> >+ uncore->debug->saved_mmio_check = uncore->debug-
>> >>unclaimed_mmio_check;
>> >+ uncore->debug->unclaimed_mmio_check = 0;
>> >}
>> >+
>> >+ spin_unlock(>debug->lock);
>> > }
>> >
>> >-static void mmio_debug_resume(struct intel_uncore_mmio_debug
>> >*mmio_debug)
>> >+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
>> >+
>> >+static void mmio_debug_resume(struct intel_uncore *uncore)
>> > {
>> >- lockdep_assert_held(_debug->lock);
>> >+ spin_lock(>debug->lock);
>> >+
>> >+ if (!--uncore->debug->suspend_count)
>> >+ uncore->debug->unclaimed_mmio_check = uncore->debug-
>> >>saved_mmio_check;
>> >
>> >- if (!--mmio_debug->suspend_count)
>> >- mmio_debug->unclaimed_mmio_check = mmio_debug-
>> >>saved_mmio_check;
>> >+ if (check_for_unclaimed_mmio(uncore))
>> >+ drm_info(>i915->drm,
>> >+"Invalid mmio detected during user access\n");
>> >+
>> >+ spin_unlock(>debug->lock);
>> > }
>> >
>> > static const char * const forcewake_domain_names[] = {
>> >@@ -677,9 +687,7 @@ void intel_uncore_forcewake_user_get(struct
>> >intel_uncore *uncore)
>> >spin_lock_irq(>lock);
>> >if (!uncore->user_forcewake_count++) {
>> >intel_uncore_forcewake_get__locked(uncore,
>> >FORCEWAKE_ALL);
>> >- spin_lock(>debug->lock);
>> >- mmio_debug_suspend(uncore->debug);
>> >- spin_unlock(>debug->lock);
>> >+ mmio_debug_suspend(uncore);
>> >}
>> >spin_unlock_irq(>lock);
>> > }
>> >@@ -695,14 +703,7 @@ void intel_uncore_forcewake_user_put(struct
>> >intel_uncore *uncore)
>> > {
>> >spin_lock_irq(>lock);
>> >if (!--uncore->user_forcewake_count) {
>> >- spin_lock(>debug->lock);
>> >- mmio_debug_resume(uncore->debug);
>> >-
>> >- if (check_for_unclaimed_mmio(uncore))
>> >-
Re: [Intel-gfx] [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
On Tue, Sep 06, 2022 at 06:39:14AM -0700, Ruhl, Michael J wrote:
> >-Original Message-
> >From: dri-devel On Behalf Of
> >Matt Roper
> >Sent: Friday, September 2, 2022 7:33 PM
> >To: intel-gfx@lists.freedesktop.org
> >Cc: dri-de...@lists.freedesktop.org; Sripada, Radhakrishna
> >
> >Subject: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into
> >mmio_debug_{suspend, resume}
> >
> >Moving the locking for MMIO debug (and the final check for unclaimed
> >accesses when resuming debug after a userspace-initiated forcewake) will
> >make it simpler to completely skip MMIO debug handling on uncores that
> >don't support it in future patches.
> >
> >Signed-off-by: Matt Roper
> >Reviewed-by: Radhakrishna Sripada
> >---
> > drivers/gpu/drm/i915/intel_uncore.c | 41 +++--
> > 1 file changed, 21 insertions(+), 20 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> >b/drivers/gpu/drm/i915/intel_uncore.c
> >index 9b81b2543ce2..e717ea55484a 100644
> >--- a/drivers/gpu/drm/i915/intel_uncore.c
> >+++ b/drivers/gpu/drm/i915/intel_uncore.c
> >@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
> >intel_uncore_mmio_debug *mmio_debug)
> > mmio_debug->unclaimed_mmio_check = 1;
> > }
> >
> >-static void mmio_debug_suspend(struct intel_uncore_mmio_debug
> >*mmio_debug)
> >+static void mmio_debug_suspend(struct intel_uncore *uncore)
>
> /bike-shedding...
>
> It seems like there has been a tend to name functions with the
>
> _unlocked
>
> postfix when the lock is being taken within the function.
>
> Would this be a reasonable name update for these changes?
I think foo_unlocked() naming is usually used when there's also a
separate foo() that can be called if/when locks are already held (or
sometimes it's foo() and foo_locked() if the situation is the other way
around). In this case we still only have one version of the function,
and it's only called from a single place in the code
(intel_uncore_forcewake_user_get) so I don't think the special naming is
necessary. It might actually add confusion here since there's a
different lock (the general uncore lock) that is still held by the
caller. It's just the mmio_debug-specific lock that's been moved into
the mmio-debug specific function here.
Matt
>
> M
>
> > {
> >-lockdep_assert_held(_debug->lock);
> >+spin_lock(>debug->lock);
> >
> > /* Save and disable mmio debugging for the user bypass */
> >-if (!mmio_debug->suspend_count++) {
> >-mmio_debug->saved_mmio_check = mmio_debug-
> >>unclaimed_mmio_check;
> >-mmio_debug->unclaimed_mmio_check = 0;
> >+if (!uncore->debug->suspend_count++) {
> >+uncore->debug->saved_mmio_check = uncore->debug-
> >>unclaimed_mmio_check;
> >+uncore->debug->unclaimed_mmio_check = 0;
> > }
> >+
> >+spin_unlock(>debug->lock);
> > }
> >
> >-static void mmio_debug_resume(struct intel_uncore_mmio_debug
> >*mmio_debug)
> >+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
> >+
> >+static void mmio_debug_resume(struct intel_uncore *uncore)
> > {
> >-lockdep_assert_held(_debug->lock);
> >+spin_lock(>debug->lock);
> >+
> >+if (!--uncore->debug->suspend_count)
> >+uncore->debug->unclaimed_mmio_check = uncore->debug-
> >>saved_mmio_check;
> >
> >-if (!--mmio_debug->suspend_count)
> >-mmio_debug->unclaimed_mmio_check = mmio_debug-
> >>saved_mmio_check;
> >+if (check_for_unclaimed_mmio(uncore))
> >+drm_info(>i915->drm,
> >+ "Invalid mmio detected during user access\n");
> >+
> >+spin_unlock(>debug->lock);
> > }
> >
> > static const char * const forcewake_domain_names[] = {
> >@@ -677,9 +687,7 @@ void intel_uncore_forcewake_user_get(struct
> >intel_uncore *uncore)
> > spin_lock_irq(>lock);
> > if (!uncore->user_forcewake_count++) {
> > intel_uncore_forcewake_get__locked(uncore,
> >FORCEWAKE_ALL);
> >-spin_lock(>debug->lock);
> >-mmio_debug_suspend(uncore->debug);
> >-spin_unlock(>debug->lock);
> >+mmio_debug_suspend(uncore);
> > }
> > spin_unlock_irq(>lock);
> > }
> >@@ -695,14 +703,7 @@ void intel_uncore_forcewake_user_put(struct
> >intel_uncore *uncore)
> > {
> > spin_lock_irq(>lock);
> > if (!--uncore->user_forcewake_count) {
> >-spin_lock(>debug->lock);
> >-mmio_debug_resume(uncore->debug);
> >-
> >-if (check_for_unclaimed_mmio(uncore))
> >-drm_info(>i915->drm,
> >- "Invalid mmio detected during user
> >access\n");
> >-spin_unlock(>debug->lock);
> >-
> >+mmio_debug_resume(uncore);
> > intel_uncore_forcewake_put__locked(uncore,
> >FORCEWAKE_ALL);
> > }
> > spin_unlock_irq(>lock);
> >--
> >2.37.2
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH 1/4] drm: Add missing DP DSC extended capability definitions.
On Tue, Sep 06, 2022 at 06:43:22PM +0300, Jani Nikula wrote: > On Tue, 06 Sep 2022, Jani Nikula wrote: > > On Mon, 05 Sep 2022, Stanislav Lisovskiy > > wrote: > >> Adding DP DSC register definitions, we might need for further > >> DSC implementation, supporting MST and DP branch pass-through mode. > >> > >> v2: - Fixed checkpatch comment warning > >> v3: - Removed function which is not yet used(Jani Nikula) > >> > >> Reviewed-by: Vinod Govindapillai > >> > >> Signed-off-by: Stanislav Lisovskiy > > > > Maarten, Maxime, Thomas - > > > > So this got pushed to drm-intel-next without your acks. Apologies. Can > > we live with it, or want a revert? > > I've reverted anyway for other reasons. But can we have an ack for the > future? :) > > BR, > Jani. I've resolved the conflict properly now(not the best way of learning about drm-rerere) but I guess its too late now. Sorry for the hassle. But what am I supposed to do now? Should proceed with merge again or wait for some acks? Patches basically would be the same anyway. Stan > > > > > > > BR, > > Jani. > > > > > >> --- > >> include/drm/display/drm_dp.h | 10 +- > >> 1 file changed, 9 insertions(+), 1 deletion(-) > >> > >> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h > >> index 6c0871164771..02c4b6f20478 100644 > >> --- a/include/drm/display/drm_dp.h > >> +++ b/include/drm/display/drm_dp.h > >> @@ -239,6 +239,9 @@ > >> > >> #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ > >> # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) > >> +# define DP_DSC_PASS_THROUGH_IS_SUPPORTED (1 << 1) > >> +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_COMP_TO_COMP(1 << 2) > >> +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_UNCOMP_TO_COMP (1 << 3) > >> > >> #define DP_DSC_REV 0x061 > >> # define DP_DSC_MAJOR_MASK (0xf << 0) > >> @@ -277,12 +280,15 @@ > >> > >> #define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 > >> # define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) > >> +# define DP_DSC_RGB_COLOR_CONV_BYPASS_SUPPORT (1 << 1) > >> > >> #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ > >> > >> #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ > >> # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) > >> # define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 > >> +# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK 0x06 > >> +# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY 0x08 > >> > >> #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 > >> # define DP_DSC_RGB (1 << 0) > >> @@ -344,11 +350,13 @@ > >> # define DP_DSC_24_PER_DP_DSC_SINK (1 << 2) > >> > >> #define DP_DSC_BITS_PER_PIXEL_INC 0x06F > >> +# define DP_DSC_RGB_YCbCr444_MAX_BPP_DELTA_MASK 0x1f > >> +# define DP_DSC_RGB_YCbCr420_MAX_BPP_DELTA_MASK 0xe0 > >> # define DP_DSC_BITS_PER_PIXEL_1_16 0x0 > >> # define DP_DSC_BITS_PER_PIXEL_1_8 0x1 > >> # define DP_DSC_BITS_PER_PIXEL_1_4 0x2 > >> # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 > >> -# define DP_DSC_BITS_PER_PIXEL_10x4 > >> +# define DP_DSC_BITS_PER_PIXEL_1_1 0x4 > >> > >> #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ > >> # define DP_PSR_IS_SUPPORTED1 > > -- > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On Tue, Sep 06, 2022 at 06:14:23PM +0200, Andrzej Hajda wrote: > > > On 06.09.2022 16:43, Ville Syrjälä wrote: > > On Tue, Sep 06, 2022 at 05:36:05PM +0300, Ville Syrjälä wrote: > >> On Tue, Sep 06, 2022 at 05:14:56PM +0300, Ville Syrjälä wrote: > >>> On Tue, Sep 06, 2022 at 03:57:37PM +0200, Andrzej Hajda wrote: > > On 06.09.2022 13:22, Ville Syrjälä wrote: > > On Tue, Sep 06, 2022 at 01:09:16PM +0200, Andrzej Hajda wrote: > >> On 05.09.2022 19:44, Ville Syrjälä wrote: > >>> On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote: > On 05.09.2022 13:48, Ville Syrjälä wrote: > > On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote: > >> In case of ICL and older generations disabling plane and/or > >> disabling > >> async update is always performed on vblank, > > It should only be broken on bdw-glk (see. > > need_async_flip_disable_wa). > On CFL it is reported every drmtip run: > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402 > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402 > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > ... > On APL it is less frequent, probably due to other bugs preventing > run of > this test, last seen at: > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > Similar for SKL: > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > I am not sure if I correctly read the docs but [1] says that 9th bit > of > PLANE_CFG (Async Address Update Enable) is "not double buffered and > the > changes will apply immediately" only for ICL, JSL, LKF1. > >>> It got broken in bdw and fixed again in icl. > >>> > So the change is not necessary in case of icl_plane_disable_arm. > > [1]: https://gfxspecs.intel.com/Predator/Home/Index/7656 > >> but if async update is enabled > >> PLANE_SURF register is updated asynchronously. Writing 0 to > >> PLANE_SURF > >> when plane is still enabled can cause DMAR/PIPE errors. > >> On the other side PLANE_SURF is used to arm plane registers - we > >> need to > >> write to it to trigger update on VBLANK, writting current value > >> should > >> be safe - the buffer address is valid till vblank. > > I think you're effectively saying that somehow the async > > flip disable w/a is not kicking in sometimes. > I was not aware of existence of this w/a and I am little lost in > figuring out how this w/a can prevent zeroing PLANE_SURF too early. > >>> When it works as designed it should: > >>> 1. turn off the async flip bit > >>> 2. wait for vblank so that gets latched > >>> 3. do the sync plane update/disable normally > >> After debugging this terra incognita, I've figured out that plane > >> states > >> are not populated in intel_crtc_async_flip_disable_wa > >> so for_each_old_intel_plane_in_state does not iterate over affected > >> planes and w/a does not work at all. > >> I have no idea where affected plane states should be added. > >> Adding them to the beginning of intel_atomic_check helped, but this is > >> just blind shot: > >> > >> @@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device > >> *dev, > >> new_crtc_state->uapi.mode_changed = true; > >> > >> if (new_crtc_state->uapi.scaling_filter != > >> old_crtc_state->uapi.scaling_filter) > >> new_crtc_state->uapi.mode_changed = true; > >> + > >> + ret = intel_atomic_add_affected_planes(state, crtc); > >> + if (ret) > >> + goto fail; > >> } > >> > >> intel_vrr_check_modeset(state); > >> > >> ret = drm_atomic_helper_check_modeset(dev, >base); > > ^ > > This guy should be adding them for any crtc that has been flagged > > for modeset ahead of time. For modesets flagged later we have to > > add them by hand (eg. in intel_modeset_all_pipes()). > This is no-modeset
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On 06.09.2022 16:43, Ville Syrjälä wrote:
On Tue, Sep 06, 2022 at 05:36:05PM +0300, Ville Syrjälä wrote:
On Tue, Sep 06, 2022 at 05:14:56PM +0300, Ville Syrjälä wrote:
On Tue, Sep 06, 2022 at 03:57:37PM +0200, Andrzej Hajda wrote:
On 06.09.2022 13:22, Ville Syrjälä wrote:
On Tue, Sep 06, 2022 at 01:09:16PM +0200, Andrzej Hajda wrote:
On 05.09.2022 19:44, Ville Syrjälä wrote:
On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote:
On 05.09.2022 13:48, Ville Syrjälä wrote:
On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote:
In case of ICL and older generations disabling plane and/or disabling
async update is always performed on vblank,
It should only be broken on bdw-glk (see. need_async_flip_disable_wa).
On CFL it is reported every drmtip run:
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
...
On APL it is less frequent, probably due to other bugs preventing run of
this test, last seen at:
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
Similar for SKL:
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
I am not sure if I correctly read the docs but [1] says that 9th bit of
PLANE_CFG (Async Address Update Enable) is "not double buffered and the
changes will apply immediately" only for ICL, JSL, LKF1.
It got broken in bdw and fixed again in icl.
So the change is not necessary in case of icl_plane_disable_arm.
[1]: https://gfxspecs.intel.com/Predator/Home/Index/7656
but if async update is enabled
PLANE_SURF register is updated asynchronously. Writing 0 to PLANE_SURF
when plane is still enabled can cause DMAR/PIPE errors.
On the other side PLANE_SURF is used to arm plane registers - we need to
write to it to trigger update on VBLANK, writting current value should
be safe - the buffer address is valid till vblank.
I think you're effectively saying that somehow the async
flip disable w/a is not kicking in sometimes.
I was not aware of existence of this w/a and I am little lost in
figuring out how this w/a can prevent zeroing PLANE_SURF too early.
When it works as designed it should:
1. turn off the async flip bit
2. wait for vblank so that gets latched
3. do the sync plane update/disable normally
After debugging this terra incognita, I've figured out that plane states
are not populated in intel_crtc_async_flip_disable_wa
so for_each_old_intel_plane_in_state does not iterate over affected
planes and w/a does not work at all.
I have no idea where affected plane states should be added.
Adding them to the beginning of intel_atomic_check helped, but this is
just blind shot:
@@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device
*dev,
new_crtc_state->uapi.mode_changed = true;
if (new_crtc_state->uapi.scaling_filter !=
old_crtc_state->uapi.scaling_filter)
new_crtc_state->uapi.mode_changed = true;
+
+ ret = intel_atomic_add_affected_planes(state, crtc);
+ if (ret)
+ goto fail;
}
intel_vrr_check_modeset(state);
ret = drm_atomic_helper_check_modeset(dev, >base);
^
This guy should be adding them for any crtc that has been flagged
for modeset ahead of time. For modesets flagged later we have to
add them by hand (eg. in intel_modeset_all_pipes()).
This is no-modeset scenario, drm_atomic_helper_check_modeset does not
add planes in this case.
Then he mystery is how intel_crtc_async_flip_disable_wa() manages
to not disable async flip for some planes...
After a few minutes of pondering I have a theory:
1. async flip on plane 1
crtc_state.*async_flip: false -> true
2. sync flip on plane 2, plane 1 not include in state
crtc_state.*async_flip: true -> false, but plane 1 still remains in
async flip mode
3. sync update/disable plane 1
crtc_state.*async_flip = true -> true, so the async flip disable w/a
Meant to write false->false there.
There is only one plane in game.
Apparently there is an issue with intel_crtc_crc_setup_workarounds.
It calls intel_atomic_get_crtc_state for fresh state, causing state
duplication, but async_flip flag is set always to false in new state.
In cases full modeset is not performed hw
Re: [Intel-gfx] [PATCH] drm/i915: Rename ggtt_view as gtt_view
On 05/09/2022 10:34, Tvrtko Ursulin wrote:
On 01/09/2022 19:38, Niranjana Vishwanathapura wrote:
So far, different views (normal, partial, rotated and remapped)
into the same object are only supported for GGTT mappings.
But with the upcoming VM_BIND feature, PPGTT will also use the
partial view mapping. Hence rename ggtt_view to more generic
gtt_view.
Signed-off-by: Niranjana Vishwanathapura
Acked-by: Tvrtko Ursulin
Easily even r-b since I did scroll through it and it all looks
straightforward.
For the record:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Regards,
Tvrtko
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.h | 2 +-
.../drm/i915/display/intel_display_types.h | 2 +-
drivers/gpu/drm/i915/display/intel_fb.c | 18 ++---
drivers/gpu/drm/i915/display/intel_fb_pin.c | 4 +-
drivers/gpu/drm/i915/display/intel_fb_pin.h | 4 +-
drivers/gpu/drm/i915/display/intel_fbdev.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 16 ++---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_mman.c | 4 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 56 +++
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 40 +--
drivers/gpu/drm/i915/i915_vma.h | 18 ++---
drivers/gpu/drm/i915/i915_vma_types.h | 42 ++--
drivers/gpu/drm/i915/selftests/i915_vma.c | 68 +--
19 files changed, 149 insertions(+), 149 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index be7cff722196..8251f87064f6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -670,7 +670,7 @@ bool intel_plane_uses_fence(const struct
intel_plane_state *plane_state)
return DISPLAY_VER(dev_priv) < 4 ||
(plane->fbc &&
- plane_state->view.gtt.type == I915_GGTT_VIEW_NORMAL);
+ plane_state->view.gtt.type == I915_GTT_VIEW_NORMAL);
}
/*
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index e895277c4cd9..e322011877bb 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -45,7 +45,7 @@ struct drm_modeset_acquire_ctx;
struct drm_plane;
struct drm_plane_state;
struct i915_address_space;
-struct i915_ggtt_view;
+struct i915_gtt_view;
struct intel_atomic_state;
struct intel_crtc;
struct intel_crtc_state;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0da9b208d56e..01977cd237eb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -105,7 +105,7 @@ struct intel_fb_view {
* In the normal view the FB object's backing store sg list is used
* directly and hence the remap information here is not used.
*/
- struct i915_ggtt_view gtt;
+ struct i915_gtt_view gtt;
/*
* The GTT view (gtt.type) specific information for each FB color
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index b191915ab351..eefa33c555ac 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -1395,7 +1395,7 @@ static u32 calc_plane_remap_info(const struct
intel_framebuffer *fb, int color_p
plane_view_height_tiles(fb, color_plane, dims, y));
}
- if (view->gtt.type == I915_GGTT_VIEW_ROTATED) {
+ if (view->gtt.type == I915_GTT_VIEW_ROTATED) {
drm_WARN_ON(>drm, remap_info->linear);
check_array_bounds(i915, view->gtt.rotated.plane, color_plane);
@@ -1420,7 +1420,7 @@ static u32 calc_plane_remap_info(const struct
intel_framebuffer *fb, int color_p
/* rotate the tile dimensions to match the GTT view */
swap(tile_width, tile_height);
} else {
- drm_WARN_ON(>drm, view->gtt.type !=
I915_GGTT_VIEW_REMAPPED);
+ drm_WARN_ON(>drm, view->gtt.type !=
I915_GTT_VIEW_REMAPPED);
check_array_bounds(i915, view->gtt.remapped.plane,
color_plane);
@@ -1503,12 +1503,12 @@ calc_plane_normal_size(const struct
intel_framebuffer *fb, int color_plane,
}
static void intel_fb_view_init(struct drm_i915_private *i915, struct
intel_fb_view *view,
- enum i915_ggtt_view_type view_type)
+ enum i915_gtt_view_type view_type)
{
memset(view, 0, sizeof(*view));
view->gtt.type = view_type;
- if (view_type == I915_GGTT_VIEW_REMAPPED && IS_ALDERLAKE_P(i915))
+ if
Re: [Intel-gfx] [PATCH 1/4] drm: Add missing DP DSC extended capability definitions.
On Tue, 06 Sep 2022, Jani Nikula wrote: > On Mon, 05 Sep 2022, Stanislav Lisovskiy > wrote: >> Adding DP DSC register definitions, we might need for further >> DSC implementation, supporting MST and DP branch pass-through mode. >> >> v2: - Fixed checkpatch comment warning >> v3: - Removed function which is not yet used(Jani Nikula) >> >> Reviewed-by: Vinod Govindapillai >> >> Signed-off-by: Stanislav Lisovskiy > > Maarten, Maxime, Thomas - > > So this got pushed to drm-intel-next without your acks. Apologies. Can > we live with it, or want a revert? I've reverted anyway for other reasons. But can we have an ack for the future? :) BR, Jani. > > > BR, > Jani. > > >> --- >> include/drm/display/drm_dp.h | 10 +- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h >> index 6c0871164771..02c4b6f20478 100644 >> --- a/include/drm/display/drm_dp.h >> +++ b/include/drm/display/drm_dp.h >> @@ -239,6 +239,9 @@ >> >> #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ >> # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) >> +# define DP_DSC_PASS_THROUGH_IS_SUPPORTED (1 << 1) >> +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_COMP_TO_COMP(1 << 2) >> +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_UNCOMP_TO_COMP (1 << 3) >> >> #define DP_DSC_REV 0x061 >> # define DP_DSC_MAJOR_MASK (0xf << 0) >> @@ -277,12 +280,15 @@ >> >> #define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 >> # define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) >> +# define DP_DSC_RGB_COLOR_CONV_BYPASS_SUPPORT (1 << 1) >> >> #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ >> >> #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ >> # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) >> # define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 >> +# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK 0x06 >> +# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY 0x08 >> >> #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 >> # define DP_DSC_RGB (1 << 0) >> @@ -344,11 +350,13 @@ >> # define DP_DSC_24_PER_DP_DSC_SINK (1 << 2) >> >> #define DP_DSC_BITS_PER_PIXEL_INC 0x06F >> +# define DP_DSC_RGB_YCbCr444_MAX_BPP_DELTA_MASK 0x1f >> +# define DP_DSC_RGB_YCbCr420_MAX_BPP_DELTA_MASK 0xe0 >> # define DP_DSC_BITS_PER_PIXEL_1_16 0x0 >> # define DP_DSC_BITS_PER_PIXEL_1_8 0x1 >> # define DP_DSC_BITS_PER_PIXEL_1_4 0x2 >> # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 >> -# define DP_DSC_BITS_PER_PIXEL_10x4 >> +# define DP_DSC_BITS_PER_PIXEL_1_1 0x4 >> >> #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ >> # define DP_PSR_IS_SUPPORTED1 -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 0/4] Add DP MST DSC support to i915
On Mon, 05 Sep 2022, Stanislav Lisovskiy wrote: > Currently we have only DSC support for DP SST. As discussed elsewhere, the patches were modified while applying to resolve conflicts, leading to further conflicts in drm-tip rebuild, and eventually drm-tip build breakage. They would've created further conflicts in linux-next as well as drm-intel-next feature pull (or drm-next backmerge to drm-intel-next). I've gone ahead and reverted the commits from drm-intel-next directly, with Rodrigo's ack. The conflict resolution would have been messy and generated a bunch of extra work, and we needed to get drm-tip build back on track ASAP. We'll need to have a clean baseline to apply the patches on, i.e. drm-misc-next pull request to drm-next, and drm-next backmerge to drm-intel-next. BR, Jani. > > Stanislav Lisovskiy (4): > drm: Add missing DP DSC extended capability definitions. > drm/i915: Fix intel_dp_mst_compute_link_config > drm/i915: Extract drm_dp_atomic_find_vcpi_slots cycle to separate > function > drm/i915: Add DSC support to MST path > > drivers/gpu/drm/i915/display/intel_dp.c | 73 > drivers/gpu/drm/i915/display/intel_dp.h | 17 ++ > drivers/gpu/drm/i915/display/intel_dp_mst.c | 195 ++-- > include/drm/display/drm_dp.h| 10 +- > 4 files changed, 237 insertions(+), 58 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PULL] drm-misc-next
On Tue, Sep 06, 2022 at 08:53:25AM +0200, Maarten Lankhorst wrote:
> Hi Dave, Daniel,
>
> A pull request prepared in Germany and Denmark, but sent from Sweden after
> fighting with gpg on an infamous bridge.
>
> My computer's somewhere in my trunk so I just copied someone else's pull
> request and pretend my laptop is a dev machine that sends pull requests every
> day works..
>
> Tag is still correctly signed, hope I didn't mess up anything!
[Dave should be back to handling pulls for everything this Fri]
Applied to drm-next, thanks.
-Daniel
>
> drm-misc-next-2022-08-20-1:
> drm-misc-next for v6.1:
>
> UAPI Changes:
>
> Cross-subsystem Changes:
> - DMA-buf: documentation updates.
> - Assorted small fixes to vga16fb
> - Fix fbdev drivers to use the aperture helpers.
> - Make removal of conflicting drivers work correctly without fbdev enabled.
>
> Core Changes:
> - bridge, scheduler, dp-mst: Assorted small fixes.
> - Add more format helpers to fourcc, and use it to replace the cpp usage.
> - Add DRM_FORMAT_Cxx, DRM_FORMAT_Rxx (single channel), and DRM_FORMAT_Dxx
> ("darkness", inverted single channel)
> - Add packed AYUV and XYUV formats.
> - Assorted documentation updates.
> - Rename ttm_bo_init to ttm_bo_init_validate.
> - Allow TTM bo's to exist without backing store.
> - Convert drm selftests to kunit.
> - Add managed init functions for (panel) bridge, crtc, encoder and connector.
> - Fix endianness handling in various format conversion helpers.
> - Make tests pass on big-endian platforms, and add test for rgb888 -> rgb565
> - Move DRM_PLANE_HELPER_NO_SCALING to atomic helpers and rename, so
> drm_plane_helper is no longer needed in most drivers.
> - Use idr_init_base instead of idr_init.
> - Rename FB and GEM CMA helpers to DMA helpers.
> - Rework XRGB related conversion helpers, and add drm_fb_blit() that
> takes a iosys_map. Make drm_fb_memcpy take an iosys_map too.
> - Move edid luminance calculation to core, and use it in i915.
>
> Driver Changes:
> - bridge/{adv7511,ti-sn65dsi86,parade-ps8640},
> panel/{simple,nt35510,tc358767},
> nouveau, sun4i, mipi-dsi, mgag200, bochs, arm, komeda, vmwgfx, pl111:
> Assorted small fixes and doc updates.
> - vc4: Rework hdmi power up, and depend on PM.
> - panel/simple: Add Samsung LTL101AL01.
> - ingenic: Add JZ4760(B) support, avoid a modeset when sharpness property
> is unchanged, and use the new PM ops.
> - Revert some amdgpu commits that cause garbaged graphics when starting
> X, and reapply them with the real problem fixed.
> - Completely rework vc4 init to use managed helpers.
> - Rename via_drv to via_dri1, and move all stuff there only used by the
> dri1 implementation in preperation for atomic modeset.
> - Use regmap bulk write in ssd130x.
> - Power sequence and clock updates to it6505.
> - Split panel-sitrox-st7701 init sequence and rework mode programming code.
> - virtio: Improve error and edge conditions handling, and convert to use
> managed
> helpers.
> - Add Samsung LTL101AL01, B120XAN01.0, R140NWF5 RH, DMT028VGHMCMI-1A T,
> panels.
> - Add generic fbdev support to komeda.
> - Split mgag200 modeset handling to make it more model-specific.
> - Convert simpledrm to use atomic helpers.
> - Improve udl suspend/disconnect handling.
> The following changes since commit 2bc7ea71a73747a77e7f83bc085b0d2393235410:
>
> Merge tag 'topic/nouveau-misc-2022-07-27' of
> git://anongit.freedesktop.org/drm/drm into drm-next (2022-07-27 11:34:07
> +1000)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2022-08-20-1
>
> for you to fetch changes up to 8869fa666a9e6782c3c896c1fa57d65adca23249:
>
> drm/virtio: remove drm_plane_cleanup() destroy hook (2022-08-19 16:00:15
> +0200)
>
>
> drm-misc-next for v6.1:
>
> UAPI Changes:
>
> Cross-subsystem Changes:
> - DMA-buf: documentation updates.
> - Assorted small fixes to vga16fb
> - Fix fbdev drivers to use the aperture helpers.
> - Make removal of conflicting drivers work correctly without fbdev enabled.
>
> Core Changes:
> - bridge, scheduler, dp-mst: Assorted small fixes.
> - Add more format helpers to fourcc, and use it to replace the cpp usage.
> - Add DRM_FORMAT_Cxx, DRM_FORMAT_Rxx (single channel), and DRM_FORMAT_Dxx
> ("darkness", inverted single channel)
> - Add packed AYUV and XYUV formats.
> - Assorted documentation updates.
> - Rename ttm_bo_init to ttm_bo_init_validate.
> - Allow TTM bo's to exist without backing store.
> - Convert drm selftests to kunit.
> - Add managed init functions for (panel) bridge, crtc, encoder and connector.
> - Fix endianness handling in various format conversion helpers.
> - Make tests pass on big-endian platforms, and add test for rgb888 -> rgb565
> - Move DRM_PLANE_HELPER_NO_SCALING to atomic helpers and rename, so
> drm_plane_helper is no longer needed in most drivers.
> - Use
Re: [Intel-gfx] [PATCH 3/6] drm/i915/xelpmp: Expose media as another GT
On Mon, 05 Sep 2022 02:11:16 -0700, Jani Nikula wrote:
>
Copying author, these patches are from a different series
(https://patchwork.freedesktop.org/series/107908/) as mentioned in the
cover letter.
> On Fri, 02 Sep 2022, Ashutosh Dixit wrote:
> > From: Matt Roper
> >
> > Xe_LPM+ platforms have "standalone media." I.e., the media unit is
> > designed as an additional GT with its own engine list, GuC, forcewake,
> > etc. Let's allow platforms to include media GTs in their device info.
> >
> > Cc: Aravind Iddamsetty
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/Makefile| 1 +
> > drivers/gpu/drm/i915/gt/intel_gt.c | 12 ++--
> > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 +
> > drivers/gpu/drm/i915/gt/intel_sa_media.c | 39
> > drivers/gpu/drm/i915/gt/intel_sa_media.h | 15 +
> > drivers/gpu/drm/i915/i915_pci.c | 15 +
> > drivers/gpu/drm/i915/intel_device_info.h | 5 ++-
> > drivers/gpu/drm/i915/intel_uncore.c | 16 --
> > drivers/gpu/drm/i915/intel_uncore.h | 20 ++--
> > 9 files changed, 123 insertions(+), 8 deletions(-)
> > create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.c
> > create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.h
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 522ef9b4aff3..e83e4cd46968 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -123,6 +123,7 @@ gt-y += \
> > gt/intel_ring.o \
> > gt/intel_ring_submission.o \
> > gt/intel_rps.o \
> > + gt/intel_sa_media.o \
> > gt/intel_sseu.o \
> > gt/intel_sseu_debugfs.o \
> > gt/intel_timeline.o \
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > index 57a6488c0e14..bfe77d01f747 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > @@ -776,10 +776,15 @@ void intel_gt_driver_late_release_all(struct
> > drm_i915_private *i915)
> > }
> > }
> >
> > -static int intel_gt_tile_setup(struct intel_gt *gt, phys_addr_t phys_addr)
> > +static int intel_gt_tile_setup(struct intel_gt *gt,
> > + phys_addr_t phys_addr,
> > + u32 gsi_offset)
> > {
> > int ret;
> >
> > + /* GSI offset is only applicable for media GTs */
> > + drm_WARN_ON(>i915->drm, gsi_offset);
> > +
> > if (!gt_is_root(gt)) {
> > struct intel_uncore_mmio_debug *mmio_debug;
> > struct intel_uncore *uncore;
> > @@ -840,7 +845,7 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
> > gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
> >
> > drm_dbg(>drm, "Setting up %s\n", gt->name);
> > - ret = intel_gt_tile_setup(gt, phys_addr);
> > + ret = intel_gt_tile_setup(gt, phys_addr, 0);
> > if (ret)
> > return ret;
> >
> > @@ -873,7 +878,8 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
> > goto err;
> > }
> >
> > - ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);
> > + ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base,
> > + gtdef->gsi_offset);
> > if (ret)
> > goto err;
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index d414785003cc..fb2c56777480 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -1578,4 +1578,12 @@
> >
> > #define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000)
> >
> > +/*
> > + * Standalone Media's non-engine GT registers are located at their regular
> > GT
> > + * offsets plus 0x38. This extra offset is stored inside the
> > intel_uncore
> > + * structure so that the existing code can be used for both GTs without
> > + * modification.
> > + */
> > +#define MTL_MEDIA_GSI_BASE 0x38
> > +
> > #endif /* __INTEL_GT_REGS__ */
> > diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.c
> > b/drivers/gpu/drm/i915/gt/intel_sa_media.c
> > new file mode 100644
> > index ..8c5c519457cc
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/gt/intel_sa_media.c
> > @@ -0,0 +1,39 @@
> > +// SPDX-License-Identifier: MIT
> > +/*
> > + * Copyright © 2021 Intel Corporation
> > + */
> > +
> > +#include
> > +
> > +#include "i915_drv.h"
> > +#include "gt/intel_gt.h"
> > +#include "gt/intel_sa_media.h"
> > +
> > +int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t phys_addr,
> > + u32 gsi_offset)
> > +{
> > + struct drm_i915_private *i915 = gt->i915;
> > + struct intel_uncore *uncore;
> > +
> > + uncore = drmm_kzalloc(>drm, sizeof(*uncore), GFP_KERNEL);
> > + if (!uncore)
> > + return -ENOMEM;
> > +
> > + uncore->gsi_offset = gsi_offset;
> > +
> > +
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Prepare more multi-GT initialization
On Tue, 06 Sep 2022 07:07:41 -0700, Rodrigo Vivi wrote:
>
Copying author, these patches are from a different series
(https://patchwork.freedesktop.org/series/107908/) as mentioned in the
cover letter.
> On Fri, Sep 02, 2022 at 04:52:57PM -0700, Ashutosh Dixit wrote:
> > From: Matt Roper
> >
> > We're going to introduce an additional intel_gt for MTL's media unit
> > soon. Let's provide a bit more multi-GT initialization framework in
> > preparation for that. The initialization will pull the list of GTs for
> > a platform from the device info structure. Although necessary for the
> > immediate MTL media enabling, this same framework will also be used
> > farther down the road when we enable remote tiles on xehpsdv and pvc.
> >
> > v2:
> > - Re-add missing test for !HAS_EXTRA_GT_LIST in intel_gt_probe_all().
> >
> > Cc: Aravind Iddamsetty
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> > drivers/gpu/drm/i915/gt/intel_gt.c| 54 ---
> > drivers/gpu/drm/i915/gt/intel_gt.h| 1 -
> > drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
> > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > drivers/gpu/drm/i915/intel_device_info.h | 16 ++
> > .../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
> > 7 files changed, 70 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 275ad72940c1..41acc285e8bf 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -736,7 +736,7 @@ static intel_engine_mask_t init_engine_mask(struct
> > intel_gt *gt)
> > u16 vdbox_mask;
> > u16 vebox_mask;
> >
> > - info->engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
> > + GEM_BUG_ON(!info->engine_mask);
> >
> > if (GRAPHICS_VER(i915) < 11)
> > return info->engine_mask;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > index e4bac2431e41..5b4263c708cc 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > @@ -815,20 +815,16 @@ static void
> > intel_gt_tile_cleanup(struct intel_gt *gt)
> > {
> > intel_uncore_cleanup_mmio(gt->uncore);
> > -
> > - if (!gt_is_root(gt)) {
> > - kfree(gt->uncore->debug);
> > - kfree(gt->uncore);
> > - kfree(gt);
> > - }
>
> In this patch I see less free...
>
> > }
> >
> > int intel_gt_probe_all(struct drm_i915_private *i915)
> > {
> > struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > struct intel_gt *gt = >gt0;
> > + const struct intel_gt_definition *gtdef;
> > phys_addr_t phys_addr;
> > unsigned int mmio_bar;
> > + unsigned int i;
> > int ret;
> >
> > mmio_bar = GRAPHICS_VER(i915) == 2 ? GEN2_GTTMMADR_BAR : GTTMMADR_BAR;
> > @@ -839,14 +835,58 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
> > * and it has been already initialized early during probe
> > * in i915_driver_probe()
> > */
> > + gt->i915 = i915;
> > + gt->name = "Primary GT";
> > + gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
> > +
> > + drm_dbg(>drm, "Setting up %s\n", gt->name);
> > ret = intel_gt_tile_setup(gt, phys_addr);
> > if (ret)
> > return ret;
> >
> > i915->gt[0] = gt;
> >
> > - /* TODO: add more tiles */
> > + if (!HAS_EXTRA_GT_LIST(i915))
> > + return 0;
> > +
> > + for (i = 1, gtdef = _INFO(i915)->extra_gt_list[i - 1];
> > +gtdef->setup != NULL;
> > +i++, gtdef = _INFO(i915)->extra_gt_list[i - 1]) {
> > + gt = drmm_kzalloc(>drm, sizeof(*gt), GFP_KERNEL);
>
> ... and more allocs...
>
> it probably deserves some smaller patches with some explanations?
>
> or something is indeed missing here?
>
> > + if (!gt) {
> > + ret = -ENOMEM;
> > + goto err;
> > + }
> > +
> > + gt->i915 = i915;
> > + gt->name = gtdef->name;
> > + gt->type = gtdef->type;
> > + gt->info.engine_mask = gtdef->engine_mask;
> > + gt->info.id = i;
> > +
> > + drm_dbg(>drm, "Setting up %s\n", gt->name);
> > + if (GEM_WARN_ON(range_overflows_t(resource_size_t,
> > + gtdef->mapping_base,
> > + SZ_16M,
> > + pci_resource_len(pdev,
> > mmio_bar {
> > + ret = -ENODEV;
> > + goto err;
> > + }
> > +
> > + ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);
> > + if (ret)
> > + goto err;
> > +
> > + i915->gt[i] = gt;
> > + }
> > +
> > return 0;
> > +
> > +err:
> > + i915_probe_error(i915, "Failed to initialize %s! (%d)\n",
[Intel-gfx] ✓ Fi.CI.IGT: success for Move all drivers to a common dma-buf locking convention
== Series Details == Series: Move all drivers to a common dma-buf locking convention URL : https://patchwork.freedesktop.org/series/108187/ State : success == Summary == CI Bug Log - changes from CI_DRM_12074_full -> Patchwork_108187v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 11) -- Missing(1): shard-rkl Known issues Here are the changes found in Patchwork_108187v1_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) -> ([PASS][26], [FAIL][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) ([i915#4392]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk9/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk1/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk1/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk1/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk2/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk2/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk2/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk2/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk3/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk3/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk3/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk6/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk7/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk7/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk7/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk7/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk8/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk9/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk8/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk8/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk9/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk2/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk2/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk2/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk3/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk3/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk3/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk5/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk5/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk5/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk6/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk6/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk6/boot.html [43]:
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On Tue, Sep 06, 2022 at 05:36:05PM +0300, Ville Syrjälä wrote: > On Tue, Sep 06, 2022 at 05:14:56PM +0300, Ville Syrjälä wrote: > > On Tue, Sep 06, 2022 at 03:57:37PM +0200, Andrzej Hajda wrote: > > > > > > > > > On 06.09.2022 13:22, Ville Syrjälä wrote: > > > > On Tue, Sep 06, 2022 at 01:09:16PM +0200, Andrzej Hajda wrote: > > > >> > > > >> On 05.09.2022 19:44, Ville Syrjälä wrote: > > > >>> On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote: > > > On 05.09.2022 13:48, Ville Syrjälä wrote: > > > > On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote: > > > >> In case of ICL and older generations disabling plane and/or > > > >> disabling > > > >> async update is always performed on vblank, > > > > It should only be broken on bdw-glk (see. > > > > need_async_flip_disable_wa). > > > On CFL it is reported every drmtip run: > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402 > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402 > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > > ... > > > On APL it is less frequent, probably due to other bugs preventing > > > run of > > > this test, last seen at: > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > > > Similar for SKL: > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > > > > > I am not sure if I correctly read the docs but [1] says that 9th bit > > > of > > > PLANE_CFG (Async Address Update Enable) is "not double buffered and > > > the > > > changes will apply immediately" only for ICL, JSL, LKF1. > > > >>> It got broken in bdw and fixed again in icl. > > > >>> > > > So the change is not necessary in case of icl_plane_disable_arm. > > > > > > [1]: https://gfxspecs.intel.com/Predator/Home/Index/7656 > > > >> but if async update is enabled > > > >> PLANE_SURF register is updated asynchronously. Writing 0 to > > > >> PLANE_SURF > > > >> when plane is still enabled can cause DMAR/PIPE errors. > > > >> On the other side PLANE_SURF is used to arm plane registers - we > > > >> need to > > > >> write to it to trigger update on VBLANK, writting current value > > > >> should > > > >> be safe - the buffer address is valid till vblank. > > > > I think you're effectively saying that somehow the async > > > > flip disable w/a is not kicking in sometimes. > > > I was not aware of existence of this w/a and I am little lost in > > > figuring out how this w/a can prevent zeroing PLANE_SURF too early. > > > >>> When it works as designed it should: > > > >>> 1. turn off the async flip bit > > > >>> 2. wait for vblank so that gets latched > > > >>> 3. do the sync plane update/disable normally > > > >> After debugging this terra incognita, I've figured out that plane > > > >> states > > > >> are not populated in intel_crtc_async_flip_disable_wa > > > >> so for_each_old_intel_plane_in_state does not iterate over affected > > > >> planes and w/a does not work at all. > > > >> I have no idea where affected plane states should be added. > > > >> Adding them to the beginning of intel_atomic_check helped, but this is > > > >> just blind shot: > > > >> > > > >> @@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device > > > >> *dev, > > > >> new_crtc_state->uapi.mode_changed = true; > > > >> > > > >> if (new_crtc_state->uapi.scaling_filter != > > > >> old_crtc_state->uapi.scaling_filter) > > > >> new_crtc_state->uapi.mode_changed = true; > > > >> + > > > >> + ret = intel_atomic_add_affected_planes(state, crtc); > > > >> + if (ret) > > > >> + goto fail; > > > >> } > > > >> > > > >> intel_vrr_check_modeset(state); > > > >> > > > >> ret = drm_atomic_helper_check_modeset(dev, >base); > > > >^ > > > > This guy should be adding them for any crtc that has been flagged > > > > for modeset ahead of time. For modesets flagged later we have to > > > > add them by hand (eg. in intel_modeset_all_pipes()). > > > > > > This is no-modeset scenario, drm_atomic_helper_check_modeset does not > > > add planes in this case. > > > > Then he mystery is
Re: [Intel-gfx] [PATCH 1/4] drm: Add missing DP DSC extended capability definitions.
On Tue, 06 Sep 2022, Jani Nikula wrote: > On Mon, 05 Sep 2022, Stanislav Lisovskiy > wrote: >> Adding DP DSC register definitions, we might need for further >> DSC implementation, supporting MST and DP branch pass-through mode. >> >> v2: - Fixed checkpatch comment warning >> v3: - Removed function which is not yet used(Jani Nikula) >> >> Reviewed-by: Vinod Govindapillai >> >> Signed-off-by: Stanislav Lisovskiy > > Maarten, Maxime, Thomas - > > So this got pushed to drm-intel-next without your acks. Apologies. Can > we live with it, or want a revert? I think dim should've warned about missing acks, did it not? :( BR, Jani. > > > BR, > Jani. > > >> --- >> include/drm/display/drm_dp.h | 10 +- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h >> index 6c0871164771..02c4b6f20478 100644 >> --- a/include/drm/display/drm_dp.h >> +++ b/include/drm/display/drm_dp.h >> @@ -239,6 +239,9 @@ >> >> #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ >> # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) >> +# define DP_DSC_PASS_THROUGH_IS_SUPPORTED (1 << 1) >> +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_COMP_TO_COMP(1 << 2) >> +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_UNCOMP_TO_COMP (1 << 3) >> >> #define DP_DSC_REV 0x061 >> # define DP_DSC_MAJOR_MASK (0xf << 0) >> @@ -277,12 +280,15 @@ >> >> #define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 >> # define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) >> +# define DP_DSC_RGB_COLOR_CONV_BYPASS_SUPPORT (1 << 1) >> >> #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ >> >> #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ >> # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) >> # define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 >> +# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK 0x06 >> +# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY 0x08 >> >> #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 >> # define DP_DSC_RGB (1 << 0) >> @@ -344,11 +350,13 @@ >> # define DP_DSC_24_PER_DP_DSC_SINK (1 << 2) >> >> #define DP_DSC_BITS_PER_PIXEL_INC 0x06F >> +# define DP_DSC_RGB_YCbCr444_MAX_BPP_DELTA_MASK 0x1f >> +# define DP_DSC_RGB_YCbCr420_MAX_BPP_DELTA_MASK 0xe0 >> # define DP_DSC_BITS_PER_PIXEL_1_16 0x0 >> # define DP_DSC_BITS_PER_PIXEL_1_8 0x1 >> # define DP_DSC_BITS_PER_PIXEL_1_4 0x2 >> # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 >> -# define DP_DSC_BITS_PER_PIXEL_10x4 >> +# define DP_DSC_BITS_PER_PIXEL_1_1 0x4 >> >> #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ >> # define DP_PSR_IS_SUPPORTED1 -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On Tue, Sep 06, 2022 at 05:14:56PM +0300, Ville Syrjälä wrote: > On Tue, Sep 06, 2022 at 03:57:37PM +0200, Andrzej Hajda wrote: > > > > > > On 06.09.2022 13:22, Ville Syrjälä wrote: > > > On Tue, Sep 06, 2022 at 01:09:16PM +0200, Andrzej Hajda wrote: > > >> > > >> On 05.09.2022 19:44, Ville Syrjälä wrote: > > >>> On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote: > > On 05.09.2022 13:48, Ville Syrjälä wrote: > > > On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote: > > >> In case of ICL and older generations disabling plane and/or disabling > > >> async update is always performed on vblank, > > > It should only be broken on bdw-glk (see. need_async_flip_disable_wa). > > On CFL it is reported every drmtip run: > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402 > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402 > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > ... > > On APL it is less frequent, probably due to other bugs preventing run > > of > > this test, last seen at: > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > > Similar for SKL: > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > > > I am not sure if I correctly read the docs but [1] says that 9th bit of > > PLANE_CFG (Async Address Update Enable) is "not double buffered and the > > changes will apply immediately" only for ICL, JSL, LKF1. > > >>> It got broken in bdw and fixed again in icl. > > >>> > > So the change is not necessary in case of icl_plane_disable_arm. > > > > [1]: https://gfxspecs.intel.com/Predator/Home/Index/7656 > > >> but if async update is enabled > > >> PLANE_SURF register is updated asynchronously. Writing 0 to > > >> PLANE_SURF > > >> when plane is still enabled can cause DMAR/PIPE errors. > > >> On the other side PLANE_SURF is used to arm plane registers - we > > >> need to > > >> write to it to trigger update on VBLANK, writting current value > > >> should > > >> be safe - the buffer address is valid till vblank. > > > I think you're effectively saying that somehow the async > > > flip disable w/a is not kicking in sometimes. > > I was not aware of existence of this w/a and I am little lost in > > figuring out how this w/a can prevent zeroing PLANE_SURF too early. > > >>> When it works as designed it should: > > >>> 1. turn off the async flip bit > > >>> 2. wait for vblank so that gets latched > > >>> 3. do the sync plane update/disable normally > > >> After debugging this terra incognita, I've figured out that plane states > > >> are not populated in intel_crtc_async_flip_disable_wa > > >> so for_each_old_intel_plane_in_state does not iterate over affected > > >> planes and w/a does not work at all. > > >> I have no idea where affected plane states should be added. > > >> Adding them to the beginning of intel_atomic_check helped, but this is > > >> just blind shot: > > >> > > >> @@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device > > >> *dev, > > >> new_crtc_state->uapi.mode_changed = true; > > >> > > >> if (new_crtc_state->uapi.scaling_filter != > > >> old_crtc_state->uapi.scaling_filter) > > >> new_crtc_state->uapi.mode_changed = true; > > >> + > > >> + ret = intel_atomic_add_affected_planes(state, crtc); > > >> + if (ret) > > >> + goto fail; > > >> } > > >> > > >> intel_vrr_check_modeset(state); > > >> > > >> ret = drm_atomic_helper_check_modeset(dev, >base); > > >^ > > > This guy should be adding them for any crtc that has been flagged > > > for modeset ahead of time. For modesets flagged later we have to > > > add them by hand (eg. in intel_modeset_all_pipes()). > > > > This is no-modeset scenario, drm_atomic_helper_check_modeset does not > > add planes in this case. > > Then he mystery is how intel_crtc_async_flip_disable_wa() manages > to not disable async flip for some planes... After a few minutes of pondering I have a theory: 1. async flip on plane 1 crtc_state.*async_flip: false -> true 2. sync flip on plane 2, plane 1 not include in state crtc_state.*async_flip: true
Re: [Intel-gfx] [PATCH 1/4] drm: Add missing DP DSC extended capability definitions.
On Mon, 05 Sep 2022, Stanislav Lisovskiy wrote: > Adding DP DSC register definitions, we might need for further > DSC implementation, supporting MST and DP branch pass-through mode. > > v2: - Fixed checkpatch comment warning > v3: - Removed function which is not yet used(Jani Nikula) > > Reviewed-by: Vinod Govindapillai > > Signed-off-by: Stanislav Lisovskiy Maarten, Maxime, Thomas - So this got pushed to drm-intel-next without your acks. Apologies. Can we live with it, or want a revert? BR, Jani. > --- > include/drm/display/drm_dp.h | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h > index 6c0871164771..02c4b6f20478 100644 > --- a/include/drm/display/drm_dp.h > +++ b/include/drm/display/drm_dp.h > @@ -239,6 +239,9 @@ > > #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ > # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) > +# define DP_DSC_PASS_THROUGH_IS_SUPPORTED (1 << 1) > +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_COMP_TO_COMP(1 << 2) > +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_UNCOMP_TO_COMP (1 << 3) > > #define DP_DSC_REV 0x061 > # define DP_DSC_MAJOR_MASK (0xf << 0) > @@ -277,12 +280,15 @@ > > #define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 > # define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) > +# define DP_DSC_RGB_COLOR_CONV_BYPASS_SUPPORT (1 << 1) > > #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ > > #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ > # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) > # define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 > +# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK 0x06 > +# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY 0x08 > > #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 > # define DP_DSC_RGB (1 << 0) > @@ -344,11 +350,13 @@ > # define DP_DSC_24_PER_DP_DSC_SINK (1 << 2) > > #define DP_DSC_BITS_PER_PIXEL_INC 0x06F > +# define DP_DSC_RGB_YCbCr444_MAX_BPP_DELTA_MASK 0x1f > +# define DP_DSC_RGB_YCbCr420_MAX_BPP_DELTA_MASK 0xe0 > # define DP_DSC_BITS_PER_PIXEL_1_16 0x0 > # define DP_DSC_BITS_PER_PIXEL_1_8 0x1 > # define DP_DSC_BITS_PER_PIXEL_1_4 0x2 > # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 > -# define DP_DSC_BITS_PER_PIXEL_10x4 > +# define DP_DSC_BITS_PER_PIXEL_1_1 0x4 > > #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ > # define DP_PSR_IS_SUPPORTED1 -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 01/19] drm/i915/perf: Fix OA filtering logic for GuC mode
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
With GuC mode of submission, GuC is in control of defining the context id field
that is part of the OA reports. To filter reports, UMD and KMD must know what sw
context id was chosen by GuC. There is not interface between KMD and GuC to
determine this, so read the upper-dword of EXECLIST_STATUS to filter/squash OA
reports for the specific context.
Signed-off-by: Umesh Nerlige Ramappa
I assume you checked with GuC that this doesn't change as the context is
running?
With i915/execlist submission mode, we had to ask i915 to pin the
sw_id/ctx_id.
If that's not the case then filtering is broken.
-Lionel
---
drivers/gpu/drm/i915/gt/intel_lrc.h | 2 +
drivers/gpu/drm/i915/i915_perf.c| 141
2 files changed, 124 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.h
b/drivers/gpu/drm/i915/gt/intel_lrc.h
index a390f0813c8b..7111bae759f3 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.h
@@ -110,6 +110,8 @@ enum {
#define XEHP_SW_CTX_ID_WIDTH 16
#define XEHP_SW_COUNTER_SHIFT 58
#define XEHP_SW_COUNTER_WIDTH 6
+#define GEN12_GUC_SW_CTX_ID_SHIFT 39
+#define GEN12_GUC_SW_CTX_ID_WIDTH 16
static inline void lrc_runtime_start(struct intel_context *ce)
{
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index f3c23fe9ad9c..735244a3aedd 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1233,6 +1233,125 @@ static struct intel_context *oa_pin_context(struct
i915_perf_stream *stream)
return stream->pinned_ctx;
}
+static int
+__store_reg_to_mem(struct i915_request *rq, i915_reg_t reg, u32 ggtt_offset)
+{
+ u32 *cs, cmd;
+
+ cmd = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
+ if (GRAPHICS_VER(rq->engine->i915) >= 8)
+ cmd++;
+
+ cs = intel_ring_begin(rq, 4);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ *cs++ = cmd;
+ *cs++ = i915_mmio_reg_offset(reg);
+ *cs++ = ggtt_offset;
+ *cs++ = 0;
+
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
+static int
+__read_reg(struct intel_context *ce, i915_reg_t reg, u32 ggtt_offset)
+{
+ struct i915_request *rq;
+ int err;
+
+ rq = i915_request_create(ce);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ i915_request_get(rq);
+
+ err = __store_reg_to_mem(rq, reg, ggtt_offset);
+
+ i915_request_add(rq);
+ if (!err && i915_request_wait(rq, 0, HZ / 2) < 0)
+ err = -ETIME;
+
+ i915_request_put(rq);
+
+ return err;
+}
+
+static int
+gen12_guc_sw_ctx_id(struct intel_context *ce, u32 *ctx_id)
+{
+ struct i915_vma *scratch;
+ u32 *val;
+ int err;
+
+ scratch =
__vm_create_scratch_for_read_pinned(>engine->gt->ggtt->vm, 4);
+ if (IS_ERR(scratch))
+ return PTR_ERR(scratch);
+
+ err = i915_vma_sync(scratch);
+ if (err)
+ goto err_scratch;
+
+ err = __read_reg(ce, RING_EXECLIST_STATUS_HI(ce->engine->mmio_base),
+i915_ggtt_offset(scratch));
+ if (err)
+ goto err_scratch;
+
+ val = i915_gem_object_pin_map_unlocked(scratch->obj, I915_MAP_WB);
+ if (IS_ERR(val)) {
+ err = PTR_ERR(val);
+ goto err_scratch;
+ }
+
+ *ctx_id = *val;
+ i915_gem_object_unpin_map(scratch->obj);
+
+err_scratch:
+ i915_vma_unpin_and_release(, 0);
+ return err;
+}
+
+/*
+ * For execlist mode of submission, pick an unused context id
+ * 0 - (NUM_CONTEXT_TAG -1) are used by other contexts
+ * XXX_MAX_CONTEXT_HW_ID is used by idle context
+ *
+ * For GuC mode of submission read context id from the upper dword of the
+ * EXECLIST_STATUS register.
+ */
+static int gen12_get_render_context_id(struct i915_perf_stream *stream)
+{
+ u32 ctx_id, mask;
+ int ret;
+
+ if (intel_engine_uses_guc(stream->engine)) {
+ ret = gen12_guc_sw_ctx_id(stream->pinned_ctx, _id);
+ if (ret)
+ return ret;
+
+ mask = ((1U << GEN12_GUC_SW_CTX_ID_WIDTH) - 1) <<
+ (GEN12_GUC_SW_CTX_ID_SHIFT - 32);
+ } else if (GRAPHICS_VER_FULL(stream->engine->i915) >= IP_VER(12, 50)) {
+ ctx_id = (XEHP_MAX_CONTEXT_HW_ID - 1) <<
+ (XEHP_SW_CTX_ID_SHIFT - 32);
+
+ mask = ((1U << XEHP_SW_CTX_ID_WIDTH) - 1) <<
+ (XEHP_SW_CTX_ID_SHIFT - 32);
+ } else {
+ ctx_id = (GEN12_MAX_CONTEXT_HW_ID - 1) <<
+(GEN11_SW_CTX_ID_SHIFT - 32);
+
+ mask = ((1U << GEN11_SW_CTX_ID_WIDTH) - 1) <<
+ (GEN11_SW_CTX_ID_SHIFT - 32);
+ }
+
Re: [Intel-gfx] [PATCH] drm/i915: Fix intel_dp_atomic_find_vcpi_slots function
On Tue, 06 Sep 2022, "Lisovskiy, Stanislav"
wrote:
> On Tue, Sep 06, 2022 at 02:57:34PM +0300, Ville Syrjälä wrote:
>> On Tue, Sep 06, 2022 at 01:23:29PM +0300, Stanislav Lisovskiy wrote:
>> > drm_dp_atomic_find_vcpi_slots no longer exists and needs
>> > to be used as drm_dp_atomic_find_time_slots.
>> > Also rename the function itself.
>> >
>> > Signed-off-by: Stanislav Lisovskiy
>> > Fixes: 7ae5ab441402 ("Extract drm_dp_atomic_find_vcpi_slots cycle to
>> > separate function")
>>
>> The problem only exists in drm-tip. You need to revert the
>> bad merge from rerere-cache and redo it.
>>
>> And please always test build drm-tip after solving merge conflicts!
>
> I would really like to figure out how it did end like that.
>
> Here is the sequence of what I've been doing:
>
> 1) There was a series supposed to be merged which had this new
>change already in place i.e using drm_dp_atomic_find_time_slots.
> 2) Then using dim tools I started pushing according to workflow:
>a) dim update-branches
>b) dim checkout drm-intel-next
>c) wget those series mbox and run dim apply-branch drm-intel-next
> Got conflict: it was complaining about those changes around
> drm_dp_atomic_find_time_slots and after some checking I figured
> out that drm_dp_atomic_find_time_slots doesn't exist anymore.
> Here probably was my bad, as I wrongly assumed that those changes
> were probably reverted as it was also mentioned, that there was
> regression because of those.
>
> So I resolved this conflict by putting drm_dp_atomic_find_vcpi_slots
> back instead of drm_dp_atomic_find_time_slots _and_ actually
> built it even.
The rule of thumb is, don't resolve conflicts while applying
patches. Apply the patches as they were posted to the mailing list.
If your patches apply to drm-tip but not to drm-intel-next, you'll know
there's stuff in other branches that affect the lines. You'll end up
with problems both at patch apply and drm-tip rebuild if you don't get
the baseline right first.
>From the committer guidelines:
* As a general rule, do not modify the patches while applying, apart from the
commit message. If the patch conflicts, or needs to be changed due to review,
have the author rebase, update and resend. Any change at this stage is a
potential issue bypassing CI.
BR,
Jani.
>
>d) I run dim push-branch drm-intel-next, it did complain about merge
> conflict again with drm-intel-next which I fixed and results were
> pushed.
> I should have build at this moment as well probably.
>
> Then I noticed that this function drm_dp_atomic_find_vcpi_slots
> doesn't exist in drm. So basically patches should have been pushed
> as they were initially, but why the conflict appeared initially - that
> is my
> question.
>
> Stan
>
>>
>> --
>> Ville Syrjälä
>> Intel
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On Tue, Sep 06, 2022 at 03:57:37PM +0200, Andrzej Hajda wrote: > > > On 06.09.2022 13:22, Ville Syrjälä wrote: > > On Tue, Sep 06, 2022 at 01:09:16PM +0200, Andrzej Hajda wrote: > >> > >> On 05.09.2022 19:44, Ville Syrjälä wrote: > >>> On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote: > On 05.09.2022 13:48, Ville Syrjälä wrote: > > On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote: > >> In case of ICL and older generations disabling plane and/or disabling > >> async update is always performed on vblank, > > It should only be broken on bdw-glk (see. need_async_flip_disable_wa). > On CFL it is reported every drmtip run: > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402 > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402 > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > ... > On APL it is less frequent, probably due to other bugs preventing run of > this test, last seen at: > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > Similar for SKL: > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > I am not sure if I correctly read the docs but [1] says that 9th bit of > PLANE_CFG (Async Address Update Enable) is "not double buffered and the > changes will apply immediately" only for ICL, JSL, LKF1. > >>> It got broken in bdw and fixed again in icl. > >>> > So the change is not necessary in case of icl_plane_disable_arm. > > [1]: https://gfxspecs.intel.com/Predator/Home/Index/7656 > >> but if async update is enabled > >> PLANE_SURF register is updated asynchronously. Writing 0 to PLANE_SURF > >> when plane is still enabled can cause DMAR/PIPE errors. > >> On the other side PLANE_SURF is used to arm plane registers - we need > >> to > >> write to it to trigger update on VBLANK, writting current value should > >> be safe - the buffer address is valid till vblank. > > I think you're effectively saying that somehow the async > > flip disable w/a is not kicking in sometimes. > I was not aware of existence of this w/a and I am little lost in > figuring out how this w/a can prevent zeroing PLANE_SURF too early. > >>> When it works as designed it should: > >>> 1. turn off the async flip bit > >>> 2. wait for vblank so that gets latched > >>> 3. do the sync plane update/disable normally > >> After debugging this terra incognita, I've figured out that plane states > >> are not populated in intel_crtc_async_flip_disable_wa > >> so for_each_old_intel_plane_in_state does not iterate over affected > >> planes and w/a does not work at all. > >> I have no idea where affected plane states should be added. > >> Adding them to the beginning of intel_atomic_check helped, but this is > >> just blind shot: > >> > >> @@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device > >> *dev, > >> new_crtc_state->uapi.mode_changed = true; > >> > >> if (new_crtc_state->uapi.scaling_filter != > >> old_crtc_state->uapi.scaling_filter) > >> new_crtc_state->uapi.mode_changed = true; > >> + > >> + ret = intel_atomic_add_affected_planes(state, crtc); > >> + if (ret) > >> + goto fail; > >> } > >> > >> intel_vrr_check_modeset(state); > >> > >> ret = drm_atomic_helper_check_modeset(dev, >base); > >^ > > This guy should be adding them for any crtc that has been flagged > > for modeset ahead of time. For modesets flagged later we have to > > add them by hand (eg. in intel_modeset_all_pipes()). > > This is no-modeset scenario, drm_atomic_helper_check_modeset does not > add planes in this case. Then he mystery is how intel_crtc_async_flip_disable_wa() manages to not disable async flip for some planes... -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 4/6] drm/i915/debugfs: Add perf_limit_reasons in debugfs
On Fri, Sep 02, 2022 at 04:53:00PM -0700, Ashutosh Dixit wrote:
> From: Tilak Tangudu
>
> Add perf_limit_reasons in debugfs. Unlike the lower 16 perf_limit_reasons
> status bits, the upper 16 log bits remain set until cleared, thereby
> ensuring the throttling occurrence is not missed. The clear fop clears
> the upper 16 log bits, the get fop gets all 32 log and status bits.
>
> Signed-off-by: Tilak Tangudu
> ---
> drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 27 +++
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> index 108b9e76c32e..5c95cba5e5df 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> @@ -655,6 +655,32 @@ static bool rps_eval(void *data)
>
> DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(rps_boost);
>
> +static int perf_limit_reasons_get(void *data, u64 *val)
> +{
> + struct intel_gt *gt = data;
> + intel_wakeref_t wakeref;
> +
> + with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> + *val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS);
> +
> + return 0;
> +}
> +
> +static int perf_limit_reasons_clear(void *data, u64 val)
> +{
> + struct intel_gt *gt = data;
> + intel_wakeref_t wakeref;
> +
> + /* Clear the upper 16 log bits, the lower 16 status bits are read-only
> */
> + with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> + intel_uncore_rmw(gt->uncore, GT0_PERF_LIMIT_REASONS,
> + GT0_PERF_LIMIT_REASONS_LOG_MASK, 0);
> +
> + return 0;
> +}
> +DEFINE_SIMPLE_ATTRIBUTE(perf_limit_reasons_fops, perf_limit_reasons_get,
> + perf_limit_reasons_clear, "%llu\n");
> +
> void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
> {
> static const struct intel_gt_debugfs_file files[] = {
> @@ -664,6 +690,7 @@ void intel_gt_pm_debugfs_register(struct intel_gt *gt,
> struct dentry *root)
> { "forcewake_user", _user_fops, NULL},
> { "llc", _fops, llc_eval },
> { "rps_boost", _boost_fops, rps_eval },
> + { "perf_limit_reasons", _limit_reasons_fops, NULL },
> };
>
> intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 5e6239864c35..10126995e1f6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1802,6 +1802,7 @@
> #define POWER_LIMIT_4_MASK REG_BIT(9)
> #define POWER_LIMIT_1_MASK REG_BIT(11)
> #define POWER_LIMIT_2_MASK REG_BIT(12)
> +#define GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16)
Is this valid for all platforms?
What does the bits are really telling us?
Could we expand the reasons? The previous bits we know exactly
what kind of limits we are dealing of, but with this combined
one without any explanation I'm afraid this will bring more
confusion than help. We will get bugged by many folks trying
to debug this out there when bit 13, for instance, is set.
"What does bit 13 mean?" will be a recurrent question with
only a tribal knowledge kind of answer.
>
> #define CHV_CLK_CTL1 _MMIO(0x101100)
> #define VLV_CLK_CTL2 _MMIO(0x101104)
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Prepare more multi-GT initialization
On Fri, Sep 02, 2022 at 04:52:57PM -0700, Ashutosh Dixit wrote:
> From: Matt Roper
>
> We're going to introduce an additional intel_gt for MTL's media unit
> soon. Let's provide a bit more multi-GT initialization framework in
> preparation for that. The initialization will pull the list of GTs for
> a platform from the device info structure. Although necessary for the
> immediate MTL media enabling, this same framework will also be used
> farther down the road when we enable remote tiles on xehpsdv and pvc.
>
> v2:
> - Re-add missing test for !HAS_EXTRA_GT_LIST in intel_gt_probe_all().
>
> Cc: Aravind Iddamsetty
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_gt.c| 54 ---
> drivers/gpu/drm/i915/gt/intel_gt.h| 1 -
> drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/intel_device_info.h | 16 ++
> .../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
> 7 files changed, 70 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 275ad72940c1..41acc285e8bf 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -736,7 +736,7 @@ static intel_engine_mask_t init_engine_mask(struct
> intel_gt *gt)
> u16 vdbox_mask;
> u16 vebox_mask;
>
> - info->engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
> + GEM_BUG_ON(!info->engine_mask);
>
> if (GRAPHICS_VER(i915) < 11)
> return info->engine_mask;
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index e4bac2431e41..5b4263c708cc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -815,20 +815,16 @@ static void
> intel_gt_tile_cleanup(struct intel_gt *gt)
> {
> intel_uncore_cleanup_mmio(gt->uncore);
> -
> - if (!gt_is_root(gt)) {
> - kfree(gt->uncore->debug);
> - kfree(gt->uncore);
> - kfree(gt);
> - }
In this patch I see less free...
> }
>
> int intel_gt_probe_all(struct drm_i915_private *i915)
> {
> struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> struct intel_gt *gt = >gt0;
> + const struct intel_gt_definition *gtdef;
> phys_addr_t phys_addr;
> unsigned int mmio_bar;
> + unsigned int i;
> int ret;
>
> mmio_bar = GRAPHICS_VER(i915) == 2 ? GEN2_GTTMMADR_BAR : GTTMMADR_BAR;
> @@ -839,14 +835,58 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
>* and it has been already initialized early during probe
>* in i915_driver_probe()
>*/
> + gt->i915 = i915;
> + gt->name = "Primary GT";
> + gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
> +
> + drm_dbg(>drm, "Setting up %s\n", gt->name);
> ret = intel_gt_tile_setup(gt, phys_addr);
> if (ret)
> return ret;
>
> i915->gt[0] = gt;
>
> - /* TODO: add more tiles */
> + if (!HAS_EXTRA_GT_LIST(i915))
> + return 0;
> +
> + for (i = 1, gtdef = _INFO(i915)->extra_gt_list[i - 1];
> + gtdef->setup != NULL;
> + i++, gtdef = _INFO(i915)->extra_gt_list[i - 1]) {
> + gt = drmm_kzalloc(>drm, sizeof(*gt), GFP_KERNEL);
... and more allocs...
it probably deserves some smaller patches with some explanations?
or something is indeed missing here?
> + if (!gt) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + gt->i915 = i915;
> + gt->name = gtdef->name;
> + gt->type = gtdef->type;
> + gt->info.engine_mask = gtdef->engine_mask;
> + gt->info.id = i;
> +
> + drm_dbg(>drm, "Setting up %s\n", gt->name);
> + if (GEM_WARN_ON(range_overflows_t(resource_size_t,
> + gtdef->mapping_base,
> + SZ_16M,
> + pci_resource_len(pdev,
> mmio_bar {
> + ret = -ENODEV;
> + goto err;
> + }
> +
> + ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);
> + if (ret)
> + goto err;
> +
> + i915->gt[i] = gt;
> + }
> +
> return 0;
> +
> +err:
> + i915_probe_error(i915, "Failed to initialize %s! (%d)\n", gtdef->name,
> ret);
> + intel_gt_release_all(i915);
> +
> + return ret;
> }
>
> int intel_gt_tiles_init(struct drm_i915_private *i915)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index 40b06adf509a..4d8779529cc2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
>
Re: [Intel-gfx] [PATCH 5/5] drm/i915: split out i915_gem.c declarations to i915_gem.h
On Mon, 05 Sep 2022, Tvrtko Ursulin wrote: > On 05/09/2022 16:00, Jani Nikula wrote: >> +/* FIXME: All of the below belong somewhere else. */ > > For the series: > > Reviewed-by: Tvrtko Ursulin Thanks, pushed to drm-intel-next. > ((( > I think historically i915_gem.h started as a stash for random bits which > felt obviously wrong to put elsewhere, but it should be fine to > "upgrade" it to a more important status now that you are working on > cleaning things up, especially i915_drv.h. > > Where this "somewhere else" place could be is a bit tricky - I suspect > there isn't any great urgency to re-home them. If one day splitting > i915_gem.c into functional parts comes on the agenda so I guess then. > But it's not that huge even so don't think it's top priority. > ))) Mostly it's a bunch of debug/trace helpers that perhaps shouldn't have been called GEM_ anything to begin with. i915_debug.h? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On 06.09.2022 13:22, Ville Syrjälä wrote: On Tue, Sep 06, 2022 at 01:09:16PM +0200, Andrzej Hajda wrote: On 05.09.2022 19:44, Ville Syrjälä wrote: On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote: On 05.09.2022 13:48, Ville Syrjälä wrote: On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote: In case of ICL and older generations disabling plane and/or disabling async update is always performed on vblank, It should only be broken on bdw-glk (see. need_async_flip_disable_wa). On CFL it is reported every drmtip run: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402 https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402 https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html ... On APL it is less frequent, probably due to other bugs preventing run of this test, last seen at: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html Similar for SKL: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html I am not sure if I correctly read the docs but [1] says that 9th bit of PLANE_CFG (Async Address Update Enable) is "not double buffered and the changes will apply immediately" only for ICL, JSL, LKF1. It got broken in bdw and fixed again in icl. So the change is not necessary in case of icl_plane_disable_arm. [1]: https://gfxspecs.intel.com/Predator/Home/Index/7656 but if async update is enabled PLANE_SURF register is updated asynchronously. Writing 0 to PLANE_SURF when plane is still enabled can cause DMAR/PIPE errors. On the other side PLANE_SURF is used to arm plane registers - we need to write to it to trigger update on VBLANK, writting current value should be safe - the buffer address is valid till vblank. I think you're effectively saying that somehow the async flip disable w/a is not kicking in sometimes. I was not aware of existence of this w/a and I am little lost in figuring out how this w/a can prevent zeroing PLANE_SURF too early. When it works as designed it should: 1. turn off the async flip bit 2. wait for vblank so that gets latched 3. do the sync plane update/disable normally After debugging this terra incognita, I've figured out that plane states are not populated in intel_crtc_async_flip_disable_wa so for_each_old_intel_plane_in_state does not iterate over affected planes and w/a does not work at all. I have no idea where affected plane states should be added. Adding them to the beginning of intel_atomic_check helped, but this is just blind shot: @@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device *dev, new_crtc_state->uapi.mode_changed = true; if (new_crtc_state->uapi.scaling_filter != old_crtc_state->uapi.scaling_filter) new_crtc_state->uapi.mode_changed = true; + + ret = intel_atomic_add_affected_planes(state, crtc); + if (ret) + goto fail; } intel_vrr_check_modeset(state); ret = drm_atomic_helper_check_modeset(dev, >base); ^ This guy should be adding them for any crtc that has been flagged for modeset ahead of time. For modesets flagged later we have to add them by hand (eg. in intel_modeset_all_pipes()). This is no-modeset scenario, drm_atomic_helper_check_modeset does not add planes in this case. Btw, tested your warns from another mail, none appeared. Regards Andrzej For normal plane updates the relevant planes are already added when the property values are updated. Let me know if there is better place/way to handle it. Regards Andrzej
Re: [Intel-gfx] [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
>-Original Message-
>From: dri-devel On Behalf Of
>Matt Roper
>Sent: Friday, September 2, 2022 7:33 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: dri-de...@lists.freedesktop.org; Sripada, Radhakrishna
>
>Subject: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into
>mmio_debug_{suspend, resume}
>
>Moving the locking for MMIO debug (and the final check for unclaimed
>accesses when resuming debug after a userspace-initiated forcewake) will
>make it simpler to completely skip MMIO debug handling on uncores that
>don't support it in future patches.
>
>Signed-off-by: Matt Roper
>Reviewed-by: Radhakrishna Sripada
>---
> drivers/gpu/drm/i915/intel_uncore.c | 41 +++--
> 1 file changed, 21 insertions(+), 20 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_uncore.c
>b/drivers/gpu/drm/i915/intel_uncore.c
>index 9b81b2543ce2..e717ea55484a 100644
>--- a/drivers/gpu/drm/i915/intel_uncore.c
>+++ b/drivers/gpu/drm/i915/intel_uncore.c
>@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
>intel_uncore_mmio_debug *mmio_debug)
> mmio_debug->unclaimed_mmio_check = 1;
> }
>
>-static void mmio_debug_suspend(struct intel_uncore_mmio_debug
>*mmio_debug)
>+static void mmio_debug_suspend(struct intel_uncore *uncore)
/bike-shedding...
It seems like there has been a tend to name functions with the
_unlocked
postfix when the lock is being taken within the function.
Would this be a reasonable name update for these changes?
M
> {
>- lockdep_assert_held(_debug->lock);
>+ spin_lock(>debug->lock);
>
> /* Save and disable mmio debugging for the user bypass */
>- if (!mmio_debug->suspend_count++) {
>- mmio_debug->saved_mmio_check = mmio_debug-
>>unclaimed_mmio_check;
>- mmio_debug->unclaimed_mmio_check = 0;
>+ if (!uncore->debug->suspend_count++) {
>+ uncore->debug->saved_mmio_check = uncore->debug-
>>unclaimed_mmio_check;
>+ uncore->debug->unclaimed_mmio_check = 0;
> }
>+
>+ spin_unlock(>debug->lock);
> }
>
>-static void mmio_debug_resume(struct intel_uncore_mmio_debug
>*mmio_debug)
>+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
>+
>+static void mmio_debug_resume(struct intel_uncore *uncore)
> {
>- lockdep_assert_held(_debug->lock);
>+ spin_lock(>debug->lock);
>+
>+ if (!--uncore->debug->suspend_count)
>+ uncore->debug->unclaimed_mmio_check = uncore->debug-
>>saved_mmio_check;
>
>- if (!--mmio_debug->suspend_count)
>- mmio_debug->unclaimed_mmio_check = mmio_debug-
>>saved_mmio_check;
>+ if (check_for_unclaimed_mmio(uncore))
>+ drm_info(>i915->drm,
>+ "Invalid mmio detected during user access\n");
>+
>+ spin_unlock(>debug->lock);
> }
>
> static const char * const forcewake_domain_names[] = {
>@@ -677,9 +687,7 @@ void intel_uncore_forcewake_user_get(struct
>intel_uncore *uncore)
> spin_lock_irq(>lock);
> if (!uncore->user_forcewake_count++) {
> intel_uncore_forcewake_get__locked(uncore,
>FORCEWAKE_ALL);
>- spin_lock(>debug->lock);
>- mmio_debug_suspend(uncore->debug);
>- spin_unlock(>debug->lock);
>+ mmio_debug_suspend(uncore);
> }
> spin_unlock_irq(>lock);
> }
>@@ -695,14 +703,7 @@ void intel_uncore_forcewake_user_put(struct
>intel_uncore *uncore)
> {
> spin_lock_irq(>lock);
> if (!--uncore->user_forcewake_count) {
>- spin_lock(>debug->lock);
>- mmio_debug_resume(uncore->debug);
>-
>- if (check_for_unclaimed_mmio(uncore))
>- drm_info(>i915->drm,
>- "Invalid mmio detected during user
>access\n");
>- spin_unlock(>debug->lock);
>-
>+ mmio_debug_resume(uncore);
> intel_uncore_forcewake_put__locked(uncore,
>FORCEWAKE_ALL);
> }
> spin_unlock_irq(>lock);
>--
>2.37.2
[Intel-gfx] ✓ Fi.CI.BAT: success for Move all drivers to a common dma-buf locking convention
== Series Details ==
Series: Move all drivers to a common dma-buf locking convention
URL : https://patchwork.freedesktop.org/series/108187/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12074 -> Patchwork_108187v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/index.html
Participating hosts (44 -> 41)
--
Additional (1): fi-icl-u2
Missing(4): fi-cml-u2 fi-bsw-nick fi-bdw-samus bat-dg2-8
Known issues
Here are the changes found in Patchwork_108187v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-icl-u2: NOTRUN -> [SKIP][1] ([i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][3] -> [DMESG-FAIL][4] ([i915#4528])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-bdw-5557u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][6] ([fdo#111827]) +8 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-icl-u2: NOTRUN -> [SKIP][7] ([i915#4103])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [PASS][8] -> [FAIL][9] ([i915#6298])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-icl-u2: NOTRUN -> [WARN][10] ([i915#6008])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][11] ([fdo#109285])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2: NOTRUN -> [SKIP][12] ([i915#3555])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][13] ([fdo#109295] / [i915#3301])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-blb-e6850: NOTRUN -> [FAIL][14] ([fdo#109271] / [i915#2403] /
[i915#4312])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-blb-e6850/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- {fi-jsl-1}: [INCOMPLETE][15] ([i915#5134]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- {bat-rplp-1}: [INCOMPLETE][17] ([i915#6690]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/bat-rplp-1/igt@i915_selftest@l...@requests.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/bat-rplp-1/igt@i915_selftest@l...@requests.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [FAIL][19] ([fdo#103375]) -> [INCOMPLETE][20]
([i915#5982])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[20]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
== Series Details == Series: drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry. URL : https://patchwork.freedesktop.org/series/108188/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/108188/revisions/1/mbox/ not applied Applying: drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry. error: patch failed: drivers/gpu/drm/i915/gvt/gtt.c:1215 error: drivers/gpu/drm/i915/gvt/gtt.c: patch does not apply error: Did you hand edit your patch? It does not apply to blobs recorded in its index. hint: Use 'git am --show-current-patch=diff' to see the failed patch Using index info to reconstruct a base tree... Patch failed at 0001 drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH] drm/i915: Fix intel_dp_atomic_find_vcpi_slots function
On Tue, Sep 06, 2022 at 03:27:17PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, Sep 06, 2022 at 02:57:34PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 06, 2022 at 01:23:29PM +0300, Stanislav Lisovskiy wrote:
> > > drm_dp_atomic_find_vcpi_slots no longer exists and needs
> > > to be used as drm_dp_atomic_find_time_slots.
> > > Also rename the function itself.
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > Fixes: 7ae5ab441402 ("Extract drm_dp_atomic_find_vcpi_slots cycle to
> > > separate function")
> >
> > The problem only exists in drm-tip. You need to revert the
> > bad merge from rerere-cache and redo it.
> >
> > And please always test build drm-tip after solving merge conflicts!
>
> I would really like to figure out how it did end like that.
>
> Here is the sequence of what I've been doing:
>
> 1) There was a series supposed to be merged which had this new
>change already in place i.e using drm_dp_atomic_find_time_slots.
> 2) Then using dim tools I started pushing according to workflow:
>a) dim update-branches
>b) dim checkout drm-intel-next
>c) wget those series mbox and run dim apply-branch drm-intel-next
> Got conflict: it was complaining about those changes around
> drm_dp_atomic_find_time_slots and after some checking I figured
> out that drm_dp_atomic_find_time_slots doesn't exist anymore.
> Here probably was my bad, as I wrongly assumed that those changes
> were probably reverted as it was also mentioned, that there was
> regression because of those.
>
> So I resolved this conflict by putting drm_dp_atomic_find_vcpi_slots
> back instead of drm_dp_atomic_find_time_slots _and_ actually
> built it even.
>
>d) I run dim push-branch drm-intel-next, it did complain about merge
> conflict again with drm-intel-next which I fixed and results were
> pushed.
> I should have build at this moment as well probably.
Yes. You didn't resolve the conflict correctly, thus the build failure.
--
Ville Syrjälä
Intel
