[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Acquire locks with interrupts disabled
== Series Details == Series: drm/i915: Acquire locks with interrupts disabled URL : https://patchwork.freedesktop.org/series/67280/ State : success == Summary == CI Bug Log - changes from CI_DRM_6963_full -> Patchwork_14552_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14552_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-apl1/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/shard-apl8/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb8/igt@gem_exec_as...@concurrent-writes-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/shard-iclb4/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +13 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb1/igt@gem_exec_sched...@independent-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/shard-iclb3/igt@gem_exec_sched...@independent-bsd2.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#105363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl10/igt@kms_f...@flip-vs-expired-vblank.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/shard-skl3/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#103191]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl10/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/shard-skl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-kbl: [PASS][15] -> [INCOMPLETE][16] ([fdo#103665]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [fdo#110403]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103166]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb3/igt@kms_plane_low...@pipe-a-tiling-x.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/shard-iclb1/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/shard-iclb1/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_setmode@basic: - shard-apl: [PASS][23] -> [FAIL][24] ([fdo#99912]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-apl1/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/shard-apl8/igt@kms_setm...@basic.html Possible fixes * igt@drm_import_export@import-close-
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Fix doc not corresponding to code
On Thu, 26 Sep 2019, Anna Karas wrote:
> Replace PLLs names used in documentation to that used in the code.
>
> Cc: Vandita Kulkarni
> Fixes: commit d0570414f3d1 ("drm/i915/tgl: Add new pll ids")
> Signed-off-by: Anna Karas
If the previous version of your patch received Reviewed-by's, and your
patch does not change substantially, please include the Reviewed-by tags
in the new versions. (No need to repost just to add those.)
BR,
Jani.
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> index e7588799fce5..104cf6d42333 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> @@ -147,11 +147,11 @@ enum intel_dpll_id {
>*/
> DPLL_ID_ICL_MGPLL4 = 6,
> /**
> - * @DPLL_ID_TGL_TCPLL5: TGL TC PLL port 5 (TC5)
> + * @DPLL_ID_TGL_MGPLL5: TGL TC PLL port 5 (TC5)
>*/
> DPLL_ID_TGL_MGPLL5 = 7,
> /**
> - * @DPLL_ID_TGL_TCPLL6: TGL TC PLL port 6 (TC6)
> + * @DPLL_ID_TGL_MGPLL6: TGL TC PLL port 6 (TC6)
>*/
> DPLL_ID_TGL_MGPLL6 = 8,
> };
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update references to previously renamed files
Am 26.09.19 um 16:32 schrieb Anna Karas: > Update references to reservation.c and reservation.h since these files > have been renamed to dma-resv.c and dma-resv.h respectively. The subject line is wrong since this isn't a i915 related patch, but apart from that it looks good to me. Regards, Christian. > > Cc: Christian König > Link: https://patchwork.freedesktop.org/patch/323401/?series=65037&rev=1 > Signed-off-by: Anna Karas > --- > Documentation/driver-api/dma-buf.rst | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/Documentation/driver-api/dma-buf.rst > b/Documentation/driver-api/dma-buf.rst > index b541e97c7ab1..c78db28519f7 100644 > --- a/Documentation/driver-api/dma-buf.rst > +++ b/Documentation/driver-api/dma-buf.rst > @@ -118,13 +118,13 @@ Kernel Functions and Structures Reference > Reservation Objects > --- > > -.. kernel-doc:: drivers/dma-buf/reservation.c > +.. kernel-doc:: drivers/dma-buf/dma-resv.c > :doc: Reservation Object Overview > > -.. kernel-doc:: drivers/dma-buf/reservation.c > +.. kernel-doc:: drivers/dma-buf/dma-resv.c > :export: > > -.. kernel-doc:: include/linux/reservation.h > +.. kernel-doc:: include/linux/dma-resv.h > :internal: > > DMA Fences ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: Fix use of kernel-doc format in structure members
== Series Details == Series: drm/i915/perf: Fix use of kernel-doc format in structure members URL : https://patchwork.freedesktop.org/series/67282/ State : success == Summary == CI Bug Log - changes from CI_DRM_6963_full -> Patchwork_14554_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14554_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#104108]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl8/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/shard-skl4/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_double_irq_loop: - shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb8/igt@gem_double_irq_loop.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/shard-iclb7/igt@gem_double_irq_loop.html * igt@gem_exec_blt@dumb-buf-min: - shard-apl: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-apl3/igt@gem_exec_...@dumb-buf-min.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/shard-apl3/igt@gem_exec_...@dumb-buf-min.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +10 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb1/igt@gem_exec_sched...@independent-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/shard-iclb7/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@pi-ringfull-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#111325]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb8/igt@gem_exec_sched...@pi-ringfull-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/shard-iclb4/igt@gem_exec_sched...@pi-ringfull-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-apl6/igt@gem_workarou...@suspend-resume-context.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/shard-apl1/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rpm@system-suspend: - shard-kbl: [PASS][13] -> [INCOMPLETE][14] ([fdo#103665] / [fdo#107807]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-kbl7/igt@i915_pm_...@system-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/shard-kbl2/igt@i915_pm_...@system-suspend.html * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic: - shard-snb: [PASS][15] -> [SKIP][16] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-snb2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/shard-snb6/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#105363]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/shard-skl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html - shard-glk: [PASS][19] -> [FAIL][20] ([fdo#105363]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-glk9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/shard-glk5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-render.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-render.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103166]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb3/igt@kms_plane_low...@pipe-a-tiling-x.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][25] -> [FAIL][26] ([fdo#108341]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963
Re: [Intel-gfx] [PATCH V2 5/8] mdev: introduce device specific ops
On 2019/9/25 下午10:11, Rob Miller wrote:
> > mdev_set_class_id(mdev, MDEV_ID_VFIO);
> > + mdev_set_dev_ops(mdev, &intel_vfio_vgpu_dev_ops);
>
> This seems rather unrefined. We're registering interdependent data in
> separate calls. All drivers need to make both of these calls. I'm not
> sure if this is a good idea, but what if we had:
>
> static const struct vfio_mdev_device_ops intel_vfio_vgpu_dev_ops = {
> .id = MDEV_ID_VFIO,
> .open = intel_vgpu_open,
> .release = intel_vgpu_release,
> ...
>
> And the set function passed &intel_vfio_vgpu_dev_ops.id
and the mdev
> bus drivers used container_of to get to their callbacks?
or just make it explicit? e.g.
mdev_set_class(mdev, MDEV_ID_VFIO, &intel_vfio_vgpu_dev_ops);
Yes, this seems even better.
Will do this in V3.
Thanks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/23] drm/i915: Enable big joiner support in enable and disable sequences.
Op 27-09-2019 om 01:54 schreef Matt Roper:
> On Wed, Sep 25, 2019 at 10:18:19PM -0700, Matt Roper wrote:
>> On Fri, Sep 20, 2019 at 01:42:24PM +0200, Maarten Lankhorst wrote:
>>> Make vdsc work when no output is enabled. The big joiner needs VDSC
>>> on the slave, so enable it and set the appropriate bits.
>>> Also update timestamping constants, because slave crtc's are not
>>> updated in drm_atomic_helper_update_legacy_modeset_state().
>>>
>>> This should be enough to bring up CRTC's in a big joiner configuration,
>>> without any plane configuration on the second pipe yet.
>>>
>>> HOWEVER, we bring up the crtc's in the wrong order. We need to make
>>> sure that the master crtc is brought up after the slave crtc, we
>>> don't do that yet. This is done correctly later in this series.
>>>
>>> The next steps are to add atomic commit, and make sure we enable and
>>> update both master and slave in the correct order.
>>>
>>> Signed-off-by: Maarten Lankhorst
>> A couple minor comments inline below, but I didn't see any clear
>> problems with this patch so
>>
>> Acked-by: Matt Roper
>>
>> However there's a lot of pretty complicated changes here in areas that
>> I'm only vaguely familiar with, so I think it would be good if someone
>> like Manasi who's more familiar with this area of the code could look it
>> over.
>>
>>
>> Matt
>>
>>
>>> ---
>>> drivers/gpu/drm/i915/display/intel_ddi.c | 55 ++-
>>> drivers/gpu/drm/i915/display/intel_display.c | 402 --
>>> .../drm/i915/display/intel_display_types.h| 17 +
>>> drivers/gpu/drm/i915/display/intel_dp.c | 18 +-
>>> drivers/gpu/drm/i915/display/intel_vdsc.c | 122 --
>>> drivers/gpu/drm/i915/display/intel_vdsc.h | 2 +
>>> 6 files changed, 418 insertions(+), 198 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
>>> b/drivers/gpu/drm/i915/display/intel_ddi.c
>>> index c775fd205915..a26155f90261 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>>> @@ -1694,6 +1694,13 @@ static void intel_ddi_clock_get(struct intel_encoder
>>> *encoder,
>>> skl_ddi_clock_get(encoder, pipe_config);
>>> else if (INTEL_GEN(dev_priv) <= 8)
>>> hsw_ddi_clock_get(encoder, pipe_config);
>>> +
>>> + if (pipe_config->bigjoiner) {
>>> + pipe_config->hw.transcoder_mode.crtc_clock =
>>> + pipe_config->hw.adjusted_mode.crtc_clock;
>>> +
>>> + pipe_config->hw.adjusted_mode.crtc_clock /= 2;
>>> + }
>>> }
>>>
>>> void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
>>> @@ -2176,13 +2183,6 @@ static void intel_ddi_get_power_domains(struct
>>> intel_encoder *encoder,
>>> intel_phy_is_tc(dev_priv, phy))
>>> intel_display_power_get(dev_priv,
>>>
>>> intel_ddi_main_link_aux_domain(dig_port));
>>> -
>>> - /*
>>> -* VDSC power is needed when DSC is enabled
>>> -*/
>>> - if (crtc_state->dsc_params.compression_enable)
>>> - intel_display_power_get(dev_priv,
>>> - intel_dsc_power_domain(crtc_state));
>>> }
>>>
>>> void intel_ddi_enable_pipe_clock(const struct intel_crtc_state *crtc_state)
>>> @@ -3290,7 +3290,8 @@ static void tgl_ddi_pre_enable_dp(struct
>>> intel_encoder *encoder,
>>>
>>> /* 7.l */
>>> intel_ddi_enable_fec(encoder, crtc_state);
>>> - intel_dsc_enable(encoder, crtc_state);
>>> + if (!crtc_state->bigjoiner)
>>> + intel_dsc_enable(encoder, crtc_state);
>>> }
>>>
>>> static void hsw_ddi_pre_enable_dp(struct intel_encoder *encoder,
>>> @@ -3361,7 +3362,8 @@ static void hsw_ddi_pre_enable_dp(struct
>>> intel_encoder *encoder,
>>> if (!is_mst)
>>> intel_ddi_enable_pipe_clock(crtc_state);
>>>
>>> - intel_dsc_enable(encoder, crtc_state);
>>> + if (!crtc_state->bigjoiner)
>>> + intel_dsc_enable(encoder, crtc_state);
>>> }
>>>
>>> static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
>>> @@ -3972,19 +3974,18 @@ void intel_ddi_compute_min_voltage_level(struct
>>> drm_i915_private *dev_priv,
>>> crtc_state->min_voltage_level = 2;
>>> }
>>>
>>> -void intel_ddi_get_config(struct intel_encoder *encoder,
>>> - struct intel_crtc_state *pipe_config)
>>> +static void intel_ddi_read_func_ctl(struct intel_encoder *encoder,
>>> + struct intel_crtc_state *pipe_config)
>>> {
>>> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>>> struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->uapi.crtc);
>>> enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
>>> u32 temp, flags = 0;
>>>
>>> - /* XXX: DSI transcoder paranoia */
>>> - if (WARN_ON(transcoder_is_dsi(cpu_transcoder)))
>>> + temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
>>> + if (!(temp & TRANS_DDI_FUNC_ENABLE))
Re: [Intel-gfx] [PATCH 19/27] drm/i915: Replace hangcheck by heartbeats
Quoting Chris Wilson (2019-09-25 13:01:29)
> Replace sampling the engine state every so often with a periodic
> heartbeat request to measure the health of an engine. This is coupled
> with the forced-preemption to allow long running requests to survive so
> long as they do not block other users.
>
> v2: Couple in sysfs controls
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> Cc: Jon Bloomfield
> Reviewed-by: Jon Bloomfield
> +++ b/drivers/gpu/drm/i915/Kconfig.profile
> @@ -37,3 +37,14 @@ config DRM_I915_PREEMPT_TIMEOUT
> to execute.
>
> May be 0 to disable the timeout.
> +
> +config DRM_I915_HEARTBEAT_INTERVAL
> + int "Interval between heartbeat pulses (ms)"
> + default 2500 # microseconds
"ms" or "us", pick one?
> + help
> + While active the driver uses a periodic request, a heartbeat, to
> + check the wellness of the GPU and to regularly flush state changes
> + (idle barriers).
> +
> + May be 0 to disable heartbeats and therefore disable automatic GPU
> + hang detection.
Worth to mention this can be overridden from sysfs.
> +static void heartbeat(struct work_struct *wrk)
> +{
> + if (i915_modparams.enable_hangcheck)
> + engine->heartbeat.systole = i915_request_get(rq);
I'd be more inclined to the userspace opt-in for running indefinitely and
getting rid of the modparam completely.
The long workloads might even not pre-empt at desired granularity.
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove begin/finish_crtc_commit, v3.
Op 26-09-2019 om 18:22 schreef Ville Syrjälä:
> On Thu, Sep 26, 2019 at 11:47:25AM +0200, Maarten Lankhorst wrote:
>> This can all be done from the intel_update_crtc function. Split out the
>> pipe update into a separate function, just like is done for the planes.
>> Pull in all the changes done during fastset as well. It makes no sense
>> for it to still exist as a separate function.
>>
>> Changes since v1:
>> - Inline intel_update_pipe_config()
>> Changes since v2:
>> - Add comments suggested by matt.
>> - Reorder commit_pipe_config() to remove all nesting. (Ville, Matt)
>> - Use intel_set_pipe_src_size((). (Matt)
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 206 +--
>> 1 file changed, 95 insertions(+), 111 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index b77574cda648..239e0ca3e3ec 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -136,8 +136,6 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
>> const struct intel_crtc_state *pipe_config);
>> static void chv_prepare_pll(struct intel_crtc *crtc,
>> const struct intel_crtc_state *pipe_config);
>> -static void intel_begin_crtc_commit(struct intel_atomic_state *, struct
>> intel_crtc *);
>> -static void intel_finish_crtc_commit(struct intel_atomic_state *, struct
>> intel_crtc *);
>> static void intel_crtc_init_scalers(struct intel_crtc *crtc,
>> struct intel_crtc_state *crtc_state);
>> static void skylake_pfit_enable(const struct intel_crtc_state *crtc_state);
>> @@ -4409,45 +4407,6 @@ static void icl_set_pipe_chicken(struct intel_crtc
>> *crtc)
>> I915_WRITE(PIPE_CHICKEN(pipe), tmp);
>> }
>>
>> -static void intel_update_pipe_config(const struct intel_crtc_state
>> *old_crtc_state,
>> - const struct intel_crtc_state
>> *new_crtc_state)
>> -{
>> -struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
>> -struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> -
>> -/* drm_atomic_helper_update_legacy_modeset_state might not be called. */
>> -crtc->base.mode = new_crtc_state->uapi.mode;
>> -
>> -/*
>> - * Update pipe size and adjust fitter if needed: the reason for this is
>> - * that in compute_mode_changes we check the native mode (not the pfit
>> - * mode) to see if we can flip rather than do a full mode set. In the
>> - * fastboot case, we'll flip, but if we don't update the pipesrc and
>> - * pfit state, we'll end up with a big fb scanned out into the wrong
>> - * sized surface.
>> - */
>> -
>> -I915_WRITE(PIPESRC(crtc->pipe),
>> - ((new_crtc_state->pipe_src_w - 1) << 16) |
>> - (new_crtc_state->pipe_src_h - 1));
>> -
>> -/* on skylake this is done by detaching scalers */
>> -if (INTEL_GEN(dev_priv) >= 9) {
>> -skl_detach_scalers(new_crtc_state);
>> -
>> -if (new_crtc_state->pch_pfit.enabled)
>> -skylake_pfit_enable(new_crtc_state);
>> -} else if (HAS_PCH_SPLIT(dev_priv)) {
>> -if (new_crtc_state->pch_pfit.enabled)
>> -ironlake_pfit_enable(new_crtc_state);
>> -else if (old_crtc_state->pch_pfit.enabled)
>> -ironlake_pfit_disable(old_crtc_state);
>> -}
>> -
>> -if (INTEL_GEN(dev_priv) >= 11)
>> -icl_set_pipe_chicken(crtc);
>> -}
>> -
>> static void intel_fdi_normal_train(struct intel_crtc *crtc)
>> {
>> struct drm_device *dev = crtc->base.dev;
>> @@ -13739,13 +13698,91 @@ u32 intel_crtc_get_vblank_counter(struct
>> intel_crtc *crtc)
>> return crtc->base.funcs->get_vblank_counter(&crtc->base);
>> }
>>
>> +void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
>> + struct intel_crtc_state *crtc_state)
>> +{
>> +struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> +
>> +if (!IS_GEN(dev_priv, 2))
>> +intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe,
>> true);
>> +
>> +if (crtc_state->has_pch_encoder) {
>> +enum pipe pch_transcoder =
>> +intel_crtc_pch_transcoder(crtc);
>> +
>> +intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder,
>> true);
>> +}
>> +}
>> +
>> +static void commit_pipe_config(struct intel_atomic_state *state,
>> + struct intel_crtc_state *old_crtc_state,
>> + struct intel_crtc_state *new_crtc_state)
>> +{
>> +struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
>> +struct drm_i915_private *dev_priv = to_i915(state->base.dev);
>> +bool modeset = needs_modeset(new_crtc_state);
>> +
>> +if (dev_priv->display.atomic_updat
Re: [Intel-gfx] [PATCH V2 6/8] mdev: introduce virtio device and its device ops
On 2019/9/25 上午7:06, Alex Williamson wrote:
On Tue, 24 Sep 2019 21:53:30 +0800
Jason Wang wrote:
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Signed-off-by: Jason Wang
---
include/linux/mdev.h| 2 +
include/linux/virtio_mdev.h | 145
2 files changed, 147 insertions(+)
create mode 100644 include/linux/virtio_mdev.h
diff --git a/include/linux/mdev.h b/include/linux/mdev.h
index 3414307311f1..73ac27b3b868 100644
--- a/include/linux/mdev.h
+++ b/include/linux/mdev.h
@@ -126,6 +126,8 @@ struct mdev_device *mdev_from_dev(struct device *dev);
enum {
MDEV_ID_VFIO = 1,
+ MDEV_ID_VIRTIO = 2,
+ MDEV_ID_VHOST = 3,
MDEV_ID_VHOST isn't used yet here. Also, given the strong
interdependence between the class_id and the ops structure, we might
wand to define them in the same place. Thanks,
Alex
Rethink about this, I believe it's better to define the device ops in
their own headers, and one set of device ops could be used for two
classes (e.g both virtio and vhost). And to avoid a duplicated ID
definition. I tend to keep this in the common mdev.h header.
Thanks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Delegate our irq handler to a thread
On 2019-09-26 16:44:33 [+0100], Chris Wilson wrote: > > It's all edge interrupts -- although for gen2/3 my memory is hazy. But > > the GPU (circa gen6) can generate more than enough interrupts to saturate > > a CPU. > > So everything older than gen5 has MSI disabled it appears and needs > ONESHOT. Also ACPI/PCI-quirks may decide that MSI is broken on the system and disable it. If you end up with a shared handler, you can't mix ONESHOT among the handlers. So either all have that flag set or none of them. In that case you need to provide a tiny primary handler which just disables the IRQ (in the HW) and the threaded handler has to enable it again (at the end of its routine). > -Chris Sebastian ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/23] drm/i915: Program planes in bigjoiner mode.
Op 26-09-2019 om 21:11 schreef Ville Syrjälä: > On Thu, Sep 26, 2019 at 07:09:22PM +0300, Ville Syrjälä wrote: >> On Thu, Sep 26, 2019 at 05:50:05PM +0200, Maarten Lankhorst wrote: >>> Op 26-09-2019 om 15:06 schreef Ville Syrjälä: On Fri, Sep 20, 2019 at 01:42:28PM +0200, Maarten Lankhorst wrote: > Now that we can program planes from the update_slave callback, and > we have done all fb pinning correctly, it's time to program those > planes as well. > > We use the update_slave callback as it allows us to use the > separate states correctly. > > Signed-off-by: Maarten Lankhorst > --- > .../gpu/drm/i915/display/intel_atomic_plane.c | 53 +++ > .../gpu/drm/i915/display/intel_atomic_plane.h | 2 + > drivers/gpu/drm/i915/display/intel_display.c | 4 +- > 3 files changed, 57 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c > index cc088676f0a2..5db091e4ad6a 100644 > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c > @@ -366,6 +366,59 @@ void skl_update_planes_on_crtc(struct > intel_atomic_state *state, > } > } > > +void icl_update_bigjoiner_planes_on_crtc(struct intel_atomic_state > *state, > + struct intel_crtc *crtc) This plane stuff is where things go very much off the rails IMO. Planes should not have to know anything about bigjoiner. They should just have their appropriate hw state and blindly bash it into the hardware. >>> We already need this for planar slave/master, what's the issue exactly? >> That already is too fragile. I don't want this spreading all over >> the driver and coupling everything to the bigjoiner logic. >> >> Here's a crude idea how I think we might avoid this: >> git://github.com/vsyrjala/linux.git uapi_hw_state_split >> >> But I didn't dare boot it yet... > It took a handful extra fixes to get that to boot. But now I at least > get a picture on the screen instead of oopses. > > Fixes pushed to the same branch. > > Looks like still something going wrong with the cursor ioctl though. > I've done a uapi-hw split in my series, is that ok with you? I will do a similar split for planes. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915: Allowed memory region for GEM obj
Each GEM object is initialized with allowed memory regions for
it's migration across memory region.
In future patch we are restricting the memory regions or few objects.
This is developed on top of v3 LMEM series
https://patchwork.freedesktop.org/series/56683/
v2:
dev_priv is retrieved from obj [Chris]
CC: Matthew Auld
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 9 +
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 0f33da5e541d..165ae03c6774 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -51,6 +51,8 @@ void i915_gem_object_free(struct drm_i915_gem_object *obj)
void i915_gem_object_init(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_object_ops *ops)
{
+ struct drm_i915_file_private *dev_priv = to_i915(obj->base.drm);
+
mutex_init(&obj->mm.lock);
spin_lock_init(&obj->vma.lock);
@@ -70,6 +72,8 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
obj->mm.madv = I915_MADV_WILLNEED;
INIT_RADIX_TREE(&obj->mm.get_page.radix, GFP_KERNEL | __GFP_NOWARN);
mutex_init(&obj->mm.get_page.lock);
+
+ obj->memory_regions = INTEL_INFO(dev_priv)->memory_regions;
}
/**
@@ -534,6 +538,11 @@ static int i915_gem_object_region_select(struct
drm_i915_private *dev_priv,
u32 region = uregions_copy[i];
enum intel_region_id id = __region_id(region);
+ if (!(obj->memory_regions & region)) {
+ ret = -EINVAL;
+ continue;
+ }
+
if (id == INTEL_MEMORY_UKNOWN) {
ret = -EINVAL;
goto err;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 7b93450a860b..af5505e0bd0a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -286,6 +286,9 @@ struct drm_i915_gem_object {
/** for phys allocated objects */
struct drm_dma_handle *phys_handle;
+
+ /* Allowed memory regions for this obj to reside in. */
+ u32 memory_regions;
};
static inline struct drm_i915_gem_object *
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915: FB backing gem obj should reside in LMEM
If Local memory is supported by hardware, we want framebuffer backing
gem objects out of local memory.
If local memory is supported and gem object if not from local memory we
migrate the obj into local memory. And once framebuffer is created we
block the migration of the associated object out of local memory.
This is developed on top of v3 LMEM series
https://patchwork.freedesktop.org/series/56683/
v2:
memory regions are correctly assigned to obj->memory_regions [tvrtko]
migration failure is reported as debug log [Tvrtko]
cc: Matthew Auld
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_display.c | 25 +
drivers/gpu/drm/i915/gem/i915_gem_object.c | 58
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +
3 files changed, 61 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1cc74844d3ea..175c01e24c78 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -56,6 +56,8 @@
#include "display/intel_tv.h"
#include "display/intel_vdsc.h"
+#include "gem/i915_gem_object.h"
+
#include "i915_drv.h"
#include "i915_trace.h"
#include "intel_acpi.h"
@@ -15496,6 +15498,11 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_private *dev_priv = to_i915(fb->dev);
+
+ /* removing the FB memory region restriction on obj, if any */
+ intel_fb->front_buffer->obj->memory_regions =
+ INTEL_INFO(dev_priv)->memory_regions;
drm_framebuffer_cleanup(fb);
intel_frontbuffer_put(intel_fb->frontbuffer);
@@ -15543,11 +15550,25 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
{
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct drm_framebuffer *fb = &intel_fb->base;
+ u32 *region_map;
u32 max_stride;
unsigned int tiling, stride;
int ret = -EINVAL;
int i;
+ /* GEM Obj for frame buffer is expected to be in LMEM. */
+ if (HAS_LMEM(dev_priv))
+ if (obj->mm.region->type != INTEL_LMEM) {
+ region_map = &intel_region_map[INTEL_MEMORY_LMEM];
+ ret = i915_gem_object_mem_region_migrate(obj,
+region_map, 1);
+ if (ret) {
+ DRM_DEBUG_KMS("Migration to LMEM Failed(%d)\n",
+ ret);
+ return ret;
+ }
+ }
+
intel_fb->frontbuffer = intel_frontbuffer_get(obj);
if (!intel_fb->frontbuffer)
return -ENOMEM;
@@ -15666,6 +15687,10 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
goto err;
}
+ /* Blocking the migration of gem obj out of LMEM */
+ if (HAS_LMEM(dev_priv))
+ obj->memory_regions = REGION_LMEM;
+
return 0;
err:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 165ae03c6774..b2e692cb18f1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -502,30 +502,11 @@ __region_id(u32 region)
return INTEL_MEMORY_UKNOWN;
}
-static int i915_gem_object_region_select(struct drm_i915_private *dev_priv,
-struct drm_i915_gem_object_param *args,
-struct drm_file *file,
-struct drm_i915_gem_object *obj)
+int i915_gem_object_mem_region_migrate(struct drm_i915_gem_object *obj,
+ u32 *uregions, u32 region_count)
{
+ struct drm_i915_file_private *dev_priv = to_i915(obj->base.drm);
struct intel_context *ce = dev_priv->engine[BCS0]->kernel_context;
- u32 __user *uregions = u64_to_user_ptr(args->data);
- u32 uregions_copy[INTEL_MEMORY_UKNOWN];
- int i, ret;
-
- if (args->size > INTEL_MEMORY_UKNOWN)
- return -EINVAL;
-
- memset(uregions_copy, 0, sizeof(uregions_copy));
- for (i = 0; i < args->size; i++) {
- u32 region;
-
- ret = get_user(region, uregions);
- if (ret)
- return ret;
-
- uregions_copy[i] = region;
- ++uregions;
- }
mutex_lock(&dev_priv->drm.struct_mutex);
ret = i915_gem_object_prepare_move(obj);
@@ -534,8 +515,8 @@ static int i915_gem_object_region_select(struct
drm_i915_private *dev_priv,
goto err;
}
- for (i = 0; i < args-
Re: [Intel-gfx] [PATCH 3/3] drm/i915: FB backing gem obj should reside in LMEM
On 2019-09-26 at 10:13:28 +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-09-26 09:53:03)
> >
> > On 26/09/2019 06:21, Ramalingam C wrote:
> > > If Local memory is supported by hardware, we want framebuffer backing
> > > gem objects out of local memory.
> > >
> > > If local memory is supported and gem object if not from local memory we
> > > migrate the obj into local memory. And once framebuffer is created we
> > > block the migration of the associated object out of local memory.
> > >
> > > This is developed on top of v3 LMEM series
> > > https://patchwork.freedesktop.org/series/56683/
> > >
> > > cc: Matthew Auld
> > > Signed-off-by: Ramalingam C
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 25 +
> > > drivers/gpu/drm/i915/gem/i915_gem_object.c | 58
> > > drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +
> > > 3 files changed, 62 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 1cc74844d3ea..d1921a317066 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -56,6 +56,8 @@
> > > #include "display/intel_tv.h"
> > > #include "display/intel_vdsc.h"
> > >
> > > +#include "gem/i915_gem_object.h"
> > > +
> > > #include "i915_drv.h"
> > > #include "i915_trace.h"
> > > #include "intel_acpi.h"
> > > @@ -15496,6 +15498,10 @@ static void intel_setup_outputs(struct
> > > drm_i915_private *dev_priv)
> > > static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
> > > {
> > > struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> > > + struct drm_i915_private *dev_priv = to_i915(fb->dev);
> > > +
> > > + /* removing the FB memory region restriction on obj, if any */
> > > + intel_fb->front_buffer->obj = INTEL_INFO(dev_priv)->memory_regions;
> >
> > Is this right, assigning bitmask to something called obj?
> >
> > >
> > > drm_framebuffer_cleanup(fb);
> > > intel_frontbuffer_put(intel_fb->frontbuffer);
> > > @@ -15543,11 +15549,26 @@ static int intel_framebuffer_init(struct
> > > intel_framebuffer *intel_fb,
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> > > struct drm_framebuffer *fb = &intel_fb->base;
> > > + u32 *region_map;
> > > u32 max_stride;
> > > unsigned int tiling, stride;
> > > int ret = -EINVAL;
> > > int i;
> > >
> > > + /* GEM Obj for frame buffer is expected to be in LMEM. */
> > > + if (HAS_LMEM(dev_priv))
> > > + if (obj->mm.region->type != INTEL_LMEM) {
> > > + region_map = &intel_region_map[INTEL_MEMORY_LMEM];
> > > + ret = i915_gem_object_mem_region_migrate(dev_priv,
> > > obj,
> > > + region_map,
> > > + 1);
> > > + if (ret) {
> > > + DRM_ERROR("FB migration to LMEM
> > > Failed(%d)\n",
> > > + ret);
> >
> > Probably should be just debug level since it is imaginably user
> > triggerable and not really an error for the kernel as such.
>
> This would be a part of pin_to_display? That's where we do the other
> conversions required for scanout objects.
I will relook through it chris. But I am just wondering when the FB is
created/destroyed itself could we fix/release the memory region required?
-Ram.
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/27] drm/i915: Replace hangcheck by heartbeats
Quoting Joonas Lahtinen (2019-09-27 09:26:52)
> Quoting Chris Wilson (2019-09-25 13:01:29)
> > Replace sampling the engine state every so often with a periodic
> > heartbeat request to measure the health of an engine. This is coupled
> > with the forced-preemption to allow long running requests to survive so
> > long as they do not block other users.
> >
> > v2: Couple in sysfs controls
> >
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
> > Cc: Tvrtko Ursulin
> > Cc: Jon Bloomfield
> > Reviewed-by: Jon Bloomfield
>
>
>
> > +++ b/drivers/gpu/drm/i915/Kconfig.profile
> > @@ -37,3 +37,14 @@ config DRM_I915_PREEMPT_TIMEOUT
> > to execute.
> >
> > May be 0 to disable the timeout.
> > +
> > +config DRM_I915_HEARTBEAT_INTERVAL
> > + int "Interval between heartbeat pulses (ms)"
> > + default 2500 # microseconds
>
> "ms" or "us", pick one?
It began with 'm', close enough when copy'n'paste :)
> > + help
> > + While active the driver uses a periodic request, a heartbeat, to
> > + check the wellness of the GPU and to regularly flush state changes
> > + (idle barriers).
> > +
> > + May be 0 to disable heartbeats and therefore disable automatic GPU
> > + hang detection.
>
> Worth to mention this can be overridden from sysfs.
The idea of setting 0 here is to disable it at compilation and DCE.
But any other value could be overridden...
> > +static void heartbeat(struct work_struct *wrk)
> > +{
>
>
>
> > + if (i915_modparams.enable_hangcheck)
> > + engine->heartbeat.systole = i915_request_get(rq);
>
> I'd be more inclined to the userspace opt-in for running indefinitely and
> getting rid of the modparam completely.
That's a separate challenge. :)
> The long workloads might even not pre-empt at desired granularity.
Indeed, but as that is a qos impact on another user, I would similarly
suggest that opting out of this is akin to setting yourself to be
non-preemptable, ergo a restricted operation.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: FB backing gem obj should reside in LMEM
Quoting Ramalingam C (2019-09-27 10:12:57) > On 2019-09-26 at 10:13:28 +0100, Chris Wilson wrote: > > This would be a part of pin_to_display? That's where we do the other > > conversions required for scanout objects. > > I will relook through it chris. But I am just wondering when the FB is > created/destroyed itself could we fix/release the memory region required? That would be atypical; we generally only restrict the user options while it is attached to HW, and err on the side of laziness. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: FB backing gem obj should reside in LMEM
On 2019-09-27 at 10:26:17 +0100, Chris Wilson wrote: > Quoting Ramalingam C (2019-09-27 10:12:57) > > On 2019-09-26 at 10:13:28 +0100, Chris Wilson wrote: > > > This would be a part of pin_to_display? That's where we do the other > > > conversions required for scanout objects. > > > > I will relook through it chris. But I am just wondering when the FB is > > created/destroyed itself could we fix/release the memory region required? > > That would be atypical; we generally only restrict the user options while > it is attached to HW, and err on the side of laziness. I will explore the pin_to_diplay path. Thanks Chris! -Ram > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Fix doc not corresponding to code (rev2)
== Series Details == Series: drm/i915/tgl: Fix doc not corresponding to code (rev2) URL : https://patchwork.freedesktop.org/series/67088/ State : success == Summary == CI Bug Log - changes from CI_DRM_6963_full -> Patchwork_14555_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14555_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@preempt-queue-contexts-bsd1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +8 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb2/igt@gem_exec_sched...@preempt-queue-contexts-bsd1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/shard-iclb5/igt@gem_exec_sched...@preempt-queue-contexts-bsd1.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb3/igt@gem_exec_sched...@preemptive-hang-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/shard-iclb2/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-apl6/igt@gem_workarou...@suspend-resume-context.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/shard-apl7/igt@gem_workarou...@suspend-resume-context.html * igt@i915_suspend@sysfs-reader: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl8/igt@i915_susp...@sysfs-reader.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/shard-skl2/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#110741]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-apl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/shard-apl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#102670]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb1/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/shard-iclb2/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_flip@plain-flip-ts-check-interruptible: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#100368]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl3/igt@kms_f...@plain-flip-ts-check-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/shard-skl8/igt@kms_f...@plain-flip-ts-check-interruptible.html * igt@kms_flip_tiling@flip-y-tiled: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#108303]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb1/igt@kms_flip_til...@flip-y-tiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/shard-iclb1/igt@kms_flip_til...@flip-y-tiled.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-blt: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-blt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-blt.html * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167] / [fdo#110378]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-rte.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-rte.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#103191]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl10/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/shard-skl6/igt@kms_pipe_crc_ba...@suspend-read-crc-pip
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/3] drm/i915: Create dumb buffer from LMEM (rev3)
== Series Details == Series: series starting with [1/3] drm/i915: Create dumb buffer from LMEM (rev3) URL : https://patchwork.freedesktop.org/series/67259/ State : failure == Summary == Applying: drm/i915: Create dumb buffer from LMEM error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_gem.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915: Create dumb buffer from LMEM When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Exercise concurrent submission to all engines
Chris Wilson writes:
> The simplest and most maximal submission we can do, a thread to submit
> requests unto each engine.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/selftests/i915_request.c | 125 ++
> 1 file changed, 125 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
> b/drivers/gpu/drm/i915/selftests/i915_request.c
> index b3688543ed7d..57cd4180d06c 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_request.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_request.c
> @@ -1062,6 +1062,130 @@ static int live_sequential_engines(void *arg)
> return err;
> }
>
> +static int __live_parallel_engine1(void *arg)
> +{
> + struct intel_engine_cs *engine = arg;
> + IGT_TIMEOUT(end_time);
> + unsigned long count;
> +
> + count = 0;
> + do {
> + struct i915_request *rq;
> + int err;
> +
> + mutex_lock(&engine->i915->drm.struct_mutex);
> + rq = i915_request_create(engine->kernel_context);
> + if (IS_ERR(rq)) {
> + mutex_unlock(&engine->i915->drm.struct_mutex);
> + return PTR_ERR(rq);
> + }
> +
> + i915_request_get(rq);
> + i915_request_add(rq);
> + mutex_unlock(&engine->i915->drm.struct_mutex);
> +
> + err = 0;
> + if (i915_request_wait(rq, 0, HZ / 5) < 0)
> + err = -ETIME;
> + i915_request_put(rq);
> + if (err)
> + return err;
> +
> + count++;
> + } while (!__igt_timeout(end_time, NULL));
> +
> + pr_info("%s: %lu request + sync\n", engine->name, count);
> + return 0;
> +}
> +
> +static int __live_parallel_engineN(void *arg)
> +{
> + struct intel_engine_cs *engine = arg;
> + IGT_TIMEOUT(end_time);
> + unsigned long count;
> +
> + count = 0;
> + do {
> + struct i915_request *rq;
> +
> + mutex_lock(&engine->i915->drm.struct_mutex);
> + rq = i915_request_create(engine->kernel_context);
> + if (IS_ERR(rq)) {
> + mutex_unlock(&engine->i915->drm.struct_mutex);
> + return PTR_ERR(rq);
> + }
> +
> + i915_request_add(rq);
> + mutex_unlock(&engine->i915->drm.struct_mutex);
> +
> + count++;
> + } while (!__igt_timeout(end_time, NULL));
> +
> + pr_info("%s: %lu requests\n", engine->name, count);
> + return 0;
> +}
> +
> +static int live_parallel_engines(void *arg)
> +{
> + struct drm_i915_private *i915 = arg;
> + static int (* const func[])(void *arg) = {
> + __live_parallel_engine1,
> + __live_parallel_engineN,
The ratio of waited vs nonwaited ones is
now up to their competition for access which
did concern me.
But then on the other hand, due to wait,
that thread will end up with lot less
access.
So, I think in the end the pattern will
be mostly unwaited ones with a wait now
and then.
Which was kind of what I was yearning for
so,
Reviewed-by: Mika Kuoppala
> + NULL,
> + };
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> + int (* const *fn)(void *arg);
> + int err = 0;
> +
> + /*
> + * Check we can submit requests to all engines concurrently. This
> + * tests that we load up the system maximally.
> + */
> +
> + for (fn = func; !err && *fn; fn++) {
> + struct task_struct *tsk[I915_NUM_ENGINES] = {};
> + struct igt_live_test t;
> +
> + mutex_lock(&i915->drm.struct_mutex);
> + err = igt_live_test_begin(&t, i915, __func__, "");
> + mutex_unlock(&i915->drm.struct_mutex);
> + if (err)
> + break;
> +
> + for_each_engine(engine, i915, id) {
> + tsk[id] = kthread_run(*fn, engine,
> + "igt/parallel:%s",
> + engine->name);
> + if (IS_ERR(tsk[id])) {
> + err = PTR_ERR(tsk[id]);
> + break;
> + }
> + get_task_struct(tsk[id]);
> + }
> +
> + for_each_engine(engine, i915, id) {
> + int status;
> +
> + if (IS_ERR_OR_NULL(tsk[id]))
> + continue;
> +
> + status = kthread_stop(tsk[id]);
> + if (status && !err)
> + err = status;
> +
> + put_task_struct(tsk[id]);
> + }
> +
> + mutex_lock(&i915->drm.struct_mutex);
> + if (igt_live_test_end(&t))
> + err = -EIO;
> + mutex_unlock(&i915->drm.struct_mutex);
> + }
> +
> + return err;
> +}
> +
>
Re: [Intel-gfx] [PATCH 05/27] drm/i915: Pull i915_vma_pin under the vm->mutex
Quoting Tvrtko Ursulin (2019-09-27 09:47:59) > > On 25/09/2019 11:01, Chris Wilson wrote: > > -int __i915_vma_do_pin(struct i915_vma *vma, > > - u64 size, u64 alignment, u64 flags) > > +static bool try_qad_pin(struct i915_vma *vma, unsigned int flags) > > What does the QAD stand for? quick and dirty [snip] > High level concept looks okay to me, and the low level details as well. > But it is so huge that I cannot guarantee I haven't missed something in > the middle. So for any hypothetical missed thing in that last third, I > put my faith that before release we catch it and fix it. It's such a huge seismic shift, that we will have to make again before too long, that some little detail will have slipped through. All we can do is to hope to capture anything that escapes the many machine months of testing (but was it testing the right thing???) into a regression test to make sure the next wave of changes is better. Plus we can look forward to all the opportunities to optimise the code all over again. :| -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 3/7] drm/i915/tgl: Enable DC3CO state in "DC Off" power well
On Thu, Sep 26, 2019 at 08:26:17PM +0530, Anshuman Gupta wrote:
> Add target_dc_state and tgl_set_target_dc_state() API
> in order to enable DC3CO state with existing DC states.
> target_dc_state will enable/disable the desired DC state in
> DC_STATE_EN reg when "DC Off" power well gets disable/enable.
>
> v2: commit log improvement.
> v3: Used intel_wait_for_register to wait for DC3CO exit. [Imre]
> Used gen9_set_dc_state() to allow/disallow DC3CO. [Imre]
> Moved transcoder psr2 exit line enablement from tgl_allow_dc3co()
> to a appropriate place haswell_crtc_enable(). [Imre]
> Changed the DC3CO power well enabled call back logic as
> recommended in review comments. [Imre]
> v4: Used wait_for_us() instead of intel_wait_for_reg(). [Imre (IRC)]
> v5: using udelay() instead of waiting for DC3CO exit status.
> v6: Fixed minor unwanted change.
> v7: Removed DC3CO powerwell and POWER_DOMAIN_VIDEO.
> v8: Uniform checks by using only target_dc_state instead of allowed_dc_mask
> in "DC off" power well callback. [Imre]
> Adding "DC off" power well id to older platforms. [Imre]
> Removed psr2_deep_sleep flag from tgl_set_target_dc_state. [Imre]
> v9: Used switch case for target DC state in
> gen9_dc_off_power_well_disable(), checking DC3CO state against
> allowed DC mask, using WARN_ON() in
> tgl_set_target_dc_state(). [Imre]
>
> Cc: Jani Nikula
> Cc: Imre Deak
> Cc: Animesh Manna
> Signed-off-by: Anshuman Gupta
> ---
> .../drm/i915/display/intel_display_power.c| 110 --
> .../drm/i915/display/intel_display_power.h| 2 +
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 3 files changed, 104 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 0b685c517bcb..9f787556f80d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -785,6 +785,38 @@ static void gen9_set_dc_state(struct drm_i915_private
> *dev_priv, u32 state)
> dev_priv->csr.dc_state = val & mask;
> }
>
> +static void
> +allowed_dc_mask_to_target_dc_state(struct drm_i915_private *dev_priv)
> +{
> + if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC6)
> + dev_priv->csr.target_dc_state = DC_STATE_EN_UPTO_DC6;
> + else if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC5)
> + dev_priv->csr.target_dc_state = DC_STATE_EN_UPTO_DC5;
> + else
> + dev_priv->csr.target_dc_state = DC_STATE_DISABLE;
> +}
The following can be used in tgl_set_target_dc_state() as well:
static u32
sanitize_target_dc_state(struct drm_i915_private *dev_priv,
u32 target_dc_state)
{
u32 states[] = {
DC_STATE_EN_UPTO_DC6,
DC_STATE_EN_UPTO_DC5,
DC_STATE_EN_DC3CO,
};
int i;
for (i = 0; i < ARRAY_SIZE(states); i++)
if (target_dc_state == states[i] &&
(dev_priv->csr.allowed_dc_mask & states[i]))
return states[i];
return DC_STATE_DISABLE;
}
> +
> +static void tgl_enable_dc3co(struct drm_i915_private *dev_priv)
> +{
> + DRM_DEBUG_KMS("Enabling DC3CO\n");
> + gen9_set_dc_state(dev_priv, DC_STATE_EN_DC3CO);
> +}
> +
> +static void tgl_disable_dc3co(struct drm_i915_private *dev_priv)
> +{
> + u32 val;
> +
> + DRM_DEBUG_KMS("Disabling DC3CO\n");
> + val = I915_READ(DC_STATE_EN);
> + val &= ~DC_STATE_DC3CO_STATUS;
> + I915_WRITE(DC_STATE_EN, val);
> + gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> + /*
> + * Delay of 200us DC3CO Exit time B.Spec 49196
> + */
> + usleep_range(200, 210);
> +}
> +
> static void bxt_enable_dc9(struct drm_i915_private *dev_priv)
> {
> assert_can_enable_dc9(dev_priv);
> @@ -952,7 +984,8 @@ static void bxt_verify_ddi_phy_power_wells(struct
> drm_i915_private *dev_priv)
> static bool gen9_dc_off_power_well_enabled(struct drm_i915_private *dev_priv,
> struct i915_power_well *power_well)
> {
> - return (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0;
> + return ((I915_READ(DC_STATE_EN) & DC_STATE_EN_DC3CO) == 0 &&
> + (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0);
> }
>
> static void gen9_assert_dbuf_enabled(struct drm_i915_private *dev_priv)
> @@ -968,6 +1001,11 @@ static void gen9_disable_dc_states(struct
> drm_i915_private *dev_priv)
> {
> struct intel_cdclk_state cdclk_state = {};
>
> + if (dev_priv->csr.target_dc_state == DC_STATE_EN_DC3CO) {
> + tgl_disable_dc3co(dev_priv);
> + return;
> + }
> +
> gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
>
> dev_priv->display.get_cdclk(dev_priv, &cdclk_state);
> @@ -1000,10 +1038,63 @@ static void gen9_dc_off_power_well
[Intel-gfx] [CI] drm/i915: Extract GT render sleep (rc6) management
From: Andi Shyti
Continuing the theme of breaking intel_pm.c up in a reasonable chunk of
powermanagement utilities, pull out the rc6 setup into its GT handler.
Based on a patch by Chris Wilson.
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20190919143840.20384-1-andi.sh...@intel.com
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt.c| 5 +-
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 92 +-
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 11 +-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +
drivers/gpu/drm/i915/gt/intel_rc6.c | 713
drivers/gpu/drm/i915/gt/intel_rc6.h | 25 +
drivers/gpu/drm/i915/gt/intel_rc6_types.h | 28 +
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 50 ++
drivers/gpu/drm/i915/i915_debugfs.c | 11 +-
drivers/gpu/drm/i915/i915_drv.h | 7 -
drivers/gpu/drm/i915/i915_pmu.c | 9 +-
drivers/gpu/drm/i915/i915_sysfs.c | 4 +-
drivers/gpu/drm/i915/intel_pm.c | 794 +-
drivers/gpu/drm/i915/intel_pm.h | 3 -
.../drm/i915/selftests/i915_live_selftests.h | 1 +
18 files changed, 917 insertions(+), 843 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_rc6.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_rc6.h
create mode 100644 drivers/gpu/drm/i915/gt/intel_rc6_types.h
create mode 100644 drivers/gpu/drm/i915/gt/selftest_gt_pm.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6313e7b4bd78..8d407ff7d59d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -85,6 +85,7 @@ gt-y += \
gt/intel_gt_pm_irq.o \
gt/intel_hangcheck.o \
gt/intel_lrc.o \
+ gt/intel_rc6.o \
gt/intel_renderstate.o \
gt/intel_reset.o \
gt/intel_ringbuffer.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index a11ad4d914ca..cca192ecff8b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -137,7 +137,6 @@ static bool switch_to_kernel_context_sync(struct intel_gt
*gt)
bool i915_gem_load_power_context(struct drm_i915_private *i915)
{
- intel_gt_pm_enable(&i915->gt);
return switch_to_kernel_context_sync(&i915->gt);
}
@@ -188,6 +187,7 @@ void i915_gem_suspend(struct drm_i915_private *i915)
i915_gem_drain_freed_objects(i915);
intel_uc_suspend(&i915->gt.uc);
+ intel_gt_suspend(&i915->gt);
}
static struct drm_i915_gem_object *first_mm_object(struct list_head *list)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index ce61c83d68e9..66fc49b76ea8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -11,6 +11,7 @@
#include "intel_engine_pool.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
+#include "intel_rc6.h"
static int __engine_unpark(struct intel_wakeref *wf)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index eef9bdae8ebb..0e5909ee0657 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -7,6 +7,7 @@
#include "intel_gt.h"
#include "intel_gt_pm.h"
#include "intel_mocs.h"
+#include "intel_rc6.h"
#include "intel_uncore.h"
#include "intel_pm.h"
@@ -369,6 +370,8 @@ int intel_gt_init(struct intel_gt *gt)
if (err)
return err;
+ intel_gt_pm_init(gt);
+
return 0;
}
@@ -387,8 +390,8 @@ void intel_gt_driver_release(struct intel_gt *gt)
{
/* Paranoia: make sure we have disabled everything before we exit. */
intel_gt_pm_disable(gt);
+ intel_gt_pm_fini(gt);
- intel_cleanup_gt_powersave(gt->i915);
intel_gt_fini_scratch(gt);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 2ccf8cacaa0a..42f175d9b98c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -11,6 +11,7 @@
#include "intel_gt.h"
#include "intel_gt_pm.h"
#include "intel_pm.h"
+#include "intel_rc6.h"
#include "intel_wakeref.h"
static void pm_notify(struct intel_gt *gt, int state)
@@ -90,6 +91,16 @@ void intel_gt_pm_init_early(struct intel_gt *gt)
BLOCKING_INIT_NOTIFIER_HEAD(>->pm_notifications);
}
+void intel_gt_pm_init(struct intel_gt *gt)
+{
+ /*
+* Enabling power-management should be "self-healing". If we cannot
+* enable a feature, simply leave it disabled with a notice to the
+* user.
+*/
+ intel_rc6_init(>->rc6);
+}
+
static bool reset_engi
Re: [Intel-gfx] [PATCH 07/27] drm/i915: Coordinate i915_active with its own mutex
On 25/09/2019 11:01, Chris Wilson wrote:
Forgo the struct_mutex serialisation for i915_active, and interpose its
own mutex handling for active/retire.
This is a multi-layered sleight-of-hand. First, we had to ensure that no
active/retire callbacks accidentally inverted the mutex ordering rules,
nor assumed that they were themselves serialised by struct_mutex. More
challenging though, is the rule over updating elements of the active
rbtree. Instead of the whole i915_active now being serialised by
struct_mutex, allocations/rotations of the tree are serialised by the
i915_active.mutex and individual nodes are serialised by the caller
using the i915_timeline.mutex (we need to use nested spinlocks to
interact with the dma_fence callback lists).
The pain point here is that instead of a single mutex around execbuf, we
now have to take a mutex for active tracker (one for each vma, context,
etc) and a couple of spinlocks for each fence update. The improvement in
fine grained locking allowing for multiple concurrent clients
(eventually!) should be worth it in typical loads.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/display/intel_frontbuffer.c | 2 +-
drivers/gpu/drm/i915/display/intel_overlay.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 9 +-
drivers/gpu/drm/i915/gt/intel_context.c | 4 +-
drivers/gpu/drm/i915/gt/intel_engine_pool.c | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 10 +-
drivers/gpu/drm/i915/gt/intel_timeline.c | 7 +-
.../gpu/drm/i915/gt/intel_timeline_types.h| 2 +-
drivers/gpu/drm/i915/gt/selftest_context.c| 16 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 10 +-
.../gpu/drm/i915/gt/selftests/mock_timeline.c | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 3 -
drivers/gpu/drm/i915/i915_active.c| 289 +++-
drivers/gpu/drm/i915/i915_active.h| 319 --
drivers/gpu/drm/i915/i915_active_types.h | 23 +-
drivers/gpu/drm/i915/i915_gem.c | 42 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/i915_request.c | 38 +--
drivers/gpu/drm/i915/i915_request.h | 1 -
drivers/gpu/drm/i915/i915_vma.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 32 +-
24 files changed, 264 insertions(+), 566 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 6428b8dd70d3..84b164f31895 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -257,7 +257,7 @@ intel_frontbuffer_get(struct drm_i915_gem_object *obj)
front->obj = obj;
kref_init(&front->ref);
atomic_set(&front->bits, 0);
- i915_active_init(i915, &front->write,
+ i915_active_init(&front->write,
frontbuffer_active,
i915_active_may_sleep(frontbuffer_retire));
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c b/drivers/gpu/drm/i915/display/intel_overlay.c
index 3f4ac1ee7668..e12e1a753af0 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -1360,8 +1360,7 @@ void intel_overlay_setup(struct drm_i915_private
*dev_priv)
overlay->contrast = 75;
overlay->saturation = 146;
- i915_active_init(dev_priv,
-&overlay->last_flip,
+ i915_active_init(&overlay->last_flip,
NULL, intel_overlay_last_flip_retire);
ret = get_registers(overlay, OVERLAY_NEEDS_PHYSICAL(dev_priv));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 4cd7d2ecf1d5..9d85aab68d34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -868,20 +868,18 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
void (*task)(void *data),
void *data)
{
- struct drm_i915_private *i915 = ctx->i915;
struct context_barrier_task *cb;
struct i915_gem_engines_iter it;
struct intel_context *ce;
int err = 0;
- lockdep_assert_held(&i915->drm.struct_mutex);
GEM_BUG_ON(!task);
cb = kmalloc(sizeof(*cb), GFP_KERNEL);
if (!cb)
return -ENOMEM;
- i915_active_init(i915, &cb->base, NULL, cb_retire);
+ i915_active_init(&cb->base, NULL, cb_retire);
err = i915_active_acquire(&cb->base);
if (err) {
kfree(cb);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index d695f187b
[Intel-gfx] [PATCH] doc: Update references to previously renamed files
Update references to reservation.c and reservation.h since these files have been renamed to dma-resv.c and dma-resv.h respectively. Cc: Christian König Link: https://patchwork.freedesktop.org/patch/323401/?series=65037&rev=1 Signed-off-by: Anna Karas --- Documentation/driver-api/dma-buf.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index b541e97c7ab1..c78db28519f7 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -118,13 +118,13 @@ Kernel Functions and Structures Reference Reservation Objects --- -.. kernel-doc:: drivers/dma-buf/reservation.c +.. kernel-doc:: drivers/dma-buf/dma-resv.c :doc: Reservation Object Overview -.. kernel-doc:: drivers/dma-buf/reservation.c +.. kernel-doc:: drivers/dma-buf/dma-resv.c :export: -.. kernel-doc:: include/linux/reservation.h +.. kernel-doc:: include/linux/dma-resv.h :internal: DMA Fences -- 2.19.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] doc: Update references to previously renamed files
Am 27.09.19 um 13:15 schrieb Anna Karas: > Update references to reservation.c and reservation.h since these files > have been renamed to dma-resv.c and dma-resv.h respectively. > > Cc: Christian König > Link: https://patchwork.freedesktop.org/patch/323401/?series=65037&rev=1 > Signed-off-by: Anna Karas Reviewed-by: Christian König You should also send that to a couple of more mailing list, only CCing intel-gfx is not really appropriate for that code. Leave me a note when you need to get this committed to drm-misc-fixes. Regards, Christian. > --- > Documentation/driver-api/dma-buf.rst | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/Documentation/driver-api/dma-buf.rst > b/Documentation/driver-api/dma-buf.rst > index b541e97c7ab1..c78db28519f7 100644 > --- a/Documentation/driver-api/dma-buf.rst > +++ b/Documentation/driver-api/dma-buf.rst > @@ -118,13 +118,13 @@ Kernel Functions and Structures Reference > Reservation Objects > --- > > -.. kernel-doc:: drivers/dma-buf/reservation.c > +.. kernel-doc:: drivers/dma-buf/dma-resv.c > :doc: Reservation Object Overview > > -.. kernel-doc:: drivers/dma-buf/reservation.c > +.. kernel-doc:: drivers/dma-buf/dma-resv.c > :export: > > -.. kernel-doc:: include/linux/reservation.h > +.. kernel-doc:: include/linux/dma-resv.h > :internal: > > DMA Fences ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915: Define explicit wedged on init reset state
== Series Details == Series: series starting with [CI,1/3] drm/i915: Define explicit wedged on init reset state URL : https://patchwork.freedesktop.org/series/67289/ State : success == Summary == CI Bug Log - changes from CI_DRM_6963_full -> Patchwork_14556_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_6963_full and Patchwork_14556_full: ### New Piglit tests (7) ### * spec@arb_gpu_shader5@texturegather@vs-rgba-2-float-2darray: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader5@texturegather@vs-rgba-3-float-2darray: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader5@texturegatheroffset@vs-rgba-0-float-2darray: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader5@texturegatheroffset@vs-rgba-0-float-2darray-const: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader5@texturegatheroffsets@vs-rgba-1-float-2d: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader5@texturegatheroffsets@vs-rgba-2-float-2d: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader5@texturegatheroffsets@vs-rgba-3-float-2d: - Statuses : 1 incomplete(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_14556_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-glk: [PASS][1] -> [FAIL][2] ([fdo#103375]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-glk5/igt@gem_ctx_isolat...@bcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/shard-glk1/igt@gem_ctx_isolat...@bcs0-s3.html - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#104108]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl1/igt@gem_ctx_isolat...@bcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/shard-skl1/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_ctx_isolation@vecs0-s3: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-apl2/igt@gem_ctx_isolat...@vecs0-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/shard-apl5/igt@gem_ctx_isolat...@vecs0-s3.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110841]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +14 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb1/igt@gem_exec_sched...@independent-bsd2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/shard-iclb3/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#111325]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb7/igt@gem_exec_sched...@reorder-wide-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@kms_flip@dpms-vs-vblank-race-interruptible: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([fdo#103540]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-hsw8/igt@kms_f...@dpms-vs-vblank-race-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/shard-hsw7/igt@kms_f...@dpms-vs-vblank-race-interruptible.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl10/igt@kms_f...@flip-vs-expired-vblank.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/shard-skl6/igt@kms_f...@flip-vs-expired-vblank.html - shard-glk: [PASS][17] -> [FAIL][18] ([fdo#105363]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-glk1/igt@kms_f...@flip-vs-expired-vblank.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/shard-glk5/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html [20]: https://intel-gfx-ci.01.org
Re: [Intel-gfx] [PATCH 07/27] drm/i915: Coordinate i915_active with its own mutex
Quoting Tvrtko Ursulin (2019-09-27 12:10:29)
>
> On 25/09/2019 11:01, Chris Wilson wrote:
> > void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence
> > *f)
> > {
> > /* We expect the caller to manage the exclusive timeline ordering */
> > GEM_BUG_ON(i915_active_is_idle(ref));
> >
> > - dma_fence_get(f);
> > -
> > - rcu_read_lock();
> > - if (rcu_access_pointer(ref->excl)) {
> > - struct dma_fence *old;
> > -
> > - old = dma_fence_get_rcu_safe(&ref->excl);
> > - if (old) {
> > - if (dma_fence_remove_callback(old, &ref->excl_cb))
> > - atomic_dec(&ref->count);
> > - dma_fence_put(old);
> > - }
> > - }
> > - rcu_read_unlock();
> > -
> > - atomic_inc(&ref->count);
> > - rcu_assign_pointer(ref->excl, f);
> > + mutex_acquire(&ref->mutex.dep_map, 0, 0, _THIS_IP_);
> > + if (!__i915_active_fence_set(&ref->excl, f))
> > + atomic_inc(&ref->count);
> > + mutex_release(&ref->mutex.dep_map, 0, _THIS_IP_);
>
> Comment for this block please to explain what's going on.
This was meant to be clued in by the opening comment that the caller is
expected to manage the exclusive timeline. But since the
i915_active_fence debug API requires us to declare what mutex guards
each timeline, we had to fake one.
> > +struct dma_fence *
> > +__i915_active_fence_set(struct i915_active_fence *active,
> > + struct dma_fence *fence)
>
> Can you add a short comment for this function explaining the racyness
> and so why it returns prev and what should the callers do with it?
Before using this function, we had the callers declare what mutex guards
this timeline and we check here that is held.
> > +{
> > + struct dma_fence *prev;
> > + unsigned long flags;
> > +
> > + /* NB: updates must be serialised by an outer timeline mutex */
>
> Can't check here?
We do, see active_is_held()
> > + spin_lock_irqsave(fence->lock, flags);
> > + GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
> > +
> > + prev = rcu_dereference_protected(active->fence,
> > active_is_held(active));
> > + if (prev) {
> > + spin_lock_nested(prev->lock, SINGLE_DEPTH_NESTING);
> > + __list_del_entry(&active->cb.node);
> > + spin_unlock(prev->lock); /* serialise with prev->cb_list */
> > + prev = rcu_access_pointer(active->fence);
> > }
> > +
> > + rcu_assign_pointer(active->fence, fence);
> > + list_add_tail(&active->cb.node, &fence->cb_list);
> > +
> > + spin_unlock_irqrestore(fence->lock, flags);
> > +
> > + return prev;
> > }
> >
> > -int i915_active_request_set(struct i915_active_request *active,
> > - struct i915_request *rq)
> > +int i915_active_fence_set(struct i915_active_fence *active,
> > + struct i915_request *rq)
> > {
> > + struct dma_fence *fence;
> > int err;
> >
> > #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
>
> Here not in diff we actually have:
>
> #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
> lockdep_assert_held(active->lock);
>
> So why only under GEM debug and how does it related to the NB comment in
> __i915_active_fence_set?
We only expand the struct when we want to for debugging.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Extract GT render sleep (rc6) management (rev2)
== Series Details == Series: drm/i915: Extract GT render sleep (rc6) management (rev2) URL : https://patchwork.freedesktop.org/series/66937/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0515efe0e44d drm/i915: Extract GT render sleep (rc6) management -:285: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #285: new file mode 100644 -:290: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #290: FILE: drivers/gpu/drm/i915/gt/intel_rc6.c:1: +/* -:291: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #291: FILE: drivers/gpu/drm/i915/gt/intel_rc6.c:2: + * SPDX-License-Identifier: MIT -:638: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #638: FILE: drivers/gpu/drm/i915/gt/intel_rc6.c:349: + set(uncore, RING_MAX_IDLE(engine->mmio_base), + 10); -:1009: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #1009: FILE: drivers/gpu/drm/i915/gt/intel_rc6.h:1: +/* -:1010: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #1010: FILE: drivers/gpu/drm/i915/gt/intel_rc6.h:2: + * SPDX-License-Identifier: MIT -:1040: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #1040: FILE: drivers/gpu/drm/i915/gt/intel_rc6_types.h:1: +/* -:1041: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #1041: FILE: drivers/gpu/drm/i915/gt/intel_rc6_types.h:2: + * SPDX-License-Identifier: MIT -:1074: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #1074: FILE: drivers/gpu/drm/i915/gt/selftest_gt_pm.c:1: + -:1076: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #1076: FILE: drivers/gpu/drm/i915/gt/selftest_gt_pm.c:3: + * SPDX-License-Identifier: MIT -:1084: WARNING:LINE_SPACING: Missing a blank line after declarations #1084: FILE: drivers/gpu/drm/i915/gt/selftest_gt_pm.c:11: + struct intel_gt *gt = arg; + IGT_TIMEOUT(end_time); total: 0 errors, 10 warnings, 1 checks, 2066 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Extract GT render sleep (rc6) management (rev2)
== Series Details ==
Series: drm/i915: Extract GT render sleep (rc6) management (rev2)
URL : https://patchwork.freedesktop.org/series/66937/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6967 -> Patchwork_14564
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14564/index.html
New tests
-
New tests have been introduced between CI_DRM_6967 and Patchwork_14564:
### New IGT tests (1) ###
* igt@i915_selftest@live_gt_pm:
- Statuses : 42 pass(s)
- Exec time: [1.37, 3.10] s
Known issues
Here are the changes found in Patchwork_14564 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-icl-u2: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] /
[fdo#109100])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6967/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14564/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
* igt@gem_mmap_gtt@basic-write-cpu-read-gtt:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6967/fi-icl-u3/igt@gem_mmap_...@basic-write-cpu-read-gtt.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14564/fi-icl-u3/igt@gem_mmap_...@basic-write-cpu-read-gtt.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- {fi-icl-dsi}: [INCOMPLETE][5] ([fdo#107713] / [fdo#109100]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6967/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14564/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][7] ([fdo#111045] / [fdo#111096]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6967/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14564/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
Participating hosts (51 -> 44)
--
Additional (2): fi-byt-j1900 fi-bsw-n3050
Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-apl-guc fi-ivb-3770 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6967 -> Patchwork_14564
CI-20190529: 20190529
CI_DRM_6967: 8d202fec48337672ef4640a1a1fb4d882335bff4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5206: 5a6c68568def840cd720f18fc66f529a89f84675 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14564: 0515efe0e44ddd3e6af0f0b529c8e593350a29ef @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0515efe0e44d drm/i915: Extract GT render sleep (rc6) management
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14564/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/27] drm/i915: Coordinate i915_active with its own mutex
On 27/09/2019 12:25, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-27 12:10:29)
On 25/09/2019 11:01, Chris Wilson wrote:
void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f)
{
/* We expect the caller to manage the exclusive timeline ordering */
GEM_BUG_ON(i915_active_is_idle(ref));
- dma_fence_get(f);
-
- rcu_read_lock();
- if (rcu_access_pointer(ref->excl)) {
- struct dma_fence *old;
-
- old = dma_fence_get_rcu_safe(&ref->excl);
- if (old) {
- if (dma_fence_remove_callback(old, &ref->excl_cb))
- atomic_dec(&ref->count);
- dma_fence_put(old);
- }
- }
- rcu_read_unlock();
-
- atomic_inc(&ref->count);
- rcu_assign_pointer(ref->excl, f);
+ mutex_acquire(&ref->mutex.dep_map, 0, 0, _THIS_IP_);
+ if (!__i915_active_fence_set(&ref->excl, f))
+ atomic_inc(&ref->count);
+ mutex_release(&ref->mutex.dep_map, 0, _THIS_IP_);
Comment for this block please to explain what's going on.
This was meant to be clued in by the opening comment that the caller is
expected to manage the exclusive timeline. But since the
i915_active_fence debug API requires us to declare what mutex guards
each timeline, we had to fake one.
I think the commentary about duality of which mutex guards things is
only present in the commit message at the moment and it would be really
good to have that somewhere in the code as well. Because after a few
months of refactoring, going from git blame to commits can stop working
so well, and then in code commentary becomes very valuable.
+struct dma_fence *
+__i915_active_fence_set(struct i915_active_fence *active,
+ struct dma_fence *fence)
Can you add a short comment for this function explaining the racyness
and so why it returns prev and what should the callers do with it?
Before using this function, we had the callers declare what mutex guards
this timeline and we check here that is held.
No, I mean because it has to reload prev and return it to the caller,
which implies that is to handle some designed-in racy-ness which I think
should be mentioned.
+{
+ struct dma_fence *prev;
+ unsigned long flags;
+
+ /* NB: updates must be serialised by an outer timeline mutex */
Can't check here?
We do, see active_is_held()
Ack!
+ spin_lock_irqsave(fence->lock, flags);
+ GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
+
+ prev = rcu_dereference_protected(active->fence, active_is_held(active));
+ if (prev) {
+ spin_lock_nested(prev->lock, SINGLE_DEPTH_NESTING);
+ __list_del_entry(&active->cb.node);
+ spin_unlock(prev->lock); /* serialise with prev->cb_list */
+ prev = rcu_access_pointer(active->fence);
}
+
+ rcu_assign_pointer(active->fence, fence);
+ list_add_tail(&active->cb.node, &fence->cb_list);
+
+ spin_unlock_irqrestore(fence->lock, flags);
+
+ return prev;
}
-int i915_active_request_set(struct i915_active_request *active,
- struct i915_request *rq)
+int i915_active_fence_set(struct i915_active_fence *active,
+ struct i915_request *rq)
{
+ struct dma_fence *fence;
int err;
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
Here not in diff we actually have:
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
lockdep_assert_held(active->lock);
So why only under GEM debug and how does it related to the NB comment in
__i915_active_fence_set?
We only expand the struct when we want to for debugging.
Missed that detail, ok.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Update references to previously renamed files
== Series Details ==
Series: drm/i915: Update references to previously renamed files
URL : https://patchwork.freedesktop.org/series/67295/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6963_full -> Patchwork_14558_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_14558_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_eio@kms}:
- shard-snb: [INCOMPLETE][1] ([fdo#105411]) -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-snb7/igt@gem_...@kms.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/shard-snb4/igt@gem_...@kms.html
Known issues
Here are the changes found in Patchwork_14558_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
* igt@gem_eio@reset-stress:
- shard-snb: [PASS][5] -> [FAIL][6] ([fdo#109661])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-snb7/igt@gem_...@reset-stress.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/shard-snb4/igt@gem_...@reset-stress.html
* igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +13 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb1/igt@gem_exec_sched...@independent-bsd2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/shard-iclb8/igt@gem_exec_sched...@independent-bsd2.html
* igt@gem_exec_schedule@preemptive-hang-bsd:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#111325]) +2 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb3/igt@gem_exec_sched...@preemptive-hang-bsd.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/shard-iclb1/igt@gem_exec_sched...@preemptive-hang-bsd.html
* igt@i915_pm_rpm@system-suspend:
- shard-kbl: [PASS][11] -> [INCOMPLETE][12] ([fdo#103665] /
[fdo#107807])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-kbl7/igt@i915_pm_...@system-suspend.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/shard-kbl3/igt@i915_pm_...@system-suspend.html
* igt@kms_atomic_transition@plane-primary-toggle-with-vblank-wait:
- shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb8/igt@kms_atomic_transit...@plane-primary-toggle-with-vblank-wait.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/shard-iclb7/igt@kms_atomic_transit...@plane-primary-toggle-with-vblank-wait.html
* igt@kms_cursor_crc@pipe-c-cursor-64x64-sliding:
- shard-apl: [PASS][15] -> [INCOMPLETE][16] ([fdo#103927])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-apl5/igt@kms_cursor_...@pipe-c-cursor-64x64-sliding.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/shard-apl3/igt@kms_cursor_...@pipe-c-cursor-64x64-sliding.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl: [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +2
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-apl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/shard-apl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: [PASS][19] -> [FAIL][20] ([fdo#105363])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/shard-skl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
* igt@kms_flip@plain-flip-fb-recreate:
- shard-skl: [PASS][21] -> [FAIL][22] ([fdo#100368]) +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl4/igt@kms_f...@plain-flip-fb-recreate.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/shard-skl6/igt@kms_f...@plain-flip-fb-recreate.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt:
- shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103167]) +2 similar
issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-
Re: [Intel-gfx] [PATCH 07/27] drm/i915: Coordinate i915_active with its own mutex
Quoting Tvrtko Ursulin (2019-09-27 13:08:51) > > On 27/09/2019 12:25, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-09-27 12:10:29) > >> > >> On 25/09/2019 11:01, Chris Wilson wrote: > >>> +struct dma_fence * > >>> +__i915_active_fence_set(struct i915_active_fence *active, > >>> + struct dma_fence *fence) > >> > >> Can you add a short comment for this function explaining the racyness > >> and so why it returns prev and what should the callers do with it? > > > > Before using this function, we had the callers declare what mutex guards > > this timeline and we check here that is held. > > No, I mean because it has to reload prev and return it to the caller, > which implies that is to handle some designed-in racy-ness which I think > should be mentioned. But that's not racing with the caller, that just racing with the callback from the interrupt handler and the reason why we have to check after serialising is called out. /* serialise with prev->cb_list */ ? The caller is responsible for ensuring that prev is executed before fence to keep the timeline in the same order as recorded. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Update references to previously renamed files (rev2)
== Series Details ==
Series: drm/i915: Update references to previously renamed files (rev2)
URL : https://patchwork.freedesktop.org/series/67295/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6967 -> Patchwork_14565
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14565/index.html
Known issues
Here are the changes found in Patchwork_14565 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-write-no-prefault:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +2
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6967/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14565/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- {fi-tgl-u2}:[DMESG-WARN][3] ([fdo#111600]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6967/fi-tgl-u2/igt@debugfs_test@read_all_entries.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14565/fi-tgl-u2/igt@debugfs_test@read_all_entries.html
* igt@gem_ctx_create@basic-files:
- {fi-icl-dsi}: [INCOMPLETE][5] ([fdo#107713] / [fdo#109100]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6967/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14565/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [FAIL][7] ([fdo#103167]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6967/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14565/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
Participating hosts (51 -> 46)
--
Additional (2): fi-byt-j1900 fi-bsw-n3050
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6967 -> Patchwork_14565
CI-20190529: 20190529
CI_DRM_6967: 8d202fec48337672ef4640a1a1fb4d882335bff4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5206: 5a6c68568def840cd720f18fc66f529a89f84675 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14565: 2e30cff176dfa656f852e36cd4148367d0d5ac01 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2e30cff176df doc: Update references to previously renamed files
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14565/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/27] drm/i915: Coordinate i915_active with its own mutex
On 27/09/2019 13:16, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-09-27 13:08:51) On 27/09/2019 12:25, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-09-27 12:10:29) On 25/09/2019 11:01, Chris Wilson wrote: +struct dma_fence * +__i915_active_fence_set(struct i915_active_fence *active, + struct dma_fence *fence) Can you add a short comment for this function explaining the racyness and so why it returns prev and what should the callers do with it? Before using this function, we had the callers declare what mutex guards this timeline and we check here that is held. No, I mean because it has to reload prev and return it to the caller, which implies that is to handle some designed-in racy-ness which I think should be mentioned. But that's not racing with the caller, that just racing with the callback from the interrupt handler and the reason why we have to check after serialising is called out. /* serialise with prev->cb_list */ ? The caller is responsible for ensuring that prev is executed before fence to keep the timeline in the same order as recorded. I did not say it is racing with the caller, but that the caller has to handle a race. "Serialise with prev->cb_list" is too low level for me. Trust me, I always struggle with the active tracking code since there is so many indirections and relationships. So in the absence of a visual diagram a higher level comment would be beneficial for the future self. Just expanding on what you replied here talking about how interrupts interacts with new stuff entering tracking would do it. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/27] drm/i915: Coordinate i915_active with its own mutex
Quoting Tvrtko Ursulin (2019-09-27 13:25:23) > > On 27/09/2019 13:16, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-09-27 13:08:51) > >> > >> On 27/09/2019 12:25, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2019-09-27 12:10:29) > > On 25/09/2019 11:01, Chris Wilson wrote: > > +struct dma_fence * > > +__i915_active_fence_set(struct i915_active_fence *active, > > + struct dma_fence *fence) > > Can you add a short comment for this function explaining the racyness > and so why it returns prev and what should the callers do with it? > >>> > >>> Before using this function, we had the callers declare what mutex guards > >>> this timeline and we check here that is held. > >> > >> No, I mean because it has to reload prev and return it to the caller, > >> which implies that is to handle some designed-in racy-ness which I think > >> should be mentioned. > > > > But that's not racing with the caller, that just racing with the > > callback from the interrupt handler and the reason why we have to check > > after serialising is called out. /* serialise with prev->cb_list */ ? > > > > The caller is responsible for ensuring that prev is executed before > > fence to keep the timeline in the same order as recorded. > > I did not say it is racing with the caller, but that the caller has to > handle a race. But the caller only has to care about "was there already an active fence on this timeline? If so, I must make sure it executes before me and take that into consideration for the flow along the timeline" I'm not seeing what race the caller has to be concerned with here. If they replace the last request in the timeline, they have it returned. If there was no request previously in the timeline, they have NULL. (That just seems straightforward.) > "Serialise with prev->cb_list" is too low level for me. Trust me, I > always struggle with the active tracking code since there is so many > indirections and relationships. So in the absence of a visual diagram a > higher level comment would be beneficial for the future self. Just > expanding on what you replied here talking about how interrupts > interacts with new stuff entering tracking would do it. It's just about that the callback may be executing and so we need to serialise the list manipulation under the lock; having performed that list manipulation, we then know whether or not we were successful in capturing the previous fence. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for DC3CO Support for TGL (rev12)
== Series Details == Series: DC3CO Support for TGL (rev12) URL : https://patchwork.freedesktop.org/series/64923/ State : success == Summary == CI Bug Log - changes from CI_DRM_6963_full -> Patchwork_14559_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14559_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vecs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-apl2/igt@gem_ctx_isolat...@vecs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14559/shard-apl6/igt@gem_ctx_isolat...@vecs0-s3.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14559/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +15 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb1/igt@gem_exec_sched...@independent-bsd2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14559/shard-iclb5/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@pi-ringfull-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb8/igt@gem_exec_sched...@pi-ringfull-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14559/shard-iclb4/igt@gem_exec_sched...@pi-ringfull-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103927]) +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-apl6/igt@gem_workarou...@suspend-resume-context.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14559/shard-apl2/igt@gem_workarou...@suspend-resume-context.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#105363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14559/shard-skl9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip_tiling@flip-x-tiled: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#108303]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb1/igt@kms_flip_til...@flip-x-tiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14559/shard-iclb6/igt@kms_flip_til...@flip-x-tiled.html * igt@kms_frontbuffer_tracking@basic: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb3/igt@kms_frontbuffer_track...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14559/shard-iclb4/igt@kms_frontbuffer_track...@basic.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [fdo#110403]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14559/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14559/shard-iclb8/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-apl1/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14559/shard-apl7/igt@kms_setm...@basic.html * igt@tools_test@tools_test: - shard-hsw: [PASS][23] -> [SKIP][24] ([fdo#109271]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-hsw6/igt@tools_test@tools_test.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14559/shard-hsw1/igt@tools_test@tools_test.html Possible fixes * igt@drm_import_export@import-close-race-flink: - shard-hsw: [INCOMPLETE][25] ([fdo#103540]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/shard-hsw1/igt@drm_import_exp...@import-close-race-flin
[Intel-gfx] [PATCH 2/5] drm/i915: Prepare the connector/encoder mask eadout for hw vs. uapi state split
From: Ville Syrjälä
Prepare the connector/encoder mask readout for the uapi vs. hw
state split. We'll want to do all readout into the hw state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8a2e780d85e1..9d4dfe2eace0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16795,24 +16795,28 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
drm_connector_list_iter_begin(dev, &conn_iter);
for_each_intel_connector_iter(connector, &conn_iter) {
if (connector->get_hw_state(connector)) {
+ struct intel_crtc_state *crtc_state;
+ struct intel_crtc *crtc;
+
connector->base.dpms = DRM_MODE_DPMS_ON;
encoder = connector->encoder;
connector->base.encoder = &encoder->base;
- if (encoder->base.crtc &&
- encoder->base.crtc->state->active) {
+ crtc = to_intel_crtc(encoder->base.crtc);
+ crtc_state = crtc ?
to_intel_crtc_state(crtc->base.state) : NULL;
+
+ if (crtc_state && crtc_state->base.active) {
/*
* This has to be done during hardware readout
* because anything calling .crtc_disable may
* rely on the connector_mask being accurate.
*/
- encoder->base.crtc->state->connector_mask |=
+ crtc_state->base.connector_mask |=
drm_connector_mask(&connector->base);
- encoder->base.crtc->state->encoder_mask |=
+ crtc_state->base.encoder_mask |=
drm_encoder_mask(&encoder->base);
}
-
} else {
connector->base.dpms = DRM_MODE_DPMS_OFF;
connector->base.encoder = NULL;
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Switch intel_legacy_cursor_update() to intel_ types
From: Ville Syrjälä
Prefer the intel_ types in intel_legacy_cursor_update() over the
drm_ types. Should make it easier to adapt this to the uapi vs. hw
state split.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 86 ++--
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8f125f1624bd..8a2e780d85e1 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14693,8 +14693,8 @@ static const struct drm_plane_funcs i8xx_plane_funcs = {
};
static int
-intel_legacy_cursor_update(struct drm_plane *plane,
- struct drm_crtc *crtc,
+intel_legacy_cursor_update(struct drm_plane *_plane,
+ struct drm_crtc *_crtc,
struct drm_framebuffer *fb,
int crtc_x, int crtc_y,
unsigned int crtc_w, unsigned int crtc_h,
@@ -14702,11 +14702,14 @@ intel_legacy_cursor_update(struct drm_plane *plane,
u32 src_w, u32 src_h,
struct drm_modeset_acquire_ctx *ctx)
{
- struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- struct drm_plane_state *old_plane_state, *new_plane_state;
- struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct intel_plane *plane = to_intel_plane(_plane);
+ struct intel_crtc *crtc = to_intel_crtc(_crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ struct intel_plane_state *old_plane_state =
+ to_intel_plane_state(plane->base.state);
+ struct intel_plane_state *new_plane_state;
struct intel_crtc_state *crtc_state =
- to_intel_crtc_state(crtc->state);
+ to_intel_crtc_state(crtc->base.state);
struct intel_crtc_state *new_crtc_state;
int ret;
@@ -14718,14 +14721,13 @@ intel_legacy_cursor_update(struct drm_plane *plane,
crtc_state->update_pipe)
goto slow;
- old_plane_state = plane->state;
/*
* Don't do an async update if there is an outstanding commit modifying
* the plane. This prevents our async update's changes from getting
* overridden by a previous synchronous update's state.
*/
- if (old_plane_state->commit &&
- !try_wait_for_completion(&old_plane_state->commit->hw_done))
+ if (old_plane_state->base.commit &&
+ !try_wait_for_completion(&old_plane_state->base.commit->hw_done))
goto slow;
/*
@@ -14733,38 +14735,37 @@ intel_legacy_cursor_update(struct drm_plane *plane,
* take the slowpath. Only changing fb or position should be
* in the fastpath.
*/
- if (old_plane_state->crtc != crtc ||
- old_plane_state->src_w != src_w ||
- old_plane_state->src_h != src_h ||
- old_plane_state->crtc_w != crtc_w ||
- old_plane_state->crtc_h != crtc_h ||
- !old_plane_state->fb != !fb)
+ if (old_plane_state->base.crtc != &crtc->base ||
+ old_plane_state->base.src_w != src_w ||
+ old_plane_state->base.src_h != src_h ||
+ old_plane_state->base.crtc_w != crtc_w ||
+ old_plane_state->base.crtc_h != crtc_h ||
+ !old_plane_state->base.fb != !fb)
goto slow;
- new_plane_state = intel_plane_duplicate_state(plane);
+ new_plane_state =
to_intel_plane_state(intel_plane_duplicate_state(&plane->base));
if (!new_plane_state)
return -ENOMEM;
- new_crtc_state = to_intel_crtc_state(intel_crtc_duplicate_state(crtc));
+ new_crtc_state =
to_intel_crtc_state(intel_crtc_duplicate_state(&crtc->base));
if (!new_crtc_state) {
ret = -ENOMEM;
goto out_free;
}
- drm_atomic_set_fb_for_plane(new_plane_state, fb);
+ drm_atomic_set_fb_for_plane(&new_plane_state->base, fb);
- new_plane_state->src_x = src_x;
- new_plane_state->src_y = src_y;
- new_plane_state->src_w = src_w;
- new_plane_state->src_h = src_h;
- new_plane_state->crtc_x = crtc_x;
- new_plane_state->crtc_y = crtc_y;
- new_plane_state->crtc_w = crtc_w;
- new_plane_state->crtc_h = crtc_h;
+ new_plane_state->base.src_x = src_x;
+ new_plane_state->base.src_y = src_y;
+ new_plane_state->base.src_w = src_w;
+ new_plane_state->base.src_h = src_h;
+ new_plane_state->base.crtc_x = crtc_x;
+ new_plane_state->base.crtc_y = crtc_y;
+ new_plane_state->base.crtc_w = crtc_w;
+ new_plane_state->base.crtc_h = crtc_h;
ret = intel_plane_atomic_check_with_state(crtc_state, new_crtc_state,
-
to_intel_plane_state(old_plane_stat
[Intel-gfx] [PATCH 2/5] drm/i915: Prepare the connector/encoder mask readout for hw vs. uapi state split
From: Ville Syrjälä
Prepare the connector/encoder mask readout for the uapi vs. hw
state split. We'll want to do all readout into the hw state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8a2e780d85e1..9d4dfe2eace0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16795,24 +16795,28 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
drm_connector_list_iter_begin(dev, &conn_iter);
for_each_intel_connector_iter(connector, &conn_iter) {
if (connector->get_hw_state(connector)) {
+ struct intel_crtc_state *crtc_state;
+ struct intel_crtc *crtc;
+
connector->base.dpms = DRM_MODE_DPMS_ON;
encoder = connector->encoder;
connector->base.encoder = &encoder->base;
- if (encoder->base.crtc &&
- encoder->base.crtc->state->active) {
+ crtc = to_intel_crtc(encoder->base.crtc);
+ crtc_state = crtc ?
to_intel_crtc_state(crtc->base.state) : NULL;
+
+ if (crtc_state && crtc_state->base.active) {
/*
* This has to be done during hardware readout
* because anything calling .crtc_disable may
* rely on the connector_mask being accurate.
*/
- encoder->base.crtc->state->connector_mask |=
+ crtc_state->base.connector_mask |=
drm_connector_mask(&connector->base);
- encoder->base.crtc->state->encoder_mask |=
+ crtc_state->base.encoder_mask |=
drm_encoder_mask(&encoder->base);
}
-
} else {
connector->base.dpms = DRM_MODE_DPMS_OFF;
connector->base.encoder = NULL;
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Prepare the mode readout for hw vs. uapi state split
From: Ville Syrjälä Prepare the mode readout for the uapi vs. hw state split. We'll want to do all readout into the hw state. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 9d4dfe2eace0..94c9bf1133ca 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -16841,7 +16841,7 @@ static void intel_modeset_readout_hw_state(struct drm_device *dev) crtc->base.mode.hdisplay = crtc_state->pipe_src_w; crtc->base.mode.vdisplay = crtc_state->pipe_src_h; intel_mode_from_pipe_config(&crtc_state->base.adjusted_mode, crtc_state); - WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, &crtc->base.mode)); + WARN_ON(drm_atomic_set_mode_for_crtc(&crtc_state->base, &crtc->base.mode)); /* * The initial mode needs to be set in order to keep -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: Add intel_atomic_crtc_state_for_each_plane_state()
From: Ville Syrjälä
drm_atomic_crtc_state_for_each_plane_state() can't be used after
we have the uapi vs. hw split. Roll our own :(
Truthfully I'd like to nuke this thing entirely, but that
requires some more work so let's live with it for now.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 10 ++
drivers/gpu/drm/i915/display/intel_atomic.h | 6 ++
drivers/gpu/drm/i915/display/intel_display.h | 9 ++
drivers/gpu/drm/i915/intel_pm.c | 99 ++--
4 files changed, 73 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index c5a552a69752..ef714b258707 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -442,3 +442,13 @@ intel_atomic_get_crtc_state(struct drm_atomic_state *state,
return to_intel_crtc_state(crtc_state);
}
+
+const struct intel_plane_state *
+__intel_atomic_get_current_plane_state(struct intel_atomic_state *state,
+ struct intel_plane *plane)
+{
+ if (state->base.planes[drm_plane_index(&plane->base)].state)
+ return
to_intel_plane_state(state->base.planes[drm_plane_index(&plane->base)].state);
+
+ return to_intel_plane_state(plane->base.state);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
b/drivers/gpu/drm/i915/display/intel_atomic.h
index 58065d3161a3..02d626e6ebf1 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -16,8 +16,10 @@ struct drm_crtc_state;
struct drm_device;
struct drm_i915_private;
struct drm_property;
+struct intel_atomic_state;
struct intel_crtc;
struct intel_crtc_state;
+struct intel_plane;
int intel_digital_connector_atomic_get_property(struct drm_connector
*connector,
const struct
drm_connector_state *state,
@@ -46,4 +48,8 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
struct intel_crtc *intel_crtc,
struct intel_crtc_state *crtc_state);
+const struct intel_plane_state *
+__intel_atomic_get_current_plane_state(struct intel_atomic_state *state,
+ struct intel_plane *plane);
+
#endif /* __INTEL_ATOMIC_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 4b9e18e5a263..ac374345726e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -440,6 +440,15 @@ enum phy_fia {
(__i)--) \
for_each_if(crtc)
+#define intel_for_each_plane_mask(plane, dev, plane_mask) \
+ list_for_each_entry((plane), &(dev)->mode_config.plane_list, base.head)
\
+ for_each_if ((plane_mask) & drm_plane_mask(&(plane)->base))
+
+#define intel_atomic_crtc_state_for_each_plane_state(plane, plane_state,
crtc_state, state) \
+ intel_for_each_plane_mask((plane), (state)->base.dev,
(crtc_state)->base.plane_mask) \
+ for_each_if (((plane_state) = \
+ __intel_atomic_get_current_plane_state((state),
(plane
+
void intel_link_compute_m_n(u16 bpp, int nlanes,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bfcf03ab5245..c2861263ad42 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3084,13 +3084,13 @@ static bool ilk_validate_pipe_wm(const struct
drm_i915_private *dev_priv,
/* Compute new watermarks for the pipe */
static int ilk_compute_pipe_wm(struct intel_crtc_state *crtc_state)
{
- struct drm_atomic_state *state = crtc_state->base.state;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ const struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ struct intel_atomic_state *state =
+ to_intel_atomic_state(crtc_state->base.state);
struct intel_pipe_wm *pipe_wm;
- struct drm_device *dev = state->dev;
- const struct drm_i915_private *dev_priv = to_i915(dev);
- struct drm_plane *plane;
- const struct drm_plane_state *plane_state;
+ struct intel_plane *plane;
+ const struct intel_plane_state *plane_state;
const struct intel_plane_state *pristate = NULL;
const struct intel_plane_state *sprstate = NULL;
const struct intel_plane_state *curstate = NULL;
@@ -3099,15 +3099,14 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state
*crtc_state)
pipe_wm = &crtc_state->wm.ilk.optimal;
- drm_atomic_crtc_state_for_each_plane_state(plane
[Intel-gfx] [PATCH 5/5] drm/i915: Add intel_atomic_add_affected_planes()
From: Ville Syrjälä
drm_atomic_add_affected_planes() can't be used in some cases
once we do the uapi vs. hw state split because we'll want
to consider the plane maks in the hw state rather than the
uapi state. Roll our own :(
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 25 +
drivers/gpu/drm/i915/display/intel_atomic.h | 3 +++
drivers/gpu/drm/i915/display/intel_cdclk.c | 3 +--
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index ef714b258707..0fb0a8d91337 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -443,6 +443,31 @@ intel_atomic_get_crtc_state(struct drm_atomic_state *state,
return to_intel_crtc_state(crtc_state);
}
+int intel_atomic_add_affected_planes(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
+{
+ const struct intel_crtc_state *old_crtc_state =
+ intel_atomic_get_old_crtc_state(state, crtc);
+ struct intel_plane *plane;
+
+ WARN_ON(!intel_atomic_get_new_crtc_state(state, crtc));
+
+ DRM_DEBUG_ATOMIC("Adding all current planes for [CRTC:%d:%s] to %p\n",
+crtc->base.base.id, crtc->base.name, state);
+
+ intel_for_each_plane_mask(plane, state->base.dev,
+ old_crtc_state->base.plane_mask) {
+ struct intel_plane_state *plane_state =
+ intel_atomic_get_plane_state(state, plane);
+
+ if (IS_ERR(plane_state))
+ return PTR_ERR(plane_state);
+ }
+
+ return 0;
+
+}
+
const struct intel_plane_state *
__intel_atomic_get_current_plane_state(struct intel_atomic_state *state,
struct intel_plane *plane)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
b/drivers/gpu/drm/i915/display/intel_atomic.h
index 02d626e6ebf1..888962a95dba 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -48,6 +48,9 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
struct intel_crtc *intel_crtc,
struct intel_crtc_state *crtc_state);
+int intel_atomic_add_affected_planes(struct intel_atomic_state *state,
+struct intel_crtc *crtc);
+
const struct intel_plane_state *
__intel_atomic_get_current_plane_state(struct intel_atomic_state *state,
struct intel_plane *plane);
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 43564295b864..08167922d7f6 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2266,8 +2266,7 @@ static int intel_modeset_all_pipes(struct
intel_atomic_state *state)
if (ret)
return ret;
- ret = drm_atomic_add_affected_planes(&state->base,
-&crtc->base);
+ ret = intel_atomic_add_affected_planes(state, crtc);
if (ret)
return ret;
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] i915/gem_ctx_isolation: Check nonpriv values are kept across switch
Verify that the values we store in our nonpriv context image registers
are restored after a switch.
v2: Use explicit ordering to ensure we force the context switch back and
forth in between the register writes and their read.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
---
tests/i915/gem_ctx_isolation.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index c4302394e..df1d655ae 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -579,6 +579,35 @@ static void nonpriv(int fd,
__func__, v, values[v]);
write_regs(fd, ctx, e, flags, values[v]);
+ if (flags & DIRTY2) {
+ uint32_t sw = gem_context_create(fd);
+ igt_spin_t *syncpt, *dirt;
+
+ /* Explicit sync to keep the switch between write/read
*/
+ syncpt = igt_spin_new(fd,
+ .ctx = ctx,
+ .engine = engine,
+ .flags = IGT_SPIN_FENCE_OUT);
+
+ dirt = igt_spin_new(fd,
+ .ctx = sw,
+ .engine = engine,
+ .fence = syncpt->out_fence,
+ .flags = (IGT_SPIN_FENCE_IN |
+ IGT_SPIN_FENCE_OUT));
+ igt_spin_free(fd, syncpt);
+
+ syncpt = igt_spin_new(fd,
+ .ctx = ctx,
+ .engine = engine,
+ .fence = dirt->out_fence,
+ .flags = IGT_SPIN_FENCE_IN);
+ igt_spin_free(fd, dirt);
+
+ igt_spin_free(fd, syncpt);
+ gem_context_destroy(fd, sw);
+ }
+
regs[1] = read_regs(fd, ctx, e, flags);
/*
@@ -838,6 +867,8 @@ igt_main
igt_subtest_f("%s-nonpriv", e->name)
nonpriv(fd, e, 0);
+ igt_subtest_f("%s-nonpriv-switch", e->name)
+ nonpriv(fd, e, DIRTY2);
igt_subtest_f("%s-clean", e->name)
isolation(fd, e, 0);
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 3/7] drm/i915/tgl: Enable DC3CO state in "DC Off" power well
On Fri, Sep 27, 2019 at 02:07:43PM +0300, Imre Deak wrote:
> On Thu, Sep 26, 2019 at 08:26:17PM +0530, Anshuman Gupta wrote:
> > Add target_dc_state and tgl_set_target_dc_state() API
> > in order to enable DC3CO state with existing DC states.
> > target_dc_state will enable/disable the desired DC state in
> > DC_STATE_EN reg when "DC Off" power well gets disable/enable.
> >
> > v2: commit log improvement.
> > v3: Used intel_wait_for_register to wait for DC3CO exit. [Imre]
> > Used gen9_set_dc_state() to allow/disallow DC3CO. [Imre]
> > Moved transcoder psr2 exit line enablement from tgl_allow_dc3co()
> > to a appropriate place haswell_crtc_enable(). [Imre]
> > Changed the DC3CO power well enabled call back logic as
> > recommended in review comments. [Imre]
> > v4: Used wait_for_us() instead of intel_wait_for_reg(). [Imre (IRC)]
> > v5: using udelay() instead of waiting for DC3CO exit status.
> > v6: Fixed minor unwanted change.
> > v7: Removed DC3CO powerwell and POWER_DOMAIN_VIDEO.
> > v8: Uniform checks by using only target_dc_state instead of allowed_dc_mask
> > in "DC off" power well callback. [Imre]
> > Adding "DC off" power well id to older platforms. [Imre]
> > Removed psr2_deep_sleep flag from tgl_set_target_dc_state. [Imre]
> > v9: Used switch case for target DC state in
> > gen9_dc_off_power_well_disable(), checking DC3CO state against
> > allowed DC mask, using WARN_ON() in
> > tgl_set_target_dc_state(). [Imre]
> >
> > Cc: Jani Nikula
> > Cc: Imre Deak
> > Cc: Animesh Manna
> > Signed-off-by: Anshuman Gupta
> > ---
> > .../drm/i915/display/intel_display_power.c| 110 --
> > .../drm/i915/display/intel_display_power.h| 2 +
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > 3 files changed, 104 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 0b685c517bcb..9f787556f80d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -785,6 +785,38 @@ static void gen9_set_dc_state(struct drm_i915_private
> > *dev_priv, u32 state)
> > dev_priv->csr.dc_state = val & mask;
> > }
> >
> > +static void
> > +allowed_dc_mask_to_target_dc_state(struct drm_i915_private *dev_priv)
> > +{
> > + if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC6)
> > + dev_priv->csr.target_dc_state = DC_STATE_EN_UPTO_DC6;
> > + else if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC5)
> > + dev_priv->csr.target_dc_state = DC_STATE_EN_UPTO_DC5;
> > + else
> > + dev_priv->csr.target_dc_state = DC_STATE_DISABLE;
> > +}
>
> The following can be used in tgl_set_target_dc_state() as well:
>
> static u32
> sanitize_target_dc_state(struct drm_i915_private *dev_priv,
> u32 target_dc_state)
> {
> u32 states[] = {
> DC_STATE_EN_UPTO_DC6,
> DC_STATE_EN_UPTO_DC5,
> DC_STATE_EN_DC3CO,
> };
> int i;
>
> for (i = 0; i < ARRAY_SIZE(states); i++)
> if (target_dc_state == states[i] &&
> (dev_priv->csr.allowed_dc_mask & states[i]))
> return states[i];
>
> return DC_STATE_DISABLE;
> }
>
> > +
> > +static void tgl_enable_dc3co(struct drm_i915_private *dev_priv)
> > +{
> > + DRM_DEBUG_KMS("Enabling DC3CO\n");
> > + gen9_set_dc_state(dev_priv, DC_STATE_EN_DC3CO);
> > +}
> > +
> > +static void tgl_disable_dc3co(struct drm_i915_private *dev_priv)
> > +{
> > + u32 val;
> > +
> > + DRM_DEBUG_KMS("Disabling DC3CO\n");
> > + val = I915_READ(DC_STATE_EN);
> > + val &= ~DC_STATE_DC3CO_STATUS;
> > + I915_WRITE(DC_STATE_EN, val);
> > + gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> > + /*
> > +* Delay of 200us DC3CO Exit time B.Spec 49196
> > +*/
> > + usleep_range(200, 210);
> > +}
> > +
> > static void bxt_enable_dc9(struct drm_i915_private *dev_priv)
> > {
> > assert_can_enable_dc9(dev_priv);
> > @@ -952,7 +984,8 @@ static void bxt_verify_ddi_phy_power_wells(struct
> > drm_i915_private *dev_priv)
> > static bool gen9_dc_off_power_well_enabled(struct drm_i915_private
> > *dev_priv,
> >struct i915_power_well *power_well)
> > {
> > - return (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0;
> > + return ((I915_READ(DC_STATE_EN) & DC_STATE_EN_DC3CO) == 0 &&
> > + (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0);
> > }
> >
> > static void gen9_assert_dbuf_enabled(struct drm_i915_private *dev_priv)
> > @@ -968,6 +1001,11 @@ static void gen9_disable_dc_states(struct
> > drm_i915_private *dev_priv)
> > {
> > struct intel_cdclk_state cdclk_state = {};
> >
> > + if (dev_priv->csr.target_dc_state == DC_STATE_EN_DC3CO) {
> > +
Re: [Intel-gfx] [PATCH v9 3/7] drm/i915/tgl: Enable DC3CO state in "DC Off" power well
On Fri, 27 Sep 2019, Imre Deak wrote: > On Fri, Sep 27, 2019 at 02:07:43PM +0300, Imre Deak wrote: >> On Thu, Sep 26, 2019 at 08:26:17PM +0530, Anshuman Gupta wrote: >> > +void tgl_set_target_dc_state(struct drm_i915_private *dev_priv, u32 state) > > We need a documentation for exported functions. And really you should make an effort to *NOT* expose platform specific functions from your C modules. Yes, we have some, but the direction should be the opposite of adding more. I'll be more strict about this going forward. We need to improve the interfaces we have. >> > @@ -256,6 +257,7 @@ void intel_display_power_suspend_late(struct >> > drm_i915_private *i915); >> > void intel_display_power_resume_early(struct drm_i915_private *i915); >> > void intel_display_power_suspend(struct drm_i915_private *i915); >> > void intel_display_power_resume(struct drm_i915_private *i915); >> > +void tgl_set_target_dc_state(struct drm_i915_private *dev_priv, u32 >> > state); This sticks out like a sore thumb. And you're not even using the function outside of intel_display_power.h! BR, Jani. >> > >> > const char * >> > intel_display_power_domain_str(enum intel_display_power_domain domain); -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 25/27] drm/dp_mst: Add basic topology reprobing when resuming
On Tue, Sep 03, 2019 at 04:46:03PM -0400, Lyude Paul wrote:
> Finally! For a very long time, our MST helpers have had one very
> annoying issue: They don't know how to reprobe the topology state when
> coming out of suspend. This means that if a user has a machine connected
> to an MST topology and decides to suspend their machine, we lose all
> topology changes that happened during that period. That can be a big
> problem if the machine was connected to a different topology on the same
> port before resuming, as we won't bother reprobing any of the ports and
> likely cause the user's monitors not to come back up as expected.
>
> So, we start fixing this by teaching our MST helpers how to reprobe the
> link addresses of each connected topology when resuming. As it turns
> out, the behavior that we want here is identical to the behavior we want
> when initially probing a newly connected MST topology, with a couple of
> important differences:
>
> - We need to be more careful about handling the potential races between
> events from the MST hub that could change the topology state as we're
> performing the link address reprobe
> - We need to be more careful about handling unlikely state changes on
> ports - such as an input port turning into an output port, something
> that would be far more likely to happen in situations like the MST hub
> we're connected to being changed while we're suspend
>
> Both of which have been solved by previous commits. That leaves one
> requirement:
>
> - We need to prune any MST ports in our in-memory topology state that
> were present when suspending, but have not appeared in the post-resume
> link address response from their parent branch device
>
> Which we can now handle in this commit by modifying
> drm_dp_send_link_address(). We then introduce suspend/resume reprobing
> by introducing drm_dp_mst_topology_mgr_invalidate_mstb(), which we call
> in drm_dp_mst_topology_mgr_suspend() to traverse the in-memory topology
> state to indicate that each mstb needs it's link address resent and PBN
> resources reprobed.
>
> On resume, we start back up &mgr->work and have it reprobe the topology
> in the same way we would on a hotplug, removing any leftover ports that
> no longer appear in the topology state.
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Signed-off-by: Lyude Paul
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> drivers/gpu/drm/drm_dp_mst_topology.c | 138 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 3 +-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 +-
> include/drm/drm_dp_mst_helper.h | 3 +-
> 5 files changed, 112 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 4d3c8bff77da..27ee3e045b86 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -973,7 +973,7 @@ static void s3_handle_mst(struct drm_device *dev, bool
> suspend)
> if (suspend) {
> drm_dp_mst_topology_mgr_suspend(mgr);
> } else {
> - ret = drm_dp_mst_topology_mgr_resume(mgr);
> + ret = drm_dp_mst_topology_mgr_resume(mgr, true);
> if (ret < 0) {
> drm_dp_mst_topology_mgr_set_mst(mgr, false);
> need_hotplug = true;
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index e407aba1fbd2..2fe24e366925 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2020,6 +2020,14 @@ drm_dp_mst_handle_link_address_port(struct
> drm_dp_mst_branch *mstb,
> goto fail_unlock;
> }
>
> + /*
> + * If this port wasn't just created, then we're reprobing because
> + * we're coming out of suspend. In this case, always resend the link
> + * address if there's an MSTB on this port
> + */
> + if (!created && port->pdt == DP_PEER_DEVICE_MST_BRANCHING)
> + send_link_addr = true;
> +
> if (send_link_addr) {
> mutex_lock(&mgr->lock);
> if (port->mstb) {
> @@ -2530,7 +2538,8 @@ static void drm_dp_send_link_address(struct
> drm_dp_mst_topology_mgr *mgr,
> {
> struct drm_dp_sideband_msg_tx *txmsg;
> struct drm_dp_link_address_ack_reply *reply;
> - int i, len, ret;
> + struct drm_dp_mst_port *port, *tmp;
> + int i, len, ret, port_mask = 0;
>
> txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> if (!txmsg)
> @@ -2560,9 +2569,28 @@ static void drm_dp_send_link_address(struct
> drm_dp_mst_topology_mgr *mgr,
>
> drm_dp_check_mstb_guid(mstb, reply->guid);
>
> - for (i = 0; i < reply->nports; i++)
> + f
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915: Switch intel_legacy_cursor_update() to intel_ types
== Series Details ==
Series: series starting with [1/5] drm/i915: Switch
intel_legacy_cursor_update() to intel_ types
URL : https://patchwork.freedesktop.org/series/67337/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6e83c3bdcc40 drm/i915: Switch intel_legacy_cursor_update() to intel_ types
3cdcb4af301c drm/i915: Prepare the connector/encoder mask eadout for hw vs.
uapi state split
4d9d48f0a291 drm/i915: Prepare the mode readout for hw vs. uapi state split
cd2aa84c322f drm/i915: Add intel_atomic_crtc_state_for_each_plane_state()
-:31: WARNING:LONG_LINE: line over 100 characters
#31: FILE: drivers/gpu/drm/i915/display/intel_atomic.c:451:
+ return
to_intel_plane_state(state->base.planes[drm_plane_index(&plane->base)].state);
-:67: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#67: FILE: drivers/gpu/drm/i915/display/intel_display.h:443:
+#define intel_for_each_plane_mask(plane, dev, plane_mask) \
+ list_for_each_entry((plane), &(dev)->mode_config.plane_list, base.head)
\
+ for_each_if ((plane_mask) & drm_plane_mask(&(plane)->base))
-:67: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plane' - possible
side-effects?
#67: FILE: drivers/gpu/drm/i915/display/intel_display.h:443:
+#define intel_for_each_plane_mask(plane, dev, plane_mask) \
+ list_for_each_entry((plane), &(dev)->mode_config.plane_list, base.head)
\
+ for_each_if ((plane_mask) & drm_plane_mask(&(plane)->base))
-:69: WARNING:SPACING: space prohibited between function name and open
parenthesis '('
#69: FILE: drivers/gpu/drm/i915/display/intel_display.h:445:
+ for_each_if ((plane_mask) & drm_plane_mask(&(plane)->base))
-:71: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#71: FILE: drivers/gpu/drm/i915/display/intel_display.h:447:
+#define intel_atomic_crtc_state_for_each_plane_state(plane, plane_state,
crtc_state, state) \
+ intel_for_each_plane_mask((plane), (state)->base.dev,
(crtc_state)->base.plane_mask) \
+ for_each_if (((plane_state) = \
+ __intel_atomic_get_current_plane_state((state),
(plane
-:71: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plane' - possible
side-effects?
#71: FILE: drivers/gpu/drm/i915/display/intel_display.h:447:
+#define intel_atomic_crtc_state_for_each_plane_state(plane, plane_state,
crtc_state, state) \
+ intel_for_each_plane_mask((plane), (state)->base.dev,
(crtc_state)->base.plane_mask) \
+ for_each_if (((plane_state) = \
+ __intel_atomic_get_current_plane_state((state),
(plane
-:71: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'state' - possible
side-effects?
#71: FILE: drivers/gpu/drm/i915/display/intel_display.h:447:
+#define intel_atomic_crtc_state_for_each_plane_state(plane, plane_state,
crtc_state, state) \
+ intel_for_each_plane_mask((plane), (state)->base.dev,
(crtc_state)->base.plane_mask) \
+ for_each_if (((plane_state) = \
+ __intel_atomic_get_current_plane_state((state),
(plane
-:73: WARNING:SPACING: space prohibited between function name and open
parenthesis '('
#73: FILE: drivers/gpu/drm/i915/display/intel_display.h:449:
+ for_each_if (((plane_state) = \
total: 2 errors, 3 warnings, 3 checks, 255 lines checked
7009d869fbe6 drm/i915: Add intel_atomic_add_affected_planes()
-:47: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#47: FILE: drivers/gpu/drm/i915/display/intel_atomic.c:469:
+
+}
total: 0 errors, 0 warnings, 1 checks, 49 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/27] drm/i915: Coordinate i915_active with its own mutex
On 27/09/2019 13:32, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-09-27 13:25:23) On 27/09/2019 13:16, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-09-27 13:08:51) On 27/09/2019 12:25, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-09-27 12:10:29) On 25/09/2019 11:01, Chris Wilson wrote: +struct dma_fence * +__i915_active_fence_set(struct i915_active_fence *active, + struct dma_fence *fence) Can you add a short comment for this function explaining the racyness and so why it returns prev and what should the callers do with it? Before using this function, we had the callers declare what mutex guards this timeline and we check here that is held. No, I mean because it has to reload prev and return it to the caller, which implies that is to handle some designed-in racy-ness which I think should be mentioned. But that's not racing with the caller, that just racing with the callback from the interrupt handler and the reason why we have to check after serialising is called out. /* serialise with prev->cb_list */ ? The caller is responsible for ensuring that prev is executed before fence to keep the timeline in the same order as recorded. I did not say it is racing with the caller, but that the caller has to handle a race. But the caller only has to care about "was there already an active fence on this timeline? If so, I must make sure it executes before me and take that into consideration for the flow along the timeline" I'm not seeing what race the caller has to be concerned with here. If they replace the last request in the timeline, they have it returned. If there was no request previously in the timeline, they have NULL. (That just seems straightforward.) "Serialise with prev->cb_list" is too low level for me. Trust me, I always struggle with the active tracking code since there is so many indirections and relationships. So in the absence of a visual diagram a higher level comment would be beneficial for the future self. Just expanding on what you replied here talking about how interrupts interacts with new stuff entering tracking would do it. It's just about that the callback may be executing and so we need to serialise the list manipulation under the lock; having performed that list manipulation, we then know whether or not we were successful in capturing the previous fence. Ok ok :), just expand the comment next to re-fetch of prev = active->fence to that effect, that's all I'm asking. :) It will make it easier for future reader to understand why it is required and under what circumstances could active->fence have became NULL in there. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/27] drm/i915: Coordinate i915_active with its own mutex
Quoting Tvrtko Ursulin (2019-09-27 14:58:24) > > On 27/09/2019 13:32, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-09-27 13:25:23) > >> > >> On 27/09/2019 13:16, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2019-09-27 13:08:51) > > On 27/09/2019 12:25, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-09-27 12:10:29) > >> > >> On 25/09/2019 11:01, Chris Wilson wrote: > >>> +struct dma_fence * > >>> +__i915_active_fence_set(struct i915_active_fence *active, > >>> + struct dma_fence *fence) > >> > >> Can you add a short comment for this function explaining the racyness > >> and so why it returns prev and what should the callers do with it? > > > > Before using this function, we had the callers declare what mutex guards > > this timeline and we check here that is held. > > No, I mean because it has to reload prev and return it to the caller, > which implies that is to handle some designed-in racy-ness which I think > should be mentioned. > >>> > >>> But that's not racing with the caller, that just racing with the > >>> callback from the interrupt handler and the reason why we have to check > >>> after serialising is called out. /* serialise with prev->cb_list */ ? > >>> > >>> The caller is responsible for ensuring that prev is executed before > >>> fence to keep the timeline in the same order as recorded. > >> > >> I did not say it is racing with the caller, but that the caller has to > >> handle a race. > > > > But the caller only has to care about "was there already an active fence > > on this timeline? If so, I must make sure it executes before me and take > > that into consideration for the flow along the timeline" > > > > I'm not seeing what race the caller has to be concerned with here. If > > they replace the last request in the timeline, they have it returned. > > If there was no request previously in the timeline, they have NULL. > > (That just seems straightforward.) > > > >> "Serialise with prev->cb_list" is too low level for me. Trust me, I > >> always struggle with the active tracking code since there is so many > >> indirections and relationships. So in the absence of a visual diagram a > >> higher level comment would be beneficial for the future self. Just > >> expanding on what you replied here talking about how interrupts > >> interacts with new stuff entering tracking would do it. > > > > It's just about that the callback may be executing and so we need to > > serialise the list manipulation under the lock; having performed that > > list manipulation, we then know whether or not we were successful in > > capturing the previous fence. > > Ok ok :), just expand the comment next to re-fetch of prev = > active->fence to that effect, that's all I'm asking. :) > > It will make it easier for future reader to understand why it is > required and under what circumstances could active->fence have became > NULL in there. spin_lock_nested(prev->lock, SINGLE_DEPTH_NESTING); __list_del_entry(&active->cb.node); spin_unlock(prev->lock); /* serialise with prev->cb_list */ + + /* +* active->fence is reset by the callback from inside +* interrupt context. We need to serialise our list +* manipulation with the fence->lock to prevent the prev +* being lost inside an interrupt (it can't be replaced as +* no other caller is allowed to enter __i915_active_fence_set +* as we hold the timeline lock). After serialising with +* the callback, we need to double check which ran first, +* our list_del() or the callback... +*/ prev = rcu_access_pointer(active->fence); } Feels a little too tautological, but it is Friday afternoon. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Switch intel_legacy_cursor_update() to intel_ types
== Series Details ==
Series: series starting with [1/5] drm/i915: Switch
intel_legacy_cursor_update() to intel_ types
URL : https://patchwork.freedesktop.org/series/67337/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6969 -> Patchwork_14566
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14566/index.html
Known issues
Here are the changes found in Patchwork_14566 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-icl-u3/igt@gem_mmap_...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14566/fi-icl-u3/igt@gem_mmap_...@basic.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-bxt-dsi: [INCOMPLETE][3] ([fdo#103927] / [fdo#111381]) ->
[PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14566/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14566/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@gem_mmap@basic:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-icl-u3/igt@gem_m...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14566/fi-icl-u3/igt@gem_m...@basic.html
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724] / [fdo#111214]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-icl-u3/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14566/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-6600u: [FAIL][11] ([fdo#107707]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14566/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107707]: https://bugs.freedesktop.org/show_bug.cgi?id=107707
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
Participating hosts (51 -> 46)
--
Additional (2): fi-hsw-peppy fi-skl-guc
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6969 -> Patchwork_14566
CI-20190529: 20190529
CI_DRM_6969: ad0d6a2a5bb90cccef673bf3722a8ee08647cf7f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5206: 5a6c68568def840cd720f18fc66f529a89f84675 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14566: 7009d869fbe6a0e6004c7e814bb9d1364e5efac4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7009d869fbe6 drm/i915: Add intel_atomic_add_affected_planes()
cd2aa84c322f drm/i915: Add intel_atomic_crtc_state_for_each_plane_state()
4d9d48f0a291 drm/i915: Prepare the mode readout for hw vs. uapi state split
3cdcb4af301c drm/i915: Prepare the connector/encoder mask eadout for hw vs.
uapi state split
6e83c3bdcc40 drm/i915: Switch intel_legacy_cursor_update() to intel_ types
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14566/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 3/7] drm/i915/tgl: Enable DC3CO state in "DC Off" power well
On Fri, Sep 27, 2019 at 04:40:59PM +0300, Jani Nikula wrote: > On Fri, 27 Sep 2019, Imre Deak wrote: > > On Fri, Sep 27, 2019 at 02:07:43PM +0300, Imre Deak wrote: > >> On Thu, Sep 26, 2019 at 08:26:17PM +0530, Anshuman Gupta wrote: > >> > +void tgl_set_target_dc_state(struct drm_i915_private *dev_priv, u32 > >> > state) > > > > We need a documentation for exported functions. > > And really you should make an effort to *NOT* expose platform specific > functions from your C modules. Yes, we have some, but the direction > should be the opposite of adding more. > > I'll be more strict about this going forward. We need to improve the > interfaces we have. Yes, the original idea was to add a new power well for the DC3co power state, which would allow us to use the existing get/put interface. That doesn't work too well though, because we can have only one of the states enabled, so we went with having only one DC power well and a new API to set its target DC state. > > >> > @@ -256,6 +257,7 @@ void intel_display_power_suspend_late(struct > >> > drm_i915_private *i915); > >> > void intel_display_power_resume_early(struct drm_i915_private *i915); > >> > void intel_display_power_suspend(struct drm_i915_private *i915); > >> > void intel_display_power_resume(struct drm_i915_private *i915); > >> > +void tgl_set_target_dc_state(struct drm_i915_private *dev_priv, u32 > >> > state); > > This sticks out like a sore thumb. Yep, so the rule is to have a uniform prefix for all exported functions, so we could rename this to intel_display_power_set_dc_target(), > And you're not even using the function outside of intel_display_power.h! It's used, but the use is added only later. I agree that, as commented elsewhere, new functions should be added in the same patch where they are used. > BR, > Jani. > > > >> > > >> > const char * > >> > intel_display_power_domain_str(enum intel_display_power_domain domain); > > -- > Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/23] drm/i915: Program planes in bigjoiner mode.
On Fri, Sep 27, 2019 at 10:56:16AM +0200, Maarten Lankhorst wrote:
> Op 26-09-2019 om 21:11 schreef Ville Syrjälä:
> > On Thu, Sep 26, 2019 at 07:09:22PM +0300, Ville Syrjälä wrote:
> >> On Thu, Sep 26, 2019 at 05:50:05PM +0200, Maarten Lankhorst wrote:
> >>> Op 26-09-2019 om 15:06 schreef Ville Syrjälä:
> On Fri, Sep 20, 2019 at 01:42:28PM +0200, Maarten Lankhorst wrote:
> > Now that we can program planes from the update_slave callback, and
> > we have done all fb pinning correctly, it's time to program those
> > planes as well.
> >
> > We use the update_slave callback as it allows us to use the
> > separate states correctly.
> >
> > Signed-off-by: Maarten Lankhorst
> > ---
> > .../gpu/drm/i915/display/intel_atomic_plane.c | 53 +++
> > .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
> > drivers/gpu/drm/i915/display/intel_display.c | 4 +-
> > 3 files changed, 57 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index cc088676f0a2..5db091e4ad6a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -366,6 +366,59 @@ void skl_update_planes_on_crtc(struct
> > intel_atomic_state *state,
> > }
> > }
> >
> > +void icl_update_bigjoiner_planes_on_crtc(struct intel_atomic_state
> > *state,
> > +struct intel_crtc *crtc)
> This plane stuff is where things go very much off the rails IMO.
> Planes should not have to know anything about bigjoiner. They should
> just have their appropriate hw state and blindly bash it into the
> hardware.
> >>> We already need this for planar slave/master, what's the issue exactly?
> >> That already is too fragile. I don't want this spreading all over
> >> the driver and coupling everything to the bigjoiner logic.
> >>
> >> Here's a crude idea how I think we might avoid this:
> >> git://github.com/vsyrjala/linux.git uapi_hw_state_split
> >>
> >> But I didn't dare boot it yet...
> > It took a handful extra fixes to get that to boot. But now I at least
> > get a picture on the screen instead of oopses.
> >
> > Fixes pushed to the same branch.
> >
> > Looks like still something going wrong with the cursor ioctl though.
> >
> I've done a uapi-hw split in my series, is that ok with you?
>
> I will do a similar split for planes.
I sent out some prep fixes, and respun my test branch as
uapi_hw_state_split_2. Even the legacy cursor now works.
So I think we might even have a chance of making this state
split thing work.
My suggestion on how to do it would be:
1. split the state and do the uapi<->hw copies, but leave the hw state still
called 'base' to minimize the diff. We can then more easily see all
the places where we have to consult to the uapi state.
2. probably do the base->hw rename with cocci or something
I think at least one thing missing from your split crtc state was
plane_mask. I added the required helpers for that in my prep patches.
I'm not 100% sure what we should do with the mode_change etc. flags. I
guess we can leave them just in the uapi state as long as we don't get
confused by the appearance of the 'uapi' name in various places.
Oh and to split the state for planes we'll need to hand roll our own
drm_atomic_helper_check_plane_state(). I didn't do that in my prep
patches because I was lazy.
Oh and drm_atomic_helper_setup_commit() is a big problem. In my test
branch I just copy pasted it to i915 and changed it to check the hw
state instead of the uapi state. But I don't really like that apporoach
so maybe we could reuse this helper still and just abstract away the
crtc active check.
Maybe have the caller pass in a function like so?
int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
bool nonblock,
bool (*crtc_is_active)(const struct
drm_crtc_state *crtc_state));
{
...
- if (!old_crtc_state->active && !new_crtc_state->active) {
+ if (!crtc_is_active(old_crtc_state) && !crtc_is_active(new_crtc_state))
{
...
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/23] drm/i915: Program planes in bigjoiner mode.
On Fri, Sep 27, 2019 at 05:41:49PM +0300, Ville Syrjälä wrote: > On Fri, Sep 27, 2019 at 10:56:16AM +0200, Maarten Lankhorst wrote: > > Op 26-09-2019 om 21:11 schreef Ville Syrjälä: > > > On Thu, Sep 26, 2019 at 07:09:22PM +0300, Ville Syrjälä wrote: > > >> On Thu, Sep 26, 2019 at 05:50:05PM +0200, Maarten Lankhorst wrote: > > >>> Op 26-09-2019 om 15:06 schreef Ville Syrjälä: > > On Fri, Sep 20, 2019 at 01:42:28PM +0200, Maarten Lankhorst wrote: > > > Now that we can program planes from the update_slave callback, and > > > we have done all fb pinning correctly, it's time to program those > > > planes as well. > > > > > > We use the update_slave callback as it allows us to use the > > > separate states correctly. > > > > > > Signed-off-by: Maarten Lankhorst > > > --- > > > .../gpu/drm/i915/display/intel_atomic_plane.c | 53 > > > +++ > > > .../gpu/drm/i915/display/intel_atomic_plane.h | 2 + > > > drivers/gpu/drm/i915/display/intel_display.c | 4 +- > > > 3 files changed, 57 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c > > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c > > > index cc088676f0a2..5db091e4ad6a 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c > > > @@ -366,6 +366,59 @@ void skl_update_planes_on_crtc(struct > > > intel_atomic_state *state, > > > } > > > } > > > > > > +void icl_update_bigjoiner_planes_on_crtc(struct intel_atomic_state > > > *state, > > > + struct intel_crtc *crtc) > > This plane stuff is where things go very much off the rails IMO. > > Planes should not have to know anything about bigjoiner. They should > > just have their appropriate hw state and blindly bash it into the > > hardware. > > >>> We already need this for planar slave/master, what's the issue exactly? > > >> That already is too fragile. I don't want this spreading all over > > >> the driver and coupling everything to the bigjoiner logic. > > >> > > >> Here's a crude idea how I think we might avoid this: > > >> git://github.com/vsyrjala/linux.git uapi_hw_state_split > > >> > > >> But I didn't dare boot it yet... > > > It took a handful extra fixes to get that to boot. But now I at least > > > get a picture on the screen instead of oopses. > > > > > > Fixes pushed to the same branch. > > > > > > Looks like still something going wrong with the cursor ioctl though. > > > > > I've done a uapi-hw split in my series, is that ok with you? > > > > I will do a similar split for planes. > > I sent out some prep fixes, and respun my test branch as > uapi_hw_state_split_2. Even the legacy cursor now works. > So I think we might even have a chance of making this state > split thing work. Drat. At least kms_big_fb is busted. Need to figure out why. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 4/7] drm/i915/tgl: Do modeset to enable and configure DC3CO exitline
On Thu, Sep 26, 2019 at 08:26:18PM +0530, Anshuman Gupta wrote:
> DC3CO enabling B.Specs sequence requires to enable end configure
> exit scanlines to TRANS_EXITLINE register, programming this register
> has to be part of modeset sequence as this can't be change when
> transcoder or port is enabled.
> When system boots with only eDP panel there may not be real
> modeset as BIOS has already programmed the necessary registers,
> therefore it needs to force a modeset to enable and configure
> DC3CO exitline.
>
> v1: Computing dc3co_exitline crtc state from a DP encoder
> compute config. [Imre]
> Enabling and disabling DC3CO PSR2 transcoder exitline from
> encoder pre_enable and post_disable hooks. [Imre]
> Computing dc3co_exitline instead of has_dc3co_exitline bool. [Imre]
>
> Cc: Jani Nikula
> Cc: Imre Deak
> Cc: Animesh Manna
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 7 ++
> drivers/gpu/drm/i915/display/intel_display.c | 1 +
> .../drm/i915/display/intel_display_power.c| 87 +++
> .../drm/i915/display/intel_display_power.h| 8 ++
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +
> 6 files changed, 106 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index aa470c70a198..e0e276909e76 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3212,6 +3212,8 @@ static void tgl_ddi_pre_enable_dp(struct intel_encoder
> *encoder,
> int level = intel_ddi_dp_level(intel_dp);
> enum transcoder transcoder = crtc_state->cpu_transcoder;
>
> + /* Program the dc3co psr2 transcoder exitline */
> + tgl_set_psr2_transcoder_exitline(crtc_state);
> intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
>crtc_state->lane_count, is_mst);
>
> @@ -3524,6 +3526,8 @@ static void intel_ddi_post_disable_dp(struct
> intel_encoder *encoder,
>
> dig_port->ddi_io_power_domain);
>
> intel_ddi_clk_disable(encoder);
> + /* Disable the dc3co psr2 transcoder exitline */
> + tgl_clear_psr2_transcoder_exitline(old_crtc_state);
> }
>
> static void intel_ddi_post_disable_hdmi(struct intel_encoder *encoder,
> @@ -4070,6 +4074,9 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
> break;
> }
>
> + if (encoder->type == INTEL_OUTPUT_EDP)
> + tgl_dc3co_exitline_get_config(pipe_config);
> +
> pipe_config->has_audio =
> intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8f125f1624bd..a467c7523e06 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -12820,6 +12820,7 @@ intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
>
> PIPE_CONF_CHECK_I(pixel_multiplier);
> PIPE_CONF_CHECK_I(output_format);
> + PIPE_CONF_CHECK_I(dc3co_exitline);
> PIPE_CONF_CHECK_BOOL(has_hdmi_sink);
> if ((INTEL_GEN(dev_priv) < 8 && !IS_HASWELL(dev_priv)) ||
> IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 9f787556f80d..84e4cfd95b43 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -19,6 +19,7 @@
> #include "intel_hotplug.h"
> #include "intel_sideband.h"
> #include "intel_tc.h"
> +#include "intel_pm.h"
>
> bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
>enum i915_power_well_id power_well_id);
> @@ -785,6 +786,92 @@ static void gen9_set_dc_state(struct drm_i915_private
> *dev_priv, u32 state)
> dev_priv->csr.dc_state = val & mask;
> }
>
> +void tgl_clear_psr2_transcoder_exitline(const struct intel_crtc_state
> *cstate)
> +{
> + struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
> + u32 val;
> +
> + if (!cstate->dc3co_exitline)
> + return;
> +
> + val = I915_READ(EXITLINE(cstate->cpu_transcoder));
> + val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
> + I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
> +}
> +
> +void tgl_set_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
> +{
> + u32 val, exit_scanlines;
> + struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
> +
> + if (!cstate->dc3co_exitline)
> + return;
> +
> + exit_scanlines = cstate->dc3co_exitline;
> + exit_scanlines <<= EXITLINE_SHIFT;
> + val = I915_READ(EXITLINE(cstate->cpu_transcode
Re: [Intel-gfx] [PATCH v9 5/7] drm/i915/tgl: DC3CO PSR2 helper
On Thu, Sep 26, 2019 at 08:26:19PM +0530, Anshuman Gupta wrote:
> Disallow DC3CO state before PSR2 exit.
> Store dc3co_exitline from crtc state to psr dev_priv
> structure to use it easily whenever it requires.
>
> v1: Moved calling of tgl_enable_psr2_transcoder_exitline() to
> intel_psr_enable(). [Imre]
> v2: Moved tgl_psr2_deep_sleep_enable/disable function to
> the patches where they are getting used and used dc3co_exitline
> check instead of TGL check. [Imre]
>
> Cc: Jani Nikula
> Cc: Imre Deak
> Cc: Animesh Manna
> Signed-off-by: Anshuman Gupta
Please merge this patch to the next one.
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 8
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index b3c7eef53bf3..bf0b741d3243 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -534,6 +534,12 @@ transcoder_has_psr2(struct drm_i915_private *dev_priv,
> enum transcoder trans)
> return trans == TRANSCODER_EDP;
> }
>
> +static void tgl_disallow_dc3co_on_psr2_exit(struct drm_i915_private
> *dev_priv)
> +{
> + if (!dev_priv->psr.dc3co_exitline)
> + return;
> +}
> +
> static bool intel_psr2_config_valid(struct intel_dp *intel_dp,
> struct intel_crtc_state *crtc_state)
> {
> @@ -746,6 +752,7 @@ static void intel_psr_enable_locked(struct
> drm_i915_private *dev_priv,
> dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv, crtc_state);
> dev_priv->psr.busy_frontbuffer_bits = 0;
> dev_priv->psr.pipe = to_intel_crtc(crtc_state->base.crtc)->pipe;
> + dev_priv->psr.dc3co_exitline = crtc_state->dc3co_exitline;
> dev_priv->psr.transcoder = crtc_state->cpu_transcoder;
>
> /*
> @@ -829,6 +836,7 @@ static void intel_psr_exit(struct drm_i915_private
> *dev_priv)
> }
>
> if (dev_priv->psr.psr2_enabled) {
> + tgl_disallow_dc3co_on_psr2_exit(dev_priv);
> val = I915_READ(EDP_PSR2_CTL(dev_priv->psr.transcoder));
> WARN_ON(!(val & EDP_PSR2_ENABLE));
> val &= ~EDP_PSR2_ENABLE;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index cddc98ea9965..c3aba078262f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -501,6 +501,7 @@ struct i915_psr {
> bool sink_not_reliable;
> bool irq_aux_error;
> u16 su_x_granularity;
> + u32 dc3co_exitline;
> };
>
> #define QUIRK_LVDS_SSC_DISABLE (1<<1)
> --
> 2.21.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Only unwedge if we can reset first
Unwedging the GPU requires a successful GPU reset before we restore the default submission, or else we may see residual context switch events that we were not expecting. v2: Pull in the special-case reset_clobbers_display, and explain why it should be safe in the context of unwedging. v3: Just forget all about resets before unwedging if it will clobber the display; risk it all. Reported-by: Janusz Krzysztofik Signed-off-by: Chris Wilson Cc: Janusz Krzysztofik Cc: Daniele Ceraolo Spurio Cc: Ville Syrjälä Reviewed-by: Daniele Ceraolo Spurio #v1 --- drivers/gpu/drm/i915/gt/intel_reset.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c index d08226f5bea5..11781a626f75 100644 --- a/drivers/gpu/drm/i915/gt/intel_reset.c +++ b/drivers/gpu/drm/i915/gt/intel_reset.c @@ -807,6 +807,7 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt) struct intel_gt_timelines *timelines = >->timelines; struct intel_timeline *tl; unsigned long flags; + bool ok; if (!test_bit(I915_WEDGED, >->reset.flags)) return true; @@ -853,7 +854,12 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt) } spin_unlock_irqrestore(&timelines->lock, flags); - intel_gt_sanitize(gt, false); + /* We must reset pending GPU events before restoring our submission */ + ok = !HAS_EXECLISTS(gt->i915); + if (!INTEL_INFO(gt->i915)->gpu_reset_clobbers_display) + ok = __intel_gt_reset(gt, ALL_ENGINES) == 0; + if (!ok) + return false; /* * Undo nop_submit_request. We prevent all new i915 requests from -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 6/7] drm/i915/tgl: switch between dc3co and dc5 based on display idleness
On Thu, Sep 26, 2019 at 08:26:20PM +0530, Anshuman Gupta wrote:
> DC3CO is useful power state, when DMC detects PSR2 idle frame
> while an active video playback, playing 30fps video on 60hz panel
> is the classic example of this use case.
>
> B.Specs:49196 has a restriction to enable DC3CO only for Video Playback.
> It will be worthy to enable DC3CO after completion of each pageflip
> and switch back to DC5 when display is idle because driver doesn't
> differentiate between video playback and a normal pageflip.
> We will use Frontbuffer flush call tgl_dc3co_flush() to enable DC3CO
> state only for ORIGIN_FLIP flush call, because DC3CO state has primarily
> targeted for VPB use case. We are not interested here for frontbuffer
> invalidates calls because that triggers PSR2 exit, which will
> explicitly disable DC3CO.
>
> DC5 and DC6 saves more power, but can't be entered during video
> playback because there are not enough idle frames in a row to meet
> most PSR2 panel deep sleep entry requirement typically 4 frames.
> As PSR2 existing implementation is using minimum 6 idle frames for
> deep sleep, it is safer to enable DC5/6 after 6 idle frames
> (By scheduling a delayed work of 6 idle frames, once DC3CO has been
> enabled after a pageflip).
>
> After manually waiting for 6 idle frames DC5/6 will be enabled and
> PSR2 deep sleep idle frames will be restored to 6 idle frames, at this
> point DMC will triggers DC5/6 once PSR2 enters to deep sleep after
> 6 idle frames.
> In future when we will enable S/W PSR2 tracking, we can change the
> PSR2 required deep sleep idle frames to 1 so DMC can trigger the
> DC5/6 immediately after S/W manual waiting of 6 idle frames get
> complete.
>
> v2: calculated s/w state to switch over dc3co when there is an
> update. [Imre]
> Used cancel_delayed_work_sync() in order to avoid any race
> with already scheduled delayed work. [Imre]
> v3: Cancel_delayed_work_sync() may blocked the commit work.
> hence dropping it, dc5_idle_thread() checks the valid wakeref before
> putting the reference count, which avoids any chances of dropping
> a zero wakeref. [Imre (IRC)]
> v4: Used frontbuffer flush mechanism. [Imre]
> v5: Used psr.pipe to extract frontbuffer busy bits. [Imre]
> Used cancel_delayed_work_sync() in encoder disable path. [Imre]
> Used mod_delayed_work() instead of cancelling and scheduling a
> delayed work. [Imre]
> Used psr.lock in tgl_dc5_idle_thread() to enable psr2 deep
> sleep. [Imre]
> Removed DC5_REQ_IDLE_FRAMES macro. [Imre]
> v6: Inited the busy_frontbuffer_bits, used dc3co_exitline check instead
> of TGL and dc3co allowed_dc_mask checks, used delayed_work_pending
> with the psr lock and removed the psr2_deep_slp_disabled flag. [Imre]
>
> Cc: Jani Nikula
> Cc: Imre Deak
> Cc: Animesh Manna
> Signed-off-by: Anshuman Gupta
> ---
> .../drm/i915/display/intel_display_power.c| 84 +++
> .../drm/i915/display/intel_display_power.h| 4 +
> .../gpu/drm/i915/display/intel_frontbuffer.c | 1 +
> drivers/gpu/drm/i915/display/intel_psr.c | 34
> drivers/gpu/drm/i915/display/intel_psr.h | 2 +
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 6 files changed, 126 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 84e4cfd95b43..00bb82e6a18f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -20,6 +20,7 @@
> #include "intel_sideband.h"
> #include "intel_tc.h"
> #include "intel_pm.h"
> +#include "intel_psr.h"
>
> bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
>enum i915_power_well_id power_well_id);
> @@ -797,6 +798,9 @@ void tgl_clear_psr2_transcoder_exitline(const struct
> intel_crtc_state *cstate)
> val = I915_READ(EXITLINE(cstate->cpu_transcoder));
> val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
> I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
> +
> + /* As psr2 encoder has disabled, cancel the dc5 idle delayed work */
> + cancel_delayed_work_sync(&dev_priv->csr.idle_work);
Let's move this to intel_psr_disable_locked(), for symmetry with the
cancel_work in intel_psr_exit().
> }
>
> void tgl_set_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
> @@ -816,6 +820,19 @@ void tgl_set_psr2_transcoder_exitline(const struct
> intel_crtc_state *cstate)
> I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
> }
>
> +static u32 intel_get_frame_time_us(const struct intel_crtc_state *cstate)
> +{
> + u32 frametime_us;
> +
> + if (!cstate || !cstate->base.active)
> + return 0;
> +
> + frametime_us = DIV_ROUND_UP(1000*1000,
> +
> drm_mode_vrefresh(&cstate->base.adjusted_mode));
Just return the value directly, and le
[Intel-gfx] [PATCH] drm/i915/userptr: Never allow userptr into the mappable GGTT
Daniel Vetter uncovered a nasty cycle in using the mmu-notifiers to
invalidate userptr objects which also happen to be pulled into GGTT
mmaps. That is when we unbind the userptr object (on mmu invalidation),
we revoke all CPU mmaps, which may then recurse into mmu invalidation.
We looked for ways of breaking the cycle, but the revocation on
invalidation is required and cannot be avoided. The only solution we
could see was to not allow such GGTT bindings of userptr objects in the
first place. In practice, no one really wants to use a GGTT mmapping of
a CPU pointer...
Just before Daniel's explosive lockdep patches land in rc1, we got a
genuine blip from CI:
<4>[ 246.793958] ==
<4>[ 246.793972] WARNING: possible circular locking dependency detected
<4>[ 246.793989] 5.3.0-gbd6c56f50d15-drmtip_372+ #1 Tainted: G U
<4>[ 246.794003] --
<4>[ 246.794017] kswapd0/145 is trying to acquire lock:
<4>[ 246.794030] 3f565be6 (&dev->struct_mutex/1){+.+.}, at:
userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
<4>[ 246.794250]
but task is already holding lock:
<4>[ 246.794263] 1799cef9 (&anon_vma->rwsem){}, at:
page_lock_anon_vma_read+0xe6/0x2a0
<4>[ 246.794291]
which lock already depends on the new lock.
<4>[ 246.794307]
the existing dependency chain (in reverse order) is:
<4>[ 246.794322]
-> #3 (&anon_vma->rwsem){}:
<4>[ 246.794344]down_write+0x33/0x70
<4>[ 246.794357]__vma_adjust+0x3d9/0x7b0
<4>[ 246.794370]__split_vma+0x16a/0x180
<4>[ 246.794385]mprotect_fixup+0x2a5/0x320
<4>[ 246.794399]do_mprotect_pkey+0x208/0x2e0
<4>[ 246.794413]__x64_sys_mprotect+0x16/0x20
<4>[ 246.794429]do_syscall_64+0x55/0x1c0
<4>[ 246.794443]entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 246.794456]
-> #2 (&mapping->i_mmap_rwsem){}:
<4>[ 246.794478]down_write+0x33/0x70
<4>[ 246.794493]unmap_mapping_pages+0x48/0x130
<4>[ 246.794519]i915_vma_revoke_mmap+0x81/0x1b0 [i915]
<4>[ 246.794519]i915_vma_unbind+0x11d/0x4a0 [i915]
<4>[ 246.794519]i915_vma_destroy+0x31/0x300 [i915]
<4>[ 246.794519]__i915_gem_free_objects+0xb8/0x4b0 [i915]
<4>[ 246.794519]drm_file_free.part.0+0x1e6/0x290
<4>[ 246.794519]drm_release+0xa6/0xe0
<4>[ 246.794519]__fput+0xc2/0x250
<4>[ 246.794519]task_work_run+0x82/0xb0
<4>[ 246.794519]do_exit+0x35b/0xdb0
<4>[ 246.794519]do_group_exit+0x34/0xb0
<4>[ 246.794519]__x64_sys_exit_group+0xf/0x10
<4>[ 246.794519]do_syscall_64+0x55/0x1c0
<4>[ 246.794519]entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 246.794519]
-> #1 (&vm->mutex){+.+.}:
<4>[ 246.794519]i915_gem_shrinker_taints_mutex+0x6d/0xe0 [i915]
<4>[ 246.794519]i915_address_space_init+0x9f/0x160 [i915]
<4>[ 246.794519]i915_ggtt_init_hw+0x55/0x170 [i915]
<4>[ 246.794519]i915_driver_probe+0xc9f/0x1620 [i915]
<4>[ 246.794519]i915_pci_probe+0x43/0x1b0 [i915]
<4>[ 246.794519]pci_device_probe+0x9e/0x120
<4>[ 246.794519]really_probe+0xea/0x3d0
<4>[ 246.794519]driver_probe_device+0x10b/0x120
<4>[ 246.794519]device_driver_attach+0x4a/0x50
<4>[ 246.794519]__driver_attach+0x97/0x130
<4>[ 246.794519]bus_for_each_dev+0x74/0xc0
<4>[ 246.794519]bus_add_driver+0x13f/0x210
<4>[ 246.794519]driver_register+0x56/0xe0
<4>[ 246.794519]do_one_initcall+0x58/0x300
<4>[ 246.794519]do_init_module+0x56/0x1f6
<4>[ 246.794519]load_module+0x25bd/0x2a40
<4>[ 246.794519]__se_sys_finit_module+0xd3/0xf0
<4>[ 246.794519]do_syscall_64+0x55/0x1c0
<4>[ 246.794519]entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 246.794519]
-> #0 (&dev->struct_mutex/1){+.+.}:
<4>[ 246.794519]__lock_acquire+0x15d8/0x1e90
<4>[ 246.794519]lock_acquire+0xa6/0x1c0
<4>[ 246.794519]__mutex_lock+0x9d/0x9b0
<4>[ 246.794519]userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
<4>[ 246.794519]__mmu_notifier_invalidate_range_start+0x85/0x110
<4>[ 246.794519]try_to_unmap_one+0x76b/0x860
<4>[ 246.794519]rmap_walk_anon+0x104/0x280
<4>[ 246.794519]try_to_unmap+0xc0/0xf0
<4>[ 246.794519]shrink_page_list+0x561/0xc10
<4>[ 246.794519]shrink_inactive_list+0x220/0x440
<4>[ 246.794519]shrink_node_memcg+0x36e/0x740
<4>[ 246.794519]shrink_node+0xcb/0x490
<4>[ 246.794519]balance_pgdat+0x241/0x580
<4>[ 246.794519]kswapd+0x16c/0x530
<4>[ 246.794519]kthread+0x119/0x130
<4>[ 246.794519]ret_from_fork+0x24/0x50
<4>[ 246.794519]
other info that might help us debug this:
Re: [Intel-gfx] [PATCH v9 7/7] drm/i915/tgl: Add DC3CO counter in i915_dmc_info
On Thu, Sep 26, 2019 at 08:26:21PM +0530, Anshuman Gupta wrote:
> Adding DC3CO counter in i915_dmc_info debugfs will be
> useful for DC3CO validation.
> DMC firmware uses DMC_DEBUG3 register as DC3CO counter
> register on TGL, as per B.Specs DMC_DEBUG3 is general
> purpose register.
>
> Cc: Jani Nikula
> Cc: Imre Deak
> Cc: Animesh Manna
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index b5b449a88cf1..8a16bbd31212 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2407,6 +2407,12 @@ static int i915_dmc_info(struct seq_file *m, void
> *unused)
> seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
> CSR_VERSION_MINOR(csr->version));
>
> + /*
> + * TGL DMC f/w uses DMC_DEBUG3 register for DC3CO counter.
> + */
The above is obvious from the code itself, so we don't need a comment
for it. Please also consider removing all other comments in the patchset
that state only what is obvious from the code.
> + if (IS_TIGERLAKE(dev_priv))
The above should match the check in get_allowed_dc_mask().
> + seq_printf(m, "DC3CO count: %d\n", I915_READ(DMC_DEBUG3));
> +
> if (INTEL_GEN(dev_priv) >= 12) {
> dc5_reg = TGL_DMC_DEBUG_DC5_COUNT;
> dc6_reg = TGL_DMC_DEBUG_DC6_COUNT;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3ee9720af207..af810f6ed652 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7263,6 +7263,8 @@ enum {
> #define TGL_DMC_DEBUG_DC5_COUNT _MMIO(0x101084)
> #define TGL_DMC_DEBUG_DC6_COUNT _MMIO(0x101088)
>
> +#define DMC_DEBUG3 _MMIO(0x101090)
> +
> /* interrupts */
> #define DE_MASTER_IRQ_CONTROL (1 << 31)
> #define DE_SPRITEB_FLIP_DONE(1 << 29)
> --
> 2.21.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/userptr: Never allow userptr into the mappable GGTT
== Series Details ==
Series: drm/i915/userptr: Never allow userptr into the mappable GGTT
URL : https://patchwork.freedesktop.org/series/67349/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e7fbf6cde45c drm/i915/userptr: Never allow userptr into the mappable GGTT
-:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#25:
<4>[ 246.794030] 3f565be6 (&dev->struct_mutex/1){+.+.}, at:
userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
total: 0 errors, 1 warnings, 0 checks, 37 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Only unwedge if we can reset first (rev2)
== Series Details ==
Series: drm/i915/gt: Only unwedge if we can reset first (rev2)
URL : https://patchwork.freedesktop.org/series/66637/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6969 -> Patchwork_14567
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14567/index.html
Known issues
Here are the changes found in Patchwork_14567 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic:
- fi-icl-u2: [PASS][1] -> [FAIL][2] ([fdo#111699])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-icl-u2/igt@gem_exec_susp...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14567/fi-icl-u2/igt@gem_exec_susp...@basic.html
* igt@gem_mmap@basic-small-bo:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-icl-u3/igt@gem_m...@basic-small-bo.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14567/fi-icl-u3/igt@gem_m...@basic-small-bo.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-bxt-dsi: [INCOMPLETE][5] ([fdo#103927] / [fdo#111381]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14567/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14567/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@gem_mmap@basic:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-icl-u3/igt@gem_m...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14567/fi-icl-u3/igt@gem_m...@basic.html
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724] / [fdo#111214]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-icl-u3/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14567/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-6600u: [FAIL][13] ([fdo#107707]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14567/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][15] ([fdo#111407]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14567/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107707]: https://bugs.freedesktop.org/show_bug.cgi?id=107707
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
[fdo#111699]: https://bugs.freedesktop.org/show_bug.cgi?id=111699
Participating hosts (51 -> 46)
--
Additional (2): fi-hsw-peppy fi-skl-guc
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6969 -> Patchwork_14567
CI-20190529: 20190529
CI_DRM_6969: ad0d6a2a5bb90cccef673bf3722a8ee08647cf7f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5206: 5a6c68568def840cd720f18fc66f529a89f84675 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14567: 8d355db806fe7fdfbcace7ddc4fabfd7e7e052ed @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8d355db806fe drm/i915/gt: Only unwedge if we can reset first
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14567/ind
Re: [Intel-gfx] [PATCH 12/21] drm/i915: Mark up address spaces that may need to allocate
Quoting Tvrtko Ursulin (2019-09-25 16:59:26)
>
> On 25/09/2019 09:23, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-09-23 09:10:26)
> >>
> >> On 20/09/2019 17:35, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2019-09-20 17:22:42)
>
> On 02/09/2019 05:02, Chris Wilson wrote:
> > Since we cannot allocate underneath the vm->mutex (it is used in the
> > direct-reclaim paths), we need to shift the allocations off into a
> > mutexless worker with fence recursion prevention. To know when we need
> > this protection, we mark up the address spaces that do allocate before
> > insertion.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +++
> > drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 9095f017162e..56d27cf09a3d 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -1500,6 +1500,7 @@ static struct i915_ppgtt
> > *gen8_ppgtt_create(struct drm_i915_private *i915)
> > goto err_free_pd;
> > }
> >
> > + ppgtt->vm.bind_alloc = I915_VMA_LOCAL_BIND;
>
> So this is re-using I915_VMA_LOCAL_BIND as a trick? Is it clear how that
> works from these call sites? Should it be called bind_alloc*s*?
> bind_allocates? Or be a boolean which is converted to a trick flag in
> i915_vma_bind where a comment can be put explaining the trick?
> >>>
> >>> Is it a trick? We need to differentiate between requests for LOCAL_BIND,
> >>> GLOBAL_BIND, LOCAL_BIND | GLOBAL_BIND, for different types of vm. Then I
> >>> have a plan on using the worker for GLOBAL_BIND on bsw/bxt to defer the
> >>> stop_machine().
> >>
> >> What's the connection between "mark up the address spaces that do
> >> allocate before insertion" and I915_VMA_LOCAL_BIND?
> >
> > Full-ppgtt is only accessible by PIN_USER.
> >
> > Aliasing-ppgtt is accessible from global-gtt as PIN_USER. Only if we
> > have an aliasing-gtt behind ggtt do we want to allocate for ggtt for
> > local binds.
> >
> > global-gtt by itself never allocates and is expected to be synchronous.
> > However, we do use stop_machine() for bxt/bsw and that unfortunately is
> > marked as an allocating mutex so one idea I had for avoiding that
> > lockdep splat was to make bxt/bsw PIN_GLOBAL async.
>
> I think we are not understanding each other from the very start.
>
> My point was that "vm.bind_alloc = I915_VMA_LOCAL_BIND", at least my
> understanding, effectively means "use the worker when pinning/binding
> PIN_USER/I915_VMA_LOCAL_BIND". And that is I think non-obvious. Where
> you have in the code:
>
> if (flags & vma->vm->bind_alloc)
>
> It is a shorter hacky way of saying:
>
> if (*flags & I915_VMA_LOCAL_BIND) &&
> vma->vm->bind_allocates)
>
> Or where you have:
>
> if (work && (bind_flags & ~vma_flags) & vma->vm->bind_alloc) {
>
> This would be:
>
> if (work &&
> vma->vm->bind_allocates &&
> (bind_flags & I915_VMA_LOCAL_BIND) &&
> !(vma_flags & I915_VMA_LOCAL_BIND)) {
>
> But I think I see now what your code is actually saying, you are having
> vm->bind_alloc mean vm->bind_flags_which_allocate. Did I get your
> thinking right now? If so compromise with renaming to vm->bind_alloc_flags?
vm->bind_alloc_flags it is.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 7/7] drm/i915/tgl: Add DC3CO counter in i915_dmc_info
On 2019-09-27 at 19:38:49 +0300, Imre Deak wrote:
> On Thu, Sep 26, 2019 at 08:26:21PM +0530, Anshuman Gupta wrote:
> > Adding DC3CO counter in i915_dmc_info debugfs will be
> > useful for DC3CO validation.
> > DMC firmware uses DMC_DEBUG3 register as DC3CO counter
> > register on TGL, as per B.Specs DMC_DEBUG3 is general
> > purpose register.
> >
> > Cc: Jani Nikula
> > Cc: Imre Deak
> > Cc: Animesh Manna
> > Signed-off-by: Anshuman Gupta
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
> > drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index b5b449a88cf1..8a16bbd31212 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2407,6 +2407,12 @@ static int i915_dmc_info(struct seq_file *m, void
> > *unused)
> > seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
> >CSR_VERSION_MINOR(csr->version));
> >
> > + /*
> > +* TGL DMC f/w uses DMC_DEBUG3 register for DC3CO counter.
> > +*/
>
> The above is obvious from the code itself, so we don't need a comment
> for it. Please also consider removing all other comments in the patchset
> that state only what is obvious from the code.
DMC_DEBUG3 is a DMC general purpose register, B.Specs doesn't specify
it as DC3CO counter unlike DC5 and DC6, that is why i have added
this comment. Shall i remove this comment considering DMC_DEBUG3
as general purpose register?
>
> > + if (IS_TIGERLAKE(dev_priv))
>
> The above should match the check in get_allowed_dc_mask().
IS_TIGERLAKE is being checked for the same reason as TGL
DMC is using DMC_DEBUG3 for DC3CO counter. It may not be true
for other Gen12 platfrom.
Thanks,
Anshuman Gupta.
>
> > + seq_printf(m, "DC3CO count: %d\n", I915_READ(DMC_DEBUG3));
> > +
> > if (INTEL_GEN(dev_priv) >= 12) {
> > dc5_reg = TGL_DMC_DEBUG_DC5_COUNT;
> > dc6_reg = TGL_DMC_DEBUG_DC6_COUNT;
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 3ee9720af207..af810f6ed652 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7263,6 +7263,8 @@ enum {
> > #define TGL_DMC_DEBUG_DC5_COUNT_MMIO(0x101084)
> > #define TGL_DMC_DEBUG_DC6_COUNT_MMIO(0x101088)
> >
> > +#define DMC_DEBUG3 _MMIO(0x101090)
> > +
> > /* interrupts */
> > #define DE_MASTER_IRQ_CONTROL (1 << 31)
> > #define DE_SPRITEB_FLIP_DONE(1 << 29)
> > --
> > 2.21.0
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/userptr: Never allow userptr into the mappable GGTT
== Series Details ==
Series: drm/i915/userptr: Never allow userptr into the mappable GGTT
URL : https://patchwork.freedesktop.org/series/67349/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6969 -> Patchwork_14568
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14568/index.html
Known issues
Here are the changes found in Patchwork_14568 that come from known issues:
### IGT changes ###
Issues hit
* igt@prime_busy@basic-wait-before-default:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-icl-u3/igt@prime_b...@basic-wait-before-default.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14568/fi-icl-u3/igt@prime_b...@basic-wait-before-default.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-bxt-dsi: [INCOMPLETE][3] ([fdo#103927] / [fdo#111381]) ->
[PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14568/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14568/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724] / [fdo#111214]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-icl-u3/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14568/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-6600u: [FAIL][9] ([fdo#107707]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14568/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-icl-u3/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14568/fi-icl-u3/igt@i915_pm_...@module-reload.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][13] ([fdo#111407]) -> [FAIL][14] ([fdo#111045]
/ [fdo#111096])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6969/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14568/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107707]: https://bugs.freedesktop.org/show_bug.cgi?id=107707
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (51 -> 45)
--
Additional (2): fi-hsw-peppy fi-skl-guc
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-pnv-d510 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6969 -> Patchwork_14568
CI-20190529: 20190529
CI_DRM_6969: ad0d6a2a5bb90cccef673bf3722a8ee08647cf7f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5206: 5a6c68568def840cd720f18fc66f529a89f84675 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14568: e7fbf6cde45c8cf137b60ab119d7400609829120 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e7fbf6cde45c drm/i915/userptr: Never allow userptr into the mappable GGTT
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14568/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/tgl: Remove single pipe restriction from SAGV
On Thu, Sep 26, 2019 at 03:34:35PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 25, 2019 at 01:33:52PM -0700, James Ausmus wrote:
> > For Gen12, BSpec no longer tells us to disable SAGV when > 1 pipe is
> > active. Update intel_can_enable_sagv to allow this, and loop through all
> > active planes on all active crtcs to check against the interlaced and
> > latency restrictions.
> >
> > BSpec: 49325
> >
> > Cc: Ville Syrjälä
> > Cc: Stanislav Lisovskiy
> > Cc: Lucas De Marchi
> > Signed-off-by: James Ausmus
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 63 +
> > 1 file changed, 32 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index ca2bec09edb5..cb50c697a6b8 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3775,7 +3775,6 @@ bool intel_can_enable_sagv(struct intel_atomic_state
> > *state)
> > struct intel_crtc *crtc;
> > struct intel_plane *plane;
> > struct intel_crtc_state *crtc_state;
> > - enum pipe pipe;
> > int level, latency;
> > int sagv_block_time_us;
> >
> > @@ -3791,47 +3790,49 @@ bool intel_can_enable_sagv(struct
> > intel_atomic_state *state)
> > return true;
> >
> > /*
> > -* SKL+ workaround: bspec recommends we disable SAGV when we have
> > +* SKL-ICL workaround: bspec recommends we disable SAGV when we have
> > * more then one pipe enabled
> > */
> > - if (hweight8(state->active_pipes) > 1)
> > + if (INTEL_GEN(dev_priv) < 12 && hweight8(state->active_pipes) > 1)
> > return false;
> >
> > - /* Since we're now guaranteed to only have one active CRTC... */
> > - pipe = ffs(state->active_pipes) - 1;
> > - crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> > - crtc_state = to_intel_crtc_state(crtc->base.state);
> > + for_each_intel_crtc(&dev_priv->drm, crtc) {
> > + crtc_state = to_intel_crtc_state(crtc->base.state);
> > + if (!crtc_state->base.active)
> > + continue;
> >
> > - if (crtc->base.state->adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE)
> > - return false;
> > + if (crtc->base.state->adjusted_mode.flags &
> > + DRM_MODE_FLAG_INTERLACE)
> > + return false;
> >
> > - for_each_intel_plane_on_crtc(dev, crtc, plane) {
> > - struct skl_plane_wm *wm =
> > - &crtc_state->wm.skl.optimal.planes[plane->id];
> > + for_each_intel_plane_on_crtc(dev, crtc, plane) {
> > + struct skl_plane_wm *wm =
> > + &crtc_state->wm.skl.optimal.planes[plane->id];
>
> This whole loop is bothering me. I'd much rather we move to a scheme
> where each plane computes it's SAGV friendlyness when computing the
> watermarks. We'll anyway need that since we need to caclulate the
> watermarks differently for the SAGV on vs. off cases.
Hmm, I'll have to look in to this. In the meantime, I'd like to get
patches 1 & 2 of this series moving forward, as those should be what's
really necessary to be able to turn on SAGV for TGL once we're ready, so
I'll send those as a separate series, and leave relaxing the 1 pipe
restriction as it's own work.
-James
>
> >
> > - /* Skip this plane if it's not enabled */
> > - if (!wm->wm[0].plane_en)
> > - continue;
> > + /* Skip this plane if it's not enabled */
> > + if (!wm->wm[0].plane_en)
> > + continue;
> >
> > - /* Find the highest enabled wm level for this plane */
> > - for (level = ilk_wm_max_level(dev_priv);
> > -!wm->wm[level].plane_en; --level)
> > -{ }
> > + /* Find the highest enabled wm level for this plane */
> > + for (level = ilk_wm_max_level(dev_priv);
> > +!wm->wm[level].plane_en; --level)
> > +{ }
> >
> > - latency = dev_priv->wm.skl_latency[level];
> > + latency = dev_priv->wm.skl_latency[level];
> >
> > - if (skl_needs_memory_bw_wa(dev_priv) &&
> > - plane->base.state->fb->modifier ==
> > - I915_FORMAT_MOD_X_TILED)
> > - latency += 15;
> > + if (skl_needs_memory_bw_wa(dev_priv) &&
> > + plane->base.state->fb->modifier ==
> > + I915_FORMAT_MOD_X_TILED)
> > + latency += 15;
> >
> > - /*
> > -* If any of the planes on this pipe don't enable wm levels that
> > -* incur memory latencies higher than sagv_block_time_us we
> > -* can't enable SAGV.
> > -*/
> > - if (latency < sagv_block_time_us)
> > - return false;
> > + /*
> > +
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/4] drm/i915/tc: Update DP_MODE programming
== Series Details == Series: series starting with [CI,1/4] drm/i915/tc: Update DP_MODE programming URL : https://patchwork.freedesktop.org/series/67312/ State : success == Summary == CI Bug Log - changes from CI_DRM_6966_full -> Patchwork_14561_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14561_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@promotion-bsd1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +16 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb1/igt@gem_exec_sched...@promotion-bsd1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb5/igt@gem_exec_sched...@promotion-bsd1.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb6/igt@gem_exec_sched...@reorder-wide-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_tiled_wc: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb3/igt@gem_tiled_wc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb7/igt@gem_tiled_wc.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108] / [fdo#107807]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-skl2/igt@i915_pm_...@system-suspend-execbuf.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-skl5/igt@i915_pm_...@system-suspend-execbuf.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-apl5/igt@i915_susp...@sysfs-reader.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-apl4/igt@i915_susp...@sysfs-reader.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103166]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-x.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb5/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-apl: [PASS][17] -> [INCOMPLETE][18] ([fdo#103927]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-apl1/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-apl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#104108]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-skl10/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-skl8/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-iclb: [PASS][21] -> [DMESG-WARN][22] ([fdo#111764]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb1/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb7/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html Possible fixes * igt@gem_ctx_isolation@vcs1-dirty-create: - shard-iclb: [SKIP][23] ([fdo#109276]) -> [PASS][24] +11 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb6/igt@gem_ctx_isolat...@vcs1-dirty-create.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb2/igt@gem_ctx_isolat...@vcs1-dirty-create.html * igt@gem_exec_balancer@smoke: - shard-iclb: [SKIP][25] ([fdo#110854]) ->
[Intel-gfx] [PATCH 00/22] LMEM basics
The basic LMEM bits, minus the uAPI, pruning, etc. The goal is to support basic LMEM object creation within the kernel. From there we can start with the dumb buffer support, and then the other display related bits. We still have a few patches that deal with lack of MAPPABLE_APERTURE support, though we can probably split that into its own series. Patches 1-2 are just noise. Patches 3-6 are the basic intel_memory_region bits + basic mock_selftests. Patches 7-11 are the basic LMEM region bits + basic live_selftests. Patches 12-14 try to turn stolen + shmem into intel_region_regions. Patches 15-21 implement the !MAPPABLE_APERTURE bits. The fake LMEM patch allows us to run the live_selftests with LMEM enabled and !HAS_MAPPABLE_APERTURE in CI. Abdiel Janulgue (4): drm/i915: Add memory region information to device_info drm/i915: setup io-mapping for LMEM drm/i915/lmem: support kernel mapping drm/i915: enumerate and init each supported region CQ Tang (1): drm/i915: check for missing aperture in GTT pread/pwrite paths Daniele Ceraolo Spurio (4): drm/i915: define HAS_MAPPABLE_APERTURE drm/i915: do not map aperture if it is not available. drm/i915: set num_fence_regs to 0 if there is no aperture drm/i915: error capture with no ggtt slot Matthew Auld (12): drm/i915: check for kernel_context drm/i915: simplify i915_gem_init_early drm/i915: introduce intel_memory_region drm/i915/region: support continuous allocations drm/i915/region: support volatile objects drm/i915: support creating LMEM objects drm/i915/selftests: add write-dword test for LMEM drm/i915/selftest: extend coverage to include LMEM huge-pages drm/i915: treat shmem as a region drm/i915: treat stolen as a region drm/i915/selftests: check for missing aperture HAX drm/i915: add the fake lmem region Michal Wajdeczko (1): drm/i915: Don't try to place HWS in non-existing mappable region arch/x86/kernel/early-quirks.c| 26 + drivers/gpu/drm/i915/Makefile | 4 + drivers/gpu/drm/i915/gem/i915_gem_internal.c | 21 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 70 +++ drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 31 + drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 23 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 26 +- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 5 +- drivers/gpu/drm/i915/gem/i915_gem_region.c| 166 + drivers/gpu/drm/i915/gem/i915_gem_region.h| 29 + drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 71 ++- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 71 ++- drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 3 +- .../drm/i915/gem/selftests/huge_gem_object.c | 4 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 212 ++- .../i915/gem/selftests/i915_gem_coherency.c | 5 +- .../drm/i915/gem/selftests/i915_gem_mman.c| 6 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 14 +- drivers/gpu/drm/i915/i915_drv.c | 13 +- drivers/gpu/drm/i915/i915_drv.h | 17 +- drivers/gpu/drm/i915/i915_gem.c | 19 +- drivers/gpu/drm/i915/i915_gem_fence_reg.c | 6 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 119 +++- drivers/gpu/drm/i915/i915_gpu_error.c | 65 +- drivers/gpu/drm/i915/i915_pci.c | 29 +- drivers/gpu/drm/i915/intel_device_info.h | 2 + drivers/gpu/drm/i915/intel_memory_region.c| 192 ++ drivers/gpu/drm/i915/intel_memory_region.h| 119 drivers/gpu/drm/i915/intel_region_lmem.c | 157 + drivers/gpu/drm/i915/intel_region_lmem.h | 16 + drivers/gpu/drm/i915/selftests/i915_gem.c | 3 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 8 +- .../drm/i915/selftests/i915_live_selftests.h | 1 + .../drm/i915/selftests/i915_mock_selftests.h | 1 + .../drm/i915/selftests/intel_memory_region.c | 587 ++ .../gpu/drm/i915/selftests/mock_gem_device.c | 9 +- drivers/gpu/drm/i915/selftests/mock_region.c | 59 ++ drivers/gpu/drm/i915/selftests/mock_region.h | 16 + include/drm/i915_drm.h| 3 + 41 files changed, 2115 insertions(+), 134 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_lmem.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_lmem.h create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_region.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_region.h create mode 100644 drivers/gpu/drm/i915/intel_memory_region.c create mode 100644 drivers/gpu/drm/i915/intel_memory_region.h create mode 100644 drivers/gpu/drm/i915/intel_region_lmem.c create mode 100644 drivers/gpu/drm/i915/intel_region_lmem.h create mode 100644 drivers/gpu/drm/i915/selftests/intel_memory_region.c create mode 100644 drivers/gpu/drm/i915/selftests/mock_region.c create mode 100644 drivers/gpu/drm/i915/selftests/mock_region.h -- 2.
[Intel-gfx] [PATCH 01/22] drm/i915: check for kernel_context
Explosions during early driver init on the error path. Make sure we fail
gracefully.
[ 9547.672258] BUG: kernel NULL pointer dereference, address: 007c
[ 9547.672288] #PF: supervisor read access in kernel mode
[ 9547.672292] #PF: error_code(0x) - not-present page
[ 9547.672296] PGD 800846b41067 P4D 800846b41067 PUD 797034067 PMD 0
[ 9547.672303] Oops: [#1] SMP PTI
[ 9547.672307] CPU: 1 PID: 25634 Comm: i915_selftest Tainted: G U
5.3.0-rc8+ #73
[ 9547.672313] Hardware name: /NUC6i7KYB, BIOS
KYSKLi70.86A.0050.2017.0831.1924 08/31/2017
[ 9547.672395] RIP: 0010:intel_context_unpin+0x9/0x100 [i915]
[ 9547.672400] Code: 6b 60 00 e9 17 ff ff ff bd fc ff ff ff e9 7c ff ff ff 66
66 2e 0f 1f 84 00 00 00 00
00 0f 1f 40 00 0f 1f 44 00 00 41 54 55 53 <8b> 47 7c 83 f8 01 74 26 8d 48 ff
f0 0f b1 4f 7c 48 8d 57 7c
75 05
[ 9547.672413] RSP: 0018:ae8ac24ff878 EFLAGS: 00010246
[ 9547.672417] RAX: 944a1b7842d0 RBX: 944a1b784000 RCX: 944a12dd6fa8
[ 9547.672422] RDX: 944a1b7842c0 RSI: 944a12dd5328 RDI:
[ 9547.672428] RBP: R08: 944a11e5d840 R09:
[ 9547.672433] R10: R11: R12:
[ 9547.672438] R13: c11aaf00 R14: ffe4 R15: 944a0e29bf38
[ 9547.672443] FS: 7fc259b88ac0() GS:944a1f88()
knlGS:
[ 9547.672449] CS: 0010 DS: ES: CR0: 80050033
[ 9547.672454] CR2: 007c CR3: 000853346003 CR4: 003606e0
[ 9547.672459] DR0: DR1: DR2:
[ 9547.672464] DR3: DR6: fffe0ff0 DR7: 0400
[ 9547.672469] Call Trace:
[ 9547.672518] intel_engine_cleanup_common+0xe3/0x270 [i915]
[ 9547.672567] execlists_destroy+0xe/0x30 [i915]
[ 9547.672669] intel_engines_init+0x94/0xf0 [i915]
[ 9547.672749] i915_gem_init+0x191/0x950 [i915]
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index f451d5076bde..f97686bdc28b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -820,8 +820,11 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine)
if (engine->default_state)
i915_gem_object_put(engine->default_state);
- intel_context_unpin(engine->kernel_context);
- intel_context_put(engine->kernel_context);
+ if (engine->kernel_context) {
+ intel_context_unpin(engine->kernel_context);
+ intel_context_put(engine->kernel_context);
+ }
+
GEM_BUG_ON(!llist_empty(&engine->barrier_tasks));
intel_wa_list_free(&engine->ctx_wa_list);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/22] drm/i915: simplify i915_gem_init_early
i915_gem_init_early doesn't need to return anything.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.c | 5 +
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 4 +---
3 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a9ee73b61f4d..91aae56b4280 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -589,9 +589,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
intel_gt_init_early(&dev_priv->gt, dev_priv);
- ret = i915_gem_init_early(dev_priv);
- if (ret < 0)
- goto err_gt;
+ i915_gem_init_early(dev_priv);
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev_priv);
@@ -613,7 +611,6 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
err_gem:
i915_gem_cleanup_early(dev_priv);
-err_gt:
intel_gt_driver_late_release(&dev_priv->gt);
vlv_free_s0ix_state(dev_priv);
err_workqueues:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b3c7dbc1832a..0dc504fc6ffc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2250,7 +2250,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void
*data,
int i915_gem_init_userptr(struct drm_i915_private *dev_priv);
void i915_gem_cleanup_userptr(struct drm_i915_private *dev_priv);
void i915_gem_sanitize(struct drm_i915_private *i915);
-int i915_gem_init_early(struct drm_i915_private *dev_priv);
+void i915_gem_init_early(struct drm_i915_private *dev_priv);
void i915_gem_cleanup_early(struct drm_i915_private *dev_priv);
int i915_gem_freeze(struct drm_i915_private *dev_priv);
int i915_gem_freeze_late(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e2897a666225..3d3fda4cae99 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1533,7 +1533,7 @@ static void i915_gem_init__mm(struct drm_i915_private
*i915)
i915_gem_init__objects(i915);
}
-int i915_gem_init_early(struct drm_i915_private *dev_priv)
+void i915_gem_init_early(struct drm_i915_private *dev_priv)
{
int err;
@@ -1545,8 +1545,6 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
err = i915_gemfs_init(dev_priv);
if (err)
DRM_NOTE("Unable to create a private tmpfs mount, hugepage
support will be disabled(%d).\n", err);
-
- return 0;
}
void i915_gem_cleanup_early(struct drm_i915_private *dev_priv)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/22] drm/i915/region: support continuous allocations
Some kernel internal objects may need to be allocated as a continuous
block, also thinking ahead the various kernel io_mapping interfaces seem
to expect it, although this is purely a limitation in the kernel
API...so perhaps something to be improved.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 4 +
drivers/gpu/drm/i915/gem/i915_gem_region.c| 15 +-
drivers/gpu/drm/i915/gem/i915_gem_region.h| 3 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 3 +-
drivers/gpu/drm/i915/intel_memory_region.c| 13 +-
drivers/gpu/drm/i915/intel_memory_region.h| 3 +-
.../drm/i915/selftests/intel_memory_region.c | 163 ++
drivers/gpu/drm/i915/selftests/mock_region.c | 2 +-
8 files changed, 197 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index d36c860c9c6f..7acd383f174f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -117,6 +117,10 @@ struct drm_i915_gem_object {
I915_SELFTEST_DECLARE(struct list_head st_link);
+ unsigned long flags;
+#define I915_BO_ALLOC_CONTIGUOUS BIT(0)
+#define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS)
+
/*
* Is the object to be mapped as read-only to the GPU
* Only honoured if hardware has relevant pte bit
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 5c3bfc121921..b317a5c84144 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -23,10 +23,10 @@ i915_gem_object_get_pages_buddy(struct drm_i915_gem_object
*obj)
{
struct intel_memory_region *mem = obj->mm.region;
struct list_head *blocks = &obj->mm.blocks;
- unsigned int flags = I915_ALLOC_MIN_PAGE_SIZE;
resource_size_t size = obj->base.size;
resource_size_t prev_end;
struct i915_buddy_block *block;
+ unsigned int flags;
struct sg_table *st;
struct scatterlist *sg;
unsigned int sg_page_sizes;
@@ -42,6 +42,10 @@ i915_gem_object_get_pages_buddy(struct drm_i915_gem_object
*obj)
return -ENOMEM;
}
+ flags = I915_ALLOC_MIN_PAGE_SIZE;
+ if (obj->flags & I915_BO_ALLOC_CONTIGUOUS)
+ flags |= I915_ALLOC_CONTIGUOUS;
+
ret = __intel_memory_region_get_pages_buddy(mem, size, flags, blocks);
if (ret)
goto err_free_sg;
@@ -56,7 +60,8 @@ i915_gem_object_get_pages_buddy(struct drm_i915_gem_object
*obj)
list_for_each_entry(block, blocks, link) {
u64 block_size, offset;
- block_size = i915_buddy_block_size(&mem->mm, block);
+ block_size = min_t(u64, size,
+ i915_buddy_block_size(&mem->mm, block));
offset = i915_buddy_block_offset(block);
GEM_BUG_ON(overflows_type(block_size, sg->length));
@@ -98,10 +103,12 @@ i915_gem_object_get_pages_buddy(struct drm_i915_gem_object
*obj)
}
void i915_gem_object_init_memory_region(struct drm_i915_gem_object *obj,
- struct intel_memory_region *mem)
+ struct intel_memory_region *mem,
+ unsigned long flags)
{
INIT_LIST_HEAD(&obj->mm.blocks);
obj->mm.region = mem;
+ obj->flags = flags;
}
void i915_gem_object_release_memory_region(struct drm_i915_gem_object *obj)
@@ -115,6 +122,8 @@ i915_gem_object_create_region(struct intel_memory_region
*mem,
{
struct drm_i915_gem_object *obj;
+ GEM_BUG_ON(flags & ~I915_BO_ALLOC_FLAGS);
+
if (!mem)
return ERR_PTR(-ENODEV);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.h
b/drivers/gpu/drm/i915/gem/i915_gem_region.h
index ebddc86d78f7..f2ff6f8bff74 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.h
@@ -17,7 +17,8 @@ void i915_gem_object_put_pages_buddy(struct
drm_i915_gem_object *obj,
struct sg_table *pages);
void i915_gem_object_init_memory_region(struct drm_i915_gem_object *obj,
- struct intel_memory_region *mem);
+ struct intel_memory_region *mem,
+ unsigned long flags);
void i915_gem_object_release_memory_region(struct drm_i915_gem_object *obj);
struct drm_i915_gem_object *
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 4e1805aaeb99..f9fbf2865782 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -471,7 +471,8 @@ static int igt_mock
[Intel-gfx] [PATCH 03/22] drm/i915: introduce intel_memory_region
Support memory regions, as defined by a given (start, end), and allow
creating GEM objects which are backed by said region. The immediate goal
here is to have something to represent our device memory, but later on
we also want to represent every memory domain with a region, so stolen,
shmem, and of course device. At some point we are probably going to want
use a common struct here, such that we are better aligned with say TTM.
Signed-off-by: Matthew Auld
Signed-off-by: Abdiel Janulgue
Signed-off-by: Niranjana Vishwanathapura
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/Makefile | 2 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 9 +
drivers/gpu/drm/i915/gem/i915_gem_region.c| 133 ++
drivers/gpu/drm/i915/gem/i915_gem_region.h| 28 +++
.../gpu/drm/i915/gem/selftests/huge_pages.c | 78
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_memory_region.c| 173 ++
drivers/gpu/drm/i915/intel_memory_region.h| 77
.../drm/i915/selftests/i915_mock_selftests.h | 1 +
.../drm/i915/selftests/intel_memory_region.c | 124 +
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
drivers/gpu/drm/i915/selftests/mock_region.c | 59 ++
drivers/gpu/drm/i915/selftests/mock_region.h | 16 ++
13 files changed, 702 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_region.c
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_region.h
create mode 100644 drivers/gpu/drm/i915/intel_memory_region.c
create mode 100644 drivers/gpu/drm/i915/intel_memory_region.h
create mode 100644 drivers/gpu/drm/i915/selftests/intel_memory_region.c
create mode 100644 drivers/gpu/drm/i915/selftests/mock_region.c
create mode 100644 drivers/gpu/drm/i915/selftests/mock_region.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6313e7b4bd78..d849dff31f76 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -50,6 +50,7 @@ i915-y += i915_drv.o \
i915_utils.o \
intel_csr.o \
intel_device_info.o \
+ intel_memory_region.o \
intel_pch.o \
intel_pm.o \
intel_runtime_pm.o \
@@ -118,6 +119,7 @@ gem-y += \
gem/i915_gem_pages.o \
gem/i915_gem_phys.o \
gem/i915_gem_pm.o \
+ gem/i915_gem_region.o \
gem/i915_gem_shmem.o \
gem/i915_gem_shrinker.o \
gem/i915_gem_stolen.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index d695f187b790..d36c860c9c6f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -158,6 +158,15 @@ struct drm_i915_gem_object {
atomic_t pages_pin_count;
atomic_t shrink_pin;
+ /**
+* Memory region for this object.
+*/
+ struct intel_memory_region *region;
+ /**
+* List of memory region blocks allocated for this object.
+*/
+ struct list_head blocks;
+
struct sg_table *pages;
void *mapping;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
new file mode 100644
index ..5c3bfc121921
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "intel_memory_region.h"
+#include "i915_gem_region.h"
+#include "i915_drv.h"
+
+void
+i915_gem_object_put_pages_buddy(struct drm_i915_gem_object *obj,
+ struct sg_table *pages)
+{
+ __intel_memory_region_put_pages_buddy(obj->mm.region, &obj->mm.blocks);
+
+ obj->mm.dirty = false;
+ sg_free_table(pages);
+ kfree(pages);
+}
+
+int
+i915_gem_object_get_pages_buddy(struct drm_i915_gem_object *obj)
+{
+ struct intel_memory_region *mem = obj->mm.region;
+ struct list_head *blocks = &obj->mm.blocks;
+ unsigned int flags = I915_ALLOC_MIN_PAGE_SIZE;
+ resource_size_t size = obj->base.size;
+ resource_size_t prev_end;
+ struct i915_buddy_block *block;
+ struct sg_table *st;
+ struct scatterlist *sg;
+ unsigned int sg_page_sizes;
+ unsigned long i;
+ int ret;
+
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return -ENOMEM;
+
+ if (sg_alloc_table(st, size >> ilog2(mem->mm.chunk_size), GFP_KERNEL)) {
+ kfree(st);
+ return -ENOMEM;
+ }
+
+ ret = __intel_memory_region_get_pages_buddy(mem, size, flags, blocks);
+ if (ret)
+ goto err_free_sg;
+
+ GEM_BUG_ON(list_empty(blocks));
+
+ sg = st->sgl;
+ st->nents = 0;
+ sg_page_sizes = 0;
+ i = 0;
+
+
[Intel-gfx] [PATCH 08/22] drm/i915: setup io-mapping for LMEM
From: Abdiel Janulgue
Signed-off-by: Abdiel Janulgue
Cc: Matthew Auld
---
drivers/gpu/drm/i915/intel_region_lmem.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
b/drivers/gpu/drm/i915/intel_region_lmem.c
index 7a3f96e1f766..051069664074 100644
--- a/drivers/gpu/drm/i915/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/intel_region_lmem.c
@@ -36,8 +36,32 @@ lmem_create_object(struct intel_memory_region *mem,
return obj;
}
+static void
+region_lmem_release(struct intel_memory_region *mem)
+{
+ io_mapping_fini(&mem->iomap);
+ intel_memory_region_release_buddy(mem);
+}
+
+static int
+region_lmem_init(struct intel_memory_region *mem)
+{
+ int ret;
+
+ if (!io_mapping_init_wc(&mem->iomap,
+ mem->io_start,
+ resource_size(&mem->region)))
+ return -EIO;
+
+ ret = intel_memory_region_init_buddy(mem);
+ if (ret)
+ io_mapping_fini(&mem->iomap);
+
+ return ret;
+}
+
const struct intel_memory_region_ops intel_region_lmem_ops = {
- .init = intel_memory_region_init_buddy,
- .release = intel_memory_region_release_buddy,
+ .init = region_lmem_init,
+ .release = region_lmem_release,
.create_object = lmem_create_object,
};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/22] drm/i915/region: support volatile objects
Volatile objects are marked as DONTNEED while pinned, therefore once
unpinned the backing store can be discarded. This is limited to kernel
internal objects.
Signed-off-by: Matthew Auld
Signed-off-by: CQ Tang
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c| 17 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 6 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h| 9 -
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_region.c | 12
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12
drivers/gpu/drm/i915/intel_memory_region.c | 4
drivers/gpu/drm/i915/intel_memory_region.h | 5 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 5 ++---
9 files changed, 56 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index 0c41e04ab8fa..5e72cb1cc2d3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -117,13 +117,6 @@ static int i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
goto err;
}
- /* Mark the pages as dontneed whilst they are still pinned. As soon
-* as they are unpinned they are allowed to be reaped by the shrinker,
-* and the caller is expected to repopulate - the contents of this
-* object are only valid whilst active and pinned.
-*/
- obj->mm.madv = I915_MADV_DONTNEED;
-
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
return 0;
@@ -143,7 +136,6 @@ static void i915_gem_object_put_pages_internal(struct
drm_i915_gem_object *obj,
internal_free_pages(pages);
obj->mm.dirty = false;
- obj->mm.madv = I915_MADV_WILLNEED;
}
static const struct drm_i915_gem_object_ops i915_gem_object_internal_ops = {
@@ -188,6 +180,15 @@ i915_gem_object_create_internal(struct drm_i915_private
*i915,
drm_gem_private_object_init(&i915->drm, &obj->base, size);
i915_gem_object_init(obj, &i915_gem_object_internal_ops);
+ /*
+* Mark the object as volatile, such that the pages are marked as
+* dontneed whilst they are still pinned. As soon as they are unpinned
+* they are allowed to be reaped by the shrinker, and the caller is
+* expected to repopulate - the contents of this object are only valid
+* whilst active and pinned.
+*/
+ obj->flags = I915_BO_ALLOC_VOLATILE;
+
obj->read_domains = I915_GEM_DOMAIN_CPU;
obj->write_domain = I915_GEM_DOMAIN_CPU;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 29b9eddc4c7f..d5839cbd82c0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -122,6 +122,12 @@ i915_gem_object_lock_fence(struct drm_i915_gem_object
*obj);
void i915_gem_object_unlock_fence(struct drm_i915_gem_object *obj,
struct dma_fence *fence);
+static inline bool
+i915_gem_object_is_volatile(const struct drm_i915_gem_object *obj)
+{
+ return obj->flags & I915_BO_ALLOC_VOLATILE;
+}
+
static inline void
i915_gem_object_set_readonly(struct drm_i915_gem_object *obj)
{
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 7acd383f174f..0d934b67e547 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -119,7 +119,8 @@ struct drm_i915_gem_object {
unsigned long flags;
#define I915_BO_ALLOC_CONTIGUOUS BIT(0)
-#define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS)
+#define I915_BO_ALLOC_VOLATILE BIT(1)
+#define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | I915_BO_ALLOC_VOLATILE)
/*
* Is the object to be mapped as read-only to the GPU
@@ -170,6 +171,12 @@ struct drm_i915_gem_object {
* List of memory region blocks allocated for this object.
*/
struct list_head blocks;
+ /**
+* Element within memory_region->objects or region->purgeable
+* if the object is marked as DONTNEED. Access is protected by
+* region->obj_lock.
+*/
+ struct list_head region_link;
struct sg_table *pages;
void *mapping;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 2e941f093a20..b0ec0959c13f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -18,6 +18,9 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
*obj,
lockdep_assert_held(&obj->mm.lock);
+ if (i915_gem_object_is_volatile
[Intel-gfx] [PATCH 06/22] drm/i915: Add memory region information to device_info
From: Abdiel Janulgue
Exposes available regions for the platform. Shared memory will
always be available.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8ed4b8c2484f..93116cc8b149 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2170,6 +2170,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_IPC(dev_priv) (INTEL_INFO(dev_priv)->display.has_ipc)
+#define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
+
#define HAS_GT_UC(dev_priv)(INTEL_INFO(dev_priv)->has_gt_uc)
/* Having GuC is not the same as using GuC */
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 0cdc2465534b..e9940f932d26 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -160,6 +160,8 @@ struct intel_device_info {
unsigned int page_sizes; /* page sizes supported by the HW */
+ u32 memory_regions; /* regions supported by the HW */
+
u32 display_mmio_offset;
u8 pipe_mask;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/22] drm/i915/selftests: add write-dword test for LMEM
Simple test writing to dwords across an object, using various engines in
a randomized order, checking that our writes land from the cpu.
Signed-off-by: Matthew Auld
---
.../drm/i915/selftests/intel_memory_region.c | 179 ++
1 file changed, 179 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
index ba98e8254b80..8d7d8b9e00da 100644
--- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
@@ -7,13 +7,16 @@
#include "../i915_selftest.h"
+
#include "mock_drm.h"
#include "mock_gem_device.h"
#include "mock_region.h"
+#include "gem/i915_gem_context.h"
#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_object_blt.h"
+#include "gem/selftests/igt_gem_utils.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_gt.h"
#include "selftests/igt_flush_test.h"
@@ -255,6 +258,133 @@ static int igt_mock_continuous(void *arg)
return err;
}
+static int igt_gpu_write_dw(struct intel_context *ce,
+ struct i915_vma *vma,
+ u32 dword,
+ u32 value)
+{
+ int err;
+
+ i915_gem_object_lock(vma->obj);
+ err = i915_gem_object_set_to_gtt_domain(vma->obj, true);
+ i915_gem_object_unlock(vma->obj);
+ if (err)
+ return err;
+
+ return igt_gpu_fill_dw(ce, vma, dword * sizeof(u32),
+ vma->size >> PAGE_SHIFT, value);
+}
+
+static int igt_cpu_check(struct drm_i915_gem_object *obj, u32 dword, u32 val)
+{
+ unsigned long n;
+ int err;
+
+ i915_gem_object_lock(obj);
+ err = i915_gem_object_set_to_wc_domain(obj, false);
+ i915_gem_object_unlock(obj);
+ if (err)
+ return err;
+
+ err = i915_gem_object_pin_pages(obj);
+ if (err)
+ return err;
+
+ for (n = 0; n < obj->base.size >> PAGE_SHIFT; ++n) {
+ u32 __iomem *base;
+ u32 read_val;
+
+ base = i915_gem_object_lmem_io_map_page_atomic(obj, n);
+
+ read_val = ioread32(base + dword);
+ io_mapping_unmap_atomic(base);
+ if (read_val != val) {
+ pr_err("n=%lu base[%u]=%u, val=%u\n",
+ n, dword, read_val, val);
+ err = -EINVAL;
+ break;
+ }
+ }
+
+ i915_gem_object_unpin_pages(obj);
+ return err;
+}
+
+static int igt_gpu_write(struct i915_gem_context *ctx,
+struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_private *i915 = ctx->i915;
+ struct i915_address_space *vm = ctx->vm ?: &i915->ggtt.vm;
+ struct i915_gem_engines *engines;
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+ I915_RND_STATE(prng);
+ IGT_TIMEOUT(end_time);
+ unsigned int count;
+ struct i915_vma *vma;
+ int *order;
+ int i, n;
+ int err = 0;
+
+ GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
+
+ n = 0;
+ count = 0;
+ for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
+ count++;
+ if (!intel_engine_can_store_dword(ce->engine))
+ continue;
+
+ n++;
+ }
+ i915_gem_context_unlock_engines(ctx);
+ if (!n)
+ return 0;
+
+ order = i915_random_order(count * count, &prng);
+ if (!order)
+ return -ENOMEM;
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto out_free;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ if (err)
+ goto out_free;
+
+ i = 0;
+ engines = i915_gem_context_lock_engines(ctx);
+ do {
+ u32 rng = prandom_u32_state(&prng);
+ u32 dword = offset_in_page(rng) / 4;
+
+ ce = engines->engines[order[i] % engines->num_engines];
+ i = (i + 1) % (count * count);
+ if (!ce || !intel_engine_can_store_dword(ce->engine))
+ continue;
+
+ err = igt_gpu_write_dw(ce, vma, dword, rng);
+ if (err)
+ break;
+
+ err = igt_cpu_check(obj, dword, rng);
+ if (err)
+ break;
+ } while (!__igt_timeout(end_time, NULL));
+ i915_gem_context_unlock_engines(ctx);
+
+out_free:
+ kfree(order);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_lmem_create(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -276,6 +406,54 @@ static int igt_lmem_create(void *arg)
return err;
}
+static int igt_lmem_write_gpu(void *a
[Intel-gfx] [PATCH 11/22] drm/i915/selftest: extend coverage to include LMEM huge-pages
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 121 +-
1 file changed, 120 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index b6dc90030156..434c1fc57adf 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -9,6 +9,7 @@
#include "i915_selftest.h"
#include "gem/i915_gem_region.h"
+#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_pm.h"
#include "gt/intel_gt.h"
@@ -970,7 +971,7 @@ static int gpu_write(struct intel_context *ce,
vma->size >> PAGE_SHIFT, val);
}
-static int cpu_check(struct drm_i915_gem_object *obj, u32 dword, u32 val)
+static int __cpu_check_shmem(struct drm_i915_gem_object *obj, u32 dword, u32
val)
{
unsigned int needs_flush;
unsigned long n;
@@ -1002,6 +1003,51 @@ static int cpu_check(struct drm_i915_gem_object *obj,
u32 dword, u32 val)
return err;
}
+static int __cpu_check_lmem(struct drm_i915_gem_object *obj, u32 dword, u32
val)
+{
+ unsigned long n;
+ int err;
+
+ i915_gem_object_lock(obj);
+ err = i915_gem_object_set_to_wc_domain(obj, false);
+ i915_gem_object_unlock(obj);
+ if (err)
+ return err;
+
+ err = i915_gem_object_pin_pages(obj);
+ if (err)
+ return err;
+
+ for (n = 0; n < obj->base.size >> PAGE_SHIFT; ++n) {
+ u32 __iomem *base;
+ u32 read_val;
+
+ base = i915_gem_object_lmem_io_map_page_atomic(obj, n);
+
+ read_val = ioread32(base + dword);
+ io_mapping_unmap_atomic(base);
+ if (read_val != val) {
+ pr_err("n=%lu base[%u]=%u, val=%u\n",
+ n, dword, read_val, val);
+ err = -EINVAL;
+ break;
+ }
+ }
+
+ i915_gem_object_unpin_pages(obj);
+ return err;
+}
+
+static int cpu_check(struct drm_i915_gem_object *obj, u32 dword, u32 val)
+{
+ if (i915_gem_object_has_struct_page(obj))
+ return __cpu_check_shmem(obj, dword, val);
+ else if (i915_gem_object_is_lmem(obj))
+ return __cpu_check_lmem(obj, dword, val);
+
+ return -ENODEV;
+}
+
static int __igt_write_huge(struct intel_context *ce,
struct drm_i915_gem_object *obj,
u64 size, u64 offset,
@@ -1386,6 +1432,78 @@ static int igt_ppgtt_gemfs_huge(void *arg)
return err;
}
+static int igt_ppgtt_lmem_huge(void *arg)
+{
+ struct i915_gem_context *ctx = arg;
+ struct drm_i915_private *i915 = ctx->i915;
+ struct drm_i915_gem_object *obj;
+ static const unsigned int sizes[] = {
+ SZ_64K,
+ SZ_512K,
+ SZ_1M,
+ SZ_2M,
+ };
+ int i;
+ int err;
+
+ if (!HAS_LMEM(i915)) {
+ pr_info("device lacks LMEM support, skipping\n");
+ return 0;
+ }
+
+ /*
+* Sanity check that the HW uses huge pages correctly through LMEM
+* -- ensure that our writes land in the right place.
+*/
+
+ for (i = 0; i < ARRAY_SIZE(sizes); ++i) {
+ unsigned int size = sizes[i];
+
+ obj = i915_gem_object_create_lmem(i915, size,
I915_BO_ALLOC_CONTIGUOUS);
+ if (IS_ERR(obj)) {
+ err = PTR_ERR(obj);
+ if (err == -E2BIG) {
+ pr_info("object too big for region!\n");
+ return 0;
+ }
+
+ return err;
+ }
+
+ err = i915_gem_object_pin_pages(obj);
+ if (err)
+ goto out_put;
+
+ if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+ pr_info("LMEM unable to allocate huge-page(s) with
size=%u\n",
+ size);
+ goto out_unpin;
+ }
+
+ err = igt_write_huge(ctx, obj);
+ if (err) {
+ pr_err("LMEM write-huge failed with size=%u\n", size);
+ goto out_unpin;
+ }
+
+ i915_gem_object_unpin_pages(obj);
+ __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
+ i915_gem_object_put(obj);
+ }
+
+ return 0;
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_ppgtt_pin_update(void *arg)
{
struct i915_gem_context *ctx = arg;
@@ -1742,6 +1860,7 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
[Intel-gfx] [PATCH 18/22] drm/i915/selftests: check for missing aperture
We may be missing support for the mappable aperture on some platforms.
Signed-off-by: Matthew Auld
Cc: Daniele Ceraolo Spurio
---
.../drm/i915/gem/selftests/i915_gem_coherency.c| 5 -
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 6 ++
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 14 ++
drivers/gpu/drm/i915/selftests/i915_gem.c | 3 +++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 3 +++
5 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index 0ff7a89aadca..07faeada86eb 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -246,7 +246,10 @@ static bool always_valid(struct drm_i915_private *i915)
static bool needs_fence_registers(struct drm_i915_private *i915)
{
- return !intel_gt_is_wedged(&i915->gt);
+ if (intel_gt_is_wedged(&i915->gt))
+ return false;
+
+ return i915->ggtt.num_fences;
}
static bool needs_mi_store_dword(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index aefe557527f8..cb880d73ef73 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -301,6 +301,9 @@ static int igt_partial_tiling(void *arg)
int tiling;
int err;
+ if (!HAS_MAPPABLE_APERTURE(i915))
+ return 0;
+
/* We want to check the page mapping and fencing of a large object
* mmapped through the GTT. The object we create is larger than can
* possibly be mmaped as a whole, and so we must use partial GGTT vma.
@@ -433,6 +436,9 @@ static int igt_smoke_tiling(void *arg)
IGT_TIMEOUT(end);
int err;
+ if (!HAS_MAPPABLE_APERTURE(i915))
+ return 0;
+
/*
* igt_partial_tiling() does an exhastive check of partial tiling
* chunking, but will undoubtably run out of time. Here, we do a
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index a0098fc35921..35cc2c68b32f 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -1189,8 +1189,12 @@ static int __igt_reset_evict_vma(struct intel_gt *gt,
struct i915_request *rq;
struct evict_vma arg;
struct hang h;
+ unsigned int pin_flags;
int err;
+ if (!gt->ggtt->num_fences && flags & EXEC_OBJECT_NEEDS_FENCE)
+ return 0;
+
if (!engine || !intel_engine_can_store_dword(engine))
return 0;
@@ -1227,10 +1231,12 @@ static int __igt_reset_evict_vma(struct intel_gt *gt,
goto out_obj;
}
- err = i915_vma_pin(arg.vma, 0, 0,
- i915_vma_is_ggtt(arg.vma) ?
- PIN_GLOBAL | PIN_MAPPABLE :
- PIN_USER);
+ pin_flags = i915_vma_is_ggtt(arg.vma) ? PIN_GLOBAL : PIN_USER;
+
+ if (flags & EXEC_OBJECT_NEEDS_FENCE)
+ pin_flags |= PIN_MAPPABLE;
+
+ err = i915_vma_pin(arg.vma, 0, 0, pin_flags);
if (err) {
i915_request_add(rq);
goto out_obj;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c
b/drivers/gpu/drm/i915/selftests/i915_gem.c
index 37593831b539..4951957a4d8d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
@@ -42,6 +42,9 @@ static void trash_stolen(struct drm_i915_private *i915)
unsigned long page;
u32 prng = 0x12345678;
+ if (!HAS_MAPPABLE_APERTURE(i915))
+ return;
+
for (page = 0; page < size; page += PAGE_SIZE) {
const dma_addr_t dma = i915->dsm.start + page;
u32 __iomem *s;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index f4d7b254c9a7..57dd237cd220 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1152,6 +1152,9 @@ static int igt_ggtt_page(void *arg)
unsigned int *order, n;
int err;
+ if (!HAS_MAPPABLE_APERTURE(i915))
+ return 0;
+
mutex_lock(&i915->drm.struct_mutex);
obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/22] drm/i915/lmem: support kernel mapping
From: Abdiel Janulgue
We can create LMEM objects, but we also need to support mapping them
into kernel space for internal use.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Signed-off-by: Steve Hampson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 36 +
drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 8 ++
drivers/gpu/drm/i915/gem/i915_gem_object.h| 6 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 20 -
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 3 +-
.../drm/i915/gem/selftests/huge_gem_object.c | 4 +-
.../drm/i915/selftests/intel_memory_region.c | 76 +++
9 files changed, 152 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index 5e72cb1cc2d3..c2e237702e8c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -140,7 +140,9 @@ static void i915_gem_object_put_pages_internal(struct
drm_i915_gem_object *obj,
static const struct drm_i915_gem_object_ops i915_gem_object_internal_ops = {
.flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE |
-I915_GEM_OBJECT_IS_SHRINKABLE,
+I915_GEM_OBJECT_IS_SHRINKABLE |
+I915_GEM_OBJECT_IS_MAPPABLE,
+
.get_pages = i915_gem_object_get_pages_internal,
.put_pages = i915_gem_object_put_pages_internal,
};
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 26a23304df32..d7ec74ed5b88 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -9,11 +9,47 @@
#include "i915_drv.h"
const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops = {
+ .flags = I915_GEM_OBJECT_IS_MAPPABLE,
+
.get_pages = i915_gem_object_get_pages_buddy,
.put_pages = i915_gem_object_put_pages_buddy,
.release = i915_gem_object_release_memory_region,
};
+/* XXX: Time to vfunc your life up? */
+void __iomem *i915_gem_object_lmem_io_map_page(struct drm_i915_gem_object *obj,
+ unsigned long n)
+{
+ resource_size_t offset;
+
+ offset = i915_gem_object_get_dma_address(obj, n);
+
+ return io_mapping_map_wc(&obj->mm.region->iomap, offset, PAGE_SIZE);
+}
+
+void __iomem *i915_gem_object_lmem_io_map_page_atomic(struct
drm_i915_gem_object *obj,
+ unsigned long n)
+{
+ resource_size_t offset;
+
+ offset = i915_gem_object_get_dma_address(obj, n);
+
+ return io_mapping_map_atomic_wc(&obj->mm.region->iomap, offset);
+}
+
+void __iomem *i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
+ unsigned long n,
+ unsigned long size)
+{
+ resource_size_t offset;
+
+ GEM_BUG_ON(!(obj->flags & I915_BO_ALLOC_CONTIGUOUS));
+
+ offset = i915_gem_object_get_dma_address(obj, n);
+
+ return io_mapping_map_wc(&obj->mm.region->iomap, offset, size);
+}
+
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
{
struct intel_memory_region *region = obj->mm.region;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
index ebc15fe24f58..31a6462bdbb6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
@@ -13,6 +13,14 @@ struct drm_i915_gem_object;
extern const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops;
+void __iomem *i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
+ unsigned long n, unsigned long size);
+void __iomem *i915_gem_object_lmem_io_map_page(struct drm_i915_gem_object *obj,
+ unsigned long n);
+void __iomem *
+i915_gem_object_lmem_io_map_page_atomic(struct drm_i915_gem_object *obj,
+ unsigned long n);
+
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
struct drm_i915_gem_object *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index d5839cbd82c0..e8cc776581d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -158,6 +158,12 @@ i915_gem_object_is_proxy(const struct drm_i915_gem_object
*obj)
return obj->ops->flags & I915_GEM_OBJECT_IS_PROXY;
}
+static inline bool
+i915_gem_object_is_mappable(const struct drm_i915_gem_object *obj)
+{
+ return obj->ops->flags & I915_GEM_OBJECT_IS_MAPPABLE;
+}
+
static inline bool
i915_gem_object_needs_async_cancel(const struct drm_i915_gem_object *obj)
{
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drive
[Intel-gfx] [PATCH 19/22] drm/i915: error capture with no ggtt slot
From: Daniele Ceraolo Spurio
If the aperture is not available in HW we can't use a ggtt slot and wc
copy, so fall back to regular kmap.
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 19
drivers/gpu/drm/i915/i915_gpu_error.c | 65 ++-
2 files changed, 64 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1be7b236f234..29f9c43b2c68 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2661,7 +2661,8 @@ static void ggtt_release_guc_top(struct i915_ggtt *ggtt)
static void cleanup_init_ggtt(struct i915_ggtt *ggtt)
{
ggtt_release_guc_top(ggtt);
- drm_mm_remove_node(&ggtt->error_capture);
+ if (drm_mm_node_allocated(&ggtt->error_capture))
+ drm_mm_remove_node(&ggtt->error_capture);
}
static int init_ggtt(struct i915_ggtt *ggtt)
@@ -2692,13 +2693,15 @@ static int init_ggtt(struct i915_ggtt *ggtt)
if (ret)
return ret;
- /* Reserve a mappable slot for our lockless error capture */
- ret = drm_mm_insert_node_in_range(&ggtt->vm.mm, &ggtt->error_capture,
- PAGE_SIZE, 0, I915_COLOR_UNEVICTABLE,
- 0, ggtt->mappable_end,
- DRM_MM_INSERT_LOW);
- if (ret)
- return ret;
+ if (HAS_MAPPABLE_APERTURE(ggtt->vm.i915)) {
+ /* Reserve a mappable slot for our lockless error capture */
+ ret = drm_mm_insert_node_in_range(&ggtt->vm.mm,
&ggtt->error_capture,
+ PAGE_SIZE, 0,
I915_COLOR_UNEVICTABLE,
+ 0, ggtt->mappable_end,
+ DRM_MM_INSERT_LOW);
+ if (ret)
+ return ret;
+ }
/*
* The upper portion of the GuC address space has a sizeable hole
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 6384a06aa5bf..c6c96f0c6b28 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -40,6 +40,7 @@
#include "display/intel_overlay.h"
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_lmem.h"
#include "i915_drv.h"
#include "i915_gpu_error.h"
@@ -235,6 +236,7 @@ struct compress {
struct pagevec pool;
struct z_stream_s zstream;
void *tmp;
+ bool wc;
};
static bool compress_init(struct compress *c)
@@ -292,7 +294,7 @@ static int compress_page(struct compress *c,
struct z_stream_s *zstream = &c->zstream;
zstream->next_in = src;
- if (c->tmp && i915_memcpy_from_wc(c->tmp, src, PAGE_SIZE))
+ if (c->wc && c->tmp && i915_memcpy_from_wc(c->tmp, src, PAGE_SIZE))
zstream->next_in = c->tmp;
zstream->avail_in = PAGE_SIZE;
@@ -367,6 +369,7 @@ static void err_compression_marker(struct
drm_i915_error_state_buf *m)
struct compress {
struct pagevec pool;
+ bool wc;
};
static bool compress_init(struct compress *c)
@@ -389,7 +392,7 @@ static int compress_page(struct compress *c,
if (!ptr)
return -ENOMEM;
- if (!i915_memcpy_from_wc(ptr, src, PAGE_SIZE))
+ if (!(c->wc && i915_memcpy_from_wc(ptr, src, PAGE_SIZE)))
memcpy(ptr, src, PAGE_SIZE);
dst->pages[dst->page_count++] = ptr;
@@ -970,7 +973,6 @@ i915_error_object_create(struct drm_i915_private *i915,
struct drm_i915_error_object *dst;
unsigned long num_pages;
struct sgt_iter iter;
- dma_addr_t dma;
int ret;
might_sleep();
@@ -996,17 +998,54 @@ i915_error_object_create(struct drm_i915_private *i915,
dst->page_count = 0;
dst->unused = 0;
+ compress->wc = i915_gem_object_is_lmem(vma->obj) ||
+ drm_mm_node_allocated(&ggtt->error_capture);
+
ret = -EINVAL;
- for_each_sgt_daddr(dma, iter, vma->pages) {
+ if (drm_mm_node_allocated(&ggtt->error_capture)) {
void __iomem *s;
+ dma_addr_t dma;
- ggtt->vm.insert_page(&ggtt->vm, dma, slot, I915_CACHE_NONE, 0);
+ for_each_sgt_daddr(dma, iter, vma->pages) {
+ ggtt->vm.insert_page(&ggtt->vm, dma, slot,
+I915_CACHE_NONE, 0);
- s = io_mapping_map_wc(&ggtt->iomap, slot, PAGE_SIZE);
- ret = compress_page(compress, (void __force *)s, dst);
- io_mapping_unmap(s);
- if (ret)
- break;
+ s = io_mapping_map_wc(&ggtt->iomap, slot, PAGE_SIZE);
+ ret = compress_page(compr
[Intel-gfx] [PATCH 17/22] drm/i915: set num_fence_regs to 0 if there is no aperture
From: Daniele Ceraolo Spurio We can't fence anything without aperture. Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Stuart Summers Cc: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_fence_reg.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c b/drivers/gpu/drm/i915/i915_gem_fence_reg.c index 615a9f4ef30c..e15e4e247576 100644 --- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c @@ -828,8 +828,10 @@ void i915_ggtt_init_fences(struct i915_ggtt *ggtt) detect_bit_6_swizzle(i915); - if (INTEL_GEN(i915) >= 7 && - !(IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))) + if (!HAS_MAPPABLE_APERTURE(i915)) + num_fences = 0; + else if (INTEL_GEN(i915) >= 7 && +!(IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))) num_fences = 32; else if (INTEL_GEN(i915) >= 4 || IS_I945G(i915) || IS_I945GM(i915) || -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/22] drm/i915: Don't try to place HWS in non-existing mappable region
From: Michal Wajdeczko HWS placement restrictions can't just rely on HAS_LLC flag. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index f97686bdc28b..2e3f7a7507ae 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -513,7 +513,7 @@ static int pin_ggtt_status_page(struct intel_engine_cs *engine, unsigned int flags; flags = PIN_GLOBAL; - if (!HAS_LLC(engine->i915)) + if (!HAS_LLC(engine->i915) && HAS_MAPPABLE_APERTURE(engine->i915)) /* * On g33, we cannot place HWS above 256MiB, so * restrict its pinning to the low mappable arena. -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/22] drm/i915: treat stolen as a region
Convert stolen memory over to a region object. Still leaves open the
question with what to do with pre-allocated objects...
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 71 +++---
drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 3 +-
drivers/gpu/drm/i915/i915_gem_gtt.c| 14 +
drivers/gpu/drm/i915/i915_pci.c| 2 +-
5 files changed, 68 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 0aeaebb41050..77e89fabbddf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -159,7 +159,7 @@ i915_gem_object_create_region(struct intel_memory_region
*mem,
return ERR_PTR(-E2BIG);
obj = mem->ops->create_object(mem, size, flags);
- if (!IS_ERR(obj))
+ if (!IS_ERR_OR_NULL(obj))
trace_i915_gem_object_create(obj);
return obj;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index bfbc3e3daf92..1ee8f1790144 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -10,6 +10,7 @@
#include
#include
+#include "gem/i915_gem_region.h"
#include "i915_drv.h"
#include "i915_gem_stolen.h"
@@ -150,7 +151,7 @@ static int i915_adjust_stolen(struct drm_i915_private
*dev_priv,
return 0;
}
-void i915_gem_cleanup_stolen(struct drm_i915_private *dev_priv)
+static void i915_gem_cleanup_stolen(struct drm_i915_private *dev_priv)
{
if (!drm_mm_initialized(&dev_priv->mm.stolen))
return;
@@ -355,7 +356,7 @@ static void icl_get_stolen_reserved(struct drm_i915_private
*i915,
}
}
-int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
+static int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
{
resource_size_t reserved_base, stolen_top;
resource_size_t reserved_total, reserved_size;
@@ -539,6 +540,9 @@ i915_gem_object_release_stolen(struct drm_i915_gem_object
*obj)
i915_gem_stolen_remove_node(dev_priv, stolen);
kfree(stolen);
+
+ if (obj->mm.region)
+ i915_gem_object_release_memory_region(obj);
}
static const struct drm_i915_gem_object_ops i915_gem_object_stolen_ops = {
@@ -548,8 +552,9 @@ static const struct drm_i915_gem_object_ops
i915_gem_object_stolen_ops = {
};
static struct drm_i915_gem_object *
-_i915_gem_object_create_stolen(struct drm_i915_private *dev_priv,
- struct drm_mm_node *stolen)
+__i915_gem_object_create_stolen(struct drm_i915_private *dev_priv,
+ struct drm_mm_node *stolen,
+ struct intel_memory_region *mem)
{
struct drm_i915_gem_object *obj;
unsigned int cache_level;
@@ -566,6 +571,9 @@ _i915_gem_object_create_stolen(struct drm_i915_private
*dev_priv,
cache_level = HAS_LLC(dev_priv) ? I915_CACHE_LLC : I915_CACHE_NONE;
i915_gem_object_set_cache_coherency(obj, cache_level);
+ if (mem)
+ i915_gem_object_init_memory_region(obj, mem, 0);
+
if (i915_gem_object_pin_pages(obj))
goto cleanup;
@@ -576,10 +584,12 @@ _i915_gem_object_create_stolen(struct drm_i915_private
*dev_priv,
return NULL;
}
-struct drm_i915_gem_object *
-i915_gem_object_create_stolen(struct drm_i915_private *dev_priv,
- resource_size_t size)
+static struct drm_i915_gem_object *
+_i915_gem_object_create_stolen(struct intel_memory_region *mem,
+ resource_size_t size,
+ unsigned int flags)
{
+ struct drm_i915_private *dev_priv = mem->i915;
struct drm_i915_gem_object *obj;
struct drm_mm_node *stolen;
int ret;
@@ -600,7 +610,7 @@ i915_gem_object_create_stolen(struct drm_i915_private
*dev_priv,
return NULL;
}
- obj = _i915_gem_object_create_stolen(dev_priv, stolen);
+ obj = __i915_gem_object_create_stolen(dev_priv, stolen, mem);
if (obj)
return obj;
@@ -609,6 +619,49 @@ i915_gem_object_create_stolen(struct drm_i915_private
*dev_priv,
return NULL;
}
+struct drm_i915_gem_object *
+i915_gem_object_create_stolen(struct drm_i915_private *dev_priv,
+ resource_size_t size)
+{
+ struct drm_i915_gem_object *obj;
+
+ obj =
i915_gem_object_create_region(dev_priv->mm.regions[INTEL_MEMORY_STOLEN],
+ size, I915_BO_ALLOC_CONTIGUOUS);
+ if (IS_ERR(obj))
+ return NULL;
+
+ return obj;
+}
+
+static int init_stolen(struct intel_memory_region *mem)
+{
+ /*
+* Initialise stolen early so that we may rese
[Intel-gfx] [PATCH 13/22] drm/i915: treat shmem as a region
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 5 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c| 14 +++-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 68 ++-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 9 ---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +-
drivers/gpu/drm/i915/i915_pci.c | 29 +---
.../gpu/drm/i915/selftests/mock_gem_device.c | 6 +-
8 files changed, 95 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
index 768356908160..8043ff63d73f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
@@ -16,6 +16,7 @@
#include "gt/intel_gt.h"
#include "i915_drv.h"
#include "i915_gem_object.h"
+#include "i915_gem_region.h"
#include "i915_scatterlist.h"
static int i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
@@ -191,8 +192,10 @@ int i915_gem_object_attach_phys(struct drm_i915_gem_object
*obj, int align)
/* Perma-pin (until release) the physical set of pages */
__i915_gem_object_pin_pages(obj);
- if (!IS_ERR_OR_NULL(pages))
+ if (!IS_ERR_OR_NULL(pages)) {
i915_gem_shmem_ops.put_pages(obj, pages);
+ i915_gem_object_release_memory_region(obj);
+ }
mutex_unlock(&obj->mm.lock);
return 0;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index e9550e0364cc..0aeaebb41050 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -6,6 +6,7 @@
#include "intel_memory_region.h"
#include "i915_gem_region.h"
#include "i915_drv.h"
+#include "i915_trace.h"
void
i915_gem_object_put_pages_buddy(struct drm_i915_gem_object *obj,
@@ -144,11 +145,22 @@ i915_gem_object_create_region(struct intel_memory_region
*mem,
GEM_BUG_ON(!size);
GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_MIN_ALIGNMENT));
+ /*
+* There is a prevalence of the assumption that we fit the object's
+* page count inside a 32bit _signed_ variable. Let's document this and
+* catch if we ever need to fix it. In the meantime, if you do spot
+* such a local variable, please consider fixing!
+*/
+
if (size >> PAGE_SHIFT > INT_MAX)
return ERR_PTR(-E2BIG);
if (overflows_type(size, obj->base.size))
return ERR_PTR(-E2BIG);
- return mem->ops->create_object(mem, size, flags);
+ obj = mem->ops->create_object(mem, size, flags);
+ if (!IS_ERR(obj))
+ trace_i915_gem_object_create(obj);
+
+ return obj;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 9f5d903f7793..696e15e8c410 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -7,7 +7,9 @@
#include
#include
+#include "gem/i915_gem_region.h"
#include "i915_drv.h"
+#include "i915_gemfs.h"
#include "i915_gem_object.h"
#include "i915_scatterlist.h"
#include "i915_trace.h"
@@ -26,6 +28,7 @@ static void check_release_pagevec(struct pagevec *pvec)
static int shmem_get_pages(struct drm_i915_gem_object *obj)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct intel_memory_region *mem = obj->mm.region;
const unsigned long page_count = obj->base.size / PAGE_SIZE;
unsigned long i;
struct address_space *mapping;
@@ -52,7 +55,7 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
* If there's no chance of allocating enough pages for the whole
* object, bail early.
*/
- if (page_count > totalram_pages())
+ if (obj->base.size > resource_size(&mem->region))
return -ENOMEM;
st = kmalloc(sizeof(*st), GFP_KERNEL);
@@ -417,6 +420,8 @@ shmem_pwrite(struct drm_i915_gem_object *obj,
static void shmem_release(struct drm_i915_gem_object *obj)
{
+ i915_gem_object_release_memory_region(obj);
+
fput(obj->base.filp);
}
@@ -435,7 +440,7 @@ const struct drm_i915_gem_object_ops i915_gem_shmem_ops = {
.release = shmem_release,
};
-static int create_shmem(struct drm_i915_private *i915,
+static int __create_shmem(struct drm_i915_private *i915,
struct drm_gem_object *obj,
size_t size)
{
@@ -456,31 +461,23 @@ static int create_shmem(struct drm_i915_private *i915,
return 0;
}
-struct drm_i915_gem_object *
-i915_gem_object_create_shmem(struct drm_i915_private *i915, u64 size)
+static struct drm_i915_gem_object *
+create_shmem(struct intel_memory_region *mem,
+resource_size_t size,
+unsigned flags)
{
+ struct drm_i915_private
[Intel-gfx] [PATCH 15/22] drm/i915: define HAS_MAPPABLE_APERTURE
From: Daniele Ceraolo Spurio The following patches in the series will use it to avoid certain operations when aperture is not available in HW. Signed-off-by: Daniele Ceraolo Spurio Cc: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 6cf13e98794a..d6303045f546 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2126,6 +2126,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define OVERLAY_NEEDS_PHYSICAL(dev_priv) \ (INTEL_INFO(dev_priv)->display.overlay_needs_physical) +#define HAS_MAPPABLE_APERTURE(dev_priv) (dev_priv->ggtt.mappable_end > 0) + /* Early gen2 have a totally busted CS tlb and require pinned batches. */ #define HAS_BROKEN_CS_TLB(dev_priv)(IS_I830(dev_priv) || IS_I845G(dev_priv)) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/22] drm/i915: support creating LMEM objects
We currently define LMEM, or local memory, as just another memory
region, like system memory or stolen, which we can expose to userspace
and can be mapped to the CPU via some BAR.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/Makefile | 2 +
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 31 +
drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 23 ++
drivers/gpu/drm/i915/i915_drv.h | 5 +++
drivers/gpu/drm/i915/intel_memory_region.c| 6 +++
drivers/gpu/drm/i915/intel_memory_region.h| 30 +
drivers/gpu/drm/i915/intel_region_lmem.c | 43 ++
drivers/gpu/drm/i915/intel_region_lmem.h | 11 +
.../drm/i915/selftests/i915_live_selftests.h | 1 +
.../drm/i915/selftests/intel_memory_region.c | 45 +++
10 files changed, 197 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_lmem.c
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_lmem.h
create mode 100644 drivers/gpu/drm/i915/intel_region_lmem.c
create mode 100644 drivers/gpu/drm/i915/intel_region_lmem.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d849dff31f76..ccf4223ed3f9 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -115,6 +115,7 @@ gem-y += \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_object_blt.o \
+ gem/i915_gem_lmem.o \
gem/i915_gem_mman.o \
gem/i915_gem_pages.o \
gem/i915_gem_phys.o \
@@ -143,6 +144,7 @@ i915-y += \
i915_scheduler.o \
i915_trace_points.o \
i915_vma.o \
+ intel_region_lmem.o \
intel_wopcm.o
# general-purpose microcontroller (GuC) support
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
new file mode 100644
index ..26a23304df32
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "intel_memory_region.h"
+#include "gem/i915_gem_region.h"
+#include "gem/i915_gem_lmem.h"
+#include "i915_drv.h"
+
+const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops = {
+ .get_pages = i915_gem_object_get_pages_buddy,
+ .put_pages = i915_gem_object_put_pages_buddy,
+ .release = i915_gem_object_release_memory_region,
+};
+
+bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
+{
+ struct intel_memory_region *region = obj->mm.region;
+
+ return region && region->type == INTEL_LMEM;
+}
+
+struct drm_i915_gem_object *
+i915_gem_object_create_lmem(struct drm_i915_private *i915,
+ resource_size_t size,
+ unsigned int flags)
+{
+ return
i915_gem_object_create_region(i915->mm.regions[INTEL_MEMORY_LMEM],
+size, flags);
+}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
new file mode 100644
index ..ebc15fe24f58
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef __I915_GEM_LMEM_H
+#define __I915_GEM_LMEM_H
+
+#include
+
+struct drm_i915_private;
+struct drm_i915_gem_object;
+
+extern const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops;
+
+bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
+
+struct drm_i915_gem_object *
+i915_gem_object_create_lmem(struct drm_i915_private *i915,
+ resource_size_t size,
+ unsigned int flags);
+
+#endif /* !__I915_GEM_LMEM_H */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 93116cc8b149..05a6491690f7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -100,6 +100,8 @@
#include "i915_vma.h"
#include "i915_irq.h"
+#include "intel_region_lmem.h"
+
#include "intel_gvt.h"
/* General customization:
@@ -686,6 +688,8 @@ struct i915_gem_mm {
*/
struct vfsmount *gemfs;
+ struct intel_memory_region *regions[INTEL_MEMORY_UKNOWN];
+
struct notifier_block oom_notifier;
struct notifier_block vmap_notifier;
struct shrinker shrinker;
@@ -2171,6 +2175,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_IPC(dev_priv) (INTEL_INFO(dev_priv)->display.has_ipc)
#define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
+#define HAS_LMEM(i915) HAS_REGION(i915, REGION_LMEM)
#define HAS_GT_UC(dev_priv)(INTEL_INFO(dev_priv)->has_gt_uc)
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index fba07f71d9bd..703c615331c0 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/driver
[Intel-gfx] [PATCH 21/22] drm/i915: check for missing aperture in GTT pread/pwrite paths
From: CQ Tang drm_mm_insert_node_in_range() treats range_start > range_end as a programmer error, such that we explode in insert_mappable_node. For now simply check for missing aperture on such paths. Signed-off-by: CQ Tang Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index fd329b6b475c..82daaab022d8 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -337,6 +337,9 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj, u64 remain, offset; int ret; + if (!HAS_MAPPABLE_APERTURE(i915)) + return -ENOSPC; + ret = mutex_lock_interruptible(&i915->drm.struct_mutex); if (ret) return ret; @@ -530,6 +533,9 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj, void __user *user_data; int ret; + if (!HAS_MAPPABLE_APERTURE(i915)) + return -ENOSPC; + ret = mutex_lock_interruptible(&i915->drm.struct_mutex); if (ret) return ret; -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/22] drm/i915: enumerate and init each supported region
From: Abdiel Janulgue
Nothing to enumerate yet...
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 70 +--
.../gpu/drm/i915/selftests/mock_gem_device.c | 6 ++
3 files changed, 72 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 05a6491690f7..cd1414f2bcb5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2394,6 +2394,9 @@ int __must_check i915_gem_evict_for_node(struct
i915_address_space *vm,
unsigned int flags);
int i915_gem_evict_vm(struct i915_address_space *vm);
+void i915_gem_cleanup_memory_regions(struct drm_i915_private *i915);
+int i915_gem_init_memory_regions(struct drm_i915_private *i915);
+
/* i915_gem_internal.c */
struct drm_i915_gem_object *
i915_gem_object_create_internal(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e62e9d1a1307..a2963677861d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2744,6 +2744,66 @@ int i915_init_ggtt(struct drm_i915_private *i915)
return 0;
}
+void i915_gem_cleanup_memory_regions(struct drm_i915_private *i915)
+{
+ int i;
+
+ i915_gem_cleanup_stolen(i915);
+
+ for (i = 0; i < ARRAY_SIZE(i915->mm.regions); i++) {
+ struct intel_memory_region *region = i915->mm.regions[i];
+
+ if (region)
+ intel_memory_region_destroy(region);
+ }
+}
+
+int i915_gem_init_memory_regions(struct drm_i915_private *i915)
+{
+ int err, i;
+
+ /*
+* Initialise stolen early so that we may reserve preallocated
+* objects for the BIOS to KMS transition.
+*/
+ /* XXX: stolen will become a region at some point */
+ err = i915_gem_init_stolen(i915);
+ if (err)
+ return err;
+
+ for (i = 0; i < ARRAY_SIZE(i915->mm.regions); i++) {
+ struct intel_memory_region *mem = NULL;
+ u32 type;
+
+ if (!HAS_REGION(i915, BIT(i)))
+ continue;
+
+ type = MEMORY_TYPE_FROM_REGION(intel_region_map[i]);
+ switch (type) {
+ default:
+ break;
+ }
+
+ if (IS_ERR(mem)) {
+ err = PTR_ERR(mem);
+ DRM_ERROR("Failed to setup region(%d) type=%d\n", err,
type);
+ goto out_cleanup;
+ }
+
+ mem->id = intel_region_map[i];
+ mem->type = type;
+ mem->instance =
MEMORY_INSTANCE_FROM_REGION(intel_region_map[i]);
+
+ i915->mm.regions[i] = mem;
+ }
+
+ return 0;
+
+out_cleanup:
+ i915_gem_cleanup_memory_regions(i915);
+ return err;
+}
+
static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
{
struct drm_i915_private *i915 = ggtt->vm.i915;
@@ -2785,6 +2845,8 @@ void i915_ggtt_driver_release(struct drm_i915_private
*i915)
{
struct pagevec *pvec;
+ i915_gem_cleanup_memory_regions(i915);
+
fini_aliasing_ppgtt(&i915->ggtt);
ggtt_cleanup_hw(&i915->ggtt);
@@ -2794,8 +2856,6 @@ void i915_ggtt_driver_release(struct drm_i915_private
*i915)
set_pages_array_wb(pvec->pages, pvec->nr);
__pagevec_release(pvec);
}
-
- i915_gem_cleanup_stolen(i915);
}
static unsigned int gen6_get_total_gtt_size(u16 snb_gmch_ctl)
@@ -3251,11 +3311,7 @@ int i915_ggtt_init_hw(struct drm_i915_private *dev_priv)
if (ret)
return ret;
- /*
-* Initialise stolen early so that we may reserve preallocated
-* objects for the BIOS to KMS transition.
-*/
- ret = i915_gem_init_stolen(dev_priv);
+ ret = i915_gem_init_memory_regions(dev_priv);
if (ret)
goto out_gtt_cleanup;
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 32e32b1cd566..f210b5043112 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -82,6 +82,8 @@ static void mock_device_release(struct drm_device *dev)
i915_gemfs_fini(i915);
+ i915_gem_cleanup_memory_regions(i915);
+
drm_mode_config_cleanup(&i915->drm);
drm_dev_fini(&i915->drm);
@@ -219,6 +221,10 @@ struct drm_i915_private *mock_gem_device(void)
WARN_ON(i915_gemfs_init(i915));
+ err = i915_gem_init_memory_regions(i915);
+ if (err)
+ goto err_context;
+
return i915;
err_context:
--
2.20.1
___
Intel-gfx mailing list
[Intel-gfx] [PATCH 22/22] HAX drm/i915: add the fake lmem region
Intended for upstream testing so that we can still exercise the LMEM
plumbing and !HAS_MAPPABLE_APERTURE paths. Smoke tested on Skull Canyon
device. This works by allocating an intel_memory_region for a reserved
portion of system memory, which we treat like LMEM. For the LMEMBAR we
steal the aperture and 1:1 it map to the stolen region.
To enable simply set i915_fake_lmem_start= on the kernel cmdline with the
start of reserved region(see memmap=). The size of the region we can
use is determined by the size of the mappable aperture, so the size of
reserved region should be >= mappable_end.
eg. memmap=2G$16G i915_fake_lmem_start=0x4
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
arch/x86/kernel/early-quirks.c | 26 +++
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 3 +
drivers/gpu/drm/i915/i915_drv.c| 8 ++
drivers/gpu/drm/i915/i915_gem_gtt.c| 3 +
drivers/gpu/drm/i915/intel_memory_region.h | 6 ++
drivers/gpu/drm/i915/intel_region_lmem.c | 90 ++
drivers/gpu/drm/i915/intel_region_lmem.h | 5 ++
include/drm/i915_drm.h | 3 +
8 files changed, 144 insertions(+)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 6f6b1d04dadf..9b04655e3926 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -603,6 +603,32 @@ static void __init intel_graphics_quirks(int num, int
slot, int func)
}
}
+struct resource intel_graphics_fake_lmem_res __ro_after_init =
DEFINE_RES_MEM(0, 0);
+EXPORT_SYMBOL(intel_graphics_fake_lmem_res);
+
+static int __init early_i915_fake_lmem_init(char *s)
+{
+ u64 start;
+ int ret;
+
+ if (*s == '=')
+ s++;
+
+ ret = kstrtoull(s, 16, &start);
+ if (ret)
+ return ret;
+
+ intel_graphics_fake_lmem_res.start = start;
+ intel_graphics_fake_lmem_res.end = SZ_2G; /* Placeholder; depends on
aperture size */
+
+ printk(KERN_INFO "Intel graphics fake LMEM starts at %pa\n",
+ &intel_graphics_fake_lmem_res.start);
+
+ return 0;
+}
+
+early_param("i915_fake_lmem_start", early_i915_fake_lmem_init);
+
static void __init force_disable_hpet(int num, int slot, int func)
{
#ifdef CONFIG_HPET_TIMER
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index d7ec74ed5b88..c5e75c2f2511 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -23,6 +23,7 @@ void __iomem *i915_gem_object_lmem_io_map_page(struct
drm_i915_gem_object *obj,
resource_size_t offset;
offset = i915_gem_object_get_dma_address(obj, n);
+ offset -= obj->mm.region->region.start;
return io_mapping_map_wc(&obj->mm.region->iomap, offset, PAGE_SIZE);
}
@@ -33,6 +34,7 @@ void __iomem *i915_gem_object_lmem_io_map_page_atomic(struct
drm_i915_gem_object
resource_size_t offset;
offset = i915_gem_object_get_dma_address(obj, n);
+ offset -= obj->mm.region->region.start;
return io_mapping_map_atomic_wc(&obj->mm.region->iomap, offset);
}
@@ -46,6 +48,7 @@ void __iomem *i915_gem_object_lmem_io_map(struct
drm_i915_gem_object *obj,
GEM_BUG_ON(!(obj->flags & I915_BO_ALLOC_CONTIGUOUS));
offset = i915_gem_object_get_dma_address(obj, n);
+ offset -= obj->mm.region->region.start;
return io_mapping_map_wc(&obj->mm.region->iomap, offset, size);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 91aae56b4280..98fa1932c4aa 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1546,6 +1546,14 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (!i915_modparams.nuclear_pageflip && match_info->gen < 5)
dev_priv->drm.driver_features &= ~DRIVER_ATOMIC;
+ /* Check if we support fake LMEM -- enable for live selftests */
+ if (INTEL_GEN(dev_priv) >= 9 && i915_selftest.live &&
+ intel_graphics_fake_lmem_res.start) {
+ mkwrite_device_info(dev_priv)->memory_regions =
+ REGION_SMEM | REGION_LMEM;
+ GEM_BUG_ON(!HAS_LMEM(dev_priv));
+ }
+
ret = pci_enable_device(pdev);
if (ret)
goto out_fini;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 29f9c43b2c68..02d2a6266b8c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2778,6 +2778,9 @@ int i915_gem_init_memory_regions(struct drm_i915_private
*i915)
case INTEL_STOLEN:
mem = i915_gem_stolen_setup(i915);
break;
+ case INTEL_LMEM:
+ mem = intel_setup_fake_lmem(i915);
+ break;
}
if
[Intel-gfx] [PATCH 16/22] drm/i915: do not map aperture if it is not available.
From: Daniele Ceraolo Spurio
Skip both setup and cleanup of the aperture mapping if the HW doesn't
have an aperture bar.
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 34 ++---
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 51b2087b214f..1be7b236f234 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2827,7 +2827,9 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
mutex_unlock(&i915->drm.struct_mutex);
arch_phys_wc_del(ggtt->mtrr);
- io_mapping_fini(&ggtt->iomap);
+
+ if (ggtt->iomap.size)
+ io_mapping_fini(&ggtt->iomap);
}
/**
@@ -3038,10 +3040,13 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
int err;
/* TODO: We're not aware of mappable constraints on gen8 yet */
- ggtt->gmadr =
- (struct resource) DEFINE_RES_MEM(pci_resource_start(pdev, 2),
-pci_resource_len(pdev, 2));
- ggtt->mappable_end = resource_size(&ggtt->gmadr);
+ /* FIXME: We probably need to add do device_info or runtime_info */
+ if (!HAS_LMEM(dev_priv)) {
+ ggtt->gmadr =
+ (struct resource)
DEFINE_RES_MEM(pci_resource_start(pdev, 2),
+pci_resource_len(pdev,
2));
+ ggtt->mappable_end = resource_size(&ggtt->gmadr);
+ }
err = pci_set_dma_mask(pdev, DMA_BIT_MASK(39));
if (!err)
@@ -3267,15 +3272,18 @@ static int ggtt_init_hw(struct i915_ggtt *ggtt)
if (!HAS_LLC(i915) && !HAS_PPGTT(i915))
ggtt->vm.mm.color_adjust = i915_ggtt_color_adjust;
- if (!io_mapping_init_wc(&ggtt->iomap,
- ggtt->gmadr.start,
- ggtt->mappable_end)) {
- ggtt->vm.cleanup(&ggtt->vm);
- ret = -EIO;
- goto out;
- }
+ if (ggtt->mappable_end) {
+ if (!io_mapping_init_wc(&ggtt->iomap,
+ ggtt->gmadr.start,
+ ggtt->mappable_end)) {
+ ggtt->vm.cleanup(&ggtt->vm);
+ ret = -EIO;
+ goto out;
+ }
- ggtt->mtrr = arch_phys_wc_add(ggtt->gmadr.start, ggtt->mappable_end);
+ ggtt->mtrr = arch_phys_wc_add(ggtt->gmadr.start,
+ ggtt->mappable_end);
+ }
i915_ggtt_init_fences(ggtt);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/22] drm/i915: check for kernel_context
Quoting Matthew Auld (2019-09-27 18:33:48) > Explosions during early driver init on the error path. Make sure we fail > gracefully. Joonas would complain about the clearly not onion unwind here, but we have thrown it in as a catch-all cleanup for what is quite a complicated setup. > [ 9547.672258] BUG: kernel NULL pointer dereference, address: 007c > [ 9547.672288] #PF: supervisor read access in kernel mode > [ 9547.672292] #PF: error_code(0x) - not-present page > [ 9547.672296] PGD 800846b41067 P4D 800846b41067 PUD 797034067 PMD 0 > [ 9547.672303] Oops: [#1] SMP PTI > [ 9547.672307] CPU: 1 PID: 25634 Comm: i915_selftest Tainted: G U >5.3.0-rc8+ #73 > [ 9547.672313] Hardware name: /NUC6i7KYB, BIOS > KYSKLi70.86A.0050.2017.0831.1924 08/31/2017 > [ 9547.672395] RIP: 0010:intel_context_unpin+0x9/0x100 [i915] > [ 9547.672400] Code: 6b 60 00 e9 17 ff ff ff bd fc ff ff ff e9 7c ff ff ff 66 > 66 2e 0f 1f 84 00 00 00 00 > 00 0f 1f 40 00 0f 1f 44 00 00 41 54 55 53 <8b> 47 7c 83 f8 01 74 26 8d 48 ff > f0 0f b1 4f 7c 48 8d 57 7c > 75 05 > [ 9547.672413] RSP: 0018:ae8ac24ff878 EFLAGS: 00010246 > [ 9547.672417] RAX: 944a1b7842d0 RBX: 944a1b784000 RCX: > 944a12dd6fa8 > [ 9547.672422] RDX: 944a1b7842c0 RSI: 944a12dd5328 RDI: > > [ 9547.672428] RBP: R08: 944a11e5d840 R09: > > [ 9547.672433] R10: R11: R12: > > [ 9547.672438] R13: c11aaf00 R14: ffe4 R15: > 944a0e29bf38 > [ 9547.672443] FS: 7fc259b88ac0() GS:944a1f88() > knlGS: > [ 9547.672449] CS: 0010 DS: ES: CR0: 80050033 > [ 9547.672454] CR2: 007c CR3: 000853346003 CR4: > 003606e0 > [ 9547.672459] DR0: DR1: DR2: > > [ 9547.672464] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 9547.672469] Call Trace: > [ 9547.672518] intel_engine_cleanup_common+0xe3/0x270 [i915] > [ 9547.672567] execlists_destroy+0xe/0x30 [i915] > [ 9547.672669] intel_engines_init+0x94/0xf0 [i915] > [ 9547.672749] i915_gem_init+0x191/0x950 [i915] > > Signed-off-by: Matthew Auld Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/22] drm/i915: simplify i915_gem_init_early
Quoting Matthew Auld (2019-09-27 18:33:49) > i915_gem_init_early doesn't need to return anything. > > Signed-off-by: Matthew Auld Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 6/8] mdev: introduce virtio device and its device ops
Hi Alex,
> -Original Message-
> From: Alex Williamson
> Sent: Tuesday, September 24, 2019 6:07 PM
> To: Jason Wang
> Cc: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> kwankh...@nvidia.com; m...@redhat.com; tiwei@intel.com;
> virtualizat...@lists.linux-foundation.org; net...@vger.kernel.org;
> coh...@redhat.com; maxime.coque...@redhat.com;
> cunming.li...@intel.com; zhihong.w...@intel.com;
> rob.mil...@broadcom.com; xiao.w.w...@intel.com;
> haotian.w...@sifive.com; zhen...@linux.intel.com; zhi.a.w...@intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com;
> rodrigo.v...@intel.com; airl...@linux.ie; dan...@ffwll.ch;
> far...@linux.ibm.com; pa...@linux.ibm.com; seb...@linux.ibm.com;
> ober...@linux.ibm.com; heiko.carst...@de.ibm.com; g...@linux.ibm.com;
> borntrae...@de.ibm.com; akrow...@linux.ibm.com; fre...@linux.ibm.com;
> lingshan@intel.com; Ido Shamay ;
> epere...@redhat.com; l...@redhat.com; Parav Pandit
> ; christophe.de.dinec...@gmail.com;
> kevin.t...@intel.com
> Subject: Re: [PATCH V2 6/8] mdev: introduce virtio device and its device ops
>
> On Tue, 24 Sep 2019 21:53:30 +0800
> Jason Wang wrote:
>
> > This patch implements basic support for mdev driver that supports
> > virtio transport for kernel virtio driver.
> >
> > Signed-off-by: Jason Wang
> > ---
> > include/linux/mdev.h| 2 +
> > include/linux/virtio_mdev.h | 145
> >
> > 2 files changed, 147 insertions(+)
> > create mode 100644 include/linux/virtio_mdev.h
> >
> > diff --git a/include/linux/mdev.h b/include/linux/mdev.h index
> > 3414307311f1..73ac27b3b868 100644
> > --- a/include/linux/mdev.h
> > +++ b/include/linux/mdev.h
> > @@ -126,6 +126,8 @@ struct mdev_device *mdev_from_dev(struct device
> > *dev);
> >
> > enum {
> > MDEV_ID_VFIO = 1,
> > + MDEV_ID_VIRTIO = 2,
> > + MDEV_ID_VHOST = 3,
>
> MDEV_ID_VHOST isn't used yet here. Also, given the strong interdependence
> between the class_id and the ops structure, we might wand to define them in
> the same place. Thanks,
>
When mlx5_core creates mdevs (parent->ops->create() and it wants to bind to
mlx5 mdev driver (which does mdev_register_driver()),
mlx5 core driver will publish MDEV_ID_MLX5_NET defined in central place as
include/linux/mdev.h without any ops structure.
Because such ops are not relevant. It uses usual, standard ops probe() remove()
on the mdev (similar to a regular PCI device).
So for VHOST case ops may be closely related to ID, but not for other type of
ID.
Just want to make sure, that scope of ID covers this case.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/4] drm/i915/tc: Update DP_MODE programming
On Fri, 2019-09-27 at 17:24 +, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/4] drm/i915/tc: Update DP_MODE > programming > URL : https://patchwork.freedesktop.org/series/67312/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_6966_full -> Patchwork_14561_full > > > Summary > --- > > **SUCCESS** > > No regressions found. Pushed to dinq, thanks for the reviews Imre and Lucas. > > > > Known issues > > > Here are the changes found in Patchwork_14561_full that come from > known issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_schedule@promotion-bsd1: > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +16 > similar issues >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb1/igt@gem_exec_sched...@promotion-bsd1.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb5/igt@gem_exec_sched...@promotion-bsd1.html > > * igt@gem_exec_schedule@reorder-wide-bsd: > - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +4 > similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb6/igt@gem_exec_sched...@reorder-wide-bsd.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html > > * igt@gem_tiled_wc: > - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713]) > +1 similar issue >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb3/igt@gem_tiled_wc.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb7/igt@gem_tiled_wc.html > > * igt@i915_pm_rpm@system-suspend-execbuf: > - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108] > / [fdo#107807]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-skl2/igt@i915_pm_...@system-suspend-execbuf.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-skl5/igt@i915_pm_...@system-suspend-execbuf.html > > * igt@i915_suspend@sysfs-reader: > - shard-apl: [PASS][9] -> [DMESG-WARN][10] > ([fdo#108566]) +5 similar issues >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-apl5/igt@i915_susp...@sysfs-reader.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-apl4/igt@i915_susp...@sysfs-reader.html > > * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: > - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +4 > similar issues >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html > > * igt@kms_plane_lowres@pipe-a-tiling-x: > - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103166]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-x.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-x.html > > * igt@kms_psr@psr2_sprite_mmap_gtt: > - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +2 > similar issues >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb5/igt@kms_psr@psr2_sprite_mmap_gtt.html > > * igt@kms_vblank@pipe-a-ts-continuation-suspend: > - shard-apl: [PASS][17] -> [INCOMPLETE][18] > ([fdo#103927]) +3 similar issues >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-apl1/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-apl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html > - shard-skl: [PASS][19] -> [INCOMPLETE][20] > ([fdo#104108]) >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-skl10/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-skl8/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html > > * igt@kms_vblank@pipe-c-ts-continuation-suspend: > - shard-iclb: [PASS][21] -> [DMESG-WARN][22] > ([fdo#111764]) >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6966/shard-iclb1/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14561/shard-iclb7/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html > > > Possible fixes > > * igt@gem_ctx_isolation@vcs1-dirty-create: > - shard-iclb: [SKIP][23] ([fdo#109276]) -> [PASS][24] +11 > simil
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Extract SAGV block time function
On Wed, Sep 25, 2019 at 01:33:50PM -0700, James Ausmus wrote:
> In prep for newer platforms having more complicated ways to determine
> the SAGV block time, extract the setting to a separate function. While
> we're at it, update the if ladder to follow the new gen -> old gen order
> preference, and warn on any non-specified gen.
>
> Cc: Ville Syrjälä
> Cc: Stanislav Lisovskiy
> Cc: Lucas De Marchi
> Signed-off-by: James Ausmus
> ---
> drivers/gpu/drm/i915/intel_pm.c | 24 ++--
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6bed2ed14574..5ad72dcb0faa 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3662,6 +3662,23 @@ intel_has_sagv(struct drm_i915_private *dev_priv)
> dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED;
> }
>
> +static int
> +intel_get_sagv_block_time_us(struct drm_i915_private *dev_priv)
The "_get_" in the name seems a bit superfluous.
> +{
> + int sagv_block_time_us = 1000; /* Default to unusable block time */
> +
> + if (IS_GEN(dev_priv, 11))
> + sagv_block_time_us = 10;
> + else if (IS_GEN(dev_priv, 10))
> + sagv_block_time_us = 20;
> + else if (IS_GEN(dev_priv, 9))
> + sagv_block_time_us = 30;
> + else
> + MISSING_CASE(INTEL_GEN(dev_priv));
> +
> + return sagv_block_time_us;
Could just return directly w/o the temp variable.
Reviewed-by: Ville Syrjälä
> +}
> +
> /*
> * SAGV dynamically adjusts the system agent voltage and clock frequencies
> * depending on power and performance requirements. The display engine access
> @@ -3755,12 +3772,7 @@ bool intel_can_enable_sagv(struct intel_atomic_state
> *state)
> if (!intel_has_sagv(dev_priv))
> return false;
>
> - if (IS_GEN(dev_priv, 9))
> - sagv_block_time_us = 30;
> - else if (IS_GEN(dev_priv, 10))
> - sagv_block_time_us = 20;
> - else
> - sagv_block_time_us = 10;
> + sagv_block_time_us = intel_get_sagv_block_time_us(dev_priv);
>
> /*
>* If there are no active CRTCs, no additional checks need be performed
> --
> 2.22.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/22] drm/i915: error capture with no ggtt slot
Quoting Matthew Auld (2019-09-27 18:34:06)
> @@ -2692,13 +2693,15 @@ static int init_ggtt(struct i915_ggtt *ggtt)
> if (ret)
> return ret;
>
> - /* Reserve a mappable slot for our lockless error capture */
> - ret = drm_mm_insert_node_in_range(&ggtt->vm.mm, &ggtt->error_capture,
> - PAGE_SIZE, 0,
> I915_COLOR_UNEVICTABLE,
> - 0, ggtt->mappable_end,
> - DRM_MM_INSERT_LOW);
> - if (ret)
> - return ret;
> + if (HAS_MAPPABLE_APERTURE(ggtt->vm.i915)) {
Uh. If only we had the answer to hand...
if (ggtt->mappable_end) {
Or make HAS_MAPPABLE_APERTURE take ggtt. Though I'd vote for less
shouting.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/huc: fix version parsing from CSS header
On 9/26/19 12:37 AM, Michal Wajdeczko wrote:
On Thu, 26 Sep 2019 01:03:20 +0200, Summers, Stuart
wrote:
On Wed, 2019-09-25 at 15:21 -0700, Daniele Ceraolo Spurio wrote:
The HuC FW has silently switched to encoding the version the same way
as
the GuC FW does, i.e. major.minor.patch instead of just major.minor.
All
the current blobs follow the new scheme, but since minor and patch
are
both zero there is no difference in the end results and we happily
load
them. New binaries, however, will have non-zero values in there, so
we
need to make sure to parse them correctly.
Signed-off-by: Daniele Ceraolo Spurio <
daniele.ceraolospu...@intel.com>
I don't have insight into the HuC change, so just taking your word
here. The code below looks sane and is an obvious improvement.
It might be interesting to get a look from someone a little closer to
this for a HuC perspective. With that disclaimer:
Reviewed-by: Stuart Summers
Double checked offline with HuC team, so
Acked-by: Michal Wajdeczko
Thanks for the double check and the review, pushed.
Daniele
Cc: Anusha Srivatsa
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 23
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 8 +++
2 files changed, 7 insertions(+), 24 deletions(-)
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 ea9a807abd4f..bb878119f06c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -339,25 +339,10 @@ int intel_uc_fw_fetch(struct intel_uc_fw
*uc_fw, struct drm_i915_private *i915)
}
/* Get version numbers from the CSS header */
- switch (uc_fw->type) {
- case INTEL_UC_FW_TYPE_GUC:
- uc_fw->major_ver_found =
FIELD_GET(CSS_SW_VERSION_GUC_MAJOR,
- css->sw_version);
- uc_fw->minor_ver_found =
FIELD_GET(CSS_SW_VERSION_GUC_MINOR,
- css->sw_version);
- break;
-
- case INTEL_UC_FW_TYPE_HUC:
- uc_fw->major_ver_found =
FIELD_GET(CSS_SW_VERSION_HUC_MAJOR,
- css->sw_version);
- uc_fw->minor_ver_found =
FIELD_GET(CSS_SW_VERSION_HUC_MINOR,
- css->sw_version);
- break;
-
- default:
- MISSING_CASE(uc_fw->type);
- break;
- }
+ uc_fw->major_ver_found = FIELD_GET(CSS_SW_VERSION_UC_MAJOR,
+ css->sw_version);
+ uc_fw->minor_ver_found = FIELD_GET(CSS_SW_VERSION_UC_MINOR,
+ css->sw_version);
if (uc_fw->major_ver_found != uc_fw->major_ver_wanted ||
uc_fw->minor_ver_found < uc_fw->minor_ver_wanted) {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
index ae58e8a8c53b..f8f6c91a0df6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
@@ -69,11 +69,9 @@ struct uc_css_header {
char username[8];
char buildnumber[12];
u32 sw_version;
-#define CSS_SW_VERSION_GUC_MAJOR (0xFF << 16)
-#define CSS_SW_VERSION_GUC_MINOR (0xFF << 8)
-#define CSS_SW_VERSION_GUC_PATCH (0xFF << 0)
-#define CSS_SW_VERSION_HUC_MAJOR (0x << 16)
-#define CSS_SW_VERSION_HUC_MINOR (0x << 0)
+#define CSS_SW_VERSION_UC_MAJOR (0xFF << 16)
+#define CSS_SW_VERSION_UC_MINOR (0xFF << 8)
+#define CSS_SW_VERSION_UC_PATCH (0xFF << 0)
u32 reserved[14];
u32 header_info;
} __packed;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/22] drm/i915: check for missing aperture in GTT pread/pwrite paths
Quoting Matthew Auld (2019-09-27 18:34:08) > From: CQ Tang > > drm_mm_insert_node_in_range() treats range_start > range_end as a > programmer error, such that we explode in insert_mappable_node. For now > simply check for missing aperture on such paths. range_start is 0. range_end is 0. drm_mm_insert_node_in_range(): DRM_MM_BUG_ON(range_start > range_end); if (size == 0 || range_end - range_start < size) return -ENOSPC; This patch is superfluous. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dmc: Update ICL DMC version to v1.09 (rev2)
And pushed. Daniele On 9/26/19 8:30 AM, Patchwork wrote: == Series Details == Series: drm/i915/dmc: Update ICL DMC version to v1.09 (rev2) URL : https://patchwork.freedesktop.org/series/66560/ State : success == Summary == CI Bug Log - changes from CI_DRM_6958_full -> Patchwork_14538_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14538_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-apl3/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-apl4/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-iclb6/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_eio@reset-stress: - shard-snb: [PASS][5] -> [FAIL][6] ([fdo#109661]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-snb6/igt@gem_...@reset-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-snb1/igt@gem_...@reset-stress.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-iclb5/igt@gem_exec_as...@concurrent-writes-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-iclb2/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([fdo#108686]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-glk9/igt@gem_tiled_swapp...@non-threaded.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-glk2/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-kbl6/igt@gem_workarou...@suspend-resume-fd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-kbl3/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_pm_rpm@pm-tiling: - shard-skl: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-skl10/igt@i915_pm_...@pm-tiling.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-skl2/igt@i915_pm_...@pm-tiling.html * igt@i915_pm_rpm@system-suspend: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#104108] / [fdo#107807]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-skl3/igt@i915_pm_...@system-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-skl7/igt@i915_pm_...@system-suspend.html * igt@i915_pm_rpm@universal-planes-dpms: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([fdo#103313]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-kbl4/igt@i915_pm_...@universal-planes-dpms.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-kbl2/igt@i915_pm_...@universal-planes-dpms.html * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-snb: [PASS][19] -> [SKIP][20] ([fdo#109271] / [fdo#109278]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-snb4/igt@kms_b...@extended-modeset-hang-newfb-render-a.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-snb2/igt@kms_b...@extended-modeset-hang-newfb-render-a.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][21] -> [INCOMPLETE][22] ([fdo#103927]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-apl7/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu: - shard-snb: [PASS][23] -> [SKIP][24] ([fdo#109271]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-snb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-snb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu.html * igt@kms_frontbuffer_tracki
Re: [Intel-gfx] [PATCH 2/3] drm/i915/tgl: Read SAGV block time from PCODE
On Wed, Sep 25, 2019 at 01:33:51PM -0700, James Ausmus wrote:
> Starting from TGL, we now need to read the SAGV block time via a PCODE
> mailbox, rather than having a static value.
>
> BSpec: 49326
>
> Cc: Ville Syrjälä
> Cc: Stanislav Lisovskiy
> Cc: Lucas De Marchi
> Signed-off-by: James Ausmus
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 20 +++-
> 2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e752de9470bd..84ae6553485b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8865,6 +8865,7 @@ enum {
> #define GEN9_SAGV_DISABLE0x0
> #define GEN9_SAGV_IS_DISABLED0x1
> #define GEN9_SAGV_ENABLE 0x3
> +#define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US 0x23
> #define GEN6_PCODE_DATA _MMIO(0x138128)
> #define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
> #define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 5ad72dcb0faa..ca2bec09edb5 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3665,16 +3665,26 @@ intel_has_sagv(struct drm_i915_private *dev_priv)
> static int
> intel_get_sagv_block_time_us(struct drm_i915_private *dev_priv)
> {
> - int sagv_block_time_us = 1000; /* Default to unusable block time */
> + uint val = 0;
uint?
> + int ret, sagv_block_time_us = 1000; /* Default to unusable block time */
val+ret could live in a tighter scope.
>
> - if (IS_GEN(dev_priv, 11))
> + if (INTEL_GEN(dev_priv) >= 12) {
> + ret = sandybridge_pcode_read(dev_priv,
> +
> GEN12_PCODE_READ_SAGV_BLOCK_TIME_US,
> + &val, NULL);
We should probably stash this somewhere so we don't have to keep
asking pcode about it every single time.
Magic numbers look correct
Reviewed-by: Ville Syrjälä
> + if (!ret)
> + sagv_block_time_us = val;
> + else
> + DRM_DEBUG_DRIVER("Couldn't read SAGV block time!\n");
> + } else if (IS_GEN(dev_priv, 11)) {
> sagv_block_time_us = 10;
> - else if (IS_GEN(dev_priv, 10))
> + } else if (IS_GEN(dev_priv, 10)) {
> sagv_block_time_us = 20;
> - else if (IS_GEN(dev_priv, 9))
> + } else if (IS_GEN(dev_priv, 9)) {
> sagv_block_time_us = 30;
> - else
> + } else {
> MISSING_CASE(INTEL_GEN(dev_priv));
> + }
>
> return sagv_block_time_us;
> }
> --
> 2.22.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
