Re: [Intel-gfx] [PATCH v4 5/7] lib/hexdump.c: Allow multiple groups to be separated by lines '|'
On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> With the wider display format, it can become hard to identify how many
> bytes into the line you are looking at.
>
> The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
> print vertical lines to separate every N groups of bytes.
>
> eg.
> buf:: 454d414e 43415053|4e495f45 00584544 NAMESPAC|E_INDEX.
> buf:0010: 0002| |
>
> Signed-off-by: Alastair D'Silva
> ---
> include/linux/printk.h | 3 +++
> lib/hexdump.c | 59 --
> 2 files changed, 54 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/printk.h b/include/linux/printk.h
[]
> @@ -485,6 +485,9 @@ enum {
>
> #define HEXDUMP_ASCIIBIT(0)
> #define HEXDUMP_SUPPRESS_REPEATEDBIT(1)
> +#define HEXDUMP_2_GRP_LINES BIT(2)
> +#define HEXDUMP_4_GRP_LINES BIT(3)
> +#define HEXDUMP_8_GRP_LINES BIT(4)
These aren't really bits as only one value should be set
as 8 overrides 4 and 4 overrides 2.
I would also expect this to be a value of 2 in your above
example, rather than 8. It's described as groups not bytes.
The example is showing a what would normally be a space ' '
separator as a vertical bar '|' every 2nd grouping.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
On Tue, 2019-06-25 at 15:06 +1000, Alastair D'Silva wrote: > The change actions Jani's suggestion: > https://lkml.org/lkml/2019/6/20/343 I suggest not changing any of the existing uses of hex_dump_to_buffer and only use hex_dump_to_buffer_ext when necessary for your extended use cases. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
On Tue, 2019-06-25 at 15:06 +1000, Alastair D'Silva wrote: > On Mon, 2019-06-24 at 22:01 -0700, Joe Perches wrote: > > On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote: > > > From: Alastair D'Silva > > > > > > In order to support additional features, rename hex_dump_to_buffer > > > to > > > hex_dump_to_buffer_ext, and replace the ascii bool parameter with > > > flags. > > [] > > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c > > > b/drivers/gpu/drm/i915/intel_engine_cs.c > > [] > > > @@ -1338,9 +1338,8 @@ static void hexdump(struct drm_printer *m, > > > const void *buf, size_t len) > > > } > > > > > > WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos, > > > - rowsize, sizeof(u32), > > > - line, sizeof(line), > > > - false) >= > > > sizeof(line)); > > > + rowsize, sizeof(u32), > > > line, > > > + sizeof(line)) >= > > > sizeof(line)); > > > > Huh? Why do this? [] > The change actions Jani's suggestion: > https://lkml.org/lkml/2019/6/20/343 I think you need to read this change again. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915/execlists: Disable preemption under GVT
On 06/24/2019 05:48 PM, Chris Wilson wrote:
> Preempt-to-busy uses a GPU semaphore to enforce an idle-barrier across
> preemption, but mediated gvt does not fully support semaphores.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_lrc.c | 21 -
> drivers/gpu/drm/i915/gt/selftest_lrc.c| 3 +++
> 3 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 4961f74fd902..d6fbc47727c1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -830,6 +830,8 @@ int intel_engine_init_common(struct intel_engine_cs
> *engine)
> struct drm_i915_private *i915 = engine->i915;
> int ret;
>
> + engine->set_default_submission(engine);
> +
> /* We may need to do things with the shrinker which
>* require us to immediately switch back to the default
>* context. This can cause a problem as pinning the
> @@ -857,8 +859,6 @@ int intel_engine_init_common(struct intel_engine_cs
> *engine)
>
> engine->emit_fini_breadcrumb_dw = ret;
>
> - engine->set_default_submission(engine);
> -
> return 0;
>
> err_unpin:
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index c8a0c9b32764..8017efb36f7b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -294,6 +294,9 @@ static inline bool need_preempt(const struct
> intel_engine_cs *engine,
> {
> int last_prio;
>
> + if (!intel_engine_has_preemption(engine))
> + return false;
> +
> /*
>* Check if the current priority hint merits a preemption attempt.
>*
> @@ -890,6 +893,9 @@ need_timeslice(struct intel_engine_cs *engine, const
> struct i915_request *rq)
> {
> int hint;
>
> + if (!intel_engine_has_preemption(engine))
> + return false;
> +
> if (list_is_last(>sched.link, >active.requests))
> return false;
>
> @@ -2600,7 +2606,8 @@ static u32 *gen8_emit_fini_breadcrumb(struct
> i915_request *request, u32 *cs)
> *cs++ = MI_USER_INTERRUPT;
>
> *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
> - cs = emit_preempt_busywait(request, cs);
> + if (intel_engine_has_preemption(request->engine))
> + cs = emit_preempt_busywait(request, cs);
>
> request->tail = intel_ring_offset(request, cs);
> assert_ring_tail_valid(request->ring, request->tail);
> @@ -2624,7 +2631,8 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct
> i915_request *request, u32 *cs)
> *cs++ = MI_USER_INTERRUPT;
>
> *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
> - cs = emit_preempt_busywait(request, cs);
> + if (intel_engine_has_preemption(request->engine))
> + cs = emit_preempt_busywait(request, cs);
>
> request->tail = intel_ring_offset(request, cs);
> assert_ring_tail_valid(request->ring, request->tail);
> @@ -2672,10 +2680,11 @@ void intel_execlists_set_default_submission(struct
> intel_engine_cs *engine)
> engine->unpark = NULL;
>
> engine->flags |= I915_ENGINE_SUPPORTS_STATS;
> - if (!intel_vgpu_active(engine->i915))
> + if (!intel_vgpu_active(engine->i915)) {
> engine->flags |= I915_ENGINE_HAS_SEMAPHORES;
> - if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
> - engine->flags |= I915_ENGINE_HAS_PREEMPTION;
> + if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
> + engine->flags |= I915_ENGINE_HAS_PREEMPTION;
> + }
> }
>
> static void execlists_destroy(struct intel_engine_cs *engine)
> @@ -3463,6 +3472,8 @@ intel_execlists_create_virtual(struct i915_gem_context
> *ctx,
> ve->base.emit_fini_breadcrumb = sibling->emit_fini_breadcrumb;
> ve->base.emit_fini_breadcrumb_dw =
> sibling->emit_fini_breadcrumb_dw;
> +
> + ve->base.flags = sibling->flags;
> }
>
> return >context;
> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> index 0c97f953e908..b99b589a6c81 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> @@ -270,6 +270,9 @@ static int live_timeslice_preempt(void *arg)
> enum intel_engine_id id;
>
> for_each_engine(engine, i915, id) {
> + if (!intel_engine_has_preemption(engine))
> + continue;
> +
> memset(vaddr, 0, PAGE_SIZE);
>
> err = slice_semaphore_queue(engine, vma, count);
Tested-by: Xiaolin Zhang
with this patch, linux guest can boot up successfully with sanity test passed.
But it is easy to get the GPU hang when running "vblank_mode=0 glxgears" in
Re: [Intel-gfx] [PATCH v4 0/7] Hexdump Enhancements
On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote: > From: Alastair D'Silva > > Apologies for the large CC list, it's a heads up for those responsible > for subsystems where a prototype change in generic code causes a change > in those subsystems. [] > The default behaviour of hexdump is unchanged, however, the prototype > for hex_dump_to_buffer() has changed, and print_hex_dump() has been > renamed to print_hex_dump_ext(), with a wrapper replacing it for > compatibility with existing code, which would have been too invasive to > change. I believe this cover letter is misleading. The point of the wrapper is to avoid unnecessary changes in existing code. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> In order to support additional features, rename hex_dump_to_buffer to
> hex_dump_to_buffer_ext, and replace the ascii bool parameter with flags.
[]
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
[]
> @@ -1338,9 +1338,8 @@ static void hexdump(struct drm_printer *m, const void
> *buf, size_t len)
> }
>
> WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos,
> - rowsize, sizeof(u32),
> - line, sizeof(line),
> - false) >= sizeof(line));
> + rowsize, sizeof(u32), line,
> + sizeof(line)) >= sizeof(line));
Huh? Why do this?
> diff --git a/drivers/isdn/hardware/mISDN/mISDNisar.c
> b/drivers/isdn/hardware/mISDN/mISDNisar.c
[]
> @@ -70,8 +70,9 @@ send_mbox(struct isar_hw *isar, u8 his, u8 creg, u8 len, u8
> *msg)
> int l = 0;
>
> while (l < (int)len) {
> - hex_dump_to_buffer(msg + l, len - l, 32, 1,
> -isar->log, 256, 1);
> + hex_dump_to_buffer_ext(msg + l, len - l, 32, 1,
> +isar->log, 256,
> +HEXDUMP_ASCII);
Again, why do any of these?
The point of the wrapper is to avoid changing these.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Display uncore (rev2)
== Series Details == Series: Display uncore (rev2) URL : https://patchwork.freedesktop.org/series/61735/ State : success == Summary == CI Bug Log - changes from CI_DRM_6337_full -> Patchwork_13408_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13408_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-kbl: [PASS][1] -> [FAIL][2] ([fdo#110667]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/shard-kbl6/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/shard-kbl6/igt@gem_...@in-flight-suspend.html * igt@gem_eio@reset-stress: - shard-snb: [PASS][3] -> [FAIL][4] ([fdo#109661]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/shard-snb4/igt@gem_...@reset-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/shard-snb7/igt@gem_...@reset-stress.html * igt@gem_exec_reloc@basic-wc-cpu-active: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#110913 ]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/shard-apl2/igt@gem_exec_re...@basic-wc-cpu-active.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/shard-apl3/igt@gem_exec_re...@basic-wc-cpu-active.html * igt@gem_partial_pwrite_pread@write: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/shard-kbl6/igt@gem_partial_pwrite_pr...@write.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/shard-kbl7/igt@gem_partial_pwrite_pr...@write.html * igt@gem_persistent_relocs@forked-faulting-reloc-thrashing: - shard-hsw: [PASS][9] -> [DMESG-WARN][10] ([fdo#110789] / [fdo#110913 ]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/shard-hsw8/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/shard-hsw1/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html * igt@gem_softpin@softpin: - shard-snb: [PASS][11] -> [DMESG-WARN][12] ([fdo#110789] / [fdo#110913 ]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/shard-snb4/igt@gem_soft...@softpin.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/shard-snb6/igt@gem_soft...@softpin.html * igt@gem_tiled_swapping@non-threaded: - shard-iclb: [PASS][13] -> [DMESG-WARN][14] ([fdo#108686]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/shard-iclb6/igt@gem_tiled_swapp...@non-threaded.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/shard-iclb5/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([fdo#110913 ]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/shard-glk3/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/shard-glk1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html * igt@i915_pm_rpm@i2c: - shard-hsw: [PASS][17] -> [FAIL][18] ([fdo#104097]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/shard-hsw5/igt@i915_pm_...@i2c.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/shard-hsw1/igt@i915_pm_...@i2c.html * igt@i915_pm_rpm@universal-planes-dpms: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#107713] / [fdo#108840]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/shard-iclb3/igt@i915_pm_...@universal-planes-dpms.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/shard-iclb8/igt@i915_pm_...@universal-planes-dpms.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([fdo#109507]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/shard-skl2/igt@kms_f...@flip-vs-suspend-interruptible.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/shard-skl8/igt@kms_f...@flip-vs-suspend-interruptible.html - shard-kbl: [PASS][23] -> [INCOMPLETE][24] ([fdo#103665]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/shard-kbl6/igt@kms_f...@flip-vs-suspend-interruptible.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/shard-kbl1/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-pgflip-blt: - shard-hsw: [PASS][25] -> [SKIP][26] ([fdo#109271]) +11 similar issues [25]:
Re: [Intel-gfx] [PATCH v3 2/4] drm/panel: set display info in panel attach
On Fri, Jun 21, 2019 at 8:41 PM Derek Basehore wrote:
>
> Devicetree systems can set panel orientation via a panel binding, but
> there's no way, as is, to propagate this setting to the connector,
> where the property need to be added.
> To address this, this patch sets orientation, as well as other fixed
> values for the panel, in the drm_panel_attach function. These values
> are stored from probe in the drm_panel struct.
>
> Signed-off-by: Derek Basehore
> ---
> drivers/gpu/drm/drm_panel.c | 28
> include/drm/drm_panel.h | 14 ++
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index 507099af4b57..5690fca30236 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -104,11 +104,23 @@ EXPORT_SYMBOL(drm_panel_remove);
> */
> int drm_panel_attach(struct drm_panel *panel, struct drm_connector
> *connector)
> {
> + struct drm_display_info *info;
> +
> if (panel->connector)
> return -EBUSY;
>
> panel->connector = connector;
> panel->drm = connector->dev;
> + info = >display_info;
> + info->width_mm = panel->width_mm;
> + info->height_mm = panel->height_mm;
> + info->bpc = panel->bpc;
> + info->panel_orientation = panel->orientation;
> + info->bus_flags = panel->bus_flags;
> + if (panel->bus_formats)
> + drm_display_info_set_bus_formats(>display_info,
> +panel->bus_formats,
> +panel->num_bus_formats);
>
> return 0;
> }
> @@ -128,6 +140,22 @@ EXPORT_SYMBOL(drm_panel_attach);
> */
> int drm_panel_detach(struct drm_panel *panel)
> {
> + struct drm_display_info *info;
> +
> + if (!panel->connector)
> + goto out;
> +
> + info = >connector->display_info;
> + info->width_mm = 0;
> + info->height_mm = 0;
> + info->bpc = 0;
> + info->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> + info->bus_flags = 0;
> + kfree(info->bus_formats);
> + info->bus_formats = NULL;
> + info->num_bus_formats = 0;
> +
> +out:
> panel->connector = NULL;
> panel->drm = NULL;
>
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 3564952f1a4f..760ca5865962 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -37,6 +37,8 @@ struct display_timing;
> * struct drm_panel_funcs - perform operations on a given panel
> * @disable: disable panel (turn off back light, etc.)
> * @unprepare: turn off panel
> + * @detach: detach panel->connector (clear internal state, etc.)
> + * @attach: attach panel->connector (update internal state, etc.)
> * @prepare: turn on panel and perform set up
> * @enable: enable panel (turn on back light, etc.)
> * @get_modes: add modes to the connector that the panel is attached to and
> @@ -93,6 +95,18 @@ struct drm_panel {
>
> const struct drm_panel_funcs *funcs;
>
> + /*
> +* panel information to be set in the connector when the panel is
> +* attached.
> +*/
> + unsigned int width_mm;
> + unsigned int height_mm;
> + unsigned int bpc;
> + int orientation;
> + const u32 *bus_formats;
> + unsigned int num_bus_formats;
> + u32 bus_flags;
Should probably put these in a struct to ensure the connector and
panel have the same data types. Will do in a following patch if we
stay with this.
> +
> struct list_head list;
> };
>
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable Transcoder Port Sync feature for Tiled displays (rev2)
== Series Details == Series: Enable Transcoder Port Sync feature for Tiled displays (rev2) URL : https://patchwork.freedesktop.org/series/59837/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6337 -> Patchwork_13409 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13409 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13409, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13409/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13409: ### IGT changes ### Possible regressions * igt@kms_busy@basic-flip-a: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/fi-icl-u3/igt@kms_b...@basic-flip-a.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13409/fi-icl-u3/igt@kms_b...@basic-flip-a.html - fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/fi-icl-u2/igt@kms_b...@basic-flip-a.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13409/fi-icl-u2/igt@kms_b...@basic-flip-a.html Known issues Here are the changes found in Patchwork_13409 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload-with-fault-injection: - fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([fdo#110900]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/fi-bsw-kefka/igt@i915_module_l...@reload-with-fault-injection.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13409/fi-bsw-kefka/igt@i915_module_l...@reload-with-fault-injection.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#109485]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13409/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@i915_selftest@live_blt: - fi-skl-iommu: [INCOMPLETE][9] ([fdo#108602]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/fi-skl-iommu/igt@i915_selftest@live_blt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13409/fi-skl-iommu/igt@i915_selftest@live_blt.html * igt@kms_busy@basic-flip-c: - fi-kbl-7500u: [SKIP][11] ([fdo#109271] / [fdo#109278]) -> [PASS][12] +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13409/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html * igt@kms_chamelium@dp-hpd-fast: - fi-kbl-7500u: [DMESG-WARN][13] ([fdo#103558] / [fdo#105602]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/fi-kbl-7500u/igt@kms_chamel...@dp-hpd-fast.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13409/fi-kbl-7500u/igt@kms_chamel...@dp-hpd-fast.html [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558 [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 [fdo#110900]: https://bugs.freedesktop.org/show_bug.cgi?id=110900 Participating hosts (50 -> 43) -- Additional (1): fi-gdg-551 Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6337 -> Patchwork_13409 CI_DRM_6337: 294d5056c1f3fc839b6c3bbd2aa6f451ac316991 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5066: a6f5cc854efb4b7dfed7f0a2c1039a9ddd1a35a5 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13409: 6aa445344e2356d77d86e93fdb1d79f6d2673232 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6aa445344e23 drm/i915/display/icl: In port sync mode disable slaves first then masters 86a0ab130772 drm/i915/display/icl: Disable transcoder port sync as part of crtc_disable() sequence cfc8af932092 drm/i915/display/icl: Enable master-slaves in trans port sync mode in correct order 105509334ec9 drm/i915/display/icl: HW state readout for transcoder port sync config 2fedf54378a8 drm/i915/display/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports f428b4bebc07
[Intel-gfx] ✓ Fi.CI.BAT: success for Display uncore (rev2)
== Series Details == Series: Display uncore (rev2) URL : https://patchwork.freedesktop.org/series/61735/ State : success == Summary == CI Bug Log - changes from CI_DRM_6337 -> Patchwork_13408 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/ Known issues Here are the changes found in Patchwork_13408 that come from known issues: ### IGT changes ### Issues hit * igt@kms_frontbuffer_tracking@basic: - fi-icl-u2: [PASS][1] -> [FAIL][2] ([fdo#103167]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@gem_ctx_create@basic-files: - fi-icl-dsi: [INCOMPLETE][3] ([fdo#107713] / [fdo#109100]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html * igt@i915_selftest@live_blt: - fi-skl-iommu: [INCOMPLETE][5] ([fdo#108602]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/fi-skl-iommu/igt@i915_selftest@live_blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/fi-skl-iommu/igt@i915_selftest@live_blt.html * igt@kms_busy@basic-flip-c: - fi-kbl-7500u: [SKIP][7] ([fdo#109271] / [fdo#109278]) -> [PASS][8] +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html * igt@kms_chamelium@dp-hpd-fast: - fi-kbl-7500u: [DMESG-WARN][9] ([fdo#103558] / [fdo#105602]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6337/fi-kbl-7500u/igt@kms_chamel...@dp-hpd-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/fi-kbl-7500u/igt@kms_chamel...@dp-hpd-fast.html [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558 [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 Participating hosts (50 -> 42) -- Additional (1): fi-gdg-551 Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-skl-lmem fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6337 -> Patchwork_13408 CI_DRM_6337: 294d5056c1f3fc839b6c3bbd2aa6f451ac316991 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5066: a6f5cc854efb4b7dfed7f0a2c1039a9ddd1a35a5 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13408: 6280c29422ffbbcb09f51d05aa3ad149ab90a480 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6280c29422ff drm/i915: convert intel_hdmi to display reg accessors 3a32a4f1b42c drm/i915: introduce display_uncore be0532e5172b drm/i915: rework mmio debug stop/start e7d02b0ed57e drm/i915: split out uncore_mmio_debug == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13408/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable Transcoder Port Sync feature for Tiled displays (rev2)
== Series Details ==
Series: Enable Transcoder Port Sync feature for Tiled displays (rev2)
URL : https://patchwork.freedesktop.org/series/59837/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e1dacdba0522 drm/i915/display: Rename update_crtcs() to commit_modeset_enables()
86c171d8590a drm/i915/display: Move the commit_tail() disable sequence to
commit_modeset_disables() hook
f428b4bebc07 drm/i915/display/icl: Save Master transcoder in slave's crtc_state
for Transcoder Port Sync
2fedf54378a8 drm/i915/display/icl: Enable TRANSCODER PORT SYNC for tiled
displays across separate ports
105509334ec9 drm/i915/display/icl: HW state readout for transcoder port sync
config
-:39: CHECK:BRACES: braces {} should be used on all arms of this statement
#39: FILE: drivers/gpu/drm/i915/display/intel_display.c:10283:
+ if (trans_port_sync & PORT_SYNC_MODE_ENABLE) {
[...]
+ } else
[...]
-:56: CHECK:BRACES: Unbalanced braces around else statement
#56: FILE: drivers/gpu/drm/i915/display/intel_display.c:10300:
+ } else
total: 0 errors, 0 warnings, 2 checks, 56 lines checked
cfc8af932092 drm/i915/display/icl: Enable master-slaves in trans port sync mode
in correct order
-:146: WARNING:LONG_LINE: line over 100 characters
#146: FILE: drivers/gpu/drm/i915/display/intel_display.c:14036:
+
_intel_crtc_state(old_crtc_state)->wm.skl.ddb) &&
total: 0 errors, 1 warnings, 0 checks, 263 lines checked
86a0ab130772 drm/i915/display/icl: Disable transcoder port sync as part of
crtc_disable() sequence
6aa445344e23 drm/i915/display/icl: In port sync mode disable slaves first then
masters
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/4] drm/i915/psr: Make PSR registers relative to transcoders
On Thu, 2019-06-20 at 17:36 +, Souza, Jose wrote:
> On Thu, 2019-06-20 at 11:13 +0300, Jani Nikula wrote:
> > On Wed, 19 Jun 2019, José Roberto de Souza
> > wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 4fc8dc083766..31fb4de5081c 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -4225,10 +4225,18 @@ enum {
> > > #define PIPESRC(trans) _MMIO_TRANS2(trans, _PIPEASRC)
> > > #define PIPE_MULT(trans) _MMIO_TRANS2(trans, _PIPE_MULT_A)
> > >
> > > -/* HSW+ eDP PSR registers */
> > > -#define HSW_EDP_PSR_BASE 0x64800
> > > -#define BDW_EDP_PSR_BASE 0x6f800
> > > -#define EDP_PSR_CTL _MMIO(dev_priv-
> > > > psr_mmio_base + 0)
> > > +/*
> > > + * HSW+ eDP PSR registers
> > > + *
> > > + * HSW PSR registers are relative to DDIA(_DDI_BUF_CTL_A +
> > > 0x800)
> > > with just one
> > > + * instance of it
> > > + */
> > > +#define _HSW_EDP_PSR_BASE0x64800
> > > +#define _SRD_CTL_A 0x60800
> > > +#define _SRD_CTL_EDP 0x6f800
> > > +#define _HSW_PSR_ADJ(reg)((reg) -
> > > _SRD_CTL_A +
> > > _HSW_EDP_PSR_BASE)
> > > +#define _PSR_ADJ(tran, reg) (IS_HASWELL(dev
> > > _priv) ? _HSW_PSR_ADJ(reg) : _TRANS2(tran, reg))
> > > +#define EDP_PSR_CTL(tran)_MMIO(_PSR_ADJ(
> > > tran,
> > > _SRD_CTL_A))
> >
> > There are currently three instances of platform/gen checks in
> > i915_reg.h. They are the exception, and they're in individual
> > macros
> > that aren't even register offset definitions let alone helpers that
> > get
> > proliferated to several other macros.
> >
> > This change here is quite a big precedent in that regard, and not
> > to
> > be
> > done lightly. Usually the case is others will follow suit, so this
> > is
> > not just about this one instance. It's about deciding whether this
> > is
> > the direction we want to take. How far are we prepared to go and
> > how
> > do
> > we stop there?
> >
> > There's really no way to set the psr->transcoder such on HSW that
> > it
> > would work with MMIO_TRANS2()?
>
> I'm going to think about but right now the only other option that
> comes
> in my mind is to have the transcoder offset as macro parameter:
>
> #define _SRD_CTL 0x800
> #define EDP_PSR_CTL(trans) _MMIO(trans + _SRD_CTL)
>
> But we would lose the full offset address of PSR registers.
This is the only other good option that I can think about.
Any other idea DK?
>
> > BR,
> > Jani.
> >
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/icl: Add new supported CD clocks
On Fri, 2019-06-21 at 09:15 -0700, Matt Roper wrote:
> On Thu, Jun 20, 2019 at 05:45:54PM -0700, José Roberto de Souza
> wrote:
> > Now 180, 172.8 and 192 MHz are supported.
> >
> > 180 and 172.8 MHz CD clocks will only be used when audio is not
> > enabled as state by BSpec and implemented in
> > intel_crtc_compute_min_cdclk(), CD clock must be at least twice of
> > Azalia BCLK and BCLK by default is 96 MHz, it could be set to 48
> > MHz
> > but we are not reading it.
> >
> > BSpec: 20598
> > BSpec: 15729
> > Cc: Clint Taylor
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
>
> I think Ville wanted a 'static' on the range arrays. But aside from
> that, the changes here match the bspec, so
>
> Reviewed-by: Matt Roper
Oh I forgot that.
I did the audio test while on low cd clock frequencies, going to wait
one more day before fix that.
>
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 30 +++---
> >
> > 1 file changed, 21 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 8993ab283562..8eef177b2bbd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1756,9 +1756,10 @@ static void cnl_sanitize_cdclk(struct
> > drm_i915_private *dev_priv)
> >
> > static int icl_calc_cdclk(int min_cdclk, unsigned int ref)
> > {
> > - int ranges_24[] = { 312000, 552000, 648000 };
> > - int ranges_19_38[] = { 307200, 556800, 652800 };
> > - int *ranges;
> > + const int ranges_24[] = { 18, 192000, 312000, 552000,
> > 648000 };
> > + const int ranges_19_38[] = { 172800, 192000, 307200, 556800,
> > 652800 };
> > + const int *ranges;
> > + int len, i;
> >
> > switch (ref) {
> > default:
> > @@ -1766,19 +1767,22 @@ static int icl_calc_cdclk(int min_cdclk,
> > unsigned int ref)
> > /* fall through */
> > case 24000:
> > ranges = ranges_24;
> > + len = ARRAY_SIZE(ranges_24);
> > break;
> > case 19200:
> > case 38400:
> > ranges = ranges_19_38;
> > + len = ARRAY_SIZE(ranges_19_38);
> > break;
> > }
> >
> > - if (min_cdclk > ranges[1])
> > - return ranges[2];
> > - else if (min_cdclk > ranges[0])
> > - return ranges[1];
> > - else
> > - return ranges[0];
> > + for (i = 0; i < len; i++) {
> > + if (min_cdclk <= ranges[i])
> > + return ranges[i];
> > + }
> > +
> > + WARN_ON(min_cdclk > ranges[len - 1]);
> > + return ranges[len - 1];
> > }
> >
> > static int icl_calc_cdclk_pll_vco(struct drm_i915_private
> > *dev_priv, int cdclk)
> > @@ -1792,16 +1796,24 @@ static int icl_calc_cdclk_pll_vco(struct
> > drm_i915_private *dev_priv, int cdclk)
> > default:
> > MISSING_CASE(cdclk);
> > /* fall through */
> > + case 172800:
> > case 307200:
> > case 556800:
> > case 652800:
> > WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
> > dev_priv->cdclk.hw.ref != 38400);
> > break;
> > + case 18:
> > case 312000:
> > case 552000:
> > case 648000:
> > WARN_ON(dev_priv->cdclk.hw.ref != 24000);
> > + break;
> > + case 192000:
> > + WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
> > + dev_priv->cdclk.hw.ref != 38400 &&
> > + dev_priv->cdclk.hw.ref != 24000);
> > + break;
> > }
> >
> > ratio = cdclk / (dev_priv->cdclk.hw.ref / 2);
> > --
> > 2.22.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 8/8] drm/i915/display/icl: In port sync mode disable slaves first then masters
In the transcoder port sync mode, the slave transcoders mask their vblanks
until master transcoder's vblank so while disabling them, make
sure slaves are disabled first and then the masters.
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 117 ++-
1 file changed, 111 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 0a0d97ef03d6..85746a26d0e0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13901,6 +13901,106 @@ static void intel_commit_modeset_disables(struct
drm_atomic_state *state)
}
}
+static void icl_commit_modeset_disables(struct drm_atomic_state *state)
+{
+ struct drm_device *dev = state->dev;
+ struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ struct intel_crtc_state *new_intel_crtc_state, *old_intel_crtc_state;
+ struct drm_crtc *crtc;
+ struct intel_crtc *intel_crtc;
+ int i;
+
+ /*
+* Disable all the Port Sync Slaves first
+*/
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ old_intel_crtc_state = to_intel_crtc_state(old_crtc_state);
+ new_intel_crtc_state = to_intel_crtc_state(new_crtc_state);
+ intel_crtc = to_intel_crtc(crtc);
+
+ if (!needs_modeset(new_crtc_state) ||
+ !is_trans_port_sync_slave(old_intel_crtc_state))
+ continue;
+
+ intel_pre_plane_update(old_intel_crtc_state,
new_intel_crtc_state);
+
+ if (old_crtc_state->active) {
+ intel_crtc_disable_planes(intel_state, intel_crtc);
+
+ /*
+* We need to disable pipe CRC before disabling the
pipe,
+* or we race against vblank off.
+*/
+ intel_crtc_disable_pipe_crc(intel_crtc);
+
+ dev_priv->display.crtc_disable(old_intel_crtc_state,
state);
+ intel_crtc->active = false;
+ intel_fbc_disable(intel_crtc);
+ intel_disable_shared_dpll(old_intel_crtc_state);
+
+ /*
+* Underruns don't always raise interrupts,
+* so check manually.
+*/
+ intel_check_cpu_fifo_underruns(dev_priv);
+ intel_check_pch_fifo_underruns(dev_priv);
+
+ /* FIXME unify this for all platforms */
+ if (!new_crtc_state->active &&
+ !HAS_GMCH(dev_priv) &&
+ dev_priv->display.initial_watermarks)
+
dev_priv->display.initial_watermarks(intel_state,
+
new_intel_crtc_state);
+ }
+ }
+
+ /*
+* Disable rest of the CRTCs other than slaves
+*/
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ old_intel_crtc_state = to_intel_crtc_state(old_crtc_state);
+ new_intel_crtc_state = to_intel_crtc_state(new_crtc_state);
+ intel_crtc = to_intel_crtc(crtc);
+
+ if (!needs_modeset(new_crtc_state) ||
+ is_trans_port_sync_slave(old_intel_crtc_state))
+ continue;
+
+ intel_pre_plane_update(old_intel_crtc_state,
new_intel_crtc_state);
+
+ if (old_crtc_state->active) {
+ intel_crtc_disable_planes(intel_state, intel_crtc);
+
+ /*
+* We need to disable pipe CRC before disabling the
pipe,
+* or we race against vblank off.
+*/
+ intel_crtc_disable_pipe_crc(intel_crtc);
+
+ dev_priv->display.crtc_disable(old_intel_crtc_state,
state);
+ intel_crtc->active = false;
+ intel_fbc_disable(intel_crtc);
+ intel_disable_shared_dpll(old_intel_crtc_state);
+
+ /*
+* Underruns don't always raise interrupts,
+* so check manually.
+*/
+ intel_check_cpu_fifo_underruns(dev_priv);
+ intel_check_pch_fifo_underruns(dev_priv);
+
+ /* FIXME unify this for all platforms */
+ if (!new_crtc_state->active &&
+
[Intel-gfx] [PATCH v3 5/8] drm/i915/display/icl: HW state readout for transcoder port sync config
After the state is committed, we readout the HW registers and compare
the HW state with the SW state that we just committed.
For Transcdoer port sync, we add master_transcoder and the
salves bitmask to the crtc_state, hence we need to read those during
the HW state readout to avoid pipe state mismatch.
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 44
1 file changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f359a6212574..7156b1b4c6c5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10271,6 +10271,47 @@ static void haswell_get_ddi_port_state(struct
intel_crtc *crtc,
}
}
+static void icelake_get_trans_port_sync_config(struct intel_crtc *crtc,
+ struct intel_crtc_state
*pipe_config)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ u32 trans_port_sync, transcoders, master_select;
+ enum transcoder cpu_transcoder;
+
+ trans_port_sync =
I915_READ(TRANS_DDI_FUNC_CTL2(pipe_config->cpu_transcoder));
+ if (trans_port_sync & PORT_SYNC_MODE_ENABLE) {
+ master_select = trans_port_sync &
+ PORT_SYNC_MODE_MASTER_SELECT_MASK;
+ switch (master_select) {
+ case 1:
+ pipe_config->master_transcoder = TRANSCODER_A;
+ break;
+ case 2:
+ pipe_config->master_transcoder = TRANSCODER_B;
+ break;
+ case 3:
+ pipe_config->master_transcoder = TRANSCODER_C;
+ break;
+ default:
+ pipe_config->master_transcoder = TRANSCODER_EDP;
+ break;
+ }
+ } else
+ pipe_config->master_transcoder = INVALID_TRANSCODER;
+
+ transcoders = BIT(TRANSCODER_EDP) |
+ BIT(TRANSCODER_A) |
+ BIT(TRANSCODER_B) |
+ BIT(TRANSCODER_C);
+ for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, transcoders) {
+ trans_port_sync =
I915_READ(TRANS_DDI_FUNC_CTL2(cpu_transcoder));
+
+ if (trans_port_sync & PORT_SYNC_MODE_ENABLE)
+ pipe_config->sync_mode_slaves_mask |=
BIT(cpu_transcoder);
+ }
+}
+
static bool haswell_get_pipe_config(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config)
{
@@ -10367,6 +10408,9 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->pixel_multiplier = 1;
}
+ if (INTEL_GEN(dev_priv) >= 11)
+ icelake_get_trans_port_sync_config(crtc, pipe_config);
+
out:
for_each_power_domain(power_domain, power_domain_mask)
intel_display_power_put(dev_priv,
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 3/8] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync
In case of tiled displays when the two tiles are sent across two CRTCs
over two separate DP SST connectors, we need a mechanism to synchronize
the two CRTCs and their corresponding transcoders.
So use the master-slave mode where there is one master corresponding
to last horizontal and vertical tile that needs to be genlocked with
all other slave tiles.
This patch identifies saves the master transcoder in all the slave
CRTC states. This is needed to select the master CRTC/transcoder
while configuring transcoder port sync for the corresponding slaves.
v3:
* Use master_tramscoder instead of master_crtc for valid
HW state readouts (Ville)
v2:
* Move this to intel_mode_set_pipe_config(Jani N, Ville)
* Use slave_bitmask to save associated slaves in master crtc state (Ville)
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 102 +++
drivers/gpu/drm/i915/display/intel_display.h | 1 +
drivers/gpu/drm/i915/intel_drv.h | 6 ++
3 files changed, 109 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c34118998ace..367c7fb2be88 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11600,6 +11600,91 @@ static bool c8_planes_changed(const struct
intel_crtc_state *new_crtc_state)
return !old_crtc_state->c8_planes != !new_crtc_state->c8_planes;
}
+static int icl_add_sync_mode_crtcs(struct drm_crtc *crtc,
+ struct intel_crtc_state *crtc_state,
+ struct drm_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+ struct drm_connector *master_connector, *connector;
+ struct drm_connector_state *connector_state;
+ struct drm_connector_list_iter conn_iter;
+ struct drm_crtc *master_crtc = NULL;
+ struct drm_crtc_state *master_crtc_state;
+ struct intel_crtc_state *master_pipe_config;
+ int i, tile_group_id;
+
+ if (INTEL_GEN(dev_priv) < 11)
+ return 0;
+
+ /*
+* In case of tiled displays there could be one or more slaves but
there is
+* only one master. Lets make the CRTC used by the connector
corresponding
+* to the last horizonal and last vertical tile a master/genlock CRTC.
+* All the other CRTCs corresponding to other tiles of the same Tile
group
+* are the slave CRTCs and hold a pointer to their genlock CRTC.
+*/
+ for_each_new_connector_in_state(state, connector, connector_state, i) {
+ if (connector_state->crtc != crtc)
+ continue;
+ if (!connector->has_tile)
+ continue;
+ if (crtc_state->base.mode.hdisplay != connector->tile_h_size ||
+ crtc_state->base.mode.vdisplay != connector->tile_v_size)
+ return 0;
+ if (connector->tile_h_loc == connector->num_h_tile - 1 &&
+ connector->tile_v_loc == connector->num_v_tile - 1)
+ continue;
+ crtc_state->sync_mode_slaves_mask = 0;
+ tile_group_id = connector->tile_group->id;
+ drm_connector_list_iter_begin(_priv->drm, _iter);
+ drm_for_each_connector_iter(master_connector, _iter) {
+ struct drm_connector_state *master_conn_state = NULL;
+
+ if (!master_connector->has_tile)
+ continue;
+ if (master_connector->tile_h_loc !=
master_connector->num_h_tile - 1 ||
+ master_connector->tile_v_loc !=
master_connector->num_v_tile - 1)
+ continue;
+ if (master_connector->tile_group->id != tile_group_id)
+ continue;
+
+ master_conn_state =
drm_atomic_get_connector_state(state,
+
master_connector);
+ if (IS_ERR(master_conn_state)) {
+ drm_connector_list_iter_end(_iter);
+ return PTR_ERR(master_conn_state);
+ }
+ if (master_conn_state->crtc) {
+ master_crtc = master_conn_state->crtc;
+ break;
+ }
+ }
+ drm_connector_list_iter_end(_iter);
+
+ if (!master_crtc) {
+ DRM_DEBUG_KMS("Could not find Master CRTC for Slave
CRTC %d\n",
+ connector_state->crtc->base.id);
+ return -EINVAL;
+ }
+
+
[Intel-gfx] [PATCH v3 6/8] drm/i915/display/icl: Enable master-slaves in trans port sync mode in correct order
As per the display enable sequence, we need to follow the enable sequence
for slaves first with DP_TP_CTL set to Idle and configure the transcoder
port sync register to select the corersponding master, then follow the
enable sequence for master leaving DP_TP_CTL to idle.
At this point the transcoder port sync mode is configured and enabled
and the Vblanks of both ports are synchronized so then set DP_TP_CTL
for the slave and master to Normal and do post crtc enable updates.
v2:
* Create a icl_update_crtcs hook (Maarten, Danvet)
* This sequence only for CRTCs in trans port sync mode (Maarten)
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 217 ++-
drivers/gpu/drm/i915/display/intel_display.h | 4 +
3 files changed, 221 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 7925a176f900..bceb7e4b1877 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3154,7 +3154,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
true);
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
intel_dp_start_link_train(intel_dp);
- if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
+ if ((port != PORT_A || INTEL_GEN(dev_priv) >= 9) &&
+ !is_trans_port_sync_mode(crtc_state))
intel_dp_stop_link_train(intel_dp);
intel_ddi_enable_fec(encoder, crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7156b1b4c6c5..f88d3a929e36 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -520,6 +520,26 @@ needs_modeset(const struct drm_crtc_state *state)
return drm_atomic_crtc_needs_modeset(state);
}
+bool
+is_trans_port_sync_mode(const struct intel_crtc_state *state)
+{
+ return (state->master_transcoder != INVALID_TRANSCODER ||
+ state->sync_mode_slaves_mask);
+}
+
+static bool
+is_trans_port_sync_slave(const struct intel_crtc_state *state)
+{
+ return state->master_transcoder != INVALID_TRANSCODER;
+}
+
+static bool
+is_trans_port_sync_master(const struct intel_crtc_state *state)
+{
+ return (state->master_transcoder == INVALID_TRANSCODER &&
+ state->sync_mode_slaves_mask);
+}
+
/*
* Platform specific helpers to calculate the port PLL loopback- (clock.m),
* and post-divider (clock.p) values, pre- (clock.vco) and post-divided fast
@@ -13944,9 +13964,200 @@ static void skl_commit_modeset_enables(struct
drm_atomic_state *state)
progress = true;
}
} while (progress);
+}
+static void icl_commit_modeset_enables(struct drm_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->dev);
+ struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+ struct drm_crtc *crtc;
+ struct intel_crtc *intel_crtc;
+ struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ struct intel_crtc_state *cstate;
+ unsigned int updated = 0;
+ bool progress;
+ enum pipe pipe;
+ int i;
+ u8 hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
+ u8 required_slices = intel_state->wm_results.ddb.enabled_slices;
+ struct skl_ddb_entry entries[I915_MAX_PIPES] = {};
+
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i)
+ /* ignore allocations for crtc's that have been turned off. */
+ if (new_crtc_state->active)
+ entries[i] =
to_intel_crtc_state(old_crtc_state)->wm.skl.ddb;
+
+ /* If 2nd DBuf slice required, enable it here */
+ if (required_slices > hw_enabled_slices)
+ icl_dbuf_slices_update(dev_priv, required_slices);
+
+ /*
+* Whenever the number of active pipes changes, we need to make sure we
+* update the pipes in the right order so that their ddb allocations
+* never overlap with eachother inbetween CRTC updates. Otherwise we'll
+* cause pipe underruns and other bad stuff.
+*/
+ do {
+ progress = false;
+
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ bool vbl_wait = false;
+ unsigned int cmask = drm_crtc_mask(crtc);
+ bool modeset = needs_modeset(new_crtc_state);
+
+ intel_crtc = to_intel_crtc(crtc);
+ cstate = to_intel_crtc_state(new_crtc_state);
+ pipe = intel_crtc->pipe;
+
+ if (updated & cmask ||
[Intel-gfx] [PATCH v3 4/8] drm/i915/display/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports
In case of tiled displays where different tiles are displayed across
different ports, we need to synchronize the transcoders involved.
This patch implements the transcoder port sync feature for
synchronizing one master transcoder with one or more slave
transcoders. This is only enbaled in slave transcoder
and the master transcoder is unaware that it is operating
in this mode.
This has been tested with tiled display connected to ICL.
v3:
* Check of DP_MST moved to atomic_check (Maarten)
v2:
* Do not use RMW, just write to the register in commit (Jani N)
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 44
1 file changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 367c7fb2be88..f359a6212574 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4366,6 +4366,47 @@ static void icl_set_pipe_chicken(struct intel_crtc *crtc)
I915_WRITE(PIPE_CHICKEN(pipe), tmp);
}
+static void icl_enable_trans_port_sync(struct intel_atomic_state
*old_intel_state,
+ const struct intel_crtc_state
*crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 trans_ddi_func_ctl2_val;
+ u8 master_select;
+
+ /*
+* Configure the master select and enable Transcoder Port Sync for
+* Slave CRTCs transcoder.
+*/
+ if (crtc_state->master_transcoder == INVALID_TRANSCODER)
+ return;
+
+ switch (crtc_state->master_transcoder) {
+ case TRANSCODER_A:
+ master_select = 1;
+ break;
+ case TRANSCODER_B:
+ master_select = 2;
+ break;
+ case TRANSCODER_C:
+ master_select = 3;
+ break;
+ case TRANSCODER_EDP:
+ default:
+ master_select = 0;
+ break;
+ }
+ /* Set the master select bits for Tranascoder Port Sync */
+ trans_ddi_func_ctl2_val = (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
+ PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
+ PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
+ /* Enable Transcoder Port Sync */
+ trans_ddi_func_ctl2_val |= PORT_SYNC_MODE_ENABLE;
+
+ I915_WRITE(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
+ trans_ddi_func_ctl2_val);
+}
+
static void intel_update_pipe_config(const struct intel_crtc_state
*old_crtc_state,
const struct intel_crtc_state
*new_crtc_state)
{
@@ -6344,6 +6385,9 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
if (!transcoder_is_dsi(cpu_transcoder))
intel_set_pipe_timings(pipe_config);
+ if (INTEL_GEN(dev_priv) >= 11)
+ icl_enable_trans_port_sync(old_intel_state, pipe_config);
+
intel_set_pipe_src_size(pipe_config);
if (cpu_transcoder != TRANSCODER_EDP &&
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/8] drm/i915/display: Move the commit_tail() disable sequence to commit_modeset_disables() hook
Create a new hook commit_modeset_disables() consistent with the naming
in drm atomic helpers and similar to the commit_modeset_enables() hook.
This helps better organize the disable sequence in atomic_commit_tail()
and move that to this disable hook.
No functional change
Suggested-by: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 105 +++
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 64 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 71e86e2f0f90..c34118998ace 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13613,6 +13613,58 @@ static void intel_update_crtc(struct drm_crtc *crtc,
intel_finish_crtc_commit(to_intel_atomic_state(state), intel_crtc);
}
+static void intel_commit_modeset_disables(struct drm_atomic_state *state)
+{
+ struct drm_device *dev = state->dev;
+ struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ struct intel_crtc_state *new_intel_crtc_state, *old_intel_crtc_state;
+ struct drm_crtc *crtc;
+ struct intel_crtc *intel_crtc;
+ int i;
+
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ old_intel_crtc_state = to_intel_crtc_state(old_crtc_state);
+ new_intel_crtc_state = to_intel_crtc_state(new_crtc_state);
+ intel_crtc = to_intel_crtc(crtc);
+
+ if (!needs_modeset(new_crtc_state))
+ continue;
+
+ intel_pre_plane_update(old_intel_crtc_state,
new_intel_crtc_state);
+
+ if (old_crtc_state->active) {
+ intel_crtc_disable_planes(intel_state, intel_crtc);
+
+ /*
+* We need to disable pipe CRC before disabling the
pipe,
+* or we race against vblank off.
+*/
+ intel_crtc_disable_pipe_crc(intel_crtc);
+
+ dev_priv->display.crtc_disable(old_intel_crtc_state,
state);
+ intel_crtc->active = false;
+ intel_fbc_disable(intel_crtc);
+ intel_disable_shared_dpll(old_intel_crtc_state);
+
+ /*
+* Underruns don't always raise interrupts,
+* so check manually.
+*/
+ intel_check_cpu_fifo_underruns(dev_priv);
+ intel_check_pch_fifo_underruns(dev_priv);
+
+ /* FIXME unify this for all platforms */
+ if (!new_crtc_state->active &&
+ !HAS_GMCH(dev_priv) &&
+ dev_priv->display.initial_watermarks)
+
dev_priv->display.initial_watermarks(intel_state,
+
new_intel_crtc_state);
+ }
+ }
+}
+
static void intel_commit_modeset_enables(struct drm_atomic_state *state)
{
struct drm_crtc *crtc;
@@ -13769,7 +13821,7 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
- struct intel_crtc_state *new_intel_crtc_state, *old_intel_crtc_state;
+ struct intel_crtc_state *new_intel_crtc_state;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
u64 put_domains[I915_MAX_PIPES] = {};
@@ -13778,58 +13830,24 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
intel_atomic_commit_fence_wait(intel_state);
- drm_atomic_helper_wait_for_dependencies(state);
-
- if (intel_state->modeset)
- wakeref = intel_display_power_get(dev_priv,
POWER_DOMAIN_MODESET);
-
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
- old_intel_crtc_state = to_intel_crtc_state(old_crtc_state);
new_intel_crtc_state = to_intel_crtc_state(new_crtc_state);
intel_crtc = to_intel_crtc(crtc);
if (needs_modeset(new_crtc_state) ||
- to_intel_crtc_state(new_crtc_state)->update_pipe) {
-
+ new_intel_crtc_state->update_pipe) {
put_domains[intel_crtc->pipe] =
modeset_get_crtc_power_domains(crtc,
-
[Intel-gfx] [PATCH v3 0/8] Enable Transcoder Port Sync feature for tiled displays
First two patches are cleanup patches with no functional changes to rename the existing update_crtc() hook to commit_modeset_enables() to better match the drm_atomic naming conventions. This also prepares to add new hook for ICL since that adds support for transcoder port sync feature. Rest of the patches enable transcoder port sync feature starting GEN 11 required to synchronize the two tile sent across two DP SST connectors. This has been validated using IGT to enable Dell tiled monitor in a 2 pipe 2 port configuration. Manasi Navare (8): drm/i915/display: Rename update_crtcs() to commit_modeset_enables() drm/i915/display: Move the commit_tail() disable sequence to commit_modeset_disables() hook drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync drm/i915/display/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports drm/i915/display/icl: HW state readout for transcoder port sync config drm/i915/display/icl: Enable master-slaves in trans port sync mode in correct order drm/i915/display/icl: Disable transcoder port sync as part of crtc_disable() sequence drm/i915/display/icl: In port sync mode disable slaves first then masters drivers/gpu/drm/i915/display/intel_ddi.c | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 647 +-- drivers/gpu/drm/i915/display/intel_display.h | 5 + drivers/gpu/drm/i915/i915_drv.h | 3 +- drivers/gpu/drm/i915/intel_drv.h | 6 + 5 files changed, 616 insertions(+), 48 deletions(-) -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 7/8] drm/i915/display/icl: Disable transcoder port sync as part of crtc_disable() sequence
This clears the transcoder port sync bits of the TRANS_DDI_FUNC_CTL2
register during crtc_disable().
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 44
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f88d3a929e36..0a0d97ef03d6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4427,6 +4427,26 @@ static void icl_enable_trans_port_sync(struct
intel_atomic_state *old_intel_stat
trans_ddi_func_ctl2_val);
}
+static void icl_disable_transcoder_port_sync(const struct intel_crtc_state
*old_crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ i915_reg_t reg;
+ u32 trans_ddi_func_ctl2_val;
+
+ if (old_crtc_state->master_transcoder == INVALID_TRANSCODER)
+ return;
+
+ DRM_DEBUG_KMS("Disabling Transcoder Port Sync on Slave Transcoder %s\n",
+ transcoder_name(old_crtc_state->cpu_transcoder));
+
+ reg = TRANS_DDI_FUNC_CTL2(old_crtc_state->cpu_transcoder);
+ trans_ddi_func_ctl2_val = I915_READ(reg);
+ trans_ddi_func_ctl2_val &= ~(PORT_SYNC_MODE_ENABLE |
+PORT_SYNC_MODE_MASTER_SELECT_MASK);
+ I915_WRITE(reg, trans_ddi_func_ctl2_val);
+}
+
static void intel_update_pipe_config(const struct intel_crtc_state
*old_crtc_state,
const struct intel_crtc_state
*new_crtc_state)
{
@@ -6586,6 +6606,9 @@ static void haswell_crtc_disable(struct intel_crtc_state
*old_crtc_state,
if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(old_crtc_state, false);
+ if (INTEL_GEN(dev_priv) >= 11)
+ icl_disable_transcoder_port_sync(old_crtc_state);
+
if (!transcoder_is_dsi(cpu_transcoder))
intel_ddi_disable_transcoder_func(old_crtc_state);
@@ -10317,18 +10340,21 @@ static void icelake_get_trans_port_sync_config(struct
intel_crtc *crtc,
pipe_config->master_transcoder = TRANSCODER_EDP;
break;
}
- } else
+
+ pipe_config->sync_mode_slaves_mask = 0;
+ } else {
pipe_config->master_transcoder = INVALID_TRANSCODER;
- transcoders = BIT(TRANSCODER_EDP) |
- BIT(TRANSCODER_A) |
- BIT(TRANSCODER_B) |
- BIT(TRANSCODER_C);
- for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, transcoders) {
- trans_port_sync =
I915_READ(TRANS_DDI_FUNC_CTL2(cpu_transcoder));
+ transcoders = BIT(TRANSCODER_EDP) |
+ BIT(TRANSCODER_A) |
+ BIT(TRANSCODER_B) |
+ BIT(TRANSCODER_C);
+ for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder,
transcoders) {
+ trans_port_sync =
I915_READ(TRANS_DDI_FUNC_CTL2(cpu_transcoder));
- if (trans_port_sync & PORT_SYNC_MODE_ENABLE)
- pipe_config->sync_mode_slaves_mask |=
BIT(cpu_transcoder);
+ if (trans_port_sync & PORT_SYNC_MODE_ENABLE)
+ pipe_config->sync_mode_slaves_mask |=
BIT(cpu_transcoder);
+ }
}
}
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/8] drm/i915/display: Rename update_crtcs() to commit_modeset_enables()
This patch has no functional changes. This just renames the update_crtcs()
hooks to commit_modeset_enables() to match the drm_atomic helper naming
conventions.
Suggested-by: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 10 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 73fe1bcfcd99..71e86e2f0f90 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13613,7 +13613,7 @@ static void intel_update_crtc(struct drm_crtc *crtc,
intel_finish_crtc_commit(to_intel_atomic_state(state), intel_crtc);
}
-static void intel_update_crtcs(struct drm_atomic_state *state)
+static void intel_commit_modeset_enables(struct drm_atomic_state *state)
{
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
@@ -13628,7 +13628,7 @@ static void intel_update_crtcs(struct drm_atomic_state
*state)
}
}
-static void skl_update_crtcs(struct drm_atomic_state *state)
+static void skl_commit_modeset_enables(struct drm_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
@@ -13868,7 +13868,7 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
}
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
- dev_priv->display.update_crtcs(state);
+ dev_priv->display.commit_modeset_enables(state);
if (intel_state->modeset)
intel_set_cdclk_post_plane_update(dev_priv,
@@ -15719,9 +15719,9 @@ void intel_init_display_hooks(struct drm_i915_private
*dev_priv)
}
if (INTEL_GEN(dev_priv) >= 9)
- dev_priv->display.update_crtcs = skl_update_crtcs;
+ dev_priv->display.commit_modeset_enables =
skl_commit_modeset_enables;
else
- dev_priv->display.update_crtcs = intel_update_crtcs;
+ dev_priv->display.commit_modeset_enables =
intel_commit_modeset_enables;
}
static i915_reg_t i915_vgacntrl_reg(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 62e7c5e8aee5..075d7eb3c3f2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -310,7 +310,7 @@ struct drm_i915_display_funcs {
struct drm_atomic_state *old_state);
void (*crtc_disable)(struct intel_crtc_state *old_crtc_state,
struct drm_atomic_state *old_state);
- void (*update_crtcs)(struct drm_atomic_state *state);
+ void (*commit_modeset_enables)(struct drm_atomic_state *state);
void (*audio_codec_enable)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/icl: Add new supported CD clocks
On Mon, 2019-06-24 at 15:39 +0300, Ville Syrjälä wrote:
> On Thu, Jun 20, 2019 at 11:33:27PM +, Souza, Jose wrote:
> > On Wed, 2019-06-19 at 20:47 +0300, Ville Syrjälä wrote:
> > > On Tue, Jun 18, 2019 at 03:50:33PM -0700, José Roberto de Souza
> > > wrote:
> > > > Now 180, 172.8 and 192 MHz are supported.
> > > >
> > > > 180 and 172.8 MHz CD clocks will only be used when audio is not
> > > > enabled as state by BSpec and implemented in
> > > > intel_crtc_compute_min_cdclk(), CD clock must be at least twice
> > > > of
> > > > Azalia BCLK and BCLK by default is 96 MHz, it could be set to
> > > > 48
> > > > MHz
> > > > but we are not reading it.
> > >
> > > Do we know whether this thing still suffers from the glk/cnl
> > > issue
> > > where
> > > we can't even talk to the codec if cdclk is too low? If it does
> > > we
> > > need
> > > to adjust the platform check for the "force min cdclk for audio"
> > > thing.
> > > Also that is going to suck on icl due to the cd2x divider always
> > > being
> > > 1 and hence we can't do the optimized cdclk change around audio
> > > power
> > > requests.
> >
> > Not sure how to test if we can talk to the codec when cdclock is
> > too
> > low(you mean lower than 192000khz(96MHz*2)?) but this workflow
> > worked:
> >
> > 1- only full HD eDP panel connected | cdclock = 172800khz
> > 2- connected a full HD DP monitor with audio | cdclock = 192000khz
> > * audio works
> > 3- disconnected full HD DP monitor | cdclock = 172800khz
> > 4- connected again a full HD DP monitor with audio | cdclock =
> > 192000khz
> > * audio works
> >
> > Do you have any other test in mind?
>
> Try to load/resume the audio driver when cdclk is low maybe?
Oh good idea.
It worked, snd_hda_intel loaded without errors while cdclk was 172800
kHz and then connecting a monitor with audio the cdclk was set to
192000 kHz and audio was send to speakers.
>
> > > > BSpec: 20598
> > > > BSpec: 15729
> > > > Cc: Clint Taylor
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 29
> > > > +++---
> > > >
> > > > 1 file changed, 20 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > index 8993ab283562..d560e25d3fb5 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > @@ -1756,9 +1756,10 @@ static void cnl_sanitize_cdclk(struct
> > > > drm_i915_private *dev_priv)
> > > >
> > > > static int icl_calc_cdclk(int min_cdclk, unsigned int ref)
> > > > {
> > > > - int ranges_24[] = { 312000, 552000, 648000 };
> > > > - int ranges_19_38[] = { 307200, 556800, 652800 };
> > > > - int *ranges;
> > > > + const int ranges_24[] = { 18, 192000, 312000,
> > > > 552000,
> > > > 648000 };
> > > > + const int ranges_19_38[] = { 172800, 192000, 307200,
> > > > 556800,
> > > > 652800 };
> > > > + const int *ranges;
> > > > + unsigned int len, i;
> > > >
> > > > switch (ref) {
> > > > default:
> > > > @@ -1766,19 +1767,22 @@ static int icl_calc_cdclk(int
> > > > min_cdclk,
> > > > unsigned int ref)
> > > > /* fall through */
> > > > case 24000:
> > > > ranges = ranges_24;
> > > > + len = ARRAY_SIZE(ranges_24);
> > > > break;
> > > > case 19200:
> > > > case 38400:
> > > > ranges = ranges_19_38;
> > > > + len = ARRAY_SIZE(ranges_19_38);
> > > > break;
> > > > }
> > > >
> > > > - if (min_cdclk > ranges[1])
> > > > - return ranges[2];
> > > > - else if (min_cdclk > ranges[0])
> > > > - return ranges[1];
> > > > - else
> > > > - return ranges[0];
> > > > + for (i = 0; i < len; i++) {
> > > > + if (min_cdclk <= ranges[i])
> > > > + return ranges[i];
> > > > + }
> > > > +
> > > > + WARN_ON(min_cdclk > ranges[len - 1]);
> > > > + return ranges[len - 1];
> > > > }
> > > >
> > > > static int icl_calc_cdclk_pll_vco(struct drm_i915_private
> > > > *dev_priv, int cdclk)
> > > > @@ -1792,16 +1796,23 @@ static int
> > > > icl_calc_cdclk_pll_vco(struct
> > > > drm_i915_private *dev_priv, int cdclk)
> > > > default:
> > > > MISSING_CASE(cdclk);
> > > > /* fall through */
> > > > + case 172800:
> > > > case 307200:
> > > > case 556800:
> > > > case 652800:
> > > > WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
> > > > dev_priv->cdclk.hw.ref != 38400);
> > > > break;
> > > > + case 18:
> > > > case 312000:
> > > > case 552000:
> > > > case 648000:
> > > >
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Display uncore (rev2)
== Series Details == Series: Display uncore (rev2) URL : https://patchwork.freedesktop.org/series/61735/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: split out uncore_mmio_debug +drivers/gpu/drm/i915/intel_uncore.c:1192:1: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1192:1: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1192:1: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1192:1: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1193:1: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1193:1: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1193:1: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1193:1: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1194:1: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1194:1: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1194:1: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1194:1: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1257:1: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1258:1: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1259:1: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1283:1: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1283:1: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1283:1: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1284:1: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1284:1: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1284:1: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1285:1: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1285:1: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1285:1: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block Commit: drm/i915: rework mmio debug stop/start +drivers/gpu/drm/i915/intel_uncore.c:44:6: warning: symbol 'uncore_mmio_debug_suspend' was not declared. Should it be static? +drivers/gpu/drm/i915/intel_uncore.c:55:6: warning: symbol 'uncore_mmio_debug_resume' was not declared. Should it be static? Commit: drm/i915: introduce display_uncore Okay! Commit: drm/i915: convert intel_hdmi to display reg accessors Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1 0/2] drm: drop uapi dependencies from include/drm
Hi Daniel. > > drm_file.h: > > - needs drm_magic_t > > drm_magic_t is a simple typedef, a simple unsigned int would do the trick > > I think we could switch over to unsigned int for this. OK, will send a v2 with this addressed. There is some preparatory patches to fix build breakage when the include file is dropped. > > > drm_legacy.h > > - needs drm_map_type and drm_map_flags. Seems legit. > > enum in uapi, sweet (never do this, it's not portable across compilers, > #defines all the way). But yeah seems legit, plus we don't care about > drm_legacy.h And this part I will happily ignore. Maybe one day I will check what other dependencies there are. On a rainy day or when there are no more users of drmP.h or so. Sam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/4] drm/panel: Add helper for reading DT rotation
Hi Derek.
On Fri, Jun 21, 2019 at 08:41:02PM -0700, Derek Basehore wrote:
> This adds a helper function for reading the rotation (panel
> orientation) from the device tree.
>
> Signed-off-by: Derek Basehore
> ---
> drivers/gpu/drm/drm_panel.c | 42 +
> include/drm/drm_panel.h | 7 +++
> 2 files changed, 49 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index dbd5b873e8f2..507099af4b57 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -172,6 +172,48 @@ struct drm_panel *of_drm_find_panel(const struct
> device_node *np)
> return ERR_PTR(-EPROBE_DEFER);
> }
> EXPORT_SYMBOL(of_drm_find_panel);
> +
> +/**
> + * of_drm_get_panel_orientation - look up the rotation of the panel using a
> + * device tree node
> + * @np: device tree node of the panel
> + * @orientation: orientation enum to be filled in
> + *
> + * Looks up the rotation of a panel in the device tree. The rotation in the
> + * device tree is counter clockwise.
> + *
> + * Return: 0 when a valid rotation value (0, 90, 180, or 270) is read or the
> + * rotation property doesn't exist. -EERROR otherwise.
> + */
This function should better spell out why it talks about rotation versus
orientation.
It happens that orientation, due to bad design choices is named rotation
in DT.
But then this function is all about orientation, that just happens to be
named rotation in DT.
And the comments associated to the function should reflect this.
something like:
/**
* of_drm_get_panel_orientation - look up the orientation of the panel using a
* device tree node
* @np: device tree node of the panel
* @orientation: orientation enum to be filled in
*
* Looks up the rotation property of a panel in the device tree.
* The orientation of the panel is expressed as a property named
* "rotation" in the device tree.
* The rotation in the device tree is counter clockwise.
*
* Return: 0 when a valid orientation value (0, 90, 180, or 270) is read or the
* rotation property doesn't exist. -EERROR otherwise.
*/
This would at least remove some of my confusiuon.
And then maybe add a bit more explanation to the binding property
description too.
Sam
> +int of_drm_get_panel_orientation(const struct device_node *np,
> + enum drm_panel_orientation *orientation)
> +{
> + int rotation, ret;
> +
> + ret = of_property_read_u32(np, "rotation", );
> + if (ret == -EINVAL) {
> + /* Don't return an error if there's no rotation property. */
> + *orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> + return 0;
> + }
> +
> + if (ret < 0)
> + return ret;
> +
> + if (rotation == 0)
> + *orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> + else if (rotation == 90)
> + *orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
> + else if (rotation == 180)
> + *orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
> + else if (rotation == 270)
> + *orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
> + else
> + return -EINVAL;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(of_drm_get_panel_orientation);
> #endif
>
> MODULE_AUTHOR("Thierry Reding ");
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 8c738c0e6e9f..3564952f1a4f 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -197,11 +197,18 @@ int drm_panel_detach(struct drm_panel *panel);
>
> #if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL)
> struct drm_panel *of_drm_find_panel(const struct device_node *np);
> +int of_drm_get_panel_orientation(const struct device_node *np,
> + enum drm_panel_orientation *orientation);
> #else
> static inline struct drm_panel *of_drm_find_panel(const struct device_node
> *np)
> {
> return ERR_PTR(-ENODEV);
> }
> +int of_drm_get_panel_orientation(const struct device_node *np,
> + enum drm_panel_orientation *orientation)
> +{
> + return -ENODEV;
> +}
> #endif
>
> #endif
> --
> 2.22.0.410.gd8fdbe21b5-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 4/4] drm/i915: convert intel_hdmi to display reg accessors
As an example of usage of the new accessors.
Changes done mechanically with some manual post-processing to use
rmw where appropriate and fix line length and formatting.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 278 ++
1 file changed, 132 insertions(+), 146 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 0ebec69bbbfc..33ad59361d54 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -72,7 +72,7 @@ assert_hdmi_port_disabled(struct intel_hdmi *intel_hdmi)
enabled_bits = HAS_DDI(dev_priv) ? DDI_BUF_CTL_ENABLE : SDVO_ENABLE;
- WARN(I915_READ(intel_hdmi->hdmi_reg) & enabled_bits,
+ WARN(intel_de_read(dev_priv, intel_hdmi->hdmi_reg) & enabled_bits,
"HDMI port enabled, expecting disabled\n");
}
@@ -80,7 +80,7 @@ static void
assert_hdmi_transcoder_func_disabled(struct drm_i915_private *dev_priv,
enum transcoder cpu_transcoder)
{
- WARN(I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder)) &
+ WARN(intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder)) &
TRANS_DDI_FUNC_ENABLE,
"HDMI transcoder function enabled, expecting disabled\n");
}
@@ -208,7 +208,7 @@ static void g4x_write_infoframe(struct intel_encoder
*encoder,
{
const u32 *data = frame;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- u32 val = I915_READ(VIDEO_DIP_CTL);
+ u32 val = intel_de_read(dev_priv, VIDEO_DIP_CTL);
int i;
WARN(!(val & VIDEO_DIP_ENABLE), "Writing DIP with CTL reg disabled\n");
@@ -218,22 +218,22 @@ static void g4x_write_infoframe(struct intel_encoder
*encoder,
val &= ~g4x_infoframe_enable(type);
- I915_WRITE(VIDEO_DIP_CTL, val);
+ intel_de_write(dev_priv, VIDEO_DIP_CTL, val);
for (i = 0; i < len; i += 4) {
- I915_WRITE(VIDEO_DIP_DATA, *data);
+ intel_de_write(dev_priv, VIDEO_DIP_DATA, *data);
data++;
}
/* Write every possible data byte to force correct ECC calculation. */
for (; i < VIDEO_DIP_DATA_SIZE; i += 4)
- I915_WRITE(VIDEO_DIP_DATA, 0);
+ intel_de_write(dev_priv, VIDEO_DIP_DATA, 0);
val |= g4x_infoframe_enable(type);
val &= ~VIDEO_DIP_FREQ_MASK;
val |= VIDEO_DIP_FREQ_VSYNC;
- I915_WRITE(VIDEO_DIP_CTL, val);
- POSTING_READ(VIDEO_DIP_CTL);
+ intel_de_write(dev_priv, VIDEO_DIP_CTL, val);
+ intel_de_posting_read(dev_priv, VIDEO_DIP_CTL);
}
static void g4x_read_infoframe(struct intel_encoder *encoder,
@@ -242,25 +242,22 @@ static void g4x_read_infoframe(struct intel_encoder
*encoder,
void *frame, ssize_t len)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- u32 val, *data = frame;
+ u32 *data = frame;
int i;
- val = I915_READ(VIDEO_DIP_CTL);
-
- val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
- val |= g4x_infoframe_index(type);
-
- I915_WRITE(VIDEO_DIP_CTL, val);
+ intel_de_rmw(dev_priv, VIDEO_DIP_CTL,
+VIDEO_DIP_SELECT_MASK | 0xf, /* clear DIP data offset */
+g4x_infoframe_index(type));
for (i = 0; i < len; i += 4)
- *data++ = I915_READ(VIDEO_DIP_DATA);
+ *data++ = intel_de_read(dev_priv, VIDEO_DIP_DATA);
}
static u32 g4x_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- u32 val = I915_READ(VIDEO_DIP_CTL);
+ u32 val = intel_de_read(dev_priv, VIDEO_DIP_CTL);
if ((val & VIDEO_DIP_ENABLE) == 0)
return 0;
@@ -281,7 +278,7 @@ static void ibx_write_infoframe(struct intel_encoder
*encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
i915_reg_t reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
- u32 val = I915_READ(reg);
+ u32 val = intel_de_read(dev_priv, reg);
int i;
WARN(!(val & VIDEO_DIP_ENABLE), "Writing DIP with CTL reg disabled\n");
@@ -291,22 +288,22 @@ static void ibx_write_infoframe(struct intel_encoder
*encoder,
val &= ~g4x_infoframe_enable(type);
- I915_WRITE(reg, val);
+ intel_de_write(dev_priv, reg, val);
for (i = 0; i < len; i += 4) {
- I915_WRITE(TVIDEO_DIP_DATA(intel_crtc->pipe), *data);
+ intel_de_write(dev_priv, TVIDEO_DIP_DATA(intel_crtc->pipe),
*data);
data++;
}
/* Write every possible data byte to force correct ECC calculation. */
for
[Intel-gfx] [RFC 0/4] Display uncore
More focused proposal for display/GT uncore split. A few notes/considerations: - I've copied the MMIO ranges check in patch 3 from a patch from Ville that did something similar in regards to splitting GT/DE register access. I'm seeing some check failures on gen 3 and 4 [1], so I'd appreciate it if someone could double check those ranges since I'm not familiar with those gens. For the same reason I don't expect BAT to pass. - Instead of doing a range check to find erroneous accesses, I considered using a new structure for display registers (wrapping i915_reg_t) and therefore force a compile-time check, but the sheer amount of register definitions that would need updating makes this hard to merge together with the switch to the new functions without hitting conflicts. If there is interest in this option, I'll put something out after all the display register accesses have transitioned to the new accessors. - When MMIO debug is enabled, the accesses from GT and DE are still serialized because the HW debug infrastructure is shared. Since our testing defaults the MMIO debug on, we won't really test parallel accesses. After the series settles down I'm going to submit a CI run with MMIO debug off, but maybe we should update some tests to run with MMIO debug disabled. Thoughts? Cc: Ville Syrjälä Cc: Jani Nikula Cc: Chris Wilson Cc: Tvrtko Ursulin [1] https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4491/? Daniele Ceraolo Spurio (4): drm/i915: split out uncore_mmio_debug drm/i915: rework mmio debug stop/start drm/i915: introduce display_uncore drm/i915: convert intel_hdmi to display reg accessors drivers/gpu/drm/i915/display/intel_hdmi.c | 278 ++ drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 20 +- drivers/gpu/drm/i915/i915_drv.h | 59 + drivers/gpu/drm/i915/intel_uncore.c | 100 +--- drivers/gpu/drm/i915/intel_uncore.h | 18 +- 6 files changed, 292 insertions(+), 185 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/4] drm/i915: introduce display_uncore
A forcewake-less uncore to be used to decouple GT accesses from display
ones to avoid serializing them when there is no need.
New accessors that implicitly use the new uncore have also been added.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 17 -
drivers/gpu/drm/i915/i915_drv.h | 58 +
drivers/gpu/drm/i915/intel_uncore.c | 9 -
3 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2d6c643dde51..e22c0a6b3992 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -903,6 +903,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv)
intel_uncore_mmio_debug_init_early(_priv->mmio_debug);
intel_uncore_init_early(_priv->uncore, dev_priv);
+ intel_uncore_init_early(_priv->de_uncore, dev_priv);
spin_lock_init(_priv->irq_lock);
spin_lock_init(_priv->gpu_error.lock);
@@ -1001,6 +1002,10 @@ static int i915_driver_init_mmio(struct drm_i915_private
*dev_priv)
if (ret < 0)
goto err_bridge;
+ ret = intel_uncore_init_mmio(_priv->de_uncore);
+ if (ret < 0)
+ goto err_uncore;
+
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev_priv);
@@ -1012,14 +1017,16 @@ static int i915_driver_init_mmio(struct
drm_i915_private *dev_priv)
ret = intel_engines_init_mmio(dev_priv);
if (ret)
- goto err_uncore;
+ goto err_mchbar;
i915_gem_init_mmio(dev_priv);
return 0;
-err_uncore:
+err_mchbar:
intel_teardown_mchbar(dev_priv);
+ intel_uncore_fini_mmio(_priv->de_uncore);
+err_uncore:
intel_uncore_fini_mmio(_priv->uncore);
err_bridge:
pci_dev_put(dev_priv->bridge_dev);
@@ -1034,6 +1041,7 @@ static int i915_driver_init_mmio(struct drm_i915_private
*dev_priv)
static void i915_driver_cleanup_mmio(struct drm_i915_private *dev_priv)
{
intel_teardown_mchbar(dev_priv);
+ intel_uncore_fini_mmio(_priv->de_uncore);
intel_uncore_fini_mmio(_priv->uncore);
pci_dev_put(dev_priv->bridge_dev);
}
@@ -2166,6 +2174,7 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
i915_gem_suspend_late(dev_priv);
+ intel_uncore_suspend(_priv->de_uncore);
intel_uncore_suspend(_priv->uncore);
intel_power_domains_suspend(dev_priv,
@@ -2363,6 +2372,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
ret);
intel_uncore_resume_early(_priv->uncore);
+ intel_uncore_resume_early(_priv->de_uncore);
intel_gt_check_and_clear_faults(_priv->gt);
@@ -2937,6 +2947,7 @@ static int intel_runtime_suspend(struct device *kdev)
intel_runtime_pm_disable_interrupts(dev_priv);
+ intel_uncore_suspend(_priv->de_uncore);
intel_uncore_suspend(_priv->uncore);
ret = 0;
@@ -2955,6 +2966,7 @@ static int intel_runtime_suspend(struct device *kdev)
if (ret) {
DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
intel_uncore_runtime_resume(_priv->uncore);
+ intel_uncore_runtime_resume(_priv->de_uncore);
intel_runtime_pm_enable_interrupts(dev_priv);
@@ -3053,6 +3065,7 @@ static int intel_runtime_resume(struct device *kdev)
}
intel_uncore_runtime_resume(_priv->uncore);
+ intel_uncore_runtime_resume(_priv->de_uncore);
intel_runtime_pm_enable_interrupts(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a53b65d78159..c554b7697bdc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1341,6 +1341,7 @@ struct drm_i915_private {
resource_size_t stolen_usable_size; /* Total size minus reserved
ranges */
struct intel_uncore uncore;
+ struct intel_uncore de_uncore;
struct intel_uncore_mmio_debug mmio_debug;
struct i915_virtual_gpu vgpu;
@@ -2746,6 +2747,63 @@ extern void intel_display_print_error_state(struct
drm_i915_error_state_buf *e,
#define I915_READ_FW(reg__) __I915_REG_OP(read_fw, dev_priv, (reg__))
#define I915_WRITE_FW(reg__, val__) __I915_REG_OP(write_fw, dev_priv, (reg__),
(val__))
+/*
+ * The following are mmio-accessors that use an independent lock and skip all
+ * the forcewake logic, to be used to access display registers, which are
+ * outside the GT forcewake wells.
+ */
+static inline void
+intel_assert_register_is_display(struct drm_i915_private *i915, i915_reg_t reg)
+{
+#ifdef CONFIG_DRM_I915_DEBUG_MMIO
+ u32 offset = i915_mmio_reg_offset(reg);
+ bool is_de_register;
+
+ if (INTEL_GEN(i915) >= 5) {
+ is_de_register = offset >= 0x4 &&
+
[Intel-gfx] [RFC 1/4] drm/i915: split out uncore_mmio_debug
Multiple uncore structures will share the debug infrastructure, so
move it to a common place and add extra locking around it.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_uncore.c | 54 +
drivers/gpu/drm/i915/intel_uncore.h | 9 -
4 files changed, 50 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e1817f89f5d5..1c4cfdb04867 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -901,6 +901,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv)
intel_device_info_subplatform_init(dev_priv);
+ intel_uncore_mmio_debug_init_early(_priv->mmio_debug);
intel_uncore_init_early(_priv->uncore, dev_priv);
spin_lock_init(_priv->irq_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 62e7c5e8aee5..a53b65d78159 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1341,6 +1341,7 @@ struct drm_i915_private {
resource_size_t stolen_usable_size; /* Total size minus reserved
ranges */
struct intel_uncore uncore;
+ struct intel_uncore_mmio_debug mmio_debug;
struct i915_virtual_gpu vgpu;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 68d54e126d79..f2dfaccd6614 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -34,6 +34,13 @@
#define __raw_posting_read(...) ((void)__raw_uncore_read32(__VA_ARGS__))
+void
+intel_uncore_mmio_debug_init_early(struct intel_uncore_mmio_debug *mmio_debug)
+{
+ spin_lock_init(_debug->lock);
+ mmio_debug->unclaimed_mmio_check = 1;
+}
+
static const char * const forcewake_domain_names[] = {
"render",
"blitter",
@@ -473,6 +480,8 @@ check_for_unclaimed_mmio(struct intel_uncore *uncore)
{
bool ret = false;
+ lockdep_assert_held(>debug->lock);
+
if (intel_uncore_has_fpga_dbg_unclaimed(uncore))
ret |= fpga_check_for_unclaimed_mmio(uncore);
@@ -605,18 +614,20 @@ void intel_uncore_forcewake_get(struct intel_uncore
*uncore,
void intel_uncore_forcewake_user_get(struct intel_uncore *uncore)
{
spin_lock_irq(>lock);
+ spin_lock(>debug->lock);
if (!uncore->user_forcewake.count++) {
intel_uncore_forcewake_get__locked(uncore, FORCEWAKE_ALL);
/* Save and disable mmio debugging for the user bypass */
uncore->user_forcewake.saved_mmio_check =
- uncore->unclaimed_mmio_check;
+ uncore->debug->unclaimed_mmio_check;
uncore->user_forcewake.saved_mmio_debug =
i915_modparams.mmio_debug;
- uncore->unclaimed_mmio_check = 0;
+ uncore->debug->unclaimed_mmio_check = 0;
i915_modparams.mmio_debug = 0;
}
+ spin_unlock(>debug->lock);
spin_unlock_irq(>lock);
}
@@ -630,18 +641,20 @@ void intel_uncore_forcewake_user_get(struct intel_uncore
*uncore)
void intel_uncore_forcewake_user_put(struct intel_uncore *uncore)
{
spin_lock_irq(>lock);
+ spin_lock(>debug->lock);
if (!--uncore->user_forcewake.count) {
- if (intel_uncore_unclaimed_mmio(uncore))
+ if (check_for_unclaimed_mmio(uncore))
dev_info(uncore->i915->drm.dev,
"Invalid mmio detected during user access\n");
- uncore->unclaimed_mmio_check =
+ uncore->debug->unclaimed_mmio_check =
uncore->user_forcewake.saved_mmio_check;
i915_modparams.mmio_debug =
uncore->user_forcewake.saved_mmio_debug;
intel_uncore_forcewake_put__locked(uncore, FORCEWAKE_ALL);
}
+ spin_unlock(>debug->lock);
spin_unlock_irq(>lock);
}
@@ -1059,7 +1072,16 @@ unclaimed_reg_debug(struct intel_uncore *uncore,
if (likely(!i915_modparams.mmio_debug))
return;
+ /* interrupts are disabled and re-enabled around uncore->lock usage */
+ lockdep_assert_held(>lock);
+
+ if (before)
+ spin_lock(>debug->lock);
+
__unclaimed_reg_debug(uncore, reg, read, before);
+
+ if (!before)
+ spin_unlock(>debug->lock);
}
#define GEN2_READ_HEADER(x) \
@@ -1579,6 +1601,7 @@ void intel_uncore_init_early(struct intel_uncore *uncore,
spin_lock_init(>lock);
uncore->i915 = i915;
uncore->rpm = >runtime_pm;
+ uncore->debug = >mmio_debug;
}
static void uncore_raw_init(struct intel_uncore *uncore)
@@ -1604,7 +1627,6 @@ static int uncore_forcewake_init(struct intel_uncore
*uncore)
ret =
[Intel-gfx] [RFC 2/4] drm/i915: rework mmio debug stop/start
Since we now have a separate object, it is cleaner to have dedicated
functions working on the object to stop and restart the mmio debug.
Apart from the cosmetic changes, this patch introduces 2 functional
updates:
- All calls to check_for_unclaimed_mmio will now return false when
the debug is suspended, not just the ones that are active only when
i915_modparams.mmio_debug is set. If we don't trust the result of the
check while a user is doing mmio access then we shouldn't attempt the
check anywhere.
- i915_modparams.mmio_debug is not save/restored anymore around user
access. The value is now never touched by the kernel while debug is
disabled so no need for save/restore.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 43 ++---
drivers/gpu/drm/i915/intel_uncore.h | 9 ++
4 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index eeecdad0e3ca..1eb72bd74ab9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1218,7 +1218,7 @@ static int i915_forcewake_domains(struct seq_file *m,
void *data)
unsigned int tmp;
seq_printf(m, "user.bypass_count = %u\n",
- uncore->user_forcewake.count);
+ uncore->user_forcewake_count);
for_each_fw_domain(fw_domain, uncore, tmp)
seq_printf(m, "%s.wake_count = %u\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1c4cfdb04867..2d6c643dde51 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2204,7 +2204,7 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
out:
enable_rpm_wakeref_asserts(rpm);
- if (!dev_priv->uncore.user_forcewake.count)
+ if (!dev_priv->uncore.user_forcewake_count)
intel_runtime_pm_cleanup(rpm);
return ret;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index f2dfaccd6614..1905fd94dd3c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -41,6 +41,25 @@ intel_uncore_mmio_debug_init_early(struct
intel_uncore_mmio_debug *mmio_debug)
mmio_debug->unclaimed_mmio_check = 1;
}
+void uncore_mmio_debug_suspend(struct intel_uncore_mmio_debug *mmio_debug)
+{
+ lockdep_assert_held(_debug->lock);
+
+ /* Save and disable mmio debugging for the user bypass */
+ if (!mmio_debug->suspend_count++) {
+ mmio_debug->saved_mmio_check = mmio_debug->unclaimed_mmio_check;
+ mmio_debug->unclaimed_mmio_check = 0;
+ }
+}
+
+void uncore_mmio_debug_resume(struct intel_uncore_mmio_debug *mmio_debug)
+{
+ lockdep_assert_held(_debug->lock);
+
+ if (!--mmio_debug->suspend_count)
+ mmio_debug->unclaimed_mmio_check = mmio_debug->saved_mmio_check;
+}
+
static const char * const forcewake_domain_names[] = {
"render",
"blitter",
@@ -482,6 +501,9 @@ check_for_unclaimed_mmio(struct intel_uncore *uncore)
lockdep_assert_held(>debug->lock);
+ if (uncore->debug->suspend_count)
+ return false;
+
if (intel_uncore_has_fpga_dbg_unclaimed(uncore))
ret |= fpga_check_for_unclaimed_mmio(uncore);
@@ -615,17 +637,9 @@ void intel_uncore_forcewake_user_get(struct intel_uncore
*uncore)
{
spin_lock_irq(>lock);
spin_lock(>debug->lock);
- if (!uncore->user_forcewake.count++) {
+ if (!uncore->user_forcewake_count++) {
intel_uncore_forcewake_get__locked(uncore, FORCEWAKE_ALL);
-
- /* Save and disable mmio debugging for the user bypass */
- uncore->user_forcewake.saved_mmio_check =
- uncore->debug->unclaimed_mmio_check;
- uncore->user_forcewake.saved_mmio_debug =
- i915_modparams.mmio_debug;
-
- uncore->debug->unclaimed_mmio_check = 0;
- i915_modparams.mmio_debug = 0;
+ uncore_mmio_debug_suspend(uncore->debug);
}
spin_unlock(>debug->lock);
spin_unlock_irq(>lock);
@@ -642,16 +656,13 @@ void intel_uncore_forcewake_user_put(struct intel_uncore
*uncore)
{
spin_lock_irq(>lock);
spin_lock(>debug->lock);
- if (!--uncore->user_forcewake.count) {
+ if (!--uncore->user_forcewake_count) {
+ uncore_mmio_debug_resume(uncore->debug);
+
if (check_for_unclaimed_mmio(uncore))
dev_info(uncore->i915->drm.dev,
"Invalid mmio detected during user access\n");
- uncore->debug->unclaimed_mmio_check =
- uncore->user_forcewake.saved_mmio_check;
-
Re: [Intel-gfx] [PATCH 19/19] drm/i915: Replace struct_mutex for batch pool serialisation
On Mon, 24 Jun 2019 at 06:45, Chris Wilson wrote:
>
> Switch to tracking activity via i915_active on individual nodes, only
> keeping a list of retired objects in the cache, and reaping the cache
> when the engine itself idles.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/Makefile | 2 +-
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 58 ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 -
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 1 -
> drivers/gpu/drm/i915/gem/i915_gem_pm.c| 4 +-
> drivers/gpu/drm/i915/gt/intel_engine.h| 1 -
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 11 +-
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +
> drivers/gpu/drm/i915/gt/intel_engine_pool.c | 164 ++
> drivers/gpu/drm/i915/gt/intel_engine_pool.h | 34
> .../gpu/drm/i915/gt/intel_engine_pool_types.h | 29
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 +-
> drivers/gpu/drm/i915/gt/mock_engine.c | 3 +
> drivers/gpu/drm/i915/i915_debugfs.c | 68
> drivers/gpu/drm/i915/i915_gem_batch_pool.h| 26 ---
> 15 files changed, 277 insertions(+), 133 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_pool.c
> create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_pool.h
> create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_pool_types.h
> delete mode 100644 drivers/gpu/drm/i915/i915_gem_batch_pool.h
i915_gem_batch_pool.c is still skulking around somewhere :)
[snip]
> +static struct list_head *
> +bucket_for_size(struct intel_engine_pool *pool, size_t sz)
> +{
> + int n;
> +
> + /*
> +* Compute a power-of-two bucket, but throw everything greater than
> +* 16KiB into the same bucket: i.e. the the buckets hold objects of
the buckets
> +* (1 page, 2 pages, 4 pages, 8+ pages).
> +*/
> + n = fls(sz >> PAGE_SHIFT) - 1;
> + if (n >= ARRAY_SIZE(pool->cache_list))
> + n = ARRAY_SIZE(pool->cache_list) - 1;
> +
> + return >cache_list[n];
> +}
> +
> +static void node_free(struct intel_engine_pool_node *node)
> +{
> + i915_gem_object_put(node->obj);
> + kfree(node);
> +}
> +
> +static int pool_active(struct i915_active *ref)
> +{
> + struct intel_engine_pool_node *node =
> + container_of(ref, typeof(*node), active);
> + struct reservation_object *resv = node->obj->base.resv;
> +
> + if (reservation_object_trylock(resv)) {
> + reservation_object_add_excl_fence(resv, NULL);
> + reservation_object_unlock(resv);
> + }
> +
> + return i915_gem_object_pin_pages(node->obj);
> +}
> +
> +static void pool_retire(struct i915_active *ref)
> +{
> + struct intel_engine_pool_node *node =
> + container_of(ref, typeof(*node), active);
> + struct intel_engine_pool *pool = node->pool;
> + struct list_head *list = bucket_for_size(pool, node->obj->base.size);
> + unsigned long flags;
> +
> + GEM_BUG_ON(!intel_engine_pm_is_awake(to_engine(pool)));
> +
> + i915_gem_object_unpin_pages(node->obj);
> +
> + spin_lock_irqsave(>lock, flags);
> + list_add(>link, list);
> + spin_unlock_irqrestore(>lock, flags);
> +}
> +
> +static struct intel_engine_pool_node *
> +node_create(struct intel_engine_pool *pool, size_t sz)
> +{
> + struct intel_engine_cs *engine = to_engine(pool);
> + struct intel_engine_pool_node *node;
> + struct drm_i915_gem_object *obj;
> +
> + node = kmalloc(sizeof(*node),
> + GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
> + if (!node)
> + return ERR_PTR(-ENOMEM);
> +
> + node->pool = pool;
> + i915_active_init(engine->i915, >active, pool_active,
> pool_retire);
> +
> + obj = i915_gem_object_create_internal(engine->i915, sz);
> + if (IS_ERR(obj)) {
> + kfree(node);
> + return ERR_CAST(obj);
i915_active_fini() somewhere, ditto for node_free?
Anyway, looks good.
Reviewed-by: Matthew Auld
___
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/gem: Clear read/write domains for GPU clear
== Series Details == Series: drm/i915/gem: Clear read/write domains for GPU clear URL : https://patchwork.freedesktop.org/series/62646/ State : success == Summary == CI Bug Log - changes from CI_DRM_6334_full -> Patchwork_13407_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13407_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_6334/shard-apl2/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/shard-apl7/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_eio@in-flight-internal-10ms: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 ]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/shard-glk1/igt@gem_...@in-flight-internal-10ms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/shard-glk2/igt@gem_...@in-flight-internal-10ms.html * igt@gem_eio@in-flight-suspend: - shard-kbl: [PASS][5] -> [FAIL][6] ([fdo#110667]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/shard-kbl3/igt@gem_...@in-flight-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/shard-kbl6/igt@gem_...@in-flight-suspend.html * igt@gem_exec_reloc@basic-write-cpu-active: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/shard-apl8/igt@gem_exec_re...@basic-write-cpu-active.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/shard-apl6/igt@gem_exec_re...@basic-write-cpu-active.html * igt@gem_persistent_relocs@forked-interruptible-thrash-inactive: - shard-hsw: [PASS][9] -> [DMESG-WARN][10] ([fdo#110789] / [fdo#110913 ]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/shard-hsw4/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/shard-hsw4/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html * igt@gem_softpin@evict-active: - shard-snb: [PASS][11] -> [DMESG-WARN][12] ([fdo#110789] / [fdo#110913 ]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/shard-snb1/igt@gem_soft...@evict-active.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/shard-snb5/igt@gem_soft...@evict-active.html * igt@gem_softpin@noreloc-s3: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#104108]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/shard-skl6/igt@gem_soft...@noreloc-s3.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/shard-skl3/igt@gem_soft...@noreloc-s3.html * igt@gem_tiled_swapping@non-threaded: - shard-hsw: [PASS][15] -> [FAIL][16] ([fdo#108686]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/shard-hsw5/igt@gem_tiled_swapp...@non-threaded.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/shard-hsw7/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_userptr_blits@sync-unmap-cycles: - shard-hsw: [PASS][17] -> [DMESG-WARN][18] ([fdo#110913 ]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/shard-hsw8/igt@gem_userptr_bl...@sync-unmap-cycles.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/shard-hsw6/igt@gem_userptr_bl...@sync-unmap-cycles.html * igt@kms_color@pipe-c-ctm-negative: - shard-hsw: [PASS][19] -> [INCOMPLETE][20] ([fdo#103540]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/shard-hsw4/igt@kms_co...@pipe-c-ctm-negative.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/shard-hsw7/igt@kms_co...@pipe-c-ctm-negative.html - shard-glk: [PASS][21] -> [INCOMPLETE][22] ([fdo#103359] / [k.org#198133]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/shard-glk9/igt@kms_co...@pipe-c-ctm-negative.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/shard-glk4/igt@kms_co...@pipe-c-ctm-negative.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103167]) +5 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-plflip-blt: - shard-skl:
[Intel-gfx] [RFC][PATCH] wake_up_var() memory ordering
Hi all,
I tried using wake_up_var() today and accidentally noticed that it
didn't imply an smp_mb() and specifically requires it through
wake_up_bit() / waitqueue_active().
Now, wake_up_bit() doesn't imply the barrier because it is assumed to be
used with the atomic bitops API which either implies (test_and_clear) or
only needs smp_mb__after_atomic(), which is 'much' cheaper than an
unconditional smp_mb().
Still, while auditing all that, I found a whole bunch of things that
could be improved. There were missing barriers, superfluous barriers and
a whole bunch of sites that could use clear_and_wake_up_bit().
So this fixes all wake_up_bit() usage without actually changing
semantics of it (which are unfortunate but understandable). This does
however change the semantics of wake_up_var(); even though wake_up_var()
is most often used with atomics and then the additional smp_mb() is most
often superfluous :/
There isn't really a good option here, comments (other than I need to
split this up)?
---
drivers/bluetooth/btmtksdio.c | 5 +
drivers/bluetooth/btmtkuart.c | 5 +
drivers/bluetooth/hci_mrvl.c| 8 ++--
drivers/gpu/drm/i915/i915_reset.c | 6 ++
drivers/md/dm-bufio.c | 10 ++
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 15 ---
fs/afs/fs_probe.c | 1 +
fs/afs/server.c | 1 +
fs/afs/vl_probe.c | 1 +
fs/afs/volume.c | 1 +
fs/aio.c| 4 +---
fs/block_dev.c | 1 +
fs/btrfs/extent_io.c| 4 +---
fs/cachefiles/namei.c | 1 +
fs/cifs/connect.c | 3 +--
fs/cifs/misc.c | 15 +--
fs/fscache/cookie.c | 2 ++
fs/fscache/object.c | 2 ++
fs/fscache/page.c | 3 +++
fs/gfs2/glock.c | 8 ++--
fs/gfs2/glops.c | 1 +
fs/gfs2/lock_dlm.c | 8 ++--
fs/gfs2/recovery.c | 4 +---
fs/gfs2/super.c | 1 +
fs/gfs2/sys.c | 4 +---
fs/nfs/nfs4state.c | 4 +---
fs/nfs/pnfs_nfs.c | 4 +---
fs/nfsd/nfs4recover.c | 4 +---
fs/orangefs/file.c | 2 +-
kernel/sched/wait_bit.c | 1 +
net/bluetooth/hci_event.c | 5 +
net/rds/ib_recv.c | 1 +
security/keys/gc.c | 5 ++---
33 files changed, 50 insertions(+), 90 deletions(-)
diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
index 813338288453..27523cfeac9a 100644
--- a/drivers/bluetooth/btmtksdio.c
+++ b/drivers/bluetooth/btmtksdio.c
@@ -356,11 +356,8 @@ static int btmtksdio_recv_event(struct hci_dev *hdev,
struct sk_buff *skb)
if (hdr->evt == HCI_EV_VENDOR) {
if (test_and_clear_bit(BTMTKSDIO_TX_WAIT_VND_EVT,
- >tx_state)) {
- /* Barrier to sync with other CPUs */
- smp_mb__after_atomic();
+ >tx_state))
wake_up_bit(>tx_state, BTMTKSDIO_TX_WAIT_VND_EVT);
- }
}
return 0;
diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
index f5dbeec8e274..7fe324df3799 100644
--- a/drivers/bluetooth/btmtkuart.c
+++ b/drivers/bluetooth/btmtkuart.c
@@ -340,11 +340,8 @@ static int btmtkuart_recv_event(struct hci_dev *hdev,
struct sk_buff *skb)
if (hdr->evt == HCI_EV_VENDOR) {
if (test_and_clear_bit(BTMTKUART_TX_WAIT_VND_EVT,
- >tx_state)) {
- /* Barrier to sync with other CPUs */
- smp_mb__after_atomic();
+ >tx_state))
wake_up_bit(>tx_state, BTMTKUART_TX_WAIT_VND_EVT);
- }
}
return 0;
diff --git a/drivers/bluetooth/hci_mrvl.c b/drivers/bluetooth/hci_mrvl.c
index 50212ac629e3..f03294d39d08 100644
--- a/drivers/bluetooth/hci_mrvl.c
+++ b/drivers/bluetooth/hci_mrvl.c
@@ -157,9 +157,7 @@ static int mrvl_recv_fw_req(struct hci_dev *hdev, struct
sk_buff *skb)
mrvl->tx_len = le16_to_cpu(pkt->lhs);
- clear_bit(STATE_FW_REQ_PENDING, >flags);
- smp_mb__after_atomic();
- wake_up_bit(>flags, STATE_FW_REQ_PENDING);
+ clear_and_wake_up_bit(STATE_FW_REQ_PENDING, >flags);
done:
kfree_skb(skb);
@@ -192,9 +190,7 @@ static int mrvl_recv_chip_ver(struct hci_dev *hdev, struct
sk_buff *skb)
Re: [Intel-gfx] [PATCH 5/6] drm/i915/sdvo: Reduce the size of the on stack buffers
On Wed, Jun 19, 2019 at 07:21:48PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-06-19 19:03:11)
> > From: Ville Syrjälä
> >
> > The strings we want to print to the on stack buffers should
> > be no more than
> > 8 * 3 + strlen("(GET_SCALED_HDTV_RESOLUTION_SUPPORT)") + 1 = 61
> > bytes. So let's shrink the buffers down to 64 bytes.
> >
>
> max args_len does seem to 8, and it gets padded out to 8.
>
> > Also switch the BUG_ON()s to WARN_ON()s if I made a mistake in
> > my arithmentic.
>
> With the command name macro, could it not do some thing like
> BUILD_BUG_ON(sizeof(#cmd) > DBG_LEN) ?
I couldn't think of a way to do that with the current struct
initialization, but we could borrow the I915_PARAMS_FOR_EACH()
trick here. Not sure it's worth the hassle though.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gem: Clear read/write domains for GPU clear
On 24/06/2019 17:00, Chris Wilson wrote: Quoting Matthew Auld (2019-06-24 16:50:48) On 24/06/2019 15:16, Chris Wilson wrote: Update the domains for the write via the GPU so that we do not shortcircuit any set-domain wait afterwards. I'm lost. How do we short-circuit the set-domain wait? If we never change the read_domain, then we may skip the clflush on set_cpu_domain thus missing the updated contents on !llc. So s/wait/clflush/ to be precise Reviewed-by: Matthew Auld -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 2/4] gitlab-ci: add libatomic to docker images
Add libatomic to the Fedora docker image so it can link binaries that use __atomic_* functions. Also explicitly add libatomic1 to Debian docker images as it is needed in particular on non-x86 architectures for run-time linkage. Signed-off-by: Guillaume Tucker --- Notes: v2: add libatomic1 in Debian docker images v3: add libatomic1 for non-x86 arches in Debian docker images v4: rebase to add libatomic1 in Dockerfile.debian-minimal Dockerfile.debian-arm64 | 1 + Dockerfile.debian-armhf | 1 + Dockerfile.debian-minimal | 1 + Dockerfile.fedora | 2 +- 4 files changed, 4 insertions(+), 1 deletion(-) diff --git a/Dockerfile.debian-arm64 b/Dockerfile.debian-arm64 index 7b3a3c7ca803..c9fb28c804b8 100644 --- a/Dockerfile.debian-arm64 +++ b/Dockerfile.debian-arm64 @@ -14,6 +14,7 @@ RUN dpkg --add-architecture arm64 RUN apt-get update RUN apt-get install -y \ gcc-aarch64-linux-gnu \ + libatomic1:arm64 \ libpciaccess-dev:arm64 \ libkmod-dev:arm64 \ libprocps-dev:arm64 \ diff --git a/Dockerfile.debian-armhf b/Dockerfile.debian-armhf index c67a1e2acf6a..3a133d849d68 100644 --- a/Dockerfile.debian-armhf +++ b/Dockerfile.debian-armhf @@ -14,6 +14,7 @@ RUN dpkg --add-architecture armhf RUN apt-get update RUN apt-get install -y \ gcc-arm-linux-gnueabihf \ + libatomic1:armhf \ libpciaccess-dev:armhf \ libkmod-dev:armhf \ libprocps-dev:armhf \ diff --git a/Dockerfile.debian-minimal b/Dockerfile.debian-minimal index bbe70bed2fb4..63844694dafa 100644 --- a/Dockerfile.debian-minimal +++ b/Dockerfile.debian-minimal @@ -6,6 +6,7 @@ RUN apt-get install -y \ flex \ bison \ pkg-config \ + libatomic1 \ libpciaccess-dev \ libkmod-dev \ libprocps-dev \ diff --git a/Dockerfile.fedora b/Dockerfile.fedora index 6686e587613d..c84b412b0723 100644 --- a/Dockerfile.fedora +++ b/Dockerfile.fedora @@ -1,7 +1,7 @@ FROM fedora:30 RUN dnf install -y \ - gcc flex bison meson ninja-build xdotool \ + gcc flex bison libatomic meson ninja-build xdotool \ 'pkgconfig(libdrm)' \ 'pkgconfig(pciaccess)' \ 'pkgconfig(libkmod)' \ -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 1/4] meson: add libatomic dependency
Add conditional dependency on GCC's libatomic in order to be able to
use the __atomic_* functions instead of the older __sync_* ones. The
libatomic library is only needed when there aren't any native support
on the current architecture, so a linker test is used for this
purpose. This makes atomic operations available on a wider number of
architectures including MIPS.
Signed-off-by: Guillaume Tucker
Reviewed-by: Simon Ser
---
Notes:
v2: add linker test for libatomic
v3: use null_dep
v4: fix sentence in commit message
meson.build | 14 ++
1 file changed, 14 insertions(+)
diff --git a/meson.build b/meson.build
index b1028ee6aaaf..f0cb2543ca64 100644
--- a/meson.build
+++ b/meson.build
@@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
dlsym = cc.find_library('dl')
zlib = cc.find_library('z')
+if cc.links('''
+#include
+int main(void) {
+ uint32_t x32 = 0;
+ uint64_t x64 = 0;
+ __atomic_load_n(, __ATOMIC_SEQ_CST);
+ __atomic_load_n(, __ATOMIC_SEQ_CST);
+ return 0;
+}''', name : 'built-in atomics')
+ libatomic = null_dep
+else
+ libatomic = cc.find_library('atomic')
+endif
+
if cc.has_header('linux/kd.h')
config.set('HAVE_LINUX_KD_H', 1)
endif
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 4/4] tests/sw_sync: use atomic_* instead of __sync_*
Replace calls to the older __sync_* functions with the new atomic_*
standard ones to be consistent with other tests and improve
portability across CPU architectures. Add dependency of sw_sync on
libatomic.
Signed-off-by: Guillaume Tucker
Reviewed-by: Simon Ser
---
Notes:
v2: use atomic_* and only link libatomic with sw_sync
tests/Makefile.am | 1 +
tests/meson.build | 8 +++-
tests/sw_sync.c | 12 ++--
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index bbd386c9c2db..7d71df8c7a2e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -122,6 +122,7 @@ prime_self_import_LDADD = $(LDADD) -lpthread
gem_userptr_blits_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_userptr_blits_LDADD = $(LDADD) -lpthread
perf_pmu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
+sw_sync_LDADD = $(LDADD) -latomic
kms_flip_LDADD = $(LDADD) -lpthread
diff --git a/tests/meson.build b/tests/meson.build
index ffd432d38193..34a74025a537 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -76,7 +76,6 @@ test_progs = [
'prime_self_import',
'prime_udl',
'prime_vgem',
- 'sw_sync',
'syncobj_basic',
'syncobj_wait',
'template',
@@ -329,6 +328,13 @@ executable('testdisplay', ['testdisplay.c',
'testdisplay_hotplug.c'],
install : true)
test_list += 'testdisplay'
+test_executables += executable('sw_sync', 'sw_sync.c',
+ dependencies : test_deps + [ libatomic ],
+ install_dir : libexecdir,
+ install_rpath : libexecdir_rpathdir,
+ install : true)
+test_list += 'sw_sync'
+
subdir('amdgpu')
gen_testlist = find_program('generate_testlist.sh')
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 950b8b614759..62d1d17cab45 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -26,6 +26,7 @@
#include
#include
+#include
#include
#include
#include
@@ -43,7 +44,7 @@ IGT_TEST_DESCRIPTION("Test SW Sync Framework");
typedef struct {
int timeline;
uint32_t thread_id;
- uint32_t *counter;
+ _Atomic(uint32_t) *counter;
sem_t *sem;
} data_t;
@@ -489,7 +490,7 @@ static void test_sync_multi_consumer(void)
pthread_t thread_arr[MULTI_CONSUMER_THREADS];
sem_t sem;
int timeline;
- uint32_t counter = 0;
+ _Atomic(uint32_t) counter = 0;
uintptr_t thread_ret = 0;
data_t data;
int i, ret;
@@ -517,7 +518,7 @@ static void test_sync_multi_consumer(void)
{
sem_wait();
- __sync_fetch_and_add(, 1);
+ atomic_fetch_add(, 1);
sw_sync_timeline_inc(timeline, 1);
}
@@ -554,7 +555,7 @@ static void * test_sync_multi_consumer_producer_thread(void
*arg)
if (sync_fence_wait(fence, 1000) < 0)
return (void *) 1;
- if (__sync_fetch_and_add(data->counter, 1) != next_point)
+ if (atomic_fetch_add(data->counter, 1) != next_point)
return (void *) 1;
/* Kick off the next thread. */
@@ -570,7 +571,7 @@ static void test_sync_multi_consumer_producer(void)
data_t data_arr[MULTI_CONSUMER_PRODUCER_THREADS];
pthread_t thread_arr[MULTI_CONSUMER_PRODUCER_THREADS];
int timeline;
- uint32_t counter = 0;
+ _Atomic(uint32_t) counter = 0;
uintptr_t thread_ret = 0;
data_t data;
int i, ret;
@@ -900,4 +901,3 @@ igt_main
igt_subtest("sync_random_merge")
test_sync_random_merge();
}
-
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 3/4] i915/gem_create: use atomic_* instead of __sync_*
This fixes builds on some architectures, in particular MIPS which
doesn't have __sync_add_and_fetch_8 and __sync_val_compare_and_swap_8
for 64-bit variable handling.
* replace calls to the older __sync_* functions with the new atomic_*
standard ones
* use the _Atomic type modifier as required with stdatomic.h functions
* add dependency for gem_create on libatomic
Signed-off-by: Guillaume Tucker
Reviewed-by: Simon Ser
---
Notes:
v2: use atomic_* and only link libatomic with gem_create
tests/Makefile.am | 2 +-
tests/i915/gem_create.c | 16
tests/meson.build | 9 -
3 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 5a428b8ac213..bbd386c9c2db 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -90,7 +90,7 @@ AM_LDFLAGS = -Wl,--as-needed
drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
drm_import_export_LDADD = $(LDADD) -lpthread
gem_create_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
-gem_create_LDADD = $(LDADD) -lpthread
+gem_create_LDADD = $(LDADD) -lpthread -latomic
gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_close_race_LDADD = $(LDADD) -lpthread
gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c
index 43cbf45f289b..9008cd8a21e3 100644
--- a/tests/i915/gem_create.c
+++ b/tests/i915/gem_create.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
@@ -156,7 +157,14 @@ static void invalid_nonaligned_size(int fd)
gem_close(fd, create.handle);
}
-static uint64_t get_npages(uint64_t *global, uint64_t npages)
+static uint64_t atomic_compare_swap_u64(_Atomic(uint64_t) *ptr,
+ uint64_t oldval, uint64_t newval)
+{
+ atomic_compare_exchange_strong(ptr, , newval);
+ return oldval;
+}
+
+static uint64_t get_npages(_Atomic(uint64_t) *global, uint64_t npages)
{
uint64_t try, old, max;
@@ -165,13 +173,13 @@ static uint64_t get_npages(uint64_t *global, uint64_t
npages)
old = max;
try = 1 + npages % (max / 2);
max -= try;
- } while ((max = __sync_val_compare_and_swap(global, old, max)) != old);
+ } while ((max = atomic_compare_swap_u64(global, old, max)) != old);
return try;
}
struct thread_clear {
- uint64_t max;
+ _Atomic(uint64_t) max;
int timeout;
int i915;
};
@@ -202,7 +210,7 @@ static void *thread_clear(void *data)
}
gem_close(i915, create.handle);
- __sync_add_and_fetch(>max, npages);
+ atomic_fetch_add(>max, npages);
}
return NULL;
diff --git a/tests/meson.build b/tests/meson.build
index f168fbbae2a8..ffd432d38193 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -110,7 +110,6 @@ i915_progs = [
'gem_close_race',
'gem_concurrent_blit',
'gem_cpu_reloc',
- 'gem_create',
'gem_cs_prefetch',
'gem_cs_tlb',
'gem_ctx_bad_destroy',
@@ -277,6 +276,14 @@ foreach prog : i915_progs
test_list += prog
endforeach
+test_executables += executable('gem_create',
+ join_paths('i915', 'gem_create.c'),
+ dependencies : test_deps + [ libatomic ],
+ install_dir : libexecdir,
+ install_rpath : libexecdir_rpathdir,
+ install : true)
+test_list += 'gem_create'
+
test_executables += executable('gem_ctx_sseu',
join_paths('i915', 'gem_ctx_sseu.c'),
dependencies : test_deps + [ lib_igt_perf ],
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 0/4] Use C11 atomics
This series replaces calls to the __sync_* functions with the more recent atomic_* ones defined in stdatomic.h in gem_create and sw_sync. It also adds dependency on libatomic when required, that is to say when the CPU architecture doesn't provide native support for some atomic operations. This makes the tests more portable, in particular for 32-bit MIPS which doesn't support 64-bit atomics. v2: - add linker test to only add dependency on libatomic when needed - only add libatomic dependency to gem_create and sw_sync - use stdatomic.h and _Atomic type modifier - explicitly require libatomic in all Docker images v3: - use sub-arch libatomic1 in Debian docker images - use null_dep in meson.build v4: - rebase with changes in Dockerfile.debian-minimal Guillaume Tucker (4): meson: add libatomic dependency gitlab-ci: add libatomic to docker images i915/gem_create: use atomic_* instead of __sync_* tests/sw_sync: use atomic_* instead of __sync_* Dockerfile.debian-arm64 | 1 + Dockerfile.debian-armhf | 1 + Dockerfile.debian-minimal | 1 + Dockerfile.fedora | 2 +- meson.build | 14 ++ tests/Makefile.am | 3 ++- tests/i915/gem_create.c | 16 tests/meson.build | 17 +++-- tests/sw_sync.c | 12 ++-- 9 files changed, 53 insertions(+), 14 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/i915: Use intel state as much as possible in wm code
On Thu, Jun 20, 2019 at 11:46:10PM +0200, Maarten Lankhorst wrote:
> Instead of directly referencing drm_crtc_state, convert to
> intel_ctc_state and use the base struct. This is useful when we're
> making the split between uapi and hw state, and also makes the
> code slightly more readable.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_pm.c | 112 ++--
> 1 file changed, 50 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 4116de2a77fd..afa069f0dc70 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3857,8 +3857,8 @@ skl_ddb_get_pipe_allocation_limits(struct
> drm_i915_private *dev_priv,
> struct drm_atomic_state *state = cstate->base.state;
> struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> struct drm_crtc *for_crtc = cstate->base.crtc;
> - const struct drm_crtc_state *crtc_state;
> - const struct drm_crtc *crtc;
> + const struct intel_crtc_state *crtc_state;
> + const struct intel_crtc *crtc;
> u32 pipe_width = 0, total_width = 0, width_before_pipe = 0;
> enum pipe for_pipe = to_intel_crtc(for_crtc)->pipe;
> u16 ddb_size;
> @@ -3901,16 +3901,16 @@ skl_ddb_get_pipe_allocation_limits(struct
> drm_i915_private *dev_priv,
>* framebuffer, So instead of allocating DDB equally among pipes
>* distribute DDB based on resolution/width of the display.
>*/
> - for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + for_each_new_intel_crtc_in_state(intel_state, crtc, crtc_state, i) {
> const struct drm_display_mode *adjusted_mode;
> int hdisplay, vdisplay;
> enum pipe pipe;
>
> - if (!crtc_state->enable)
> + if (!crtc_state->base.enable)
> continue;
>
> - pipe = to_intel_crtc(crtc)->pipe;
> - adjusted_mode = _state->adjusted_mode;
> + pipe = crtc->pipe;
> + adjusted_mode = _state->base.adjusted_mode;
Those two could be done when declaring the variables.
> drm_mode_get_hv_timing(adjusted_mode, , );
> total_width += hdisplay;
>
> @@ -4139,11 +4139,9 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc
> *intel_crtc,
> struct intel_crtc_state *cstate)
> {
> struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> - struct drm_crtc_state *crtc_state = >base;
> - struct drm_atomic_state *state = crtc_state->state;
> + struct drm_atomic_state *state = cstate->base.state;
> struct drm_plane *plane;
> - const struct drm_plane_state *pstate;
> - struct intel_plane_state *intel_pstate;
> + const struct drm_plane_state *drm_pstate;
> int crtc_clock, dotclk;
> u32 pipe_max_pixel_rate;
> uint_fixed_16_16_t pipe_downscale;
> @@ -4152,22 +4150,21 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc
> *intel_crtc,
> if (!cstate->base.enable)
> return 0;
>
> - drm_atomic_crtc_state_for_each_plane_state(plane, pstate, crtc_state) {
> + drm_atomic_crtc_state_for_each_plane_state(plane, drm_pstate,
> >base) {
> uint_fixed_16_16_t plane_downscale;
> uint_fixed_16_16_t fp_9_div_8 = div_fixed16(9, 8);
> int bpp;
> + const struct intel_plane_state *pstate =
> + to_intel_plane_state(drm_pstate);
>
> - if (!intel_wm_plane_visible(cstate,
> - to_intel_plane_state(pstate)))
> + if (!intel_wm_plane_visible(cstate, pstate))
> continue;
>
> - if (WARN_ON(!pstate->fb))
> + if (WARN_ON(!pstate->base.fb))
> return -EINVAL;
>
> - intel_pstate = to_intel_plane_state(pstate);
> - plane_downscale = skl_plane_downscale_amount(cstate,
> - intel_pstate);
> - bpp = pstate->fb->format->cpp[0] * 8;
> + plane_downscale = skl_plane_downscale_amount(cstate, pstate);
> + bpp = pstate->base.fb->format->cpp[0] * 8;
> if (bpp == 64)
> plane_downscale = mul_fixed16(plane_downscale,
> fp_9_div_8);
> @@ -4178,7 +4175,7 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc
> *intel_crtc,
>
> pipe_downscale = mul_fixed16(pipe_downscale, max_downscale);
>
> - crtc_clock = crtc_state->adjusted_mode.crtc_clock;
> + crtc_clock = cstate->base.adjusted_mode.crtc_clock;
> dotclk = to_intel_atomic_state(state)->cdclk.logical.cdclk;
>
> if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
> @@ -4196,11 +4193,10 @@ int
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Pass intel state to plane functions as well
On Thu, Jun 20, 2019 at 11:46:09PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 39 +++--
> .../gpu/drm/i915/display/intel_atomic_plane.h | 5 +-
> drivers/gpu/drm/i915/display/intel_display.c | 58 +--
> 3 files changed, 49 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 30bd4e76fff9..025c09461c9a 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -176,33 +176,36 @@ int intel_plane_atomic_check_with_state(const struct
> intel_crtc_state *old_crtc_
> new_crtc_state->data_rate[plane->id] =
> intel_plane_data_rate(new_crtc_state, new_plane_state);
>
> - return intel_plane_atomic_calc_changes(old_crtc_state,
> -_crtc_state->base,
> -old_plane_state,
> -_plane_state->base);
> + return intel_plane_atomic_calc_changes(old_crtc_state, new_crtc_state,
> +old_plane_state,
> new_plane_state);
> }
>
> static int intel_plane_atomic_check(struct drm_plane *plane,
> struct drm_plane_state *new_plane_state)
> {
> - struct drm_atomic_state *state = new_plane_state->state;
> - const struct drm_plane_state *old_plane_state =
> - drm_atomic_get_old_plane_state(state, plane);
> - struct drm_crtc *crtc = new_plane_state->crtc ?: old_plane_state->crtc;
> - const struct drm_crtc_state *old_crtc_state;
> - struct drm_crtc_state *new_crtc_state;
> -
> - new_plane_state->visible = false;
> + struct intel_atomic_state *state =
> + to_intel_atomic_state(new_plane_state->state);
> + const struct intel_plane_state *old_intel_plane_state =
> + intel_atomic_get_old_plane_state(state, to_intel_plane(plane));
> + struct intel_plane_state *new_intel_plane_state =
> + to_intel_plane_state(new_plane_state);
I think we should do the _new_plane_state trick for the function
arguments and then use the non-underscore names for the intel types.
> + struct drm_crtc *crtc =
> + new_intel_plane_state->base.crtc ?:
> old_intel_plane_state->base.crtc;
> + struct intel_crtc *intel_crtc = crtc ? to_intel_crtc(crtc) : NULL;
?: not needed. I also dislike the crtc vs. intel_crc thing. Maybe
extract this mess into a small function that just returns the
intel_crtc we want?
Reviewed-by: Ville Syrjälä
> + const struct intel_crtc_state *old_crtc_state;
> + struct intel_crtc_state *new_crtc_state;
> +
> + new_intel_plane_state->base.visible = false;
> if (!crtc)
> return 0;
>
> - old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc);
> - new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> + old_crtc_state = intel_atomic_get_old_crtc_state(state, intel_crtc);
> + new_crtc_state = intel_atomic_get_new_crtc_state(state, intel_crtc);
>
> - return
> intel_plane_atomic_check_with_state(to_intel_crtc_state(old_crtc_state),
> -
> to_intel_crtc_state(new_crtc_state),
> -
> to_intel_plane_state(old_plane_state),
> -
> to_intel_plane_state(new_plane_state));
> + return intel_plane_atomic_check_with_state(old_crtc_state,
> +new_crtc_state,
> +old_intel_plane_state,
> +new_intel_plane_state);
> }
>
> static struct intel_plane *
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> index 1437a8797e10..cb7ef4f9eafd 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> @@ -8,7 +8,6 @@
>
> #include
>
> -struct drm_crtc_state;
> struct drm_plane;
> struct drm_property;
> struct intel_atomic_state;
> @@ -43,8 +42,8 @@ int intel_plane_atomic_check_with_state(const struct
> intel_crtc_state *old_crtc_
> const struct intel_plane_state
> *old_plane_state,
> struct intel_plane_state *intel_state);
> int intel_plane_atomic_calc_changes(const struct intel_crtc_state
> *old_crtc_state,
> - struct drm_crtc_state *crtc_state,
> + struct intel_crtc_state *crtc_state,
> const struct intel_plane_state
> *old_plane_state,
> - struct
Re: [Intel-gfx] [PATCH] drm/i915/gem: Clear read/write domains for GPU clear
Quoting Matthew Auld (2019-06-24 16:50:48) > On 24/06/2019 15:16, Chris Wilson wrote: > > Update the domains for the write via the GPU so that we do not > > shortcircuit any set-domain wait afterwards. > > I'm lost. How do we short-circuit the set-domain wait? If we never change the read_domain, then we may skip the clflush on set_cpu_domain thus missing the updated contents on !llc. So s/wait/clflush/ to be precise -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/9] drm/i915: Use intel_crtc_state in sanitize_watermarks() too
On Thu, Jun 20, 2019 at 11:46:08PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index a518d74f898f..baa0e1957ffe 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15738,8 +15738,8 @@ static void sanitize_watermarks(struct drm_device
> *dev)
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct drm_atomic_state *state;
> struct intel_atomic_state *intel_state;
> - struct drm_crtc *crtc;
> - struct drm_crtc_state *cstate;
> + struct intel_crtc *crtc;
> + struct intel_crtc_state *cstate;
s/cstate/crtc_state/ might be good here too.
Reviewed-by: Ville Syrjälä
> struct drm_modeset_acquire_ctx ctx;
> int ret;
> int i;
> @@ -15794,13 +15794,11 @@ static void sanitize_watermarks(struct drm_device
> *dev)
> }
>
> /* Write calculated watermark values back */
> - for_each_new_crtc_in_state(state, crtc, cstate, i) {
> - struct intel_crtc_state *cs = to_intel_crtc_state(cstate);
> -
> - cs->wm.need_postvbl_update = true;
> - dev_priv->display.optimize_watermarks(intel_state, cs);
> + for_each_new_intel_crtc_in_state(intel_state, crtc, cstate, i) {
> + cstate->wm.need_postvbl_update = true;
> + dev_priv->display.optimize_watermarks(intel_state, cstate);
>
> - to_intel_crtc_state(crtc->state)->wm = cs->wm;
> + to_intel_crtc_state(crtc->base.state)->wm = cstate->wm;
> }
>
> put_state:
> --
> 2.20.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 3/9] drm/i915: Convert hw state verifier to take more intel state
On Thu, Jun 20, 2019 at 11:46:07PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 154 +--
> 1 file changed, 74 insertions(+), 80 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 855f90a81396..a518d74f898f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6977,7 +6977,7 @@ void intel_encoder_destroy(struct drm_encoder *encoder)
>
> /* Cross check the actual hw state with our own modeset state tracking (and
> it's
> * internal consistency). */
> -static void intel_connector_verify_state(struct drm_crtc_state *crtc_state,
> +static void intel_connector_verify_state(struct intel_crtc_state *crtc_state,
>struct drm_connector_state *conn_state)
> {
> struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> @@ -6995,7 +6995,7 @@ static void intel_connector_verify_state(struct
> drm_crtc_state *crtc_state,
> if (!crtc_state)
> return;
>
> - I915_STATE_WARN(!crtc_state->active,
> + I915_STATE_WARN(!crtc_state->base.active,
> "connector is active, but attached crtc isn't\n");
>
> if (!encoder || encoder->type == INTEL_OUTPUT_DP_MST)
> @@ -7007,7 +7007,7 @@ static void intel_connector_verify_state(struct
> drm_crtc_state *crtc_state,
> I915_STATE_WARN(conn_state->crtc != encoder->base.crtc,
> "attached encoder crtc differs from connector crtc\n");
> } else {
> - I915_STATE_WARN(crtc_state && crtc_state->active,
> + I915_STATE_WARN(crtc_state && crtc_state->base.active,
> "attached crtc is active, but connector isn't\n");
> I915_STATE_WARN(!crtc_state && conn_state->best_encoder,
> "best encoder set without crtc!\n");
> @@ -12695,10 +12695,10 @@ static void intel_pipe_config_sanity_check(struct
> drm_i915_private *dev_priv,
> }
> }
>
> -static void verify_wm_state(struct drm_crtc *crtc,
> - struct drm_crtc_state *new_state)
> +static void verify_wm_state(struct intel_crtc *crtc,
> + struct intel_crtc_state *new_state)
s/new_state/new_crtc_state/ etc. might be nice to do as well.
> {
> - struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> struct skl_hw_state {
> struct skl_ddb_entry ddb_y[I915_MAX_PLANES];
> struct skl_ddb_entry ddb_uv[I915_MAX_PLANES];
> @@ -12708,21 +12708,20 @@ static void verify_wm_state(struct drm_crtc *crtc,
> struct skl_ddb_allocation *sw_ddb;
> struct skl_pipe_wm *sw_wm;
> struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry;
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - const enum pipe pipe = intel_crtc->pipe;
> + const enum pipe pipe = crtc->pipe;
> int plane, level, max_level = ilk_wm_max_level(dev_priv);
>
> - if (INTEL_GEN(dev_priv) < 9 || !new_state->active)
> + if (INTEL_GEN(dev_priv) < 9 || !new_state->base.active)
> return;
>
> hw = kzalloc(sizeof(*hw), GFP_KERNEL);
> if (!hw)
> return;
>
> - skl_pipe_wm_get_hw_state(intel_crtc, >wm);
> - sw_wm = _intel_crtc_state(new_state)->wm.skl.optimal;
> + skl_pipe_wm_get_hw_state(crtc, >wm);
> + sw_wm = _state->wm.skl.optimal;
>
> - skl_pipe_ddb_get_hw_state(intel_crtc, hw->ddb_y, hw->ddb_uv);
> + skl_pipe_ddb_get_hw_state(crtc, hw->ddb_y, hw->ddb_uv);
>
> skl_ddb_get_hw_state(dev_priv, >ddb);
> sw_ddb = _priv->wm.skl_hw.ddb;
> @@ -12770,7 +12769,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
>
> /* DDB */
> hw_ddb_entry = >ddb_y[plane];
> - sw_ddb_entry =
> _intel_crtc_state(new_state)->wm.skl.plane_ddb_y[plane];
> + sw_ddb_entry = _state->wm.skl.plane_ddb_y[plane];
>
> if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
> DRM_ERROR("mismatch in DDB state pipe %c plane %d
> (expected (%u,%u), found (%u,%u))\n",
> @@ -12822,7 +12821,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
>
> /* DDB */
> hw_ddb_entry = >ddb_y[PLANE_CURSOR];
> - sw_ddb_entry =
> _intel_crtc_state(new_state)->wm.skl.plane_ddb_y[PLANE_CURSOR];
> + sw_ddb_entry = _state->wm.skl.plane_ddb_y[PLANE_CURSOR];
>
> if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
> DRM_ERROR("mismatch in DDB state pipe %c cursor
> (expected (%u,%u), found (%u,%u))\n",
> @@ -12836,23 +12835,22 @@ static void verify_wm_state(struct
Re: [Intel-gfx] [PATCH] drm/i915/gem: Clear read/write domains for GPU clear
On 24/06/2019 15:16, Chris Wilson wrote:
Update the domains for the write via the GPU so that we do not
shortcircuit any set-domain wait afterwards.
I'm lost. How do we short-circuit the set-domain wait?
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110978
Fixes: b2dbf8d982a4 ("drm/i915/blt: Remove recursive vma->lock")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 9b01c3b5b31d..6f537e8e4dea 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -162,11 +162,12 @@ static void clear_pages_worker(struct work_struct *work)
goto out_signal;
if (obj->cache_dirty) {
- obj->write_domain = 0;
if (i915_gem_object_has_struct_page(obj))
drm_clflush_sg(w->sleeve->pages);
obj->cache_dirty = false;
}
+ obj->read_domains = I915_GEM_GPU_DOMAINS;
+ obj->write_domain = 0;
/* XXX: we need to kill this */
mutex_lock(>drm.struct_mutex);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/9] drm/i915: Pass intel_crtc_state to needs_modeset()
On Thu, Jun 20, 2019 at 11:46:05PM +0200, Maarten Lankhorst wrote:
Commit msg missing from some of these.
Apart from that:
Reviewed-by: Ville Syrjälä
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 68 ++--
> 1 file changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8592a7d422de..02565e97995a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -515,9 +515,9 @@ icl_wa_scalerclkgating(struct drm_i915_private *dev_priv,
> enum pipe pipe,
> }
>
> static bool
> -needs_modeset(const struct drm_crtc_state *state)
> +needs_modeset(const struct intel_crtc_state *state)
> {
> - return drm_atomic_crtc_needs_modeset(state);
> + return drm_atomic_crtc_needs_modeset(>base);
> }
>
> /*
> @@ -5796,7 +5796,7 @@ static bool hsw_pre_update_disable_ips(const struct
> intel_crtc_state *old_crtc_s
> if (!old_crtc_state->ips_enabled)
> return false;
>
> - if (needs_modeset(_crtc_state->base))
> + if (needs_modeset(new_crtc_state))
> return true;
>
> /*
> @@ -5823,7 +5823,7 @@ static bool hsw_post_update_enable_ips(const struct
> intel_crtc_state *old_crtc_s
> if (!new_crtc_state->ips_enabled)
> return false;
>
> - if (needs_modeset(_crtc_state->base))
> + if (needs_modeset(new_crtc_state))
> return true;
>
> /*
> @@ -5900,7 +5900,7 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
> intel_fbc_post_update(crtc);
>
> if (new_primary_state->visible &&
> - (needs_modeset(_config->base) ||
> + (needs_modeset(pipe_config) ||
>!old_primary_state->visible))
> intel_post_enable_primary(>base, pipe_config);
> }
> @@ -5924,7 +5924,7 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state,
> struct drm_plane *primary = crtc->base.primary;
> struct drm_plane_state *old_primary_state =
> drm_atomic_get_old_plane_state(old_state, primary);
> - bool modeset = needs_modeset(_config->base);
> + bool modeset = needs_modeset(pipe_config);
> struct intel_atomic_state *old_intel_state =
> to_intel_atomic_state(old_state);
>
> @@ -5984,7 +5984,7 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state,
>* If we're doing a modeset, we're done. No need to do any pre-vblank
>* watermark programming here.
>*/
> - if (needs_modeset(_config->base))
> + if (needs_modeset(pipe_config))
> return;
>
> /*
> @@ -11339,7 +11339,7 @@ int intel_plane_atomic_calc_changes(const struct
> intel_crtc_state *old_crtc_stat
> struct intel_plane *plane = to_intel_plane(plane_state->plane);
> struct drm_device *dev = crtc->dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> - bool mode_changed = needs_modeset(crtc_state);
> + bool mode_changed = needs_modeset(pipe_config);
> bool was_crtc_enabled = old_crtc_state->base.active;
> bool is_crtc_enabled = crtc_state->active;
> bool turn_off, turn_on, visible, was_visible;
> @@ -11608,7 +11608,7 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *crtc,
> struct intel_crtc_state *pipe_config =
> to_intel_crtc_state(crtc_state);
> int ret;
> - bool mode_changed = needs_modeset(crtc_state);
> + bool mode_changed = needs_modeset(pipe_config);
>
> if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv) &&
> mode_changed && !crtc_state->active)
> @@ -13088,7 +13088,7 @@ intel_modeset_verify_crtc(struct drm_crtc *crtc,
> struct drm_crtc_state *old_state,
> struct drm_crtc_state *new_state)
> {
> - if (!needs_modeset(new_state) &&
> + if (!needs_modeset(to_intel_crtc_state(new_state)) &&
> !to_intel_crtc_state(new_state)->update_pipe)
> return;
>
> @@ -13180,7 +13180,7 @@ static void intel_modeset_clear_plls(struct
> intel_atomic_state *state)
> struct intel_shared_dpll *old_dpll =
> old_crtc_state->shared_dpll;
>
> - if (!needs_modeset(_crtc_state->base))
> + if (!needs_modeset(new_crtc_state))
> continue;
>
> new_crtc_state->shared_dpll = NULL;
> @@ -13210,7 +13210,7 @@ static int haswell_mode_set_planes_workaround(struct
> intel_atomic_state *state)
> /* look at all crtc's that are going to be enabled in during modeset */
> for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> if (!crtc_state->base.active ||
> - !needs_modeset(_state->base))
>
Re: [Intel-gfx] [PATCH 2/9] drm/i915: Convert most of atomic commit to take more intel state
On Thu, Jun 20, 2019 at 11:46:06PM +0200, Maarten Lankhorst wrote:
> Instead of passing along drm_crtc_state and drm_atomic_state, pass
> along more intel_atomic_state and intel_crtc_state. This will
> make the code more readable by not casting between drm state
> and intel state all the time.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 403 +--
> drivers/gpu/drm/i915/i915_drv.h | 6 +-
> drivers/gpu/drm/i915/intel_pm.c | 11 +-
> drivers/gpu/drm/i915/intel_pm.h | 4 +-
> 4 files changed, 196 insertions(+), 228 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 02565e97995a..855f90a81396 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6036,19 +6036,19 @@ static void intel_crtc_disable_planes(struct
> intel_atomic_state *state,
> intel_frontbuffer_flip(dev_priv, fb_bits);
> }
>
> -static void intel_encoders_pre_pll_enable(struct drm_crtc *crtc,
> +static void intel_encoders_pre_pll_enable(struct intel_crtc *crtc,
> struct intel_crtc_state *crtc_state,
> - struct drm_atomic_state *old_state)
> + struct intel_atomic_state *old_state)
Maybe s/old_state/state/ while at it?
Reviewed-by: Ville Syrjälä
> {
> struct drm_connector_state *conn_state;
> struct drm_connector *conn;
> int i;
>
> - for_each_new_connector_in_state(old_state, conn, conn_state, i) {
> + for_each_new_connector_in_state(_state->base, conn, conn_state, i) {
> struct intel_encoder *encoder =
> to_intel_encoder(conn_state->best_encoder);
>
> - if (conn_state->crtc != crtc)
> + if (conn_state->crtc != >base)
> continue;
>
> if (encoder->pre_pll_enable)
> @@ -6056,19 +6056,19 @@ static void intel_encoders_pre_pll_enable(struct
> drm_crtc *crtc,
> }
> }
>
> -static void intel_encoders_pre_enable(struct drm_crtc *crtc,
> +static void intel_encoders_pre_enable(struct intel_crtc *crtc,
> struct intel_crtc_state *crtc_state,
> - struct drm_atomic_state *old_state)
> + struct intel_atomic_state *old_state)
> {
> struct drm_connector_state *conn_state;
> struct drm_connector *conn;
> int i;
>
> - for_each_new_connector_in_state(old_state, conn, conn_state, i) {
> + for_each_new_connector_in_state(_state->base, conn, conn_state, i) {
> struct intel_encoder *encoder =
> to_intel_encoder(conn_state->best_encoder);
>
> - if (conn_state->crtc != crtc)
> + if (conn_state->crtc != >base)
> continue;
>
> if (encoder->pre_enable)
> @@ -6076,19 +6076,19 @@ static void intel_encoders_pre_enable(struct drm_crtc
> *crtc,
> }
> }
>
> -static void intel_encoders_enable(struct drm_crtc *crtc,
> +static void intel_encoders_enable(struct intel_crtc *crtc,
> struct intel_crtc_state *crtc_state,
> - struct drm_atomic_state *old_state)
> + struct intel_atomic_state *old_state)
> {
> struct drm_connector_state *conn_state;
> struct drm_connector *conn;
> int i;
>
> - for_each_new_connector_in_state(old_state, conn, conn_state, i) {
> + for_each_new_connector_in_state(_state->base, conn, conn_state, i) {
> struct intel_encoder *encoder =
> to_intel_encoder(conn_state->best_encoder);
>
> - if (conn_state->crtc != crtc)
> + if (conn_state->crtc != >base)
> continue;
>
> if (encoder->enable)
> @@ -6097,19 +6097,19 @@ static void intel_encoders_enable(struct drm_crtc
> *crtc,
> }
> }
>
> -static void intel_encoders_disable(struct drm_crtc *crtc,
> +static void intel_encoders_disable(struct intel_crtc *crtc,
> struct intel_crtc_state *old_crtc_state,
> -struct drm_atomic_state *old_state)
> +struct intel_atomic_state *old_state)
> {
> struct drm_connector_state *old_conn_state;
> struct drm_connector *conn;
> int i;
>
> - for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
> + for_each_old_connector_in_state(_state->base, conn, old_conn_state,
> i) {
> struct intel_encoder *encoder =
> to_intel_encoder(old_conn_state->best_encoder);
>
> - if (old_conn_state->crtc != crtc)
> + if
Re: [Intel-gfx] [PATCH 0/5] drm: Aspect ratio fixes
On Fri, Jun 21, 2019 at 07:28:30PM -0400, Alex Deucher wrote: > On Thu, Jun 20, 2019 at 10:26 AM Ville Syrjala > wrote: > > > > From: Ville Syrjälä > > > > Ilia pointed out some oddball crap in the i915 aspect ratio handling. > > While looking at that I noticed a bunch of fail in the core as well. > > This series aims to fix it all. > > > > Cc: Ilia Mirkin > > > > Ville Syrjälä (5): > > drm: Do not use bitwise OR to set picure_aspect_ratio > > drm: Do not accept garbage mode aspect ratio flags > > drm: WARN on illegal aspect ratio when converting a mode to umode > > Patches 1-3: > Reviewed-by: Alex Deucher Thanks. 1-3 pushed to drm-misc-next. -- Ville Syrjälä Intel ___ 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/gem: Clear read/write domains for GPU clear
== Series Details == Series: drm/i915/gem: Clear read/write domains for GPU clear URL : https://patchwork.freedesktop.org/series/62646/ State : success == Summary == CI Bug Log - changes from CI_DRM_6334 -> Patchwork_13407 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/ Known issues Here are the changes found in Patchwork_13407 that come from known issues: ### IGT changes ### Issues hit * igt@kms_frontbuffer_tracking@basic: - fi-icl-u2: [PASS][1] -> [FAIL][2] ([fdo#103167]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@gem_basic@create-fd-close: - fi-icl-u3: [DMESG-WARN][3] ([fdo#107724]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/fi-icl-u3/igt@gem_ba...@create-fd-close.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/fi-icl-u3/igt@gem_ba...@create-fd-close.html * igt@gem_ctx_create@basic-files: - fi-icl-u3: [INCOMPLETE][5] ([fdo#107713] / [fdo#109100]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html * igt@i915_selftest@live_hangcheck: - fi-icl-dsi: [INCOMPLETE][7] ([fdo#107713] / [fdo#108569]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [DMESG-WARN][9] ([fdo#102614]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [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#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100 Participating hosts (50 -> 43) -- Additional (1): fi-byt-j1900 Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6334 -> Patchwork_13407 CI_DRM_6334: 86d1a866f35634912d7699f1eb4d04a2007df18e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5065: f454000b5ba221b19d696a27415fe5824d743284 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13407: 79c87db9358c1e206b660199d9bce483378b9728 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 79c87db9358c drm/i915/gem: Clear read/write domains for GPU clear == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13407/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/execlists: Switch to using STOP_RING instead of a semaphore
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Switch to using STOP_RING instead of a semaphore URL : https://patchwork.freedesktop.org/series/62641/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6334 -> Patchwork_13405 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13405 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13405, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13405/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13405: ### IGT changes ### Possible regressions * igt@i915_selftest@live_execlists: - fi-cfl-8700k: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/fi-cfl-8700k/igt@i915_selftest@live_execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13405/fi-cfl-8700k/igt@i915_selftest@live_execlists.html Known issues Here are the changes found in Patchwork_13405 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_blt: - fi-skl-iommu: [PASS][3] -> [INCOMPLETE][4] ([fdo#108602]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/fi-skl-iommu/igt@i915_selftest@live_blt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13405/fi-skl-iommu/igt@i915_selftest@live_blt.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u2: [PASS][5] -> [FAIL][6] ([fdo#103167]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13405/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][7] ([fdo#109485]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13405/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [DMESG-WARN][9] ([fdo#102614]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6334/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13405/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 Participating hosts (50 -> 40) -- Additional (1): fi-byt-j1900 Missing(11): fi-kbl-soraka fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-icl-u3 fi-icl-y fi-icl-dsi fi-bdw-samus Build changes - * Linux: CI_DRM_6334 -> Patchwork_13405 CI_DRM_6334: 86d1a866f35634912d7699f1eb4d04a2007df18e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5065: f454000b5ba221b19d696a27415fe5824d743284 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13405: 837e62fe62a4f050e66b61701428f2b640e7e2be @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 837e62fe62a4 drm/i915/execlists: Convert recursive defer_request() into iterative 68e7226beb2c drm/i915: Emit final breadcrumb in request_add ccee12ecc162 drm/i915/execlists: Switch to using STOP_RING instead of a semaphore == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13405/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On Mon, Jun 24, 2019 at 03:58:00PM +0200, Christian König wrote: > Am 24.06.19 um 13:23 schrieb Koenig, Christian: > > Am 21.06.19 um 18:27 schrieb Daniel Vetter: > > > > > So I pondered a few ideas while working out: > > > > > > 1) We drop this filtering. Importer needs to keep track of all its > > > mappings and filter out invalidates that aren't for that specific importer > > > (either because already invalidated, or not yet mapped, or whatever). > > > Feels fragile. > > > > > > [SNIP] > > [SNIP] > > > > I will take a moment and look into #1 as well, but I still don't see the > > need to change anything. > > That turned out much cleaner than I thought it would be. Essentially it is > only a single extra line of code in amdgpu. > > Going to send that out as a patch set in a minute. Yeah I mean kinda expected that because: - everything's protected with ww_mutex anyway - importer needs to keep track of mappings anways So really all it needs to do is not be stupid and add the mapping it just created to its tracking while still holding the ww_mutex. Similar on invalidate/unmap. With that all we need is a huge note in the docs that importers need to keep track of their mappings and dtrt (with all the examples here spelled out in the appropriate kerneldoc). And then I'm happy :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On Mon, Jun 24, 2019 at 11:23:34AM +, Koenig, Christian wrote: > Am 21.06.19 um 18:27 schrieb Daniel Vetter: > >>> Your scenario here is new, and iirc my suggestion back then was to > >>> count the number of pending mappings so you don't go around calling > >>> ->invalidate on mappings that don't exist. > >> Well the key point is we don't call invalidate on mappings, but we call > >> invalidate on attachments. > >> > >> When the invalidate on an attachment is received all the importer should at > >> least start to tear down all mappings. > > Hm, so either we invalidate mappings instead (pretty big change for > > dma-buf, but maybe worth it). Or importers need to deal with invalidate on > > stuff they're don't even have mapped anywhere anyway. > > I actually I don't see a problem with this, but see below. > > >> [SNIP] > >>> - your scenario, where you call ->invalidate on an attachment which > >>> doesn't have a mapping. I'll call that very lazy accounting, feels > >>> like a bug :-) It's also very easy to fix by keeping track who > >>> actually has a mapping, and then you fix it everywhere, not just for > >>> the specific case of a recursion into the same caller. > >> Yeah, exactly. Unfortunately it's not so easy to handle as just a counter. > >> > >> When somebody unmaps a mapping you need to know if that is already > >> invalidated or not. And this requires tracking of each mapping. > > Yeah we'd need to track mappings. Well, someone has to track mappings, and > > atm it seems to be a mix of both importer and exporter (and dma-buf.c). > > Maybe I'm missing something, but I don't see the mix? > > Only the importer is responsible to tracking mappings, e.g. the importer > calls dma_buf_map_attachment() when it needs a mapping and calls > dma_buf_unmap_attachment() when it is done with the mapping. > > In between those two neither the exporter nor the DMA-buf cares about > what mappings currently exist. And apart from debugging I actually don't > see a reason why they should. Atm importer has to track which mappings it actually has. Plus dma-buf.c also tracks that, somehow, with your recursion-preventation code. So that's the mix. > >> [SNIP] > >>> But I guess there's other fixes too possible. > >>> > >>> Either way none of this is about recursion, I think the recursive case > >>> is simply the one where you've hit this already. Drivers will have to > >>> handle all these additional ->invalidates no matter what with your > >>> current proposal. After all the point here is that the exporter can > >>> move the buffers around whenever it feels like, for whatever reasons. > >> The recursion case is still perfectly valid. In the importer I need to > >> ignore invalidations which are caused by creating a mapping. > >> > >> Otherwise it is perfectly possible that we invalidate a mapping because of > >> its creation which will result in creating a new one > >> > >> So even if you fix up your mapping case, you absolutely still need this to > >> prevent recursion :) > > Hm, but if we stop tracking attachments and instead start tracking > > mappings, then how is that possible: > > Yeah, but why should we do this? I don't see a benefit here. Importers > just create/destroy mappings as they need them. > > > 1. importer has no mappings > > 2. importer creates attachment. still no mapping > > 3. importer calls dma_buf_attach_map_sg, still no mapping at this point > > 4. we call into the exporter implementation. still no mapping > > 5. exporter does whatever it does. still no mapping > > 6. exporter finishes. conceptually from the dma-buf pov, _this_ is where > > the mapping starts to exist. > > 7. invalidates (hey the exporter maybe changed its mind!) are totally > > fine, and will be serialized with ww_mutex. > > > > So I kinda don understand why the exporter here is allowed to call > > invalidate too early (the mapping doesn't exist yet from dma-buf pov), and > > dma-buf needs to filter it out. > > > > But anywhere else where we might call ->invalidate and there's not yet a > > mapping (again purely from dma-buf pov), there the importer is supposed to > > do the filter. > > Maybe this becomes clearer if we call the callback "moved" instead of > "invalidated"? > > I mean this is actually all about the exporter informing the importer > that the DMA-buf in question is moving to a new location. > > That we need to create a new mapping and destroy the old one at some > point is an implementation detail on the importer. > > I mean the long term idea is to use this for notification that a buffer > is moving inside the same driver as well. And in this particular case I > actually don't think that we would create mappings at all. Thinking more > about it this is actually a really good argument to favor the > implementation as it is currently. > > > Someone needs to keep track of all this, and I want clear > > responsibilities. What they are exactly is not that important. > > Clear
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v11
== Series Details == Series: series starting with [1/6] dma-buf: add dynamic DMA-buf handling v11 URL : https://patchwork.freedesktop.org/series/62644/ State : failure == Summary == Applying: dma-buf: add dynamic DMA-buf handling v11 Applying: drm/ttm: remove the backing store if no placement is given Applying: drm/ttm: use the parent resv for ghost objects v2 Applying: drm/amdgpu: use allowed_domains for exported DMA-bufs Applying: drm/amdgpu: add independent DMA-buf export v6 Applying: drm/amdgpu: add independent DMA-buf import v7 Using index info to reconstruct a base tree... M drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c M drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h M drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c Auto-merging drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h CONFLICT (content): Merge conflict in drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h Auto-merging drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0006 drm/amdgpu: add independent DMA-buf import v7 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
[Intel-gfx] [PATCH] drm/i915/gem: Clear read/write domains for GPU clear
Update the domains for the write via the GPU so that we do not
shortcircuit any set-domain wait afterwards.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110978
Fixes: b2dbf8d982a4 ("drm/i915/blt: Remove recursive vma->lock")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 9b01c3b5b31d..6f537e8e4dea 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -162,11 +162,12 @@ static void clear_pages_worker(struct work_struct *work)
goto out_signal;
if (obj->cache_dirty) {
- obj->write_domain = 0;
if (i915_gem_object_has_struct_page(obj))
drm_clflush_sg(w->sleeve->pages);
obj->cache_dirty = false;
}
+ obj->read_domains = I915_GEM_GPU_DOMAINS;
+ obj->write_domain = 0;
/* XXX: we need to kill this */
mutex_lock(>drm.struct_mutex);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/ttm: use the parent resv for ghost objects v2
This way we can even pipeline imported BO evictions.
v2: Limit this to only cases when the parent object uses a separate
reservation object as well. This fixes another OOM problem.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 895d77d799e4..95f47d685921 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -517,9 +517,11 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
kref_init(>base.kref);
fbo->base.destroy = _transfered_destroy;
fbo->base.acc_size = 0;
- fbo->base.resv = >base.ttm_resv;
- reservation_object_init(fbo->base.resv);
- ret = reservation_object_trylock(fbo->base.resv);
+ if (bo->resv == >ttm_resv)
+ fbo->base.resv = >base.ttm_resv;
+
+ reservation_object_init(>base.ttm_resv);
+ ret = reservation_object_trylock(>base.ttm_resv);
WARN_ON(!ret);
*new_obj = >base;
@@ -716,7 +718,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
if (ret)
return ret;
- reservation_object_add_excl_fence(ghost_obj->resv, fence);
+ reservation_object_add_excl_fence(_obj->ttm_resv, fence);
/**
* If we're not moving to fixed memory, the TTM object
@@ -729,7 +731,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
else
bo->ttm = NULL;
- ttm_bo_unreserve(ghost_obj);
+ reservation_object_unlock(_obj->ttm_resv);
ttm_bo_put(ghost_obj);
}
@@ -772,7 +774,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
if (ret)
return ret;
- reservation_object_add_excl_fence(ghost_obj->resv, fence);
+ reservation_object_add_excl_fence(_obj->ttm_resv, fence);
/**
* If we're not moving to fixed memory, the TTM object
@@ -785,7 +787,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
else
bo->ttm = NULL;
- ttm_bo_unreserve(ghost_obj);
+ reservation_object_unlock(_obj->ttm_resv);
ttm_bo_put(ghost_obj);
} else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
@@ -841,7 +843,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
if (ret)
return ret;
- ret = reservation_object_copy_fences(ghost->resv, bo->resv);
+ ret = reservation_object_copy_fences(>ttm_resv, bo->resv);
/* Last resort, wait for the BO to be idle when we are OOM */
if (ret)
ttm_bo_wait(bo, false, false);
@@ -850,7 +852,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
bo->mem.mem_type = TTM_PL_SYSTEM;
bo->ttm = NULL;
- ttm_bo_unreserve(ghost);
+ reservation_object_unlock(>ttm_resv);
ttm_bo_put(ghost);
return 0;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/amdgpu: add independent DMA-buf export v6
The caching of SGT's is actually quite harmful and should probably removed
altogether when all drivers are audited.
Start by providing a separate DMA-buf export implementation in amdgpu.
This is also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging leftovers
v3: split out from unpinned DMA-buf work
v4: rebase on top of new no_sgt_cache flag
v5: fix some warnings by including amdgpu_dma_buf.h
v6: fix locking for non amdgpu exports
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 210 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 +
4 files changed, 139 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 489041df1f45..579e33b31f2d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -34,26 +34,11 @@
#include "amdgpu.h"
#include "amdgpu_display.h"
#include "amdgpu_gem.h"
+#include "amdgpu_dma_buf.h"
#include
#include
#include
-/**
- * amdgpu_gem_prime_get_sg_table - _driver.gem_prime_get_sg_table
- * implementation
- * @obj: GEM buffer object (BO)
- *
- * Returns:
- * A scatter/gather table for the pinned pages of the BO's memory.
- */
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- int npages = bo->tbo.num_pages;
-
- return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
-}
-
/**
* amdgpu_gem_prime_vmap - _buf_ops.vmap implementation
* @obj: GEM BO
@@ -179,92 +164,163 @@ __reservation_object_make_exclusive(struct
reservation_object *obj)
}
/**
- * amdgpu_dma_buf_map_attach - _buf_ops.attach implementation
- * @dma_buf: Shared DMA buffer
+ * amdgpu_dma_buf_attach - _buf_ops.attach implementation
+ *
+ * @dmabuf: DMA-buf where we attach to
+ * @attach: attachment to add
+ *
+ * Add the attachment as user to the exported DMA-buf.
+ */
+static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf,
+struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ int r;
+
+ if (attach->dev->driver == adev->dev->driver)
+ return 0;
+
+ r = amdgpu_bo_reserve(bo, false);
+ if (unlikely(r != 0))
+ return r;
+
+ /*
+* We only create shared fences for internal use, but importers
+* of the dmabuf rely on exclusive fences for implicitly
+* tracking write hazards. As any of the current fences may
+* correspond to a write, we need to convert all existing
+* fences on the reservation object into a single exclusive
+* fence.
+*/
+ r = __reservation_object_make_exclusive(bo->tbo.resv);
+ if (r)
+ return r;
+
+ bo->prime_shared_count++;
+ amdgpu_bo_unreserve(bo);
+ return 0;
+}
+
+/**
+ * amdgpu_dma_buf_detach - _buf_ops.detach implementation
+ *
+ * @dmabuf: DMA-buf where we remove the attachment from
+ * @attach: the attachment to remove
+ *
+ * Called when an attachment is removed from the DMA-buf.
+ */
+static void amdgpu_dma_buf_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+
+ if (attach->dev->driver != adev->dev->driver && bo->prime_shared_count)
+ bo->prime_shared_count--;
+}
+
+/**
+ * amdgpu_dma_buf_pin - _buf_ops.pin implementation
+ *
+ * @attach: attachment to pin down
+ *
+ * Pin the BO which is backing the DMA-buf so that it can't move any more.
+ */
+static int amdgpu_dma_buf_pin(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+ /* pin buffer into GTT */
+ return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
+}
+
+/**
+ * amdgpu_dma_buf_unpin - _buf_ops.unpin implementation
+ *
+ * @attach: attachment to unpin
+ *
+ * Unpin a previously pinned BO to make it movable again.
+ */
+static void amdgpu_dma_buf_unpin(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+ amdgpu_bo_unpin(bo);
+}
+
+/**
+ * amdgpu_dma_buf_map_dma_buf - _buf_ops.map_dma_buf implementation
* @attach: DMA-buf attachment
+ * @dir: DMA direction
*
* Makes sure that the shared DMA buffer can be accessed by the target device.
* For now, simply pins it to the GTT domain, where
[Intel-gfx] [PATCH 2/6] drm/ttm: remove the backing store if no placement is given
Pipeline removal of the BOs backing store when no placement is given
during validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c7de667d482a..682a1a035b35 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1240,6 +1240,18 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
uint32_t new_flags;
reservation_object_assert_held(bo->resv);
+
+ /*
+* Remove the backing store if no placement is given.
+*/
+ if (!placement->num_placement && !placement->num_busy_placement) {
+ ret = ttm_bo_pipeline_gutting(bo);
+ if (ret)
+ return ret;
+
+ return ttm_tt_create(bo, false);
+ }
+
/*
* Check whether we need to move buffer.
*/
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/amdgpu: add independent DMA-buf import v7
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach interface
v4: split out from unpinned DMA-buf work
v5: rebased and cleanup on new DMA-buf interface
v6: squash with invalidation callback change,
stop using _(map|unmap)_locked
v7: drop invalidations when the BO is already in system domain
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 68 -
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 4 --
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 32 --
5 files changed, 86 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 579e33b31f2d..b5972e0631f6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -424,31 +424,28 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device
*dev,
}
/**
- * amdgpu_gem_prime_import_sg_table - _driver.gem_prime_import_sg_table
- * implementation
+ * amdgpu_dma_buf_create_obj - create BO for DMA-buf import
+ *
* @dev: DRM device
- * @attach: DMA-buf attachment
- * @sg: Scatter/gather table
+ * @dma_buf: DMA-buf
*
- * Imports shared DMA buffer memory exported by another device.
+ * Creates an empty SG BO for DMA-buf import.
*
* Returns:
* A new GEM BO of the given DRM device, representing the memory
* described by the given DMA-buf attachment and scatter/gather table.
*/
-struct drm_gem_object *
-amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-struct dma_buf_attachment *attach,
-struct sg_table *sg)
+static struct drm_gem_object *
+amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
{
- struct reservation_object *resv = attach->dmabuf->resv;
+ struct reservation_object *resv = dma_buf->resv;
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_bo *bo;
struct amdgpu_bo_param bp;
int ret;
memset(, 0, sizeof(bp));
- bp.size = attach->dmabuf->size;
+ bp.size = dma_buf->size;
bp.byte_align = PAGE_SIZE;
bp.domain = AMDGPU_GEM_DOMAIN_CPU;
bp.flags = 0;
@@ -459,11 +456,9 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
if (ret)
goto error;
- bo->tbo.sg = sg;
- bo->tbo.ttm->sg = sg;
bo->allowed_domains = AMDGPU_GEM_DOMAIN_GTT;
bo->preferred_domains = AMDGPU_GEM_DOMAIN_GTT;
- if (attach->dmabuf->ops != _dmabuf_ops)
+ if (dma_buf->ops != _dmabuf_ops)
bo->prime_shared_count = 1;
ww_mutex_unlock(>lock);
@@ -474,6 +469,35 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
}
+/**
+ * amdgpu_gem_prime_invalidate_mappings - implementation
+ *
+ * @attach: the DMA-buf attachment
+ *
+ * Invalidate the DMA-buf attachment, making sure that the we re-create the
+ * mapping before the next use.
+ */
+static void
+amdgpu_gem_prime_invalidate_mappings(struct dma_buf_attachment *attach)
+{
+ struct ttm_operation_ctx ctx = { false, false };
+ struct drm_gem_object *obj = attach->importer_priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct ttm_placement placement = {};
+ int r;
+
+ if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
+ return;
+
+ r = ttm_bo_validate(>tbo, , );
+ if (r)
+ DRM_ERROR("Failed to invalidate DMA-buf import (%d))\n", r);
+}
+
+static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = {
+ .invalidate = amdgpu_gem_prime_invalidate_mappings
+};
+
/**
* amdgpu_gem_prime_import - _driver.gem_prime_import implementation
* @dev: DRM device
@@ -488,6 +512,7 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
{
+ struct dma_buf_attachment *attach;
struct drm_gem_object *obj;
if (dma_buf->ops == _dmabuf_ops) {
@@ -502,5 +527,18 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct
drm_device *dev,
}
}
- return drm_gem_prime_import(dev, dma_buf);
+ obj = amdgpu_dma_buf_create_obj(dev, dma_buf);
+ if (IS_ERR(obj))
+ return obj;
+
+ attach = dma_buf_dynamic_attach(dma_buf, dev->dev,
+ _dma_buf_attach_ops, obj);
+ if (IS_ERR(attach)) {
+ drm_gem_object_put(obj);
+ return
[Intel-gfx] [PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs
Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index dc63707e426f..0da512341194 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -414,7 +415,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
/* Don't move this buffer if we have depleted our allowance
* to move it. Don't move anything if the threshold is zero.
*/
- if (p->bytes_moved < p->bytes_moved_threshold) {
+ if (p->bytes_moved < p->bytes_moved_threshold &&
+ (!bo->gem_base.dma_buf ||
+ list_empty(>gem_base.dma_buf->attachments))) {
if (!amdgpu_gmc_vram_full_visible(>gmc) &&
(bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
/* And don't move a CPU_ACCESS_REQUIRED BO to limited
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v11
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.
On the importer side we add an optional invalidate callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
v11: drop automatically re-entry avoidance
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 179 --
include/linux/dma-buf.h | 109 +--
2 files changed, 274 insertions(+), 14 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 6c15deb5d4ad..ee09f18d3a2f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -531,6 +531,9 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
+ if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
+ return ERR_PTR(-EINVAL);
+
if (!try_module_get(exp_info->owner))
return ERR_PTR(-ENOENT);
@@ -651,10 +654,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
EXPORT_SYMBOL_GPL(dma_buf_put);
/**
- * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
+ * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list;
optionally,
* calls attach() of dma_buf_ops to allow device-specific attach functionality
- * @dmabuf:[in]buffer to attach device to.
- * @dev: [in]device to be attached.
+ * @dmabuf:[in]buffer to attach device to.
+ * @dev: [in]device to be attached.
+ * @importer_ops [in]importer operations for the attachment
+ * @importer_priv [in]importer private pointer for the attachment
*
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
* must be cleaned up by calling dma_buf_detach().
@@ -668,8 +673,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* accessible to @dev, and cannot be moved to a more suitable place. This is
* indicated with the error code -EBUSY.
*/
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
+struct dma_buf_attachment *
+dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
+ const struct dma_buf_attach_ops *importer_ops,
+ void *importer_priv)
{
struct dma_buf_attachment *attach;
int ret;
@@ -683,6 +690,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
attach->dev = dev;
attach->dmabuf = dmabuf;
+ attach->importer_ops = importer_ops;
+ attach->importer_priv = importer_priv;
mutex_lock(>lock);
@@ -691,16 +700,72 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
if (ret)
goto err_attach;
}
+ reservation_object_lock(dmabuf->resv, NULL);
list_add(>node, >attachments);
+ reservation_object_unlock(dmabuf->resv);
mutex_unlock(>lock);
+ /* When either the importer or the exporter can't handle dynamic
+* mappings we cache the mapping here to avoid issues with the
+* reservation object lock.
+*/
+ if (dma_buf_attachment_is_dynamic(attach) !=
+ dma_buf_is_dynamic(dmabuf)) {
+ struct sg_table *sgt;
+
+ if (dma_buf_is_dynamic(attach->dmabuf)) {
+ reservation_object_lock(attach->dmabuf->resv, NULL);
+ ret = dma_buf_pin(attach);
+ if (ret)
+ goto err_unlock;
+ }
+
+ sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
+ if (!sgt)
+ sgt = ERR_PTR(-ENOMEM);
+ if (IS_ERR(sgt)) {
+ ret = PTR_ERR(sgt);
+ goto err_unpin;
+ }
+ if (dma_buf_is_dynamic(attach->dmabuf))
+
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
Am 24.06.19 um 13:23 schrieb Koenig, Christian: Am 21.06.19 um 18:27 schrieb Daniel Vetter: So I pondered a few ideas while working out: 1) We drop this filtering. Importer needs to keep track of all its mappings and filter out invalidates that aren't for that specific importer (either because already invalidated, or not yet mapped, or whatever). Feels fragile. [SNIP] [SNIP] I will take a moment and look into #1 as well, but I still don't see the need to change anything. That turned out much cleaner than I thought it would be. Essentially it is only a single extra line of code in amdgpu. Going to send that out as a patch set in a minute. Christian. Christian. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/4] drm/connector: Split out orientation quirk detection
On Fri, Jun 21, 2019 at 08:41:04PM -0700, Derek Basehore wrote:
> Not every platform needs quirk detection for panel orientation, so
> split the drm_connector_init_panel_orientation_property into two
> functions. One for platforms without the need for quirks, and the
> other for platforms that need quirks.
>
> Signed-off-by: Derek Basehore
> ---
> drivers/gpu/drm/drm_connector.c | 45 -
> drivers/gpu/drm/i915/intel_dp.c | 4 +--
> drivers/gpu/drm/i915/vlv_dsi.c | 5 ++--
> include/drm/drm_connector.h | 2 ++
> 4 files changed, 39 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index e17586aaa80f..c4b01adf927a 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1894,31 +1894,23 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> * drm_connector_init_panel_orientation_property -
> * initialize the connecters panel_orientation property
> * @connector: connector for which to init the panel-orientation property.
> - * @width: width in pixels of the panel, used for panel quirk detection
> - * @height: height in pixels of the panel, used for panel quirk detection
> *
> * This function should only be called for built-in panels, after setting
> * connector->display_info.panel_orientation first (if known).
> *
> - * This function will check for platform specific (e.g. DMI based) quirks
> - * overriding display_info.panel_orientation first, then if panel_orientation
> - * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
> - * "panel orientation" property to the connector.
> + * This function will check if the panel_orientation is not
> + * DRM_MODE_PANEL_ORIENTATION_UNKNOWN. If not, it will attach the "panel
> + * orientation" property to the connector.
> *
> * Returns:
> * Zero on success, negative errno on failure.
> */
> int drm_connector_init_panel_orientation_property(
> - struct drm_connector *connector, int width, int height)
> + struct drm_connector *connector)
> {
> struct drm_device *dev = connector->dev;
> struct drm_display_info *info = >display_info;
> struct drm_property *prop;
> - int orientation_quirk;
> -
> - orientation_quirk = drm_get_panel_orientation_quirk(width, height);
> - if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
> - info->panel_orientation = orientation_quirk;
>
> if (info->panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
> return 0;
> @@ -1941,6 +1933,35 @@ int drm_connector_init_panel_orientation_property(
> }
> EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
>
> +/**
> + * drm_connector_init_panel_orientation_property_quirk -
> + * initialize the connecters panel_orientation property with a quirk
> + * override
> + * @connector: connector for which to init the panel-orientation property.
> + * @width: width in pixels of the panel, used for panel quirk detection
> + * @height: height in pixels of the panel, used for panel quirk detection
> + *
> + * This function will check for platform specific (e.g. DMI based) quirks
> + * overriding display_info.panel_orientation first, then if panel_orientation
> + * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
> + * "panel orientation" property to the connector.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_init_panel_orientation_property_quirk(
> + struct drm_connector *connector, int width, int height)
> +{
> + int orientation_quirk;
> +
> + orientation_quirk = drm_get_panel_orientation_quirk(width, height);
> + if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
> + connector->display_info.panel_orientation = orientation_quirk;
> +
> + return drm_connector_init_panel_orientation_property(connector);
> +}
> +EXPORT_SYMBOL(drm_connector_init_panel_orientation_property_quirk);
> +
> int drm_connector_set_obj_prop(struct drm_mode_object *obj,
> struct drm_property *property,
> uint64_t value)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b099a9dc28fd..7d4e61cf5463 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -7282,8 +7282,8 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> intel_panel_setup_backlight(connector, pipe);
>
> if (fixed_mode)
> - drm_connector_init_panel_orientation_property(
> - connector, fixed_mode->hdisplay, fixed_mode->vdisplay);
> + drm_connector_init_panel_orientation_property_quirk(connector,
> + fixed_mode->hdisplay, fixed_mode->vdisplay);
>
> return true;
>
> diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
>
[Intel-gfx] [PATCH 3/3] drm/i915/execlists: Convert recursive defer_request() into iterative
As this engine owns the lock around rq->sched.link (for those waiters
submitted to this engine), we can use that link as an element in a local
list. We can thus replace the recursive algorithm with an iterative walk
over the ordered list of waiters.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 52 +++--
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index c2aaab4b743e..17b178dba7c0 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -827,10 +827,9 @@ last_active(const struct intel_engine_execlists *execlists)
return *last;
}
-static void
-defer_request(struct i915_request * const rq, struct list_head * const pl)
+static void defer_request(struct i915_request *rq, struct list_head * const pl)
{
- struct i915_dependency *p;
+ LIST_HEAD(list);
/*
* We want to move the interrupted request to the back of
@@ -839,34 +838,37 @@ defer_request(struct i915_request * const rq, struct
list_head * const pl)
* flight and were waiting for the interrupted request to
* be run after it again.
*/
- list_move_tail(>sched.link, pl);
+ do {
+ struct i915_dependency *p;
- list_for_each_entry(p, >sched.waiters_list, wait_link) {
- struct i915_request *w =
- container_of(p->waiter, typeof(*w), sched);
+ GEM_BUG_ON(i915_request_is_active(rq));
+ list_move_tail(>sched.link, pl);
- /* Leave semaphores spinning on the other engines */
- if (w->engine != rq->engine)
- continue;
+ list_for_each_entry(p, >sched.waiters_list, wait_link) {
+ struct i915_request *w =
+ container_of(p->waiter, typeof(*w), sched);
- /* No waiter should start before the active request completed */
- GEM_BUG_ON(i915_request_started(w));
+ /* Leave semaphores spinning on the other engines */
+ if (w->engine != rq->engine)
+ continue;
- GEM_BUG_ON(rq_prio(w) > rq_prio(rq));
- if (rq_prio(w) < rq_prio(rq))
- continue;
+ /* No waiter should start before its signaler */
+ GEM_BUG_ON(i915_request_started(w) &&
+ !i915_request_completed(rq));
- if (list_empty(>sched.link))
- continue; /* Not yet submitted; unready */
+ GEM_BUG_ON(i915_request_is_active(w));
+ if (list_empty(>sched.link))
+ continue; /* Not yet submitted; unready */
- /*
-* This should be very shallow as it is limited by the
-* number of requests that can fit in a ring (<64) and
-* the number of contexts that can be in flight on this
-* engine.
-*/
- defer_request(w, pl);
- }
+ if (rq_prio(w) < rq_prio(rq))
+ continue;
+
+ GEM_BUG_ON(rq_prio(w) > rq_prio(rq));
+ list_move_tail(>sched.link, );
+ }
+
+ rq = list_first_entry_or_null(, typeof(*rq), sched.link);
+ } while (rq);
}
static void defer_active(struct intel_engine_cs *engine)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Emit final breadcrumb in request_add
With everything now known at the point of adding the request to the context's timeline, we can move the emission of the final breadcrumb to the request add and pull it out of the CS interrupt service handler. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 5ff87c4a0cd5..f45dd2c260d4 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -437,9 +437,6 @@ void __i915_request_submit(struct i915_request *request) spin_unlock(>lock); - engine->emit_fini_breadcrumb(request, -request->ring->vaddr + request->postfix); - engine->serial++; trace_i915_request_execute(request); @@ -1178,6 +1175,9 @@ struct i915_request *__i915_request_commit(struct i915_request *rq) GEM_BUG_ON(IS_ERR(cs)); rq->postfix = intel_ring_offset(rq, cs); + cs = engine->emit_fini_breadcrumb(rq, cs); + GEM_BUG_ON(rq->ring->vaddr + rq->ring->emit != cs); + prev = __i915_request_add_to_timeline(rq); list_add_tail(>ring_link, >request_list); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/execlists: Switch to using STOP_RING instead of a semaphore
Not all mediated environments yet support HW semaphores, so we should
avoid using one for our preempt-to-busy barrier and instead request that
the CS be paused and not advance on to the next execlist.
There's a natural advantage with the register writes being serialised
with the writes to the ELSP register that should allow the barrier to be
much more constrained. On the other hand, we can no longer track the
extents of the barrier and so must be a lot more lenient in accepting
early CS events.
Signed-off-by: Chris Wilson
Cc: Zhenyu Wang
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 8 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 69
2 files changed, 35 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 7e056114344e..1353df264236 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -166,6 +166,8 @@ struct intel_engine_execlists {
*/
bool no_priolist;
+ u16 ring_mode;
+
/**
* @submit_reg: gen-specific execlist submission register
* set to the ExecList Submission Port (elsp) register pre-Gen11 and to
@@ -179,6 +181,12 @@ struct intel_engine_execlists {
*/
u32 __iomem *ctrl_reg;
+ /**
+* @ring_mode: the engine control register, used to freeze the command
+* streamer around preempt-to-busy
+*/
+ u32 __iomem *ring_reg;
+
#define EXECLIST_MAX_PORTS 2
/**
* @active: the currently known context executing on HW
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 28685ba91a2c..c2aaab4b743e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -224,24 +224,18 @@ static void execlists_init_reg_state(u32 *reg_state,
struct intel_engine_cs *engine,
struct intel_ring *ring);
-static inline u32 intel_hws_preempt_address(struct intel_engine_cs *engine)
+static inline void ring_set_paused(struct intel_engine_cs *engine, u32 state)
{
- return (i915_ggtt_offset(engine->status_page.vma) +
- I915_GEM_HWS_PREEMPT_ADDR);
-}
+ u16 x;
-static inline void
-ring_set_paused(const struct intel_engine_cs *engine, int state)
-{
- /*
-* We inspect HWS_PREEMPT with a semaphore inside
-* engine->emit_fini_breadcrumb. If the dword is true,
-* the ring is paused as the semaphore will busywait
-* until the dword is false.
-*/
- engine->status_page.addr[I915_GEM_HWS_PREEMPT] = state;
- if (state)
- wmb();
+ x = engine->execlists.ring_mode;
+ x &= ~(state >> 16);
+ x |= state;
+ if (x == engine->execlists.ring_mode)
+ return;
+
+ engine->execlists.ring_mode = x;
+ writel(state, engine->execlists.ring_reg);
}
static inline struct i915_priolist *to_priolist(struct rb_node *rb)
@@ -981,7 +975,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* as we unwind (and until we resubmit) so that we do
* not accidentally tell it to go backwards.
*/
- ring_set_paused(engine, 1);
+ ring_set_paused(engine, _MASKED_BIT_ENABLE(STOP_RING));
/*
* Note that we have not stopped the GPU at this point,
@@ -1010,7 +1004,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
last->sched.attr.priority,
execlists->queue_priority_hint);
- ring_set_paused(engine, 1);
+ ring_set_paused(engine, _MASKED_BIT_ENABLE(STOP_RING));
defer_active(engine);
/*
@@ -1244,9 +1238,10 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
*port = execlists_schedule_in(last, port - execlists->pending);
memset(port + 1, 0, (last_port - port) * sizeof(*port));
execlists_submit_ports(engine);
- } else {
- ring_set_paused(engine, 0);
}
+
+ if (!inject_preempt_hang(execlists))
+ ring_set_paused(engine, _MASKED_BIT_DISABLE(STOP_RING));
}
void
@@ -1355,9 +1350,6 @@ static void process_csb(struct intel_engine_cs *engine)
if (enable_timeslice(engine))
mod_timer(>timer, jiffies + 1);
-
- if (!inject_preempt_hang(execlists))
- ring_set_paused(engine, 0);
} else if (status & GEN8_CTX_STATUS_PREEMPTED) {
struct i915_request * const *port = execlists->active;
@@ -1378,8
Re: [Intel-gfx] [PATCH 1/3] drm/i915/icl: Add new supported CD clocks
On Thu, Jun 20, 2019 at 11:33:27PM +, Souza, Jose wrote:
> On Wed, 2019-06-19 at 20:47 +0300, Ville Syrjälä wrote:
> > On Tue, Jun 18, 2019 at 03:50:33PM -0700, José Roberto de Souza
> > wrote:
> > > Now 180, 172.8 and 192 MHz are supported.
> > >
> > > 180 and 172.8 MHz CD clocks will only be used when audio is not
> > > enabled as state by BSpec and implemented in
> > > intel_crtc_compute_min_cdclk(), CD clock must be at least twice of
> > > Azalia BCLK and BCLK by default is 96 MHz, it could be set to 48
> > > MHz
> > > but we are not reading it.
> >
> > Do we know whether this thing still suffers from the glk/cnl issue
> > where
> > we can't even talk to the codec if cdclk is too low? If it does we
> > need
> > to adjust the platform check for the "force min cdclk for audio"
> > thing.
> > Also that is going to suck on icl due to the cd2x divider always
> > being
> > 1 and hence we can't do the optimized cdclk change around audio power
> > requests.
>
> Not sure how to test if we can talk to the codec when cdclock is too
> low(you mean lower than 192000khz(96MHz*2)?) but this workflow worked:
>
> 1- only full HD eDP panel connected | cdclock = 172800khz
> 2- connected a full HD DP monitor with audio | cdclock = 192000khz
> * audio works
> 3- disconnected full HD DP monitor | cdclock = 172800khz
> 4- connected again a full HD DP monitor with audio | cdclock =
> 192000khz
> * audio works
>
> Do you have any other test in mind?
Try to load/resume the audio driver when cdclk is low maybe?
>
> >
> > > BSpec: 20598
> > > BSpec: 15729
> > > Cc: Clint Taylor
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 29 +++---
> > >
> > > 1 file changed, 20 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index 8993ab283562..d560e25d3fb5 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -1756,9 +1756,10 @@ static void cnl_sanitize_cdclk(struct
> > > drm_i915_private *dev_priv)
> > >
> > > static int icl_calc_cdclk(int min_cdclk, unsigned int ref)
> > > {
> > > - int ranges_24[] = { 312000, 552000, 648000 };
> > > - int ranges_19_38[] = { 307200, 556800, 652800 };
> > > - int *ranges;
> > > + const int ranges_24[] = { 18, 192000, 312000, 552000,
> > > 648000 };
> > > + const int ranges_19_38[] = { 172800, 192000, 307200, 556800,
> > > 652800 };
> > > + const int *ranges;
> > > + unsigned int len, i;
> > >
> > > switch (ref) {
> > > default:
> > > @@ -1766,19 +1767,22 @@ static int icl_calc_cdclk(int min_cdclk,
> > > unsigned int ref)
> > > /* fall through */
> > > case 24000:
> > > ranges = ranges_24;
> > > + len = ARRAY_SIZE(ranges_24);
> > > break;
> > > case 19200:
> > > case 38400:
> > > ranges = ranges_19_38;
> > > + len = ARRAY_SIZE(ranges_19_38);
> > > break;
> > > }
> > >
> > > - if (min_cdclk > ranges[1])
> > > - return ranges[2];
> > > - else if (min_cdclk > ranges[0])
> > > - return ranges[1];
> > > - else
> > > - return ranges[0];
> > > + for (i = 0; i < len; i++) {
> > > + if (min_cdclk <= ranges[i])
> > > + return ranges[i];
> > > + }
> > > +
> > > + WARN_ON(min_cdclk > ranges[len - 1]);
> > > + return ranges[len - 1];
> > > }
> > >
> > > static int icl_calc_cdclk_pll_vco(struct drm_i915_private
> > > *dev_priv, int cdclk)
> > > @@ -1792,16 +1796,23 @@ static int icl_calc_cdclk_pll_vco(struct
> > > drm_i915_private *dev_priv, int cdclk)
> > > default:
> > > MISSING_CASE(cdclk);
> > > /* fall through */
> > > + case 172800:
> > > case 307200:
> > > case 556800:
> > > case 652800:
> > > WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
> > > dev_priv->cdclk.hw.ref != 38400);
> > > break;
> > > + case 18:
> > > case 312000:
> > > case 552000:
> > > case 648000:
> > > WARN_ON(dev_priv->cdclk.hw.ref != 24000);
> > > + break;
> > > + case 192000:
> > > + WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
> > > + dev_priv->cdclk.hw.ref != 38400 &&
> > > + dev_priv->cdclk.hw.ref != 24000);
> > > }
> > >
> > > ratio = cdclk / (dev_priv->cdclk.hw.ref / 2);
> > > --
> > > 2.22.0
> > >
> > > ___
> > > 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 1/2] drm: Pretty print mode flags
On Thu, Jun 20, 2019 at 10:25:42PM +0200, Sam Ravnborg wrote:
> Hi Ville.
>
> On Thu, Jun 20, 2019 at 09:50:48PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Decode the mode flags when printing the modeline so that I
> > no longer have to decode the hex number myself.
> You are extending the current way to print mode flags,
> but I would anyway like to point out a different approach.
>
> When I need to print a fourcc code it is as simple as:
>
> {
> struct drm_format_name_buf fbuf;
>
> printk("My format: %s\n", drm_get_format_name(format, );
> }
>
> This way to handle this feels more straightforward
> than the current approach used for modes.
>
> Maybe bikeshedding, as your mileage may vary.
You're suggesting to print the whole mode to a temp buffer, and then
print that with just %s? I thought about that, but it would waste
even more stack so didn't think it was all that great.
>
> A middle ground could be to introduce a struct for the buf so we know
> the callers do it right.
I'm not a fan of that struct approach because it forces you to use
a dedicated buffer for the thing. With just a raw char[] you can
print to anything, so it could be used more like strcat() as well.
Also I think it makes it more clear how much stack space you're
blowing away. And it looks a bit like snprintf() so it's more
clear what's happening on. Although in this case that last point
is kinda lost due to the macro thing.
>
> Most of the code would be the same, but all call sites would need to be
> updated.
> What do you think?
>
> Sam
>
>
> >
> > To do this neatly I made the caller provide a temporary
> > on stack buffer where we can produce the results. I choce 64
> > bytes as a reasonable size for this. The worst case I think
> > is > 100 bytes but that kind of mode would be nonsense anyway
> > so I figured correct decoding isn't as important in such
> > cases.
> >
> > Cc: Russell King
> > Cc: Neil Armstrong
> > Cc: Rob Clark
> > Cc: Tomi Valkeinen
> > Cc: Thierry Reding
> > Cc: Sam Ravnborg
> > Cc: Benjamin Gaignard
> > Cc: Vincent Abriou
> > Cc: linux-amlo...@lists.infradead.org
> > Cc: linux-arm-...@vger.kernel.org
> > Cc: freedr...@lists.freedesktop.org
> > Cc: Ilia Mirkin
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/armada/armada_crtc.c | 3 +-
> > drivers/gpu/drm/drm_atomic.c | 3 +-
> > drivers/gpu/drm/drm_modes.c | 116 +-
> > drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
> > drivers/gpu/drm/meson/meson_dw_hdmi.c | 3 +-
> > drivers/gpu/drm/meson/meson_venc.c| 4 +-
> > drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 3 +-
> > .../gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c | 3 +-
> > .../gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c | 3 +-
> > .../gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 3 +-
> > .../gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 4 +-
> > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 3 +-
> > drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 3 +-
> > drivers/gpu/drm/msm/dsi/dsi_manager.c | 3 +-
> > drivers/gpu/drm/msm/edp/edp_bridge.c | 3 +-
> > drivers/gpu/drm/omapdrm/omap_connector.c | 5 +-
> > drivers/gpu/drm/omapdrm/omap_crtc.c | 3 +-
> > drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 3 +-
> > drivers/gpu/drm/sti/sti_crtc.c| 3 +-
> > include/drm/drm_modes.h | 14 ++-
> > 20 files changed, 165 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/armada/armada_crtc.c
> > b/drivers/gpu/drm/armada/armada_crtc.c
> > index ba4a3fab7745..ce9335682bd2 100644
> > --- a/drivers/gpu/drm/armada/armada_crtc.c
> > +++ b/drivers/gpu/drm/armada/armada_crtc.c
> > @@ -262,6 +262,7 @@ static void armada_drm_crtc_mode_set_nofb(struct
> > drm_crtc *crtc)
> > unsigned long flags;
> > unsigned i;
> > bool interlaced = !!(adj->flags & DRM_MODE_FLAG_INTERLACE);
> > + char buf[DRM_MODE_FLAGS_BUF_LEN];
> >
> > i = 0;
> > rm = adj->crtc_hsync_start - adj->crtc_hdisplay;
> > @@ -270,7 +271,7 @@ static void armada_drm_crtc_mode_set_nofb(struct
> > drm_crtc *crtc)
> > tm = adj->crtc_vtotal - adj->crtc_vsync_end;
> >
> > DRM_DEBUG_KMS("[CRTC:%d:%s] mode " DRM_MODE_FMT "\n",
> > - crtc->base.id, crtc->name, DRM_MODE_ARG(adj));
> > + crtc->base.id, crtc->name, DRM_MODE_ARG(adj, buf));
> > DRM_DEBUG_KMS("lm %d rm %d tm %d bm %d\n", lm, rm, tm, bm);
> >
> > /* Now compute the divider for real */
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 419381abbdd1..81caf91fbd72 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -380,6 +380,7 @@ static void drm_atomic_crtc_print_state(struct
> > drm_printer *p,
> > const struct drm_crtc_state *state)
> > {
> > struct drm_crtc
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/19] drm/i915/execlists: Always clear ring_pause if we do not submit
Quoting Patchwork (2019-06-24 09:55:07) > Possible regressions > > * igt@gem_ctx_switch@basic-queue-heavy: > - shard-skl: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-skl4/igt@gem_ctx_swi...@basic-queue-heavy.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-skl6/igt@gem_ctx_swi...@basic-queue-heavy.html Fwiw, this smells like a use-after-free that does not appear before drm/i915: Protect request retirement with timeline->mutex My guess is that I dropped a reference and freed an active request, though I haven't yet found the hole. -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/execlists: Always clear ring_pause if we do not submit (rev2)
== Series Details == Series: drm/i915/execlists: Always clear ring_pause if we do not submit (rev2) URL : https://patchwork.freedesktop.org/series/62540/ State : success == Summary == CI Bug Log - changes from CI_DRM_6331_full -> Patchwork_13403_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13403_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@throttle: - shard-iclb: [PASS][1] -> [DMESG-WARN][2] ([fdo#110913 ]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-iclb5/igt@gem_...@throttle.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/shard-iclb3/igt@gem_...@throttle.html * igt@gem_partial_pwrite_pread@writes-after-reads-uncached: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 ]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-kbl1/igt@gem_partial_pwrite_pr...@writes-after-reads-uncached.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/shard-kbl1/igt@gem_partial_pwrite_pr...@writes-after-reads-uncached.html * igt@gem_persistent_relocs@forked-faulting-reloc-thrashing: - shard-snb: [PASS][5] -> [DMESG-WARN][6] ([fdo#110789] / [fdo#110913 ]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-snb4/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/shard-snb7/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html * igt@gem_persistent_relocs@forked-thrash-inactive: - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-glk5/igt@gem_persistent_rel...@forked-thrash-inactive.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/shard-glk1/igt@gem_persistent_rel...@forked-thrash-inactive.html * igt@gem_softpin@evict-active: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#110913 ]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-apl2/igt@gem_soft...@evict-active.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/shard-apl8/igt@gem_soft...@evict-active.html * igt@gem_tiled_partial_pwrite_pread@writes-after-reads: - shard-hsw: [PASS][11] -> [DMESG-WARN][12] ([fdo#110789] / [fdo#110913 ]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-hsw2/igt@gem_tiled_partial_pwrite_pr...@writes-after-reads.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/shard-hsw2/igt@gem_tiled_partial_pwrite_pr...@writes-after-reads.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([fdo#108566]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-apl1/igt@i915_susp...@debugfs-reader.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/shard-apl7/igt@i915_susp...@debugfs-reader.html * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#104108]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-skl8/igt@kms_fbcon_...@psr-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/shard-skl1/igt@kms_fbcon_...@psr-suspend.html * igt@kms_flip@2x-plain-flip-ts-check-interruptible: - shard-hsw: [PASS][17] -> [SKIP][18] ([fdo#109271]) +17 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-hsw5/igt@kms_f...@2x-plain-flip-ts-check-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/shard-hsw1/igt@kms_f...@2x-plain-flip-ts-check-interruptible.html * igt@kms_frontbuffer_tracking@fbc-modesetfrombusy: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-iclb3/igt@kms_frontbuffer_track...@fbc-modesetfrombusy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/shard-iclb2/igt@kms_frontbuffer_track...@fbc-modesetfrombusy.html * igt@kms_psr@psr2_cursor_blt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/shard-iclb3/igt@kms_psr@psr2_cursor_blt.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_6331/shard-apl6/igt@kms_setm...@basic.html [24]:
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
Am 21.06.19 um 18:27 schrieb Daniel Vetter: >>> Your scenario here is new, and iirc my suggestion back then was to >>> count the number of pending mappings so you don't go around calling >>> ->invalidate on mappings that don't exist. >> Well the key point is we don't call invalidate on mappings, but we call >> invalidate on attachments. >> >> When the invalidate on an attachment is received all the importer should at >> least start to tear down all mappings. > Hm, so either we invalidate mappings instead (pretty big change for > dma-buf, but maybe worth it). Or importers need to deal with invalidate on > stuff they're don't even have mapped anywhere anyway. I actually I don't see a problem with this, but see below. >> [SNIP] >>> - your scenario, where you call ->invalidate on an attachment which >>> doesn't have a mapping. I'll call that very lazy accounting, feels >>> like a bug :-) It's also very easy to fix by keeping track who >>> actually has a mapping, and then you fix it everywhere, not just for >>> the specific case of a recursion into the same caller. >> Yeah, exactly. Unfortunately it's not so easy to handle as just a counter. >> >> When somebody unmaps a mapping you need to know if that is already >> invalidated or not. And this requires tracking of each mapping. > Yeah we'd need to track mappings. Well, someone has to track mappings, and > atm it seems to be a mix of both importer and exporter (and dma-buf.c). Maybe I'm missing something, but I don't see the mix? Only the importer is responsible to tracking mappings, e.g. the importer calls dma_buf_map_attachment() when it needs a mapping and calls dma_buf_unmap_attachment() when it is done with the mapping. In between those two neither the exporter nor the DMA-buf cares about what mappings currently exist. And apart from debugging I actually don't see a reason why they should. >> [SNIP] >>> But I guess there's other fixes too possible. >>> >>> Either way none of this is about recursion, I think the recursive case >>> is simply the one where you've hit this already. Drivers will have to >>> handle all these additional ->invalidates no matter what with your >>> current proposal. After all the point here is that the exporter can >>> move the buffers around whenever it feels like, for whatever reasons. >> The recursion case is still perfectly valid. In the importer I need to >> ignore invalidations which are caused by creating a mapping. >> >> Otherwise it is perfectly possible that we invalidate a mapping because of >> its creation which will result in creating a new one >> >> So even if you fix up your mapping case, you absolutely still need this to >> prevent recursion :) > Hm, but if we stop tracking attachments and instead start tracking > mappings, then how is that possible: Yeah, but why should we do this? I don't see a benefit here. Importers just create/destroy mappings as they need them. > 1. importer has no mappings > 2. importer creates attachment. still no mapping > 3. importer calls dma_buf_attach_map_sg, still no mapping at this point > 4. we call into the exporter implementation. still no mapping > 5. exporter does whatever it does. still no mapping > 6. exporter finishes. conceptually from the dma-buf pov, _this_ is where > the mapping starts to exist. > 7. invalidates (hey the exporter maybe changed its mind!) are totally > fine, and will be serialized with ww_mutex. > > So I kinda don understand why the exporter here is allowed to call > invalidate too early (the mapping doesn't exist yet from dma-buf pov), and > dma-buf needs to filter it out. > > But anywhere else where we might call ->invalidate and there's not yet a > mapping (again purely from dma-buf pov), there the importer is supposed to > do the filter. Maybe this becomes clearer if we call the callback "moved" instead of "invalidated"? I mean this is actually all about the exporter informing the importer that the DMA-buf in question is moving to a new location. That we need to create a new mapping and destroy the old one at some point is an implementation detail on the importer. I mean the long term idea is to use this for notification that a buffer is moving inside the same driver as well. And in this particular case I actually don't think that we would create mappings at all. Thinking more about it this is actually a really good argument to favor the implementation as it is currently. > Someone needs to keep track of all this, and I want clear > responsibilities. What they are exactly is not that important. Clear responsibilities is indeed a good idea. >>> We could also combine the last two with some helpers, e.g. if your >>> exporter really expects importers to delay the unmap until it's no >>> longer in use, then we could do a small helper which puts all these >>> unmaps onto a list with a worker. But I think you want to integrate >>> that into your exporters lru management directly. >>> So this is just the most defensive thing
Re: [Intel-gfx] [PATCH v1 0/2] drm: drop uapi dependencies from include/drm
On Mon, 24 Jun 2019, Emil Velikov wrote: > On Mon, 24 Jun 2019 at 09:21, Daniel Vetter wrote: > >> > drm_legacy.h >> > - needs drm_map_type and drm_map_flags. Seems legit. >> >> enum in uapi, sweet (never do this, it's not portable across compilers, >> #defines all the way). > > Don't look too closely then > $ git grep enum -- include/uapi/drm/ | wc -l > 96 > > A handful of those are legacy stuff, yet quite a few are not :-\ Enums are just fine for *values* as long as they're not used as types in struct members or function parameters or return types, right? So we do have some we've screwed up, but it's not nearly as bad as the git grep above would lead you to believe. The ones in question are used in struct drm_map which is used in DRM_IOCTL_GET_MAP, DRM_IOCTL_ADD_MAP, and DRM_IOCTL_RM_MAP. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Disable preemption under GVT (rev5)
Quoting Chris Wilson (2019-06-24 11:37:06) > Quoting Patchwork (2019-06-24 11:30:47) > > == Series Details == > > > > Series: drm/i915/execlists: Disable preemption under GVT (rev5) > > URL : https://patchwork.freedesktop.org/series/62533/ > > State : failure > > > > == Summary == > > > > CI Bug Log - changes from CI_DRM_6331 -> Patchwork_13404 > > > > > > Summary > > --- > > > > **FAILURE** > > > > Serious unknown changes coming with Patchwork_13404 absolutely need to be > > verified manually. > > > > If you think the reported changes have nothing to do with the changes > > introduced in Patchwork_13404, please notify your bug team to allow them > > to document this new failure mode, which will reduce false positives in > > CI. > > > > External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/ > > > > Possible new issues > > --- > > > > Here are the unknown changes that may have been introduced in > > Patchwork_13404: > > > > ### IGT changes ### > > > > Possible regressions > > > > * igt@i915_selftest@live_execlists: > > - fi-kbl-7567u: [PASS][1] -> [INCOMPLETE][2] > >[1]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-kbl-7567u/igt@i915_selftest@live_execlists.html > >[2]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-kbl-7567u/igt@i915_selftest@live_execlists.html > > - fi-bsw-n3050: [PASS][3] -> [DMESG-FAIL][4] > >[3]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-bsw-n3050/igt@i915_selftest@live_execlists.html > >[4]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-bsw-n3050/igt@i915_selftest@live_execlists.html > > - fi-bsw-kefka: [PASS][5] -> [DMESG-FAIL][6] > >[5]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-bsw-kefka/igt@i915_selftest@live_execlists.html > >[6]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-bsw-kefka/igt@i915_selftest@live_execlists.html > > - fi-skl-6260u: [PASS][7] -> [INCOMPLETE][8] > >[7]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-6260u/igt@i915_selftest@live_execlists.html > >[8]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-skl-6260u/igt@i915_selftest@live_execlists.html > > - fi-skl-6770hq: [PASS][9] -> [INCOMPLETE][10] > >[9]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-6770hq/igt@i915_selftest@live_execlists.html > >[10]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-skl-6770hq/igt@i915_selftest@live_execlists.html > > - fi-bdw-5557u: [PASS][11] -> [DMESG-FAIL][12] > >[11]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-bdw-5557u/igt@i915_selftest@live_execlists.html > >[12]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-bdw-5557u/igt@i915_selftest@live_execlists.html > > - fi-skl-lmem:[PASS][13] -> [INCOMPLETE][14] > >[13]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-lmem/igt@i915_selftest@live_execlists.html > >[14]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-skl-lmem/igt@i915_selftest@live_execlists.html > > Sigh. Incompatible flags. However, given that we know have regular bdw complaining because preemption was disabled, we can conclude that bdwgvtdvm is not simply freezing because of the emit_preempt_busywait. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Disable preemption under GVT (rev5)
Quoting Patchwork (2019-06-24 11:30:47) > == Series Details == > > Series: drm/i915/execlists: Disable preemption under GVT (rev5) > URL : https://patchwork.freedesktop.org/series/62533/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_6331 -> Patchwork_13404 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_13404 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_13404, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/ > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_13404: > > ### IGT changes ### > > Possible regressions > > * igt@i915_selftest@live_execlists: > - fi-kbl-7567u: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-kbl-7567u/igt@i915_selftest@live_execlists.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-kbl-7567u/igt@i915_selftest@live_execlists.html > - fi-bsw-n3050: [PASS][3] -> [DMESG-FAIL][4] >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-bsw-n3050/igt@i915_selftest@live_execlists.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-bsw-n3050/igt@i915_selftest@live_execlists.html > - fi-bsw-kefka: [PASS][5] -> [DMESG-FAIL][6] >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-bsw-kefka/igt@i915_selftest@live_execlists.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-bsw-kefka/igt@i915_selftest@live_execlists.html > - fi-skl-6260u: [PASS][7] -> [INCOMPLETE][8] >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-6260u/igt@i915_selftest@live_execlists.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-skl-6260u/igt@i915_selftest@live_execlists.html > - fi-skl-6770hq: [PASS][9] -> [INCOMPLETE][10] >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-6770hq/igt@i915_selftest@live_execlists.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-skl-6770hq/igt@i915_selftest@live_execlists.html > - fi-bdw-5557u: [PASS][11] -> [DMESG-FAIL][12] >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-bdw-5557u/igt@i915_selftest@live_execlists.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-bdw-5557u/igt@i915_selftest@live_execlists.html > - fi-skl-lmem:[PASS][13] -> [INCOMPLETE][14] >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-lmem/igt@i915_selftest@live_execlists.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-skl-lmem/igt@i915_selftest@live_execlists.html Sigh. Incompatible flags. We want to keep preemption of busywaiting userspace semaphores. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Disable preemption under GVT (rev5)
== Series Details == Series: drm/i915/execlists: Disable preemption under GVT (rev5) URL : https://patchwork.freedesktop.org/series/62533/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6331 -> Patchwork_13404 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13404 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13404, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13404: ### IGT changes ### Possible regressions * igt@i915_selftest@live_execlists: - fi-kbl-7567u: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-kbl-7567u/igt@i915_selftest@live_execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-kbl-7567u/igt@i915_selftest@live_execlists.html - fi-bsw-n3050: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-bsw-n3050/igt@i915_selftest@live_execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-bsw-n3050/igt@i915_selftest@live_execlists.html - fi-bsw-kefka: [PASS][5] -> [DMESG-FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-bsw-kefka/igt@i915_selftest@live_execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-bsw-kefka/igt@i915_selftest@live_execlists.html - fi-skl-6260u: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-6260u/igt@i915_selftest@live_execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-skl-6260u/igt@i915_selftest@live_execlists.html - fi-skl-6770hq: [PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-6770hq/igt@i915_selftest@live_execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-skl-6770hq/igt@i915_selftest@live_execlists.html - fi-bdw-5557u: [PASS][11] -> [DMESG-FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-bdw-5557u/igt@i915_selftest@live_execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-bdw-5557u/igt@i915_selftest@live_execlists.html - fi-skl-lmem:[PASS][13] -> [INCOMPLETE][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-lmem/igt@i915_selftest@live_execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-skl-lmem/igt@i915_selftest@live_execlists.html Known issues Here are the changes found in Patchwork_13404 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-icl-dsi: [PASS][15] -> [INCOMPLETE][16] ([fdo#107713]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-icl-dsi/igt@i915_module_l...@reload.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-icl-dsi/igt@i915_module_l...@reload.html * igt@i915_selftest@live_blt: - fi-skl-iommu: [PASS][17] -> [INCOMPLETE][18] ([fdo#108602]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-iommu/igt@i915_selftest@live_blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-skl-iommu/igt@i915_selftest@live_blt.html * igt@i915_selftest@live_execlists: - fi-icl-u2: [PASS][19] -> [INCOMPLETE][20] ([fdo#107713]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-icl-u2/igt@i915_selftest@live_execlists.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-icl-u2/igt@i915_selftest@live_execlists.html - fi-icl-u3: [PASS][21] -> [INCOMPLETE][22] ([fdo#107713]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-icl-u3/igt@i915_selftest@live_execlists.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-icl-u3/igt@i915_selftest@live_execlists.html - fi-cfl-8109u: [PASS][23] -> [INCOMPLETE][24] ([fdo#110977]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-cfl-8109u/igt@i915_selftest@live_execlists.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13404/fi-cfl-8109u/igt@i915_selftest@live_execlists.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-skl-6700k2: [PASS][25] -> [INCOMPLETE][26] ([fdo#104108]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html [26]:
Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Always clear ring_pause if we do not submit
Chris Wilson writes:
> In the unlikely case (thank you CI!), we may find ourselves wanting to
> issue a preemption but having no runnable requests left. In this case,
> we set the semaphore before computing the preemption and so must unset
> it before forgetting (or else we leave the machine busywaiting until the
> next request comes along and so likely hang).
>
> v2: Replace readback with only a wmb after asserting the semaphore
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 8017efb36f7b..a392186ca40b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -240,7 +240,8 @@ ring_set_paused(const struct intel_engine_cs *engine, int
> state)
>* until the dword is false.
>*/
> engine->status_page.addr[I915_GEM_HWS_PREEMPT] = state;
> - wmb();
> + if (state)
> + wmb();
> }
>
> static inline struct i915_priolist *to_priolist(struct rb_node *rb)
> @@ -1249,6 +1250,8 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> *port = execlists_schedule_in(last, port - execlists->pending);
> memset(port + 1, 0, (last_port - port) * sizeof(*port));
> execlists_submit_ports(engine);
> + } else {
> + ring_set_paused(engine, 0);
> }
> }
>
> --
> 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/19] drm/i915/execlists: Always clear ring_pause if we do not submit
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-06-24 10:03:48)
>> Chris Wilson writes:
>>
>> > In the unlikely case (thank you CI!), we may find ourselves wanting to
>> > issue a preemption but having no runnable requests left. In this case,
>> > we set the semaphore before computing the preemption and so must unset
>> > it before forgetting (or else we leave the machine busywaiting until the
>> > next request comes along and so likely hang).
>> >
>> > Signed-off-by: Chris Wilson
>> > ---
>> > drivers/gpu/drm/i915/gt/intel_lrc.c | 9 -
>> > 1 file changed, 8 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
>> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
>> > index c8a0c9b32764..efccc31887de 100644
>> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
>> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
>> > @@ -233,13 +233,18 @@ static inline u32 intel_hws_preempt_address(struct
>> > intel_engine_cs *engine)
>> > static inline void
>> > ring_set_paused(const struct intel_engine_cs *engine, int state)
>> > {
>> > + u32 *sema = >status_page.addr[I915_GEM_HWS_PREEMPT];
>> > +
>> > + if (*sema == state)
>> > + return;
>> > +
>>
>> So you want to avoid useless wmb, as I don't see other
>> benefit. Makes this look suspiciously racy but seems
>> to be just my usual paranoia.
>
> Instead of the readback,
> if (state)
> wmb();
> would also work, if we ditch one half the paranoia. That's better.
Ok, as unpausing should not be so critical. So both forms
of paranoia is fine with me.
For wmb one can think of it as a paranoia or one can think it of as
documentation. Or both.
Reviewed-by: Mika Kuoppala
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1 0/2] drm: drop uapi dependencies from include/drm
On Mon, 24 Jun 2019 at 09:21, Daniel Vetter wrote: > > drm_legacy.h > > - needs drm_map_type and drm_map_flags. Seems legit. > > enum in uapi, sweet (never do this, it's not portable across compilers, > #defines all the way). Don't look too closely then $ git grep enum -- include/uapi/drm/ | wc -l 96 A handful of those are legacy stuff, yet quite a few are not :-\ HTH -Emil ___ 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/execlists: Always clear ring_pause if we do not submit (rev2)
== Series Details == Series: drm/i915/execlists: Always clear ring_pause if we do not submit (rev2) URL : https://patchwork.freedesktop.org/series/62540/ State : success == Summary == CI Bug Log - changes from CI_DRM_6331 -> Patchwork_13403 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/ Known issues Here are the changes found in Patchwork_13403 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_param@basic: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-icl-u3/igt@gem_ctx_pa...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/fi-icl-u3/igt@gem_ctx_pa...@basic.html * igt@i915_selftest@live_hangcheck: - fi-icl-u3: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#108569]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-icl-u3/igt@i915_selftest@live_hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/fi-icl-u3/igt@i915_selftest@live_hangcheck.html * igt@kms_chamelium@dp-crc-fast: - fi-cml-u2: [PASS][5] -> [FAIL][6] ([fdo#110387]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [PASS][7] -> [DMESG-WARN][8] ([fdo#102614]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@gem_mmap_gtt@basic-small-bo: - fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387 Participating hosts (48 -> 42) -- Additional (1): fi-pnv-d510 Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-bdw-samus fi-skl-6600u Build changes - * Linux: CI_DRM_6331 -> Patchwork_13403 CI_DRM_6331: a20afe5511160e9c1ea22b80b3be0226dfb0917a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5064: 22850c1906550fb97b405c019275dcfb34be8cf7 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13403: 975f9c471da025a3fe170094e7b09e9b82cfdbbc @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 975f9c471da0 drm/i915/execlists: Always clear ring_pause if we do not submit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13403/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915/execlists: Disable preemption under GVT
Preempt-to-busy uses a GPU semaphore to enforce an idle-barrier across
preemption, but mediated gvt does not fully support semaphores.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_lrc.c | 21 -
drivers/gpu/drm/i915/gt/selftest_lrc.c| 3 +++
3 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 4961f74fd902..d6fbc47727c1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -830,6 +830,8 @@ int intel_engine_init_common(struct intel_engine_cs *engine)
struct drm_i915_private *i915 = engine->i915;
int ret;
+ engine->set_default_submission(engine);
+
/* We may need to do things with the shrinker which
* require us to immediately switch back to the default
* context. This can cause a problem as pinning the
@@ -857,8 +859,6 @@ int intel_engine_init_common(struct intel_engine_cs *engine)
engine->emit_fini_breadcrumb_dw = ret;
- engine->set_default_submission(engine);
-
return 0;
err_unpin:
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index c8a0c9b32764..8017efb36f7b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -294,6 +294,9 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
{
int last_prio;
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
/*
* Check if the current priority hint merits a preemption attempt.
*
@@ -890,6 +893,9 @@ need_timeslice(struct intel_engine_cs *engine, const struct
i915_request *rq)
{
int hint;
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
if (list_is_last(>sched.link, >active.requests))
return false;
@@ -2600,7 +2606,8 @@ static u32 *gen8_emit_fini_breadcrumb(struct i915_request
*request, u32 *cs)
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
- cs = emit_preempt_busywait(request, cs);
+ if (intel_engine_has_preemption(request->engine))
+ cs = emit_preempt_busywait(request, cs);
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
@@ -2624,7 +2631,8 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct
i915_request *request, u32 *cs)
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
- cs = emit_preempt_busywait(request, cs);
+ if (intel_engine_has_preemption(request->engine))
+ cs = emit_preempt_busywait(request, cs);
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
@@ -2672,10 +2680,11 @@ void intel_execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->unpark = NULL;
engine->flags |= I915_ENGINE_SUPPORTS_STATS;
- if (!intel_vgpu_active(engine->i915))
+ if (!intel_vgpu_active(engine->i915)) {
engine->flags |= I915_ENGINE_HAS_SEMAPHORES;
- if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
- engine->flags |= I915_ENGINE_HAS_PREEMPTION;
+ if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
+ engine->flags |= I915_ENGINE_HAS_PREEMPTION;
+ }
}
static void execlists_destroy(struct intel_engine_cs *engine)
@@ -3463,6 +3472,8 @@ intel_execlists_create_virtual(struct i915_gem_context
*ctx,
ve->base.emit_fini_breadcrumb = sibling->emit_fini_breadcrumb;
ve->base.emit_fini_breadcrumb_dw =
sibling->emit_fini_breadcrumb_dw;
+
+ ve->base.flags = sibling->flags;
}
return >context;
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 0c97f953e908..b99b589a6c81 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -270,6 +270,9 @@ static int live_timeslice_preempt(void *arg)
enum intel_engine_id id;
for_each_engine(engine, i915, id) {
+ if (!intel_engine_has_preemption(engine))
+ continue;
+
memset(vaddr, 0, PAGE_SIZE);
err = slice_semaphore_queue(engine, vma, count);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915/execlists: Disable preemption under GVT
Preempt-to-busy uses a GPU semaphore to enforce an idle-barrier across
preemption, but mediated gvt does not fully support semaphores.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_lrc.c | 21 -
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 4961f74fd902..d6fbc47727c1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -830,6 +830,8 @@ int intel_engine_init_common(struct intel_engine_cs *engine)
struct drm_i915_private *i915 = engine->i915;
int ret;
+ engine->set_default_submission(engine);
+
/* We may need to do things with the shrinker which
* require us to immediately switch back to the default
* context. This can cause a problem as pinning the
@@ -857,8 +859,6 @@ int intel_engine_init_common(struct intel_engine_cs *engine)
engine->emit_fini_breadcrumb_dw = ret;
- engine->set_default_submission(engine);
-
return 0;
err_unpin:
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index c8a0c9b32764..8017efb36f7b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -294,6 +294,9 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
{
int last_prio;
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
/*
* Check if the current priority hint merits a preemption attempt.
*
@@ -890,6 +893,9 @@ need_timeslice(struct intel_engine_cs *engine, const struct
i915_request *rq)
{
int hint;
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
if (list_is_last(>sched.link, >active.requests))
return false;
@@ -2600,7 +2606,8 @@ static u32 *gen8_emit_fini_breadcrumb(struct i915_request
*request, u32 *cs)
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
- cs = emit_preempt_busywait(request, cs);
+ if (intel_engine_has_preemption(request->engine))
+ cs = emit_preempt_busywait(request, cs);
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
@@ -2624,7 +2631,8 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct
i915_request *request, u32 *cs)
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
- cs = emit_preempt_busywait(request, cs);
+ if (intel_engine_has_preemption(request->engine))
+ cs = emit_preempt_busywait(request, cs);
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
@@ -2672,10 +2680,11 @@ void intel_execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->unpark = NULL;
engine->flags |= I915_ENGINE_SUPPORTS_STATS;
- if (!intel_vgpu_active(engine->i915))
+ if (!intel_vgpu_active(engine->i915)) {
engine->flags |= I915_ENGINE_HAS_SEMAPHORES;
- if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
- engine->flags |= I915_ENGINE_HAS_PREEMPTION;
+ if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
+ engine->flags |= I915_ENGINE_HAS_PREEMPTION;
+ }
}
static void execlists_destroy(struct intel_engine_cs *engine)
@@ -3463,6 +3472,8 @@ intel_execlists_create_virtual(struct i915_gem_context
*ctx,
ve->base.emit_fini_breadcrumb = sibling->emit_fini_breadcrumb;
ve->base.emit_fini_breadcrumb_dw =
sibling->emit_fini_breadcrumb_dw;
+
+ ve->base.flags = sibling->flags;
}
return >context;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/execlists: Always clear ring_pause if we do not submit (rev2)
== Series Details == Series: drm/i915/execlists: Always clear ring_pause if we do not submit (rev2) URL : https://patchwork.freedesktop.org/series/62540/ State : warning == Summary == $ dim checkpatch origin/drm-tip 975f9c471da0 drm/i915/execlists: Always clear ring_pause if we do not submit -:28: WARNING:MEMORY_BARRIER: memory barrier without comment #28: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:244: + wmb(); total: 0 errors, 1 warnings, 0 checks, 17 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Disable preemption under GVT (rev3)
== Series Details == Series: drm/i915/execlists: Disable preemption under GVT (rev3) URL : https://patchwork.freedesktop.org/series/62533/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6331 -> Patchwork_13402 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13402 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13402, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13402: ### IGT changes ### Possible regressions * igt@gem_close_race@basic-process: - fi-bxt-j4205: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-bxt-j4205/igt@gem_close_r...@basic-process.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-bxt-j4205/igt@gem_close_r...@basic-process.html - fi-cml-u: [PASS][3] -> [FAIL][4] +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-cml-u/igt@gem_close_r...@basic-process.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-cml-u/igt@gem_close_r...@basic-process.html - fi-cfl-8109u: [PASS][5] -> [FAIL][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-cfl-8109u/igt@gem_close_r...@basic-process.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-cfl-8109u/igt@gem_close_r...@basic-process.html - fi-bxt-dsi: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-bxt-dsi/igt@gem_close_r...@basic-process.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-bxt-dsi/igt@gem_close_r...@basic-process.html * igt@gem_close_race@basic-threads: - fi-whl-u: [PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-whl-u/igt@gem_close_r...@basic-threads.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-whl-u/igt@gem_close_r...@basic-threads.html - fi-skl-guc: [PASS][11] -> [INCOMPLETE][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-guc/igt@gem_close_r...@basic-threads.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-skl-guc/igt@gem_close_r...@basic-threads.html - fi-kbl-7567u: [PASS][13] -> [INCOMPLETE][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-kbl-7567u/igt@gem_close_r...@basic-threads.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-kbl-7567u/igt@gem_close_r...@basic-threads.html - fi-skl-6260u: [PASS][15] -> [INCOMPLETE][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-6260u/igt@gem_close_r...@basic-threads.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-skl-6260u/igt@gem_close_r...@basic-threads.html - fi-skl-6770hq: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-6770hq/igt@gem_close_r...@basic-threads.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-skl-6770hq/igt@gem_close_r...@basic-threads.html - fi-cfl-guc: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-cfl-guc/igt@gem_close_r...@basic-threads.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-cfl-guc/igt@gem_close_r...@basic-threads.html - fi-skl-lmem:[PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-lmem/igt@gem_close_r...@basic-threads.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-skl-lmem/igt@gem_close_r...@basic-threads.html - fi-skl-6700k2: [PASS][23] -> [INCOMPLETE][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-6700k2/igt@gem_close_r...@basic-threads.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-skl-6700k2/igt@gem_close_r...@basic-threads.html - fi-cfl-8700k: [PASS][25] -> [INCOMPLETE][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-cfl-8700k/igt@gem_close_r...@basic-threads.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-cfl-8700k/igt@gem_close_r...@basic-threads.html * igt@gem_cpu_reloc@basic: - fi-kbl-7500u: [PASS][27] -> [WARN][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-kbl-7500u/igt@gem_cpu_re...@basic.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13402/fi-kbl-7500u/igt@gem_cpu_re...@basic.html *
[Intel-gfx] [PATCH v2] drm/i915/execlists: Always clear ring_pause if we do not submit
In the unlikely case (thank you CI!), we may find ourselves wanting to
issue a preemption but having no runnable requests left. In this case,
we set the semaphore before computing the preemption and so must unset
it before forgetting (or else we leave the machine busywaiting until the
next request comes along and so likely hang).
v2: Replace readback with only a wmb after asserting the semaphore
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 8017efb36f7b..a392186ca40b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -240,7 +240,8 @@ ring_set_paused(const struct intel_engine_cs *engine, int
state)
* until the dword is false.
*/
engine->status_page.addr[I915_GEM_HWS_PREEMPT] = state;
- wmb();
+ if (state)
+ wmb();
}
static inline struct i915_priolist *to_priolist(struct rb_node *rb)
@@ -1249,6 +1250,8 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
*port = execlists_schedule_in(last, port - execlists->pending);
memset(port + 1, 0, (last_port - port) * sizeof(*port));
execlists_submit_ports(engine);
+ } else {
+ ring_set_paused(engine, 0);
}
}
--
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/19] drm/i915/execlists: Always clear ring_pause if we do not submit
Quoting Mika Kuoppala (2019-06-24 10:03:48)
> Chris Wilson writes:
>
> > In the unlikely case (thank you CI!), we may find ourselves wanting to
> > issue a preemption but having no runnable requests left. In this case,
> > we set the semaphore before computing the preemption and so must unset
> > it before forgetting (or else we leave the machine busywaiting until the
> > next request comes along and so likely hang).
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index c8a0c9b32764..efccc31887de 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -233,13 +233,18 @@ static inline u32 intel_hws_preempt_address(struct
> > intel_engine_cs *engine)
> > static inline void
> > ring_set_paused(const struct intel_engine_cs *engine, int state)
> > {
> > + u32 *sema = >status_page.addr[I915_GEM_HWS_PREEMPT];
> > +
> > + if (*sema == state)
> > + return;
> > +
>
> So you want to avoid useless wmb, as I don't see other
> benefit. Makes this look suspiciously racy but seems
> to be just my usual paranoia.
Instead of the readback,
if (state)
wmb();
would also work, if we ditch one half the paranoia. That's better.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Disable preemption under GVT
Quoting Zhenyu Wang (2019-06-24 10:02:31) > On 2019.06.21 20:13:13 +0100, Chris Wilson wrote: > > Preempt-to-busy uses a GPU semaphore to enforce an idle-barrier across > > preemption, but mediated gvt does not fully support semaphores. > > > > Current looks semaphore is still used from emit_fini_breadcrumb which > caused gvt error, gvt may support memory based semaphore but not for > reg based. Already resent patch to avoid the emission as well, as I guessed that even using a no-op semaphore might be problematic :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/19] drm/i915/execlists: Always clear ring_pause if we do not submit
Quoting Mika Kuoppala (2019-06-24 10:03:48)
> Chris Wilson writes:
>
> > In the unlikely case (thank you CI!), we may find ourselves wanting to
> > issue a preemption but having no runnable requests left. In this case,
> > we set the semaphore before computing the preemption and so must unset
> > it before forgetting (or else we leave the machine busywaiting until the
> > next request comes along and so likely hang).
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index c8a0c9b32764..efccc31887de 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -233,13 +233,18 @@ static inline u32 intel_hws_preempt_address(struct
> > intel_engine_cs *engine)
> > static inline void
> > ring_set_paused(const struct intel_engine_cs *engine, int state)
> > {
> > + u32 *sema = >status_page.addr[I915_GEM_HWS_PREEMPT];
> > +
> > + if (*sema == state)
> > + return;
> > +
>
> So you want to avoid useless wmb, as I don't see other
> benefit. Makes this look suspiciously racy but seems
> to be just my usual paranoia.
It's always set under the execlists spinlock.
> > /*
> >* We inspect HWS_PREEMPT with a semaphore inside
> >* engine->emit_fini_breadcrumb. If the dword is true,
> >* the ring is paused as the semaphore will busywait
> >* until the dword is false.
> >*/
> > - engine->status_page.addr[I915_GEM_HWS_PREEMPT] = state;
> > + *sema = state;
> > wmb();
> > }
> >
> > @@ -1243,6 +1248,8 @@ static void execlists_dequeue(struct intel_engine_cs
> > *engine)
> > *port = execlists_schedule_in(last, port -
> > execlists->pending);
> > memset(port + 1, 0, (last_port - port) * sizeof(*port));
> > execlists_submit_ports(engine);
> > + } else {
> > + ring_set_paused(engine, 0);
>
> This looks like a right thing to do. But why did we end up
> figuring things out wrong in need_preempt()?
It's because we didn't find anything else that needed the preemption
after checking what came next in the queue -- it has already been
completed by earlier submission.
> One would think that if there were nothing to preempt into,
> we would never set the pause in the first place.
I hear you -- we try very hard to not even look for preemption.
False preemption cycles show up as bad scheduling behaviour for
saturated transcode jobs.
> Also the preempt to idle cycle mention in effective_prio()
> seems to be off. Could be that someone forgot to
> point that out when he did review preempt-to-busy.
Preempt-to-busy still has an effective idle point :-p
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Disable preemption under GVT
On 2019.06.21 20:13:13 +0100, Chris Wilson wrote:
> Preempt-to-busy uses a GPU semaphore to enforce an idle-barrier across
> preemption, but mediated gvt does not fully support semaphores.
>
Current looks semaphore is still used from emit_fini_breadcrumb which
caused gvt error, gvt may support memory based semaphore but not for
reg based.
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index c8a0c9b32764..d8649e759ce8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -294,6 +294,9 @@ static inline bool need_preempt(const struct
> intel_engine_cs *engine,
> {
> int last_prio;
>
> + if (!intel_engine_has_preemption(engine))
> + return false;
> +
> /*
>* Check if the current priority hint merits a preemption attempt.
>*
> @@ -890,6 +893,9 @@ need_timeslice(struct intel_engine_cs *engine, const
> struct i915_request *rq)
> {
> int hint;
>
> + if (!intel_engine_has_preemption(engine))
> + return false;
> +
> if (list_is_last(>sched.link, >active.requests))
> return false;
>
> @@ -2672,10 +2678,11 @@ void intel_execlists_set_default_submission(struct
> intel_engine_cs *engine)
> engine->unpark = NULL;
>
> engine->flags |= I915_ENGINE_SUPPORTS_STATS;
> - if (!intel_vgpu_active(engine->i915))
> + if (!intel_vgpu_active(engine->i915)) {
> engine->flags |= I915_ENGINE_HAS_SEMAPHORES;
> - if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
> - engine->flags |= I915_ENGINE_HAS_PREEMPTION;
> + if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
> + engine->flags |= I915_ENGINE_HAS_PREEMPTION;
> + }
> }
>
> static void execlists_destroy(struct intel_engine_cs *engine)
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/19] drm/i915/execlists: Always clear ring_pause if we do not submit
Chris Wilson writes:
> In the unlikely case (thank you CI!), we may find ourselves wanting to
> issue a preemption but having no runnable requests left. In this case,
> we set the semaphore before computing the preemption and so must unset
> it before forgetting (or else we leave the machine busywaiting until the
> next request comes along and so likely hang).
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index c8a0c9b32764..efccc31887de 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -233,13 +233,18 @@ static inline u32 intel_hws_preempt_address(struct
> intel_engine_cs *engine)
> static inline void
> ring_set_paused(const struct intel_engine_cs *engine, int state)
> {
> + u32 *sema = >status_page.addr[I915_GEM_HWS_PREEMPT];
> +
> + if (*sema == state)
> + return;
> +
So you want to avoid useless wmb, as I don't see other
benefit. Makes this look suspiciously racy but seems
to be just my usual paranoia.
> /*
>* We inspect HWS_PREEMPT with a semaphore inside
>* engine->emit_fini_breadcrumb. If the dword is true,
>* the ring is paused as the semaphore will busywait
>* until the dword is false.
>*/
> - engine->status_page.addr[I915_GEM_HWS_PREEMPT] = state;
> + *sema = state;
> wmb();
> }
>
> @@ -1243,6 +1248,8 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> *port = execlists_schedule_in(last, port - execlists->pending);
> memset(port + 1, 0, (last_port - port) * sizeof(*port));
> execlists_submit_ports(engine);
> + } else {
> + ring_set_paused(engine, 0);
This looks like a right thing to do. But why did we end up
figuring things out wrong in need_preempt()?
One would think that if there were nothing to preempt into,
we would never set the pause in the first place.
Also the preempt to idle cycle mention in effective_prio()
seems to be off. Could be that someone forgot to
point that out when he did review preempt-to-busy.
-Mika
> }
> }
>
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915/execlists: Disable preemption under GVT
Preempt-to-busy uses a GPU semaphore to enforce an idle-barrier across
preemption, but mediated gvt does not fully support semaphores.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index c8a0c9b32764..8017efb36f7b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -294,6 +294,9 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
{
int last_prio;
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
/*
* Check if the current priority hint merits a preemption attempt.
*
@@ -890,6 +893,9 @@ need_timeslice(struct intel_engine_cs *engine, const struct
i915_request *rq)
{
int hint;
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
if (list_is_last(>sched.link, >active.requests))
return false;
@@ -2600,7 +2606,8 @@ static u32 *gen8_emit_fini_breadcrumb(struct i915_request
*request, u32 *cs)
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
- cs = emit_preempt_busywait(request, cs);
+ if (intel_engine_has_preemption(request->engine))
+ cs = emit_preempt_busywait(request, cs);
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
@@ -2624,7 +2631,8 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct
i915_request *request, u32 *cs)
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
- cs = emit_preempt_busywait(request, cs);
+ if (intel_engine_has_preemption(request->engine))
+ cs = emit_preempt_busywait(request, cs);
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
@@ -2672,10 +2680,11 @@ void intel_execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->unpark = NULL;
engine->flags |= I915_ENGINE_SUPPORTS_STATS;
- if (!intel_vgpu_active(engine->i915))
+ if (!intel_vgpu_active(engine->i915)) {
engine->flags |= I915_ENGINE_HAS_SEMAPHORES;
- if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
- engine->flags |= I915_ENGINE_HAS_PREEMPTION;
+ if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
+ engine->flags |= I915_ENGINE_HAS_PREEMPTION;
+ }
}
static void execlists_destroy(struct intel_engine_cs *engine)
@@ -3463,6 +3472,8 @@ intel_execlists_create_virtual(struct i915_gem_context
*ctx,
ve->base.emit_fini_breadcrumb = sibling->emit_fini_breadcrumb;
ve->base.emit_fini_breadcrumb_dw =
sibling->emit_fini_breadcrumb_dw;
+
+ ve->base.flags = sibling->flags;
}
return >context;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/19] drm/i915/execlists: Always clear ring_pause if we do not submit
== Series Details == Series: series starting with [01/19] drm/i915/execlists: Always clear ring_pause if we do not submit URL : https://patchwork.freedesktop.org/series/62612/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6331_full -> Patchwork_13401_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13401_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13401_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13401_full: ### IGT changes ### Possible regressions * igt@gem_ctx_switch@basic-queue-heavy: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-skl4/igt@gem_ctx_swi...@basic-queue-heavy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-skl6/igt@gem_ctx_swi...@basic-queue-heavy.html * igt@gem_ctx_switch@basic-queue-light: - shard-iclb: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-iclb6/igt@gem_ctx_swi...@basic-queue-light.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-iclb5/igt@gem_ctx_swi...@basic-queue-light.html - shard-skl: [PASS][5] -> [TIMEOUT][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-skl9/igt@gem_ctx_swi...@basic-queue-light.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-skl2/igt@gem_ctx_swi...@basic-queue-light.html - shard-kbl: [PASS][7] -> [TIMEOUT][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-kbl3/igt@gem_ctx_swi...@basic-queue-light.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-kbl6/igt@gem_ctx_swi...@basic-queue-light.html - shard-apl: [PASS][9] -> [TIMEOUT][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-apl6/igt@gem_ctx_swi...@basic-queue-light.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-apl4/igt@gem_ctx_swi...@basic-queue-light.html * igt@gem_exec_parallel@bcs0-contexts: - shard-hsw: [PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-hsw4/igt@gem_exec_paral...@bcs0-contexts.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-hsw8/igt@gem_exec_paral...@bcs0-contexts.html Known issues Here are the changes found in Patchwork_13401_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_switch@basic-queue-heavy: - shard-glk: [PASS][13] -> [INCOMPLETE][14] ([fdo#103359] / [k.org#198133]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-glk6/igt@gem_ctx_swi...@basic-queue-heavy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-glk5/igt@gem_ctx_swi...@basic-queue-heavy.html - shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([fdo#107713]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-iclb7/igt@gem_ctx_swi...@basic-queue-heavy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-iclb6/igt@gem_ctx_swi...@basic-queue-heavy.html - shard-kbl: [PASS][17] -> [INCOMPLETE][18] ([fdo#103665]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-kbl1/igt@gem_ctx_swi...@basic-queue-heavy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-kbl4/igt@gem_ctx_swi...@basic-queue-heavy.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][19] -> [DMESG-WARN][20] ([fdo#108686]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-glk7/igt@gem_tiled_swapp...@non-threaded.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-glk3/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-iclb: [PASS][21] -> [INCOMPLETE][22] ([fdo#107713] / [fdo#108840]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-iclb7/igt@i915_pm_...@system-suspend-execbuf.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-iclb2/igt@i915_pm_...@system-suspend-execbuf.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([fdo#109507]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/shard-skl4/igt@kms_f...@flip-vs-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/shard-skl4/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip@flip-vs-suspend-interruptible:
Re: [Intel-gfx] [PATCH v1 0/2] drm: drop uapi dependencies from include/drm
On Sat, Jun 22, 2019 at 02:11:54PM +0200, Sam Ravnborg wrote: > include/drm/* shall have no or at least minimal dependencies > to include/uapi/drm/*. > Following two patches do a small effort to drop such dependencies. > > After these patches there are two users > of uapi/drm/drm.h left in include/drm: > > drm_file.h: > - needs drm_magic_t > drm_magic_t is a simple typedef, a simple unsigned int would do the trick I think we could switch over to unsigned int for this. > drm_legacy.h > - needs drm_map_type and drm_map_flags. Seems legit. enum in uapi, sweet (never do this, it's not portable across compilers, #defines all the way). But yeah seems legit, plus we don't care about drm_legacy.h > > I did not spend time to analyze further dependencies. > > Patches are build tested. > > Sam > > Sam Ravnborg (2): > drm: drop uapi dependency from drm_print.h > drm: drop uapi dependency from drm_vblank.h On both Reviewed-by: Daniel Vetter > > include/drm/drm_print.h | 4 +--- > include/drm/drm_vblank.h | 1 - > 2 files changed, 1 insertion(+), 4 deletions(-) > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/19] drm/i915/execlists: Always clear ring_pause if we do not submit
== Series Details == Series: series starting with [01/19] drm/i915/execlists: Always clear ring_pause if we do not submit URL : https://patchwork.freedesktop.org/series/62612/ State : success == Summary == CI Bug Log - changes from CI_DRM_6331 -> Patchwork_13401 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/ Known issues Here are the changes found in Patchwork_13401 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_param@basic: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-icl-u3/igt@gem_ctx_pa...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/fi-icl-u3/igt@gem_ctx_pa...@basic.html * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: [PASS][3] -> [FAIL][4] ([fdo#108511]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-skl-6770hq/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/fi-skl-6770hq/igt@i915_pm_...@module-reload.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#109485]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@gem_mmap_gtt@basic-small-bo: - fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6331/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 Participating hosts (48 -> 41) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-bdw-samus fi-skl-6600u Build changes - * Linux: CI_DRM_6331 -> Patchwork_13401 CI_DRM_6331: a20afe5511160e9c1ea22b80b3be0226dfb0917a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5064: 22850c1906550fb97b405c019275dcfb34be8cf7 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13401: 0b202e3b3bfb51ab4d06fb6e0837281a2dd5fec8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0b202e3b3bfb drm/i915: Replace struct_mutex for batch pool serialisation e32d77e3c6d1 drm/i915: Protect request retirement with timeline->mutex 7b4beefd667b drm/i915/gt: Drop stale commentary for timeline density 7e3b10829e7d drm/i915/gt: Always call kref_init for the timeline 0e23c4b14977 drm/i915/selftests: Hold ref on request across waits b99ea82088cd drm/i915/gt: Guard timeline pinning with its own mutex 5cc733c6a4bf drm/i915/gt: Convert timeline tracking to spinlock 04234a447a4d drm/i915/gt: Track timeline activeness in enter/exit c368b8ca78ee drm/i915: Teach execbuffer to take the engine wakeref not GT 98b27c39f6af drm/i915: Lift intel_engines_resume() to callers a44002018103 drm/i915: Only recover active engines e24b23a19ef7 drm/i915: Add a wakeref getter for iff the wakeref is already active 997c5179ea07 drm/i915: Rename intel_wakeref_[is]_active 967a4aec42b1 drm/i915/selftests: Fixup atomic reset checking 6adb57162c1b drm/i915/selftest: Drop manual request wakerefs around hangcheck 5a2731bd57c9 drm/i915/selftests: Serialise nop reset with retirement b87561f35a6f drm/i915/gt: Pass intel_gt to pm routines bee84a8f5dd3 drm/i915/execlists: Convert recursive defer_request() into an iteractive 64d75313cafc drm/i915/execlists: Always clear ring_pause if we do not submit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13401/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/19] drm/i915/execlists: Always clear ring_pause if we do not submit
== Series Details == Series: series starting with [01/19] drm/i915/execlists: Always clear ring_pause if we do not submit URL : https://patchwork.freedesktop.org/series/62612/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Always clear ring_pause if we do not submit Okay! Commit: drm/i915/execlists: Convert recursive defer_request() into an iteractive Okay! Commit: drm/i915/gt: Pass intel_gt to pm routines Okay! Commit: drm/i915/selftests: Serialise nop reset with retirement Okay! Commit: drm/i915/selftest: Drop manual request wakerefs around hangcheck Okay! Commit: drm/i915/selftests: Fixup atomic reset checking Okay! Commit: drm/i915: Rename intel_wakeref_[is]_active +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) Commit: drm/i915: Add a wakeref getter for iff the wakeref is already active Okay! Commit: drm/i915: Only recover active engines Okay! Commit: drm/i915: Lift intel_engines_resume() to callers Okay! Commit: drm/i915: Teach execbuffer to take the engine wakeref not GT Okay! Commit: drm/i915/gt: Track timeline activeness in enter/exit Okay! Commit: drm/i915/gt: Convert timeline tracking to spinlock Okay! Commit: drm/i915/gt: Guard timeline pinning with its own mutex Okay! Commit: drm/i915/selftests: Hold ref on request across waits Okay! Commit: drm/i915/gt: Always call kref_init for the timeline Okay! Commit: drm/i915/gt: Drop stale commentary for timeline density Okay! Commit: drm/i915: Protect request retirement with timeline->mutex Okay! Commit: drm/i915: Replace struct_mutex for batch pool serialisation +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 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 series starting with [01/19] drm/i915/execlists: Always clear ring_pause if we do not submit
== Series Details == Series: series starting with [01/19] drm/i915/execlists: Always clear ring_pause if we do not submit URL : https://patchwork.freedesktop.org/series/62612/ State : warning == Summary == $ dim checkpatch origin/drm-tip 64d75313cafc drm/i915/execlists: Always clear ring_pause if we do not submit bee84a8f5dd3 drm/i915/execlists: Convert recursive defer_request() into an iteractive b87561f35a6f drm/i915/gt: Pass intel_gt to pm routines 5a2731bd57c9 drm/i915/selftests: Serialise nop reset with retirement 6adb57162c1b drm/i915/selftest: Drop manual request wakerefs around hangcheck 967a4aec42b1 drm/i915/selftests: Fixup atomic reset checking 997c5179ea07 drm/i915: Rename intel_wakeref_[is]_active e24b23a19ef7 drm/i915: Add a wakeref getter for iff the wakeref is already active a44002018103 drm/i915: Only recover active engines 98b27c39f6af drm/i915: Lift intel_engines_resume() to callers -:215: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #215: FILE: drivers/gpu/drm/i915/i915_gem.c:1200: + BUG_ON(!i915->kernel_context); total: 0 errors, 1 warnings, 0 checks, 432 lines checked c368b8ca78ee drm/i915: Teach execbuffer to take the engine wakeref not GT 04234a447a4d drm/i915/gt: Track timeline activeness in enter/exit 5cc733c6a4bf drm/i915/gt: Convert timeline tracking to spinlock b99ea82088cd drm/i915/gt: Guard timeline pinning with its own mutex 0e23c4b14977 drm/i915/selftests: Hold ref on request across waits 7e3b10829e7d drm/i915/gt: Always call kref_init for the timeline 7b4beefd667b drm/i915/gt: Drop stale commentary for timeline density e32d77e3c6d1 drm/i915: Protect request retirement with timeline->mutex 0b202e3b3bfb drm/i915: Replace struct_mutex for batch pool serialisation -:304: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #304: new file mode 100644 -:309: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #309: FILE: drivers/gpu/drm/i915/gt/intel_engine_pool.c:1: +/* -:310: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #310: FILE: drivers/gpu/drm/i915/gt/intel_engine_pool.c:2: + * SPDX-License-Identifier: MIT -:479: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #479: FILE: drivers/gpu/drm/i915/gt/intel_engine_pool.h:1: +/* -:480: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #480: FILE: drivers/gpu/drm/i915/gt/intel_engine_pool.h:2: + * SPDX-License-Identifier: MIT -:519: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #519: FILE: drivers/gpu/drm/i915/gt/intel_engine_pool_types.h:1: +/* -:520: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #520: FILE: drivers/gpu/drm/i915/gt/intel_engine_pool_types.h:2: + * SPDX-License-Identifier: MIT -:536: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #536: FILE: drivers/gpu/drm/i915/gt/intel_engine_pool_types.h:18: + spinlock_t lock; total: 0 errors, 7 warnings, 1 checks, 593 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
