[Intel-gfx] [PATCH] drm/i915: Request driver probe from an async task
As we are careful not to register external interfaces before the
internals are brought up, we are not dependent upon a synchronous
probing and can allow ourselves to be probed from a secondary thread
during system bootup. We already do relegate some configuration to
asynchronous tasks (such as setting up the fbdev), now do the entire
probe.
References: https://bugs.freedesktop.org/show_bug.cgi?id=105622
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: David Weinehall
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 4364922e935d..be7b03d48229 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -726,6 +726,7 @@ static struct pci_driver i915_pci_driver = {
.probe = i915_pci_probe,
.remove = i915_pci_remove,
.driver.pm = &i915_pm_ops,
+ .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
};
static int __init i915_init(void)
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/guc: Fix null pointer dereference when GuC FW is not available
Michal, Can you send this with the enable_guc HAX patch to get a run in the CI with GuC. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
Hi,
Yunwei Zhang writes:
> WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
> read into Slice/Subslice specific registers, MCR packet control
> register(0xFDC) needs to be programmed to point to any enabled
> slice/subslice pair. Otherwise, incorrect value will be returned.
>
> However, that means each subsequent MMIO read will be forwarded to a
> specific slice/subslice combination as read is unicast. This is OK since
> slice/subslice specific register values are consistent in almost all cases
> across slice/subslice. There are rare occasions such as INSTDONE that this
> value will be dependent on slice/subslice combo, in such cases, we need to
> program 0xFDC and recover this after. This is already covered by
> read_subslice_reg for INSTDONE.
>
> Also, 0xFDC will lose its information after TDR/engine reset/power state
> change.
>
> v2:
> - use fls() instead of find_last_bit() (Chris)
> - added INTEL_SSEU to extract sseu from device info. (Chris)
> v3:
> - rebase on latest tip
>
Please add the relevant bspec id's and/or hsds
as a references into both patches.
For example see commit 86ebb015fa744dd1e265c9b45ade870ac859a4d5
-Mika
> Signed-off-by: Yunwei Zhang
> Cc: Oscar Mateo
> Cc: Michel Thierry
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1 +
> drivers/gpu/drm/i915/intel_engine_cs.c | 39
> --
> 2 files changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c9c3b2b..d902c50 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2296,6 +2296,7 @@ intel_info(const struct drm_i915_private *dev_priv)
>
> #define INTEL_GEN(dev_priv) ((dev_priv)->info.gen)
> #define INTEL_DEVID(dev_priv)((dev_priv)->info.device_id)
> +#define INTEL_SSEU(dev_priv) ((dev_priv)->info.sseu)
>
> #define REVID_FOREVER0xff
> #define INTEL_REVID(dev_priv)((dev_priv)->drm.pdev->revision)
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index de09fa4..cc19e0a 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct drm_i915_private
> *i915, int type)
> }
> }
>
> +static u32 calculate_mcr(u32 mcr, struct drm_i915_private *dev_priv)
> +{
> + const struct sseu_dev_info *sseu = &(INTEL_SSEU(dev_priv));
> + u32 slice = fls(sseu->slice_mask);
> + u32 subslice = fls(sseu->subslice_mask[slice]);
> +
> + mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
> + mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> +
> + return mcr;
> +}
> +
> +static void wa_init_mcr(struct drm_i915_private *dev_priv)
> +{
> + u32 mcr;
> +
> + mcr = I915_READ(GEN8_MCR_SELECTOR);
> + mcr = calculate_mcr(mcr, dev_priv);
> + I915_WRITE(GEN8_MCR_SELECTOR, mcr);
> +}
> +
> static inline uint32_t
> read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
> int subslice, i915_reg_t reg)
> @@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv,
> int slice,
> intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
>
> mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
> +
> /*
>* The HW expects the slice and sublice selectors to be reset to 0
>* after reading out the registers.
>*/
> - WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
> + if (INTEL_GEN(dev_priv) < 10)
> + WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
> mcr &= ~mcr_slice_subslice_mask;
> mcr |= mcr_slice_subslice_select;
> I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
>
> ret = I915_READ_FW(reg);
>
> - mcr &= ~mcr_slice_subslice_mask;
> + /*
> + * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
> + * expects mcr to be programed to a enabled slice/subslice pair
> + * before any MMIO read into slice/subslice register
> + */
> + if (INTEL_GEN(dev_priv) < 10)
> + mcr &= ~mcr_slice_subslice_mask;
> + else
> + mcr = calculate_mcr(mcr, dev_priv);
> +
> I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
>
> intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
> @@ -1307,6 +1339,9 @@ static int cnl_init_workarounds(struct intel_engine_cs
> *engine)
> struct drm_i915_private *dev_priv = engine->i915;
> int ret;
>
> + /* WaProgramMgsrForCorrectSliceSpecificMmioReads: cnl */
> + wa_init_mcr(dev_priv);
> +
> /* WaDisableI2mCycleOnWRPort:cnl (pre-prod) */
> if (IS_CNL_REVID(dev_priv, CNL_REVID_B0, CNL_REVID_B0))
> I915_WRITE(GAMT_CHKN_BIT_REG,
> --
> 2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedeskto
[Intel-gfx] [PATCH] drm/i915: Include submission tasklet state in engine dump
For the off-chance we have an interrupt posted and haven't processed the CSB. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_engine_cs.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index de09fa42a509..df17d3e519df 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -1859,12 +1859,14 @@ static void intel_engine_print_registers(const struct intel_engine_cs *engine, ptr = I915_READ(RING_CONTEXT_STATUS_PTR(engine)); read = GEN8_CSB_READ_PTR(ptr); write = GEN8_CSB_WRITE_PTR(ptr); - drm_printf(m, "\tExeclist CSB read %d [%d cached], write %d [%d from hws], interrupt posted? %s\n", + drm_printf(m, "\tExeclist CSB read %d [%d cached], write %d [%d from hws], interrupt posted? %s, tasklet queued? %s\n", read, execlists->csb_head, write, intel_read_status_page(engine, intel_hws_csb_write_index(engine->i915)), yesno(test_bit(ENGINE_IRQ_EXECLIST, - &engine->irq_posted))); + &engine->irq_posted)), + yesno(test_bit(TASKLET_STATE_SCHED, + &engine->execlists.tasklet.state))); if (read >= GEN8_CSB_ENTRIES) read = 0; if (write >= GEN8_CSB_ENTRIES) -- 2.16.2 ___ 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 series starting with [v2,3/3] HAX: Enable GuC for CI (rev4)
Quoting Patchwork (2018-03-22 21:52:05) > == Series Details == > > Series: series starting with [v2,3/3] HAX: Enable GuC for CI (rev4) > URL : https://patchwork.freedesktop.org/series/40516/ > State : failure > > == Summary == > > Applying: HAX: Enable GuC for CI > Applying: drm/i915/uc: Fetch uC firmware in init_early > error: Failed to merge in the changes. > Using index info to reconstruct a base tree... > M drivers/gpu/drm/i915/i915_drv.c > Falling back to patching base and 3-way merge... > Auto-merging drivers/gpu/drm/i915/i915_drv.c > CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.c > Patch failed at 0002 drm/i915/uc: Fetch uC firmware in init_early > The copy of the patch that failed is found in: .git/rebase-apply/patch > 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". Send it afresh, pw got confused by the reply with a different series length. -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: Request driver probe from an async task
== Series Details == Series: drm/i915: Request driver probe from an async task URL : https://patchwork.freedesktop.org/series/40547/ State : failure == Summary == Series 40547v1 drm/i915: Request driver probe from an async task https://patchwork.freedesktop.org/api/1.0/series/40547/revisions/1/mbox/ Possible new issues: Test gem_exec_flush: Subgroup basic-wb-pro-default: pass -> INCOMPLETE (fi-skl-6770hq) Test gvt_basic: Subgroup invalid-placeholder-test: skip -> INCOMPLETE (fi-cnl-y3) Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 pass -> DMESG-WARN (fi-cnl-y3) fdo#104951 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:436s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:446s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:532s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:299s fi-bxt-dsi total:243 pass:216 dwarn:0 dfail:0 fail:0 skip:26 fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:512s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:520s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:509s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:418s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:528s fi-cnl-y3total:285 pass:258 dwarn:1 dfail:0 fail:0 skip:25 fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:431s fi-gdg-551 total:285 pass:177 dwarn:0 dfail:0 fail:0 skip:108 time:319s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:425s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:477s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:429s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:479s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:474s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:513s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:653s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:542s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:509s fi-skl-6770hqtotal:58 pass:56 dwarn:0 dfail:0 fail:0 skip:1 fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:431s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:450s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:602s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:403s 9e3f06af248708774c765efd55bf8e883f24fbfd drm-tip: 2018y-03m-22d-21h-17m-42s UTC integration manifest 660ea53368eb drm/i915: Request driver probe from an async task == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8465/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Actually flush interrupts on reset not just wedging
Commit 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
reset") got confused and only applied the flush to the set-wedge path
(which itself is proving troublesome), but we also need the
serialisation on the regular reset path. Oops.
Move the interrupt into reset_irq() and make it common to the reset and
final set-wedge.
References: 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
Cc: Michał Winiarski
Cc: Jeff McGee
---
drivers/gpu/drm/i915/intel_lrc.c | 105 ---
1 file changed, 53 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ce09c5ad334f..2e53882b826b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -740,6 +740,57 @@ execlists_cancel_port_requests(struct
intel_engine_execlists * const execlists)
}
}
+static void clear_gtiir(struct intel_engine_cs *engine)
+{
+ static const u8 gtiir[] = {
+ [RCS] = 0,
+ [BCS] = 0,
+ [VCS] = 1,
+ [VCS2] = 1,
+ [VECS] = 3,
+ };
+ struct drm_i915_private *dev_priv = engine->i915;
+ int i;
+
+ /* TODO: correctly reset irqs for gen11 */
+ if (WARN_ON_ONCE(INTEL_GEN(engine->i915) >= 11))
+ return;
+
+ GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
+
+ /*
+* Clear any pending interrupt state.
+*
+* We do it twice out of paranoia that some of the IIR are
+* double buffered, and so if we only reset it once there may
+* still be an interrupt pending.
+*/
+ for (i = 0; i < 2; i++) {
+ I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
+ engine->irq_keep_mask);
+ POSTING_READ(GEN8_GT_IIR(gtiir[engine->id]));
+ }
+ GEM_BUG_ON(I915_READ(GEN8_GT_IIR(gtiir[engine->id])) &
+ engine->irq_keep_mask);
+}
+
+static void reset_irq(struct intel_engine_cs *engine)
+{
+ /* Mark all CS interrupts as complete */
+ smp_store_mb(engine->execlists.active, 0);
+ synchronize_hardirq(engine->i915->drm.irq);
+
+ clear_gtiir(engine);
+
+ /*
+* The port is checked prior to scheduling a tasklet, but
+* just in case we have suspended the tasklet to do the
+* wedging make sure that when it wakes, it decides there
+* is no work to do by clearing the irq_posted bit.
+*/
+ clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+}
+
static void execlists_cancel_requests(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -765,6 +816,8 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
*/
local_irq_save(flags);
+ reset_irq(engine);
+
/* Cancel the requests on the HW and clear the ELSP tracker. */
execlists_cancel_port_requests(execlists);
@@ -805,18 +858,6 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
spin_unlock(&engine->timeline->lock);
- /* Mark all CS interrupts as complete */
- smp_store_mb(execlists->active, 0);
- synchronize_hardirq(engine->i915->drm.irq);
-
- /*
-* The port is checked prior to scheduling a tasklet, but
-* just in case we have suspended the tasklet to do the
-* wedging make sure that when it wakes, it decides there
-* is no work to do by clearing the irq_posted bit.
-*/
- clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
-
local_irq_restore(flags);
}
@@ -1566,14 +1607,6 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
return ret;
}
-static u8 gtiir[] = {
- [RCS] = 0,
- [BCS] = 0,
- [VCS] = 1,
- [VCS2] = 1,
- [VECS] = 3,
-};
-
static void enable_execlists(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
@@ -1657,35 +1690,6 @@ static int gen9_init_render_ring(struct intel_engine_cs
*engine)
return init_workarounds_ring(engine);
}
-static void reset_irq(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
- int i;
-
- /* TODO: correctly reset irqs for gen11 */
- if (WARN_ON_ONCE(INTEL_GEN(engine->i915) >= 11))
- return;
-
- GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
-
- /*
-* Clear any pending interrupt state.
-*
-* We do it twice out of paranoia that some of the IIR are double
-* buffered, and if we only reset it once there may still be
-* an interrupt pending.
-*/
- for (i = 0; i < 2; i++) {
- I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
- engine->irq_keep_
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Include submission tasklet state in engine dump
== Series Details == Series: drm/i915: Include submission tasklet state in engine dump URL : https://patchwork.freedesktop.org/series/40548/ State : success == Summary == Series 40548v1 drm/i915: Include submission tasklet state in engine dump https://patchwork.freedesktop.org/api/1.0/series/40548/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> FAIL (fi-skl-guc) fdo#103191 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:436s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:442s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:377s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:535s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:515s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:513s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:521s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:508s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:413s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:514s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:590s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:318s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:538s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:421s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:474s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:429s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:479s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:466s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:516s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:652s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:444s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:532s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:509s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:501s fi-skl-guc total:285 pass:256 dwarn:0 dfail:0 fail:1 skip:28 time:425s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:560s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:411s 9e3f06af248708774c765efd55bf8e883f24fbfd drm-tip: 2018y-03m-22d-21h-17m-42s UTC integration manifest 82aeab5e84a9 drm/i915: Include submission tasklet state in engine dump == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8466/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/3] tests/gem_eio: Speed up test execution
On 22/03/2018 17:44, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-03-22 17:24:16)
From: Tvrtko Ursulin
If we stop relying on regular GPU hangs to be detected, but trigger them
manually as soon as we know our batch of interest is actually executing
on the GPU, we can dramatically speed up various subtests.
This is enabled by the pollable spin batch added in the previous patch.
v2:
* Test gem_wait after reset/wedge and with reset/wedge after a few
predefined intervals since gem_wait invocation. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Antonio Argenziano
---
lib.tar | Bin 0 -> 102400 bytes
tests/gem_eio.c | 214 ++--
2 files changed, 160 insertions(+), 54 deletions(-)
create mode 100644 lib.tar
diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 4bcc5937db39..2f9e954085ec 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
@@ -71,26 +72,23 @@ static void trigger_reset(int fd)
gem_quiescent_gpu(fd);
}
-static void wedge_gpu(int fd)
+static void manual_hang(int drm_fd)
{
- /* First idle the GPU then disable GPU resets before injecting a hang */
- gem_quiescent_gpu(fd);
-
- igt_require(i915_reset_control(false));
+ int dir = igt_debugfs_dir(drm_fd);
- igt_debug("Wedging GPU by injecting hang\n");
- igt_post_hang_ring(fd, igt_hang_ring(fd, I915_EXEC_DEFAULT));
+ igt_sysfs_set(dir, "i915_wedged", "-1");
- igt_assert(i915_reset_control(true));
+ close(dir);
}
-static void wedgeme(int drm_fd)
+static void wedge_gpu(int fd)
{
- int dir = igt_debugfs_dir(drm_fd);
-
- igt_sysfs_set(dir, "i915_wedged", "-1");
+ /* First idle the GPU then disable GPU resets before injecting a hang */
+ gem_quiescent_gpu(fd);
- close(dir);
+ igt_require(i915_reset_control(false));
+ manual_hang(fd);
+ igt_assert(i915_reset_control(true));
}
static int __gem_throttle(int fd)
@@ -149,26 +147,111 @@ static int __gem_wait(int fd, uint32_t handle, int64_t
timeout)
return err;
}
-static void test_wait(int fd)
+static igt_spin_t * __spin_poll(int fd, uint32_t ctx, unsigned long flags)
+{
+ if (gem_can_store_dword(fd, flags))
+ return __igt_spin_batch_new_poll(fd, ctx, flags);
+ else
+ return __igt_spin_batch_new(fd, ctx, flags, 0);
+}
+
+static void __spin_wait(int fd, igt_spin_t *spin)
+{
+ if (spin->running) {
+ igt_spin_busywait_until_running(spin);
+ } else {
+ igt_debug("__spin_wait - usleep mode\n");
+ usleep(500e3); /* Better than nothing! */
+ }
+}
+
+static igt_spin_t * spin_sync(int fd, uint32_t ctx, unsigned long flags)
+{
+ igt_spin_t *spin = __spin_poll(fd, ctx, flags);
+
+ __spin_wait(fd, spin);
+
+ return spin;
+}
+
+static int debugfs_dir = -1;
+
+static void hang_handler(int sig)
+{
+ igt_sysfs_set(debugfs_dir, "i915_wedged", "-1");
+}
+
+static void hang_after(int fd, unsigned int us)
+{
+struct sigaction sa = { .sa_handler = hang_handler };
+ struct itimerval itv = { };
+
+ debugfs_dir = igt_debugfs_dir(fd);
+ igt_assert_fd(debugfs_dir);
+
+ igt_assert_eq(sigaction(SIGALRM, &sa, NULL), 0);
+
+ itv.it_value.tv_sec = us / 100;
USEC_PER_SEC.
+ itv.it_value.tv_usec = us % 100;
+ setitimer(ITIMER_REAL, &itv, NULL);
Ok, that gives a single shot signal.
I would have used
struct sigevent sev = {
.sigev_notify = SIGEV_THREAD,
.sigev_value.sigval_int = debugfs_dir
.sigev_notify_function = hang_handler
};
timer_create(CLOCK_MONOTONIC, &sec, &timer);
timer_settime(timer, 0, &its, NULL);
Then
static void hang_handler(union sigval arg)
{
igt_sysfs_set(arg.sival_int, "i915_wedged", 1);
}
No signals, nor globals required :)
I wasn't familiar with this facility.
It creates a new thread, so any hopes for small microsecond delays might
be ruined. I can try it if you think it is still worth it?
The problem with using a signal is that it interrupts the gem_wait()
and so we don't actually check that it is being woken by the hang
because it is already awake. Gah.
Hm... if I am following correctly, we end up with -ERESTARTSYS and the
the ioctl can get restarted for us, if I would set SA_RESTART.
At the moment it happens to work because drmIoctl restart the signal.
+static void cleanup_hang(void)
+{
+ struct itimerval itv = { };
+
+ igt_assert_eq(setitimer(ITIMER_REAL, &itv, NULL), 0);
You also need a sleep here as it does not flush inflight signals.
(Also timer_destroy :)
I always pass a longer timeout to gem_wait than the signal so I think it
should be guaranteed that the signal had fired before gem_wait will be
exiting.
Regards,
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/3] tests/gem_eio: Speed up test execution
On 22/03/2018 18:14, Chris Wilson wrote: Quoting Antonio Argenziano (2018-03-22 17:32:46) On 22/03/18 05:42, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-03-22 12:36:58) On 22/03/2018 11:39, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-03-22 11:17:11) trigger_reset(fd); + + /* HACK for CI */ + igt_assert(igt_nsec_elapsed(&ts) < 5e9); igt_seconds_elapsed() the approximation is worth the readability. In this case you might like to try igt_set_timeout(), as I think each subtest and exithandlers are in place to make them robust against premature failures. Well this was just to see that will happen on the shards here. As mentioned in the commit I get that yet unexplained GPU hang at subtest exit here. So the assert above is just to notice if the same happens on shards. And I was thinking it was a reasonable enhancement :) Probably more so for igt/gem_wait itself to ask that if we reset the request we are waiting upon it completes in a timely manner. (We don't care about wedged handling there, just reset handling.) How about checking for reset when we do gem_test_engine(), which seems to not fail on reset, (crudely https://paste.debian.net/1016059/)? I was thinking that the timeout would be good around the test as a whole, because it is now meant to be uberfast. Whole subtests with igt_set_timeout, or alternatively I was thinking to just time the trigger_reset helper. Since other bits are covered by short timeout gem_wait now, I think tigger_reset is the only one which I need to additionally cover. If we stick with signals for delayed hangs, that also might be simpler than to find a different signal than SIGALARM for it (so it doesn't clash with igt_set_timeout). Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/3] tests/gem_eio: Speed up test execution
Quoting Tvrtko Ursulin (2018-03-23 09:46:49)
>
> On 22/03/2018 17:44, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-03-22 17:24:16)
> >> + itv.it_value.tv_usec = us % 100;
> >> + setitimer(ITIMER_REAL, &itv, NULL);
> >
> > Ok, that gives a single shot signal.
> >
> > I would have used
> > struct sigevent sev = {
> > .sigev_notify = SIGEV_THREAD,
> > .sigev_value.sigval_int = debugfs_dir
> > .sigev_notify_function = hang_handler
> > };
> > timer_create(CLOCK_MONOTONIC, &sec, &timer);
> > timer_settime(timer, 0, &its, NULL);
> >
> > Then
> >
> > static void hang_handler(union sigval arg)
> > {
> > igt_sysfs_set(arg.sival_int, "i915_wedged", 1);
> > }
> >
> > No signals, nor globals required :)
>
> I wasn't familiar with this facility.
>
> It creates a new thread, so any hopes for small microsecond delays might
> be ruined. I can try it if you think it is still worth it?
Yes, still worth a shot. We can always poke glibc for some smarts. Or
chase it ourselves with custom threading. We need an igt_debug() to
actually tell us how long it took to respond (from spin start to
gem_wait return).
> > The problem with using a signal is that it interrupts the gem_wait()
> > and so we don't actually check that it is being woken by the hang
> > because it is already awake. Gah.
>
> Hm... if I am following correctly, we end up with -ERESTARTSYS and the
> the ioctl can get restarted for us, if I would set SA_RESTART.
>
> At the moment it happens to work because drmIoctl restart the signal.
Yes. But even automatic -ERESTARTSYS handling still implies we break
i915_request_wait() due to signal_pending_state().
> >> +static void cleanup_hang(void)
> >> +{
> >> + struct itimerval itv = { };
> >> +
> >> + igt_assert_eq(setitimer(ITIMER_REAL, &itv, NULL), 0);
> >
> > You also need a sleep here as it does not flush inflight signals.
> > (Also timer_destroy :)
>
> I always pass a longer timeout to gem_wait than the signal so I think it
> should be guaranteed that the signal had fired before gem_wait will be
> exiting.
I hadn't considered that. Please leave a comment as the timer
cancellation leaving pending signals inflight is something that keeps
catching me out.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Actually flush interrupts on reset not just wedging
== Series Details ==
Series: drm/i915: Actually flush interrupts on reset not just wedging
URL : https://patchwork.freedesktop.org/series/40550/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cac6dd787287 drm/i915: Actually flush interrupts on reset not just wedging
-:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#17:
References: 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
reset")
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 0f36a85c3bd5 ("drm/i915: Flush
pending interrupt following a GPU reset")'
#17:
References: 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
reset")
total: 1 errors, 1 warnings, 0 checks, 141 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Avoid setting ring freq on invalid rps freqs
Chris Wilson writes: > Quoting Mika Kuoppala (2018-03-20 15:17:33) >> Looping through rps frequencies when both min and max are zero >> ends up into an endless loop. This can happen during hardware >> enablement. >> >> Bail out early if rps frequencies are not correctly set yet. >> >> Cc: Chris Wilson >> Signed-off-by: Mika Kuoppala > Reviewed-by: Chris Wilson Pushed. Thanks for review. -Mika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/5] tests/perf_pmu: Add tests for engine queued/runnable/running stats
On 19/03/2018 20:58, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-03-19 18:22:04)
From: Tvrtko Ursulin
Simple tests to check reported queue depths are correct.
Signed-off-by: Tvrtko Ursulin
---
tests/perf_pmu.c | 224 +++
1 file changed, 224 insertions(+)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 469b9becdbac..206c18960b7b 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -966,6 +966,196 @@ multi_client(int gem_fd, const struct
intel_execution_engine2 *e)
assert_within_epsilon(val[1], perf_slept[1], tolerance);
}
+static double calc_queued(uint64_t d_val, uint64_t d_ns)
+{
+ return (double)d_val * 1e9 / I915_SAMPLE_QUEUED_DIVISOR / d_ns;
+}
+
+static void
+queued(int gem_fd, const struct intel_execution_engine2 *e)
+{
+ const unsigned long engine = e2ring(gem_fd, e);
+ const unsigned int max_rq = 10;
+ double queued[max_rq + 1];
+ uint32_t bo[max_rq + 1];
+ unsigned int n, i;
+ uint64_t val[2];
+ uint64_t ts[2];
+ int fd;
igt_require_sw_sync();
I guess we should do igt_require_cork(CORK_SYNC_FD) or something like
that.
+
+ memset(queued, 0, sizeof(queued));
+ memset(bo, 0, sizeof(bo));
+
+ fd = open_pmu(I915_PMU_ENGINE_QUEUED(e->class, e->instance));
+
+ for (n = 0; n <= max_rq; n++) {
+ int fence = -1;
+ struct igt_cork cork = { .fd = fence, .type = CORK_SYNC_FD };
IGT_CORK_FENCE(cork); if you prefer
Missed it.
+
+ gem_quiescent_gpu(gem_fd);
+
+ if (n)
+ fence = igt_cork_plug(&cork, -1);
+
+ for (i = 0; i < n; i++) {
+ struct drm_i915_gem_exec_object2 obj = { };
+ struct drm_i915_gem_execbuffer2 eb = { };
+
+ if (!bo[i]) {
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+
+ bo[i] = gem_create(gem_fd, 4096);
+ gem_write(gem_fd, bo[i], 4092, &bbe,
+ sizeof(bbe));
+ }
+
+ obj.handle = bo[i];
Looks like you can use just the one handle multiple times?
Hm yeah.
+
+ eb.buffer_count = 1;
+ eb.buffers_ptr = to_user_pointer(&obj);
+
+ eb.flags = engine | I915_EXEC_FENCE_IN;
+ eb.rsvd2 = fence;
You do however also want to check with one context per execbuf.
Ok.
if (flags & CONTEXTS)
eb.rsvd1 = gem_context_create(fd);
+
+ gem_execbuf(gem_fd, &eb);
if (flags & CONTEXTS)
gem_context_destroy(fd, eb.rsvd1);
eb.rsvd1 = gem_context_create();
+ }
+
+ val[0] = __pmu_read_single(fd, &ts[0]);
+ usleep(batch_duration_ns / 1000);
+ val[1] = __pmu_read_single(fd, &ts[1]);
+
+ queued[n] = calc_queued(val[1] - val[0], ts[1] - ts[0]);
+ igt_info("n=%u queued=%.2f\n", n, queued[n]);
+
+ if (fence >= 0)
+ igt_cork_unplug(&cork);
Maybe we should just make this a no-op when used on an unplugged cork.
Don't know really, there's an assert in there and I didn't feel like
evaluating all callers.
+
+ for (i = 0; i < n; i++)
+ gem_sync(gem_fd, bo[i]);
+ }
+
+ close(fd);
+
+ for (i = 0; i < max_rq; i++) {
+ if (bo[i])
+ gem_close(gem_fd, bo[i]);
+ }
+
+ for (i = 0; i <= max_rq; i++)
+ assert_within_epsilon(queued[i], i, tolerance);
+}
+
+static void
+runnable(int gem_fd, const struct intel_execution_engine2 *e)
+{
+ const unsigned long engine = e2ring(gem_fd, e);
+ const unsigned int max_rq = 10;
+ igt_spin_t *spin[max_rq + 1];
+ double runnable[max_rq + 1];
+ uint32_t ctx[max_rq];
+ unsigned int n, i;
+ uint64_t val[2];
+ uint64_t ts[2];
+ int fd;
+
+ memset(runnable, 0, sizeof(runnable));
+ memset(ctx, 0, sizeof(ctx));
+
+ fd = open_pmu(I915_PMU_ENGINE_RUNNABLE(e->class, e->instance));
+
+ for (n = 0; n <= max_rq; n++) {
+ gem_quiescent_gpu(gem_fd);
+
+ for (i = 0; i < n; i++) {
+ if (!ctx[i])
+ ctx[i] = gem_context_create(gem_fd);
+
+ if (i == 0)
+ spin[i] = __spin_poll(gem_fd, ctx[i], engine);
+ else
+ spin[i] = __igt_spin_batch_new(gem_fd, ctx[i],
+ engine, 0);
+ }
+
+ if (n)
+ __spin_wait(gem_fd, spin[0]);
+
+ val[0] = __pmu_read_single(fd, &ts[0]);
+
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Include submission tasklet state in engine dump
== Series Details == Series: drm/i915: Include submission tasklet state in engine dump URL : https://patchwork.freedesktop.org/series/40548/ State : success == Summary == Known issues: Test kms_cursor_legacy: Subgroup 2x-long-flip-vs-cursor-atomic: fail -> PASS (shard-hsw) fdo#104873 Test kms_flip: Subgroup plain-flip-fb-recreate: pass -> FAIL (shard-hsw) fdo#100368 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3484 pass:1820 dwarn:1 dfail:0 fail:7 skip:1655 time:13060s shard-hswtotal:3484 pass:1773 dwarn:1 dfail:0 fail:2 skip:1707 time:11813s shard-snbtotal:3484 pass:1363 dwarn:1 dfail:0 fail:3 skip:2117 time:7258s Blacklisted hosts: shard-kbltotal:3484 pass:1944 dwarn:1 dfail:1 fail:9 skip:1529 time:10010s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8466/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/guc: Fix null pointer dereference when GuC FW is not available
On Fri, 23 Mar 2018 09:49:45 +0100, Joonas Lahtinen wrote: Michal, Can you send this with the enable_guc HAX patch to get a run in the CI with GuC. Piotr will send it with CI prefix very soon. Thanks, Michal ___ 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: Actually flush interrupts on reset not just wedging
== Series Details == Series: drm/i915: Actually flush interrupts on reset not just wedging URL : https://patchwork.freedesktop.org/series/40550/ State : failure == Summary == Series 40550v1 drm/i915: Actually flush interrupts on reset not just wedging https://patchwork.freedesktop.org/api/1.0/series/40550/revisions/1/mbox/ Possible new issues: Test gem_busy: Subgroup basic-hang-default: pass -> INCOMPLETE (fi-bdw-5557u) pass -> INCOMPLETE (fi-bdw-gvtdvm) pass -> INCOMPLETE (fi-bsw-n3050) pass -> INCOMPLETE (fi-bxt-j4205) pass -> INCOMPLETE (fi-cfl-8700k) pass -> INCOMPLETE (fi-cfl-u) pass -> INCOMPLETE (fi-cnl-y3) pass -> INCOMPLETE (fi-glk-1) pass -> INCOMPLETE (fi-kbl-7500u) pass -> INCOMPLETE (fi-kbl-7567u) pass -> INCOMPLETE (fi-kbl-r) Known issues: Test gem_busy: Subgroup basic-hang-default: pass -> INCOMPLETE (fi-skl-6260u) fdo#104108 +5 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-bdw-gvtdvmtotal:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:384s fi-bsw-n3050 total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:302s fi-bxt-j4205 total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:518s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:507s fi-cfl-8700k total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-cfl-u total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-cnl-y3total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:314s fi-glk-1 total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:405s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:420s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:461s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:428s fi-kbl-7500u total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-kbl-7567u total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-kbl-r total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:648s fi-skl-6260u total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-skl-6600u total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-skl-6700k2total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-skl-6770hqtotal:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-skl-guc total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-skl-gvtdvmtotal:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:576s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:401s Blacklisted hosts: fi-cfl-s3total:11 pass:10 dwarn:0 dfail:0 fail:0 skip:0 4db112a713cbe4fa2e65a2f1c5c21bf1076aae49 drm-tip: 2018y-03m-23d-09h-23m-53s UTC integration manifest cac6dd787287 drm/i915: Actually flush interrupts on reset not just wedging == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8467/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Actually flush interrupts on reset not just wedging
Commit 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
reset") got confused and only applied the flush to the set-wedge path
(which itself is proving troublesome), but we also need the
serialisation on the regular reset path. Oops.
Move the interrupt into reset_irq() and make it common to the reset and
final set-wedge.
v2: reset_irq() after port cancellation, as we assert that
execlists->active is sane for cancellation (and is being reset by
reset_irq).
References: 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
Cc: Michał Winiarski
Cc: Jeff McGee
---
drivers/gpu/drm/i915/intel_lrc.c | 107 +++
1 file changed, 53 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ce09c5ad334f..b4ab06b05e58 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -740,6 +740,57 @@ execlists_cancel_port_requests(struct
intel_engine_execlists * const execlists)
}
}
+static void clear_gtiir(struct intel_engine_cs *engine)
+{
+ static const u8 gtiir[] = {
+ [RCS] = 0,
+ [BCS] = 0,
+ [VCS] = 1,
+ [VCS2] = 1,
+ [VECS] = 3,
+ };
+ struct drm_i915_private *dev_priv = engine->i915;
+ int i;
+
+ /* TODO: correctly reset irqs for gen11 */
+ if (WARN_ON_ONCE(INTEL_GEN(engine->i915) >= 11))
+ return;
+
+ GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
+
+ /*
+* Clear any pending interrupt state.
+*
+* We do it twice out of paranoia that some of the IIR are
+* double buffered, and so if we only reset it once there may
+* still be an interrupt pending.
+*/
+ for (i = 0; i < 2; i++) {
+ I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
+ engine->irq_keep_mask);
+ POSTING_READ(GEN8_GT_IIR(gtiir[engine->id]));
+ }
+ GEM_BUG_ON(I915_READ(GEN8_GT_IIR(gtiir[engine->id])) &
+ engine->irq_keep_mask);
+}
+
+static void reset_irq(struct intel_engine_cs *engine)
+{
+ /* Mark all CS interrupts as complete */
+ smp_store_mb(engine->execlists.active, 0);
+ synchronize_hardirq(engine->i915->drm.irq);
+
+ clear_gtiir(engine);
+
+ /*
+* The port is checked prior to scheduling a tasklet, but
+* just in case we have suspended the tasklet to do the
+* wedging make sure that when it wakes, it decides there
+* is no work to do by clearing the irq_posted bit.
+*/
+ clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+}
+
static void execlists_cancel_requests(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -767,6 +818,7 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
/* Cancel the requests on the HW and clear the ELSP tracker. */
execlists_cancel_port_requests(execlists);
+ reset_irq(engine);
spin_lock(&engine->timeline->lock);
@@ -805,18 +857,6 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
spin_unlock(&engine->timeline->lock);
- /* Mark all CS interrupts as complete */
- smp_store_mb(execlists->active, 0);
- synchronize_hardirq(engine->i915->drm.irq);
-
- /*
-* The port is checked prior to scheduling a tasklet, but
-* just in case we have suspended the tasklet to do the
-* wedging make sure that when it wakes, it decides there
-* is no work to do by clearing the irq_posted bit.
-*/
- clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
-
local_irq_restore(flags);
}
@@ -1566,14 +1606,6 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
return ret;
}
-static u8 gtiir[] = {
- [RCS] = 0,
- [BCS] = 0,
- [VCS] = 1,
- [VCS2] = 1,
- [VECS] = 3,
-};
-
static void enable_execlists(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
@@ -1657,35 +1689,6 @@ static int gen9_init_render_ring(struct intel_engine_cs
*engine)
return init_workarounds_ring(engine);
}
-static void reset_irq(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
- int i;
-
- /* TODO: correctly reset irqs for gen11 */
- if (WARN_ON_ONCE(INTEL_GEN(engine->i915) >= 11))
- return;
-
- GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
-
- /*
-* Clear any pending interrupt state.
-*
-* We do it twice out of paranoia that some of the IIR are double
-* buffered, and if we only reset it once there may still be
-* an interrupt pending.
-
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 5/5] tests/i915_query: Engine queues tests
On 22/03/2018 21:22, Lionel Landwerlin wrote:
On 19/03/18 18:22, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
---
tests/i915_query.c | 381
+
1 file changed, 381 insertions(+)
diff --git a/tests/i915_query.c b/tests/i915_query.c
index c7de8cbd8371..94e7a3297ebd 100644
--- a/tests/i915_query.c
+++ b/tests/i915_query.c
@@ -477,8 +477,358 @@ test_query_topology_known_pci_ids(int fd, int
devid)
free(topo_info);
}
+#define DRM_I915_QUERY_ENGINE_QUEUES 2
+
+struct drm_i915_query_engine_queues {
+ /** Engine class as in enum drm_i915_gem_engine_class. */
+ __u16 class;
+
+ /** Engine instance number. */
+ __u16 instance;
+
+ /** Number of requests with unresolved fences and dependencies. */
+ __u32 queued;
+
+ /** Number of ready requests waiting on a slot on GPU. */
+ __u32 runnable;
+
+ /** Number of requests executing on the GPU. */
+ __u32 running;
+
+ __u32 rsvd[5];
+};
+
+static bool query_engine_queues_supported(int fd)
+{
+ struct drm_i915_query_item item = {
+ .query_id = DRM_I915_QUERY_ENGINE_QUEUES,
+ };
+
+ return __i915_query_items(fd, &item, 1) == 0 && item.length > 0;
+}
+
+static void engine_queues_invalid(int fd)
+{
+ struct drm_i915_query_engine_queues queues;
+ struct drm_i915_query_item item;
+ unsigned int len;
+ unsigned int i;
+
+ /* Flags is MBZ. */
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.flags = 1;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -EINVAL);
+
+ /* Length not zero and not greater or equal required size. */
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = 1;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -ENOSPC);
+
+ /* Query correct length. */
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ i915_query_items(fd, &item, 1);
+ igt_assert(item.length >= 0);
+ len = item.length;
+
+ /* Ivalid pointer. */
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = len;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -EFAULT);
+
+ /* Reserved fields are MBZ. */
+
+ for (i = 0; i < ARRAY_SIZE(queues.rsvd); i++) {
+ memset(&queues, 0, sizeof(queues));
+ queues.rsvd[i] = 1;
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = len;
+ item.data_ptr = to_user_pointer(&queues);
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -EINVAL);
+ }
+
+ memset(&queues, 0, sizeof(queues));
+ queues.class = -1;
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = len;
+ item.data_ptr = to_user_pointer(&queues);
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -ENOENT);
+
Looks like you've copied the few lines above after.
It seems to be the same test.
Above is checking invalid class is rejected, below is checking invalid
instance - if I understood correctly what you are pointing at?
+ memset(&queues, 0, sizeof(queues));
+ queues.instance = -1;
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = len;
+ item.data_ptr = to_user_pointer(&queues);
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -ENOENT);
+}
+
+static void engine_queues(int fd, const struct
intel_execution_engine2 *e)
+{
+ struct drm_i915_query_engine_queues queues;
+ struct drm_i915_query_item item;
+ unsigned int len;
+
+ /* Query required buffer length. */
+ memset(&queues, 0, sizeof(queues));
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.data_ptr = to_user_pointer(&queues);
+ i915_query_items(fd, &item, 1);
+ igt_assert(item.length >= 0);
+ igt_assert(item.length <= sizeof(queues));
+ len = item.length;
+
+ /* Check length larger than required works and reports same
length. */
+ memset(&queues, 0, sizeof(queues));
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.data_ptr = to_user_pointer(&queues);
+ item.length = len + 1;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, len);
+
+ /* Actual query. */
+ memset(&queues, 0, sizeof(queues));
+ queues.class = e->class;
+ queues.instance = e->instance;
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.data_ptr = to_user_pointer(&queues);
+ item.length = len;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, len);
+}
+
+static unsigned int e2ring(int gem_fd, const struct
intel_execution_engine2 *e)
+
Re: [Intel-gfx] [PATCH i-g-t] meson: Chamelium depends on GSL
On Tue, Mar 20, 2018 at 09:19:48PM +, Daniel Stone wrote:
> Chamelium support requires igt_frame to be built, which requires both
> GSL and Pixman.
>
> Signed-off-by: Daniel Stone
Reviewed-by: Petri Latvala
Also a reminder about https://lists.freedesktop.org/mailman/listinfo/igt-dev
> ---
> meson.build | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index ef7017cb..5b783e5d 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -76,7 +76,7 @@ if not xmlrpc.found() and xmlrpc_cmd.found()
> endif
> endif
>
> -if pixman.found() and xmlrpc.found() and xmlrpc_util.found() and
> xmlrpc_client.found()
> +if pixman.found() and gsl.found() and xmlrpc.found() and xmlrpc_util.found()
> and xmlrpc_client.found()
> chamelium = declare_dependency(dependencies : [ pixman, xmlrpc,
> xmlrpc_util, xmlrpc_client])
> config.set('HAVE_CHAMELIUM', 1)
> --
> 2.16.2
>
> ___
> 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 igt] igt/gem_ctx_switch: Measure qlen for timing loops
Quoting Chris Wilson (2018-03-16 18:03:25) > Some platforms may execute the heavy workload very slowly, such that > using a batch of 1024 takes tens of seconds and immediately overrunning > the 5s timeout on a pass. Added up over a few dozen passes, this turns a > 120 second test into 10 minutes. Counter this by doing a warmup loop to > estimate the appropriate queue len for timing. > > Signed-off-by: Chris Wilson #define MAGNIFICENT_FACTOR_8 (3 + 5) or maybe a comment. Reviewed-by: Joonas Lahtinen Regards, Joonas ___ 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: Request driver probe from an async task
== Series Details == Series: drm/i915: Request driver probe from an async task URL : https://patchwork.freedesktop.org/series/40547/ State : success == Summary == Series 40547v1 drm/i915: Request driver probe from an async task https://patchwork.freedesktop.org/api/1.0/series/40547/revisions/1/mbox/ Known issues: Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (fi-skl-6770hq) fdo#100368 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:434s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:440s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:537s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:301s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:514s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:520s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:507s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:413s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:508s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:591s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:427s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:319s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:534s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:407s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:423s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:474s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:428s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:478s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:466s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:519s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:648s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:440s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:530s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:501s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:511s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:431s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:449s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:586s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:404s Blacklisted hosts: fi-cfl-s3total:285 pass:258 dwarn:0 dfail:0 fail:1 skip:26 time:550s fi-cnl-psr total:224 pass:198 dwarn:0 dfail:0 fail:1 skip:24 4db112a713cbe4fa2e65a2f1c5c21bf1076aae49 drm-tip: 2018y-03m-23d-09h-23m-53s UTC integration manifest 7a9c17decf7c drm/i915: Request driver probe from an async task == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8468/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 5/5] tests/i915_query: Engine queues tests
On 23/03/18 10:18, Tvrtko Ursulin wrote:
On 22/03/2018 21:22, Lionel Landwerlin wrote:
On 19/03/18 18:22, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
---
tests/i915_query.c | 381
+
1 file changed, 381 insertions(+)
diff --git a/tests/i915_query.c b/tests/i915_query.c
index c7de8cbd8371..94e7a3297ebd 100644
--- a/tests/i915_query.c
+++ b/tests/i915_query.c
@@ -477,8 +477,358 @@ test_query_topology_known_pci_ids(int fd, int
devid)
free(topo_info);
}
+#define DRM_I915_QUERY_ENGINE_QUEUES 2
+
+struct drm_i915_query_engine_queues {
+ /** Engine class as in enum drm_i915_gem_engine_class. */
+ __u16 class;
+
+ /** Engine instance number. */
+ __u16 instance;
+
+ /** Number of requests with unresolved fences and dependencies. */
+ __u32 queued;
+
+ /** Number of ready requests waiting on a slot on GPU. */
+ __u32 runnable;
+
+ /** Number of requests executing on the GPU. */
+ __u32 running;
+
+ __u32 rsvd[5];
+};
+
+static bool query_engine_queues_supported(int fd)
+{
+ struct drm_i915_query_item item = {
+ .query_id = DRM_I915_QUERY_ENGINE_QUEUES,
+ };
+
+ return __i915_query_items(fd, &item, 1) == 0 && item.length > 0;
+}
+
+static void engine_queues_invalid(int fd)
+{
+ struct drm_i915_query_engine_queues queues;
+ struct drm_i915_query_item item;
+ unsigned int len;
+ unsigned int i;
+
+ /* Flags is MBZ. */
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.flags = 1;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -EINVAL);
+
+ /* Length not zero and not greater or equal required size. */
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = 1;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -ENOSPC);
+
+ /* Query correct length. */
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ i915_query_items(fd, &item, 1);
+ igt_assert(item.length >= 0);
+ len = item.length;
+
+ /* Ivalid pointer. */
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = len;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -EFAULT);
+
+ /* Reserved fields are MBZ. */
+
+ for (i = 0; i < ARRAY_SIZE(queues.rsvd); i++) {
+ memset(&queues, 0, sizeof(queues));
+ queues.rsvd[i] = 1;
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = len;
+ item.data_ptr = to_user_pointer(&queues);
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -EINVAL);
+ }
+
+ memset(&queues, 0, sizeof(queues));
+ queues.class = -1;
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = len;
+ item.data_ptr = to_user_pointer(&queues);
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -ENOENT);
+
Looks like you've copied the few lines above after.
It seems to be the same test.
Above is checking invalid class is rejected, below is checking invalid
instance - if I understood correctly what you are pointing at?
Oops, missed that.
+ memset(&queues, 0, sizeof(queues));
+ queues.instance = -1;
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = len;
+ item.data_ptr = to_user_pointer(&queues);
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -ENOENT);
+}
+
+static void engine_queues(int fd, const struct
intel_execution_engine2 *e)
+{
+ struct drm_i915_query_engine_queues queues;
+ struct drm_i915_query_item item;
+ unsigned int len;
+
+ /* Query required buffer length. */
+ memset(&queues, 0, sizeof(queues));
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.data_ptr = to_user_pointer(&queues);
+ i915_query_items(fd, &item, 1);
+ igt_assert(item.length >= 0);
+ igt_assert(item.length <= sizeof(queues));
+ len = item.length;
+
+ /* Check length larger than required works and reports same
length. */
+ memset(&queues, 0, sizeof(queues));
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.data_ptr = to_user_pointer(&queues);
+ item.length = len + 1;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, len);
+
+ /* Actual query. */
+ memset(&queues, 0, sizeof(queues));
+ queues.class = e->class;
+ queues.instance = e->instance;
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.data_ptr = to_user_pointer(&queues);
+ item.length = len;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, len);
+}
+
+static unsigned int
Re: [Intel-gfx] [PATCH v2] drm/i915: Actually flush interrupts on reset not just wedging
Chris Wilson writes:
> Commit 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
> reset") got confused and only applied the flush to the set-wedge path
> (which itself is proving troublesome), but we also need the
> serialisation on the regular reset path. Oops.
>
> Move the interrupt into reset_irq() and make it common to the reset and
> final set-wedge.
>
> v2: reset_irq() after port cancellation, as we assert that
> execlists->active is sane for cancellation (and is being reset by
> reset_irq).
>
> References: 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
> reset")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Michel Thierry
> Cc: Michał Winiarski
> Cc: Jeff McGee
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 107
> +++
> 1 file changed, 53 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index ce09c5ad334f..b4ab06b05e58 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -740,6 +740,57 @@ execlists_cancel_port_requests(struct
> intel_engine_execlists * const execlists)
> }
> }
>
> +static void clear_gtiir(struct intel_engine_cs *engine)
> +{
> + static const u8 gtiir[] = {
> + [RCS] = 0,
> + [BCS] = 0,
> + [VCS] = 1,
> + [VCS2] = 1,
> + [VECS] = 3,
> + };
> + struct drm_i915_private *dev_priv = engine->i915;
> + int i;
> +
> + /* TODO: correctly reset irqs for gen11 */
> + if (WARN_ON_ONCE(INTEL_GEN(engine->i915) >= 11))
> + return;
> +
> + GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
> +
> + /*
> + * Clear any pending interrupt state.
> + *
> + * We do it twice out of paranoia that some of the IIR are
> + * double buffered, and so if we only reset it once there may
> + * still be an interrupt pending.
> + */
> + for (i = 0; i < 2; i++) {
> + I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
> +engine->irq_keep_mask);
> + POSTING_READ(GEN8_GT_IIR(gtiir[engine->id]));
> + }
> + GEM_BUG_ON(I915_READ(GEN8_GT_IIR(gtiir[engine->id])) &
> +engine->irq_keep_mask);
> +}
> +
> +static void reset_irq(struct intel_engine_cs *engine)
> +{
> + /* Mark all CS interrupts as complete */
> + smp_store_mb(engine->execlists.active, 0);
> + synchronize_hardirq(engine->i915->drm.irq);
> +
> + clear_gtiir(engine);
Should clearing the iir be before we synchronize?
Our master irq is off, so no bit can light up,
clear iir, prevent tasklet with active and synchronize.
For documentation it would be nice that we have
assert that the tasklet is indeed disabled.
-Mika
> +
> + /*
> + * The port is checked prior to scheduling a tasklet, but
> + * just in case we have suspended the tasklet to do the
> + * wedging make sure that when it wakes, it decides there
> + * is no work to do by clearing the irq_posted bit.
> + */
> + clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> +}
> +
> static void execlists_cancel_requests(struct intel_engine_cs *engine)
> {
> struct intel_engine_execlists * const execlists = &engine->execlists;
> @@ -767,6 +818,7 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
>
> /* Cancel the requests on the HW and clear the ELSP tracker. */
> execlists_cancel_port_requests(execlists);
> + reset_irq(engine);
>
> spin_lock(&engine->timeline->lock);
>
> @@ -805,18 +857,6 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
>
> spin_unlock(&engine->timeline->lock);
>
> - /* Mark all CS interrupts as complete */
> - smp_store_mb(execlists->active, 0);
> - synchronize_hardirq(engine->i915->drm.irq);
> -
> - /*
> - * The port is checked prior to scheduling a tasklet, but
> - * just in case we have suspended the tasklet to do the
> - * wedging make sure that when it wakes, it decides there
> - * is no work to do by clearing the irq_posted bit.
> - */
> - clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> -
> local_irq_restore(flags);
> }
>
> @@ -1566,14 +1606,6 @@ static int intel_init_workaround_bb(struct
> intel_engine_cs *engine)
> return ret;
> }
>
> -static u8 gtiir[] = {
> - [RCS] = 0,
> - [BCS] = 0,
> - [VCS] = 1,
> - [VCS2] = 1,
> - [VECS] = 3,
> -};
> -
> static void enable_execlists(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *dev_priv = engine->i915;
> @@ -1657,35 +1689,6 @@ static int gen9_init_render_ring(struct
> intel_engine_cs *engine)
> return init_workarounds_ring(engine);
> }
>
> -static void reset_irq(struct intel_engine_cs *engine)
> -{
> - struct drm_i915_private *dev_priv = engine->i915;
> - int i;
> -
> - /*
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 5/5] tests/i915_query: Engine queues tests
Quoting Tvrtko Ursulin (2018-03-23 10:18:37) > > On 22/03/2018 21:22, Lionel Landwerlin wrote: > > I guess we could add a group for the topology too. > > My dilemma was whether to stuff tests for any query into i915_query.c, > or split out to separate binaries. > > I can imagine, if/when the number of queries grows, i915_query.c would > become unmanageable with the former approach. What do you think? #tags ;) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Actually flush interrupts on reset not just wedging
Quoting Mika Kuoppala (2018-03-23 10:53:00)
> Chris Wilson writes:
>
> > Commit 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
> > reset") got confused and only applied the flush to the set-wedge path
> > (which itself is proving troublesome), but we also need the
> > serialisation on the regular reset path. Oops.
> >
> > Move the interrupt into reset_irq() and make it common to the reset and
> > final set-wedge.
> >
> > v2: reset_irq() after port cancellation, as we assert that
> > execlists->active is sane for cancellation (and is being reset by
> > reset_irq).
> >
> > References: 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a
> > GPU reset")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Michel Thierry
> > Cc: Michał Winiarski
> > Cc: Jeff McGee
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 107
> > +++
> > 1 file changed, 53 insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index ce09c5ad334f..b4ab06b05e58 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -740,6 +740,57 @@ execlists_cancel_port_requests(struct
> > intel_engine_execlists * const execlists)
> > }
> > }
> >
> > +static void clear_gtiir(struct intel_engine_cs *engine)
> > +{
> > + static const u8 gtiir[] = {
> > + [RCS] = 0,
> > + [BCS] = 0,
> > + [VCS] = 1,
> > + [VCS2] = 1,
> > + [VECS] = 3,
> > + };
> > + struct drm_i915_private *dev_priv = engine->i915;
> > + int i;
> > +
> > + /* TODO: correctly reset irqs for gen11 */
> > + if (WARN_ON_ONCE(INTEL_GEN(engine->i915) >= 11))
> > + return;
> > +
> > + GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
> > +
> > + /*
> > + * Clear any pending interrupt state.
> > + *
> > + * We do it twice out of paranoia that some of the IIR are
> > + * double buffered, and so if we only reset it once there may
> > + * still be an interrupt pending.
> > + */
> > + for (i = 0; i < 2; i++) {
> > + I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
> > +engine->irq_keep_mask);
> > + POSTING_READ(GEN8_GT_IIR(gtiir[engine->id]));
> > + }
> > + GEM_BUG_ON(I915_READ(GEN8_GT_IIR(gtiir[engine->id])) &
> > +engine->irq_keep_mask);
> > +}
> > +
> > +static void reset_irq(struct intel_engine_cs *engine)
> > +{
> > + /* Mark all CS interrupts as complete */
> > + smp_store_mb(engine->execlists.active, 0);
> > + synchronize_hardirq(engine->i915->drm.irq);
> > +
> > + clear_gtiir(engine);
>
> Should clearing the iir be before we synchronize?
> Our master irq is off, so no bit can light up,
> clear iir, prevent tasklet with active and synchronize.
After I think. Before we risk running at the same time as an interrupt
handler on another thread. Hence the mb on disabling the execlists
(corresponding with the READ_ONE(active) in gen8_cs_irq_handler).
Not that is makes much difference (since we don't trust the consistentcy
of IIR inside the irq handler, because we do randomly reset it), but I
think it makes sense; clear off the interrupt handler, cancel IIR, let
the system resume processing interrupts.
> For documentation it would be nice that we have
> assert that the tasklet is indeed disabled.
Not without poking inside tasklet :) In a couple of patches time I plan
to have tasklet_disable/tasklet_enable from inside intel_lrc. I'll
shovel something in then.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Request driver probe from an async task
Quoting Chris Wilson (2018-03-23 08:30:48) > As we are careful not to register external interfaces before the > internals are brought up, we are not dependent upon a synchronous > probing and can allow ourselves to be probed from a secondary thread > during system bootup. We already do relegate some configuration to > asynchronous tasks (such as setting up the fbdev), now do the entire > probe. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=105622 > Signed-off-by: Chris Wilson > Cc: Imre Deak > Cc: Ville Syrjälä > Cc: David Weinehall For doing what it says on the tin, Tested-by: Paul Menzel -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Fix uabi regression by allowing garbage mode->type from userspace
Op 22-03-18 om 08:42 schreef Thomas Hellstrom:
> On 03/21/2018 10:12 PM, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> Apparently xf86-video-vmware leaves the mode->type uninitialized
>> when feeding the mode to the kernel. Thus we have no choice but
>> to accept the garbage in. We'll just ignore any of the bits we
>> don't want. The mode type is just a hint anyway, and more
>> useful for the kernel->userspace direction.
>>
>> Reported-by: Thomas Hellstrom
>> CC: Thomas Hellstrom
>> Cc: Adam Jackson
>> Cc: Alex Deucher
>> Fixes: c6ed6dad5cfb ("drm/uapi: Validate the mode flags/type")
>> References:
>> https://lists.freedesktop.org/archives/dri-devel/2018-March/170213.html
>> Signed-off-by: Ville Syrjälä
>> ---
>> drivers/gpu/drm/drm_modes.c | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index f6b7c0e36a1a..e82b61e08f8c 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -1611,7 +1611,13 @@ int drm_mode_convert_umode(struct drm_device *dev,
>> out->vscan = in->vscan;
>> out->vrefresh = in->vrefresh;
>> out->flags = in->flags;
>> - out->type = in->type;
>> + /*
>> + * Old xf86-video-vmware (possibly others too) used to
>> + * leave 'type' unititialized. Just ignore any bits we
>> + * don't like. It's a just hint after all, and more
>> + * useful for the kernel->userspace direction anyway.
>> + */
>> + out->type = in->type & DRM_MODE_TYPE_ALL;
>> strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>> out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>>
>
> Tested-by: Thomas Hellstrom
>
> Thanks,
>
> Thomas
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Fix uabi regression by allowing garbage mode->type from userspace
On 21 March 2018 at 21:12, Ville Syrjala wrote: > Apparently xf86-video-vmware leaves the mode->type uninitialized > when feeding the mode to the kernel. Thus we have no choice but > to accept the garbage in. We'll just ignore any of the bits we > don't want. The mode type is just a hint anyway, and more > useful for the kernel->userspace direction. Reviewed-by: Daniel Stone ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 3/3] HAX: Enable GuC for CI
Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/3] drm/i915: Reorder early initialization
In upcoming patch, we want to perform more actions in early
initialization of the uC. This reordering will help resolve
new dependencies that will be introduced by future patch.
v2: s/i915_gem_load_init/i915_gem_init_early (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 17 -
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 3 +--
3 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7d3275..4d244d7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -919,17 +919,21 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
mutex_init(&dev_priv->wm.wm_mutex);
mutex_init(&dev_priv->pps_mutex);
- intel_wopcm_init_early(&dev_priv->wopcm);
- intel_uc_init_early(dev_priv);
i915_memcpy_init_early(dev_priv);
ret = i915_workqueues_init(dev_priv);
if (ret < 0)
goto err_engines;
+ ret = i915_gem_init_early(dev_priv);
+ if (ret < 0)
+ goto err_workqueues;
+
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev_priv);
+ intel_wopcm_init_early(&dev_priv->wopcm);
+ intel_uc_init_early(dev_priv);
intel_pm_setup(dev_priv);
intel_init_dpio(dev_priv);
intel_power_domains_init(dev_priv);
@@ -938,18 +942,13 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
intel_init_display_hooks(dev_priv);
intel_init_clock_gating_hooks(dev_priv);
intel_init_audio_hooks(dev_priv);
- ret = i915_gem_load_init(dev_priv);
- if (ret < 0)
- goto err_irq;
-
intel_display_crc_init(dev_priv);
intel_detect_preproduction_hw(dev_priv);
return 0;
-err_irq:
- intel_irq_fini(dev_priv);
+err_workqueues:
i915_workqueues_cleanup(dev_priv);
err_engines:
i915_engines_cleanup(dev_priv);
@@ -962,8 +961,8 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
*/
static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
{
- i915_gem_load_cleanup(dev_priv);
intel_irq_fini(dev_priv);
+ i915_gem_load_cleanup(dev_priv);
i915_workqueues_cleanup(dev_priv);
i915_engines_cleanup(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9c3b2b..65a0b53 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2869,7 +2869,7 @@ int i915_gem_get_aperture_ioctl(struct drm_device *dev,
void *data,
int i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
void i915_gem_sanitize(struct drm_i915_private *i915);
-int i915_gem_load_init(struct drm_i915_private *dev_priv);
+int i915_gem_init_early(struct drm_i915_private *dev_priv);
void i915_gem_load_cleanup(struct drm_i915_private *dev_priv);
void i915_gem_load_init_fences(struct drm_i915_private *dev_priv);
int i915_gem_freeze(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 802df8e..bce2e26 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5502,8 +5502,7 @@ static void i915_gem_init__mm(struct drm_i915_private
*i915)
INIT_WORK(&i915->mm.free_work, __i915_gem_free_work);
}
-int
-i915_gem_load_init(struct drm_i915_private *dev_priv)
+int i915_gem_init_early(struct drm_i915_private *dev_priv)
{
int err = -ENOMEM;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/3] drm/i915/uc: Fetch uC firmware in init_early
We were fetching uC firmwares in separate uc_init_fw step, while
there is no reason why we can't fetch them during init_early.
This will also simplify upcoming patches, as size of the firmware
may be used for register initialization.
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 8 ++--
drivers/gpu/drm/i915/intel_guc_fw.c | 5 ++---
drivers/gpu/drm/i915/intel_huc_fw.c | 5 ++---
drivers/gpu/drm/i915/intel_uc.c | 37 ++---
drivers/gpu/drm/i915/intel_uc.h | 3 +--
5 files changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4d244d7..5094ea0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -692,11 +692,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
- intel_uc_init_fw(dev_priv);
-
ret = i915_gem_init(dev_priv);
if (ret)
- goto cleanup_uc;
+ goto cleanup_irq;
intel_setup_overlay(dev_priv);
@@ -716,8 +714,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
i915_gem_fini(dev_priv);
-cleanup_uc:
- intel_uc_fini_fw(dev_priv);
cleanup_irq:
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev_priv);
@@ -962,6 +958,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
{
intel_irq_fini(dev_priv);
+ intel_uc_cleanup_early(dev_priv);
i915_gem_load_cleanup(dev_priv);
i915_workqueues_cleanup(dev_priv);
i915_engines_cleanup(dev_priv);
@@ -1457,7 +1454,6 @@ void i915_driver_unload(struct drm_device *dev)
i915_reset_error_state(dev_priv);
i915_gem_fini(dev_priv);
- intel_uc_fini_fw(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
intel_power_domains_fini(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
b/drivers/gpu/drm/i915/intel_guc_fw.c
index 978668c..a9e6fcc 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -275,9 +275,8 @@ static int guc_fw_xfer(struct intel_uc_fw *guc_fw, struct
i915_vma *vma)
* Called from intel_uc_init_hw() during driver load, resume from sleep and
* after a GPU reset.
*
- * The firmware image should have already been fetched into memory by the
- * earlier call to intel_uc_init_fw(), so here we need to only check that
- * fetch succeeded, and then transfer the image to the h/w.
+ * The firmware image should have already been fetched into memory, so only
+ * check that fetch succeeded, and then transfer the image to the h/w.
*
* Return: non-zero code on error
*/
diff --git a/drivers/gpu/drm/i915/intel_huc_fw.c
b/drivers/gpu/drm/i915/intel_huc_fw.c
index bb0f8b7..f93d238 100644
--- a/drivers/gpu/drm/i915/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/intel_huc_fw.c
@@ -155,9 +155,8 @@ static int huc_fw_xfer(struct intel_uc_fw *huc_fw, struct
i915_vma *vma)
* Called from intel_uc_init_hw() during driver load, resume from sleep and
* after a GPU reset. Note that HuC must be loaded before GuC.
*
- * The firmware image should have already been fetched into memory by the
- * earlier call to intel_uc_init_fw(), so here we need to only check that
- * fetch succeeded, and then transfer the image to the h/w.
+ * The firmware image should have already been fetched into memory, so only
+ * check that fetch succeeded, and then transfer the image to the h/w.
*
* Return: non-zero code on error
*/
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 34f8a2c..4aad844 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -162,36 +162,35 @@ static void sanitize_options_early(struct
drm_i915_private *dev_priv)
GEM_BUG_ON(i915_modparams.guc_log_level < 0);
}
-void intel_uc_init_early(struct drm_i915_private *dev_priv)
+void intel_uc_init_early(struct drm_i915_private *i915)
{
- intel_guc_init_early(&dev_priv->guc);
- intel_huc_init_early(&dev_priv->huc);
+ struct intel_guc *guc = &i915->guc;
+ struct intel_huc *huc = &i915->huc;
- sanitize_options_early(dev_priv);
-}
+ intel_guc_init_early(guc);
+ intel_huc_init_early(huc);
-void intel_uc_init_fw(struct drm_i915_private *dev_priv)
-{
- if (!USES_GUC(dev_priv))
- return;
+ sanitize_options_early(i915);
- if (USES_HUC(dev_priv))
- intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
+ if (USES_GUC(i915))
+ intel_uc_fw_fetch(i915, &guc->fw);
- intel_uc_f
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Request driver probe from an async task
== Series Details == Series: drm/i915: Request driver probe from an async task URL : https://patchwork.freedesktop.org/series/40547/ State : failure == Summary == Possible new issues: Test drv_selftest: Subgroup live_objects: pass -> INCOMPLETE (shard-apl) Test kms_flip: Subgroup busy-flip: fail -> PASS (shard-apl) Known issues: Test gem_softpin: Subgroup noreloc-s3: incomplete -> PASS (shard-hsw) fdo#103540 Test kms_flip: Subgroup 2x-flip-vs-blocking-wf-vblank: fail -> PASS (shard-hsw) fdo#100368 +1 Subgroup 2x-flip-vs-expired-vblank: fail -> PASS (shard-hsw) fdo#102887 Test kms_setmode: Subgroup basic: pass -> FAIL (shard-apl) fdo#99912 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-apltotal:3459 pass:1795 dwarn:1 dfail:0 fail:7 skip:1655 time:12587s shard-hswtotal:3484 pass:1773 dwarn:1 dfail:0 fail:2 skip:1707 time:11736s shard-snbtotal:3484 pass:1363 dwarn:1 dfail:0 fail:3 skip:2117 time:7239s Blacklisted hosts: shard-kbltotal:3484 pass:1943 dwarn:1 dfail:0 fail:11 skip:1529 time:9976s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8468/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915/guc: Fix null pointer dereference when GuC FW is not available
If GuC firmware is not available on the system and we load i915 with enable
GuC, then we hit this null pointer dereference issue:
[ 71.098873] BUG: unable to handle kernel NULL pointer dereference at
0008
[ 71.098938] IP: intel_uc_fw_upload+0x1f/0x360 [i915]
[ 71.098947] PGD 0 P4D 0
[ 71.098956] Oops: [#1] PREEMPT SMP PTI
[ 71.098965] Modules linked in: i915(O+) netconsole x86_pkg_temp_thermal
intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
mei_me i2c_i801 prime_numbers mei [last unloaded: i915]
[ 71.099005] CPU: 2 PID: 1167 Comm: insmod Tainted: G U W O
4.16.0-rc1+ #337
[ 71.099018] Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0065.2018.0103.1000
01/03/2018
[ 71.099077] RIP: 0010:intel_uc_fw_upload+0x1f/0x360 [i915]
[ 71.099087] RSP: 0018:c9417aa0 EFLAGS: 00010282
[ 71.099097] RAX: RBX: 88084cad12f8 RCX: a03e9357
[ 71.099108] RDX: 0002 RSI: a034dba0 RDI: 88084cad12f8
[ 71.099118] RBP: 0002 R08: 88085344ca90 R09: 0001
[ 71.099128] R10: R11: R12: 88084cad
[ 71.099139] R13: a034dba0 R14: fff5 R15: 88084cad12b0
[ 71.099151] FS: 7f7f24ae2740() GS:88085e20()
knlGS:
[ 71.099162] CS: 0010 DS: ES: CR0: 80050033
[ 71.099171] CR2: 0008 CR3: 000855f48001 CR4: 003606e0
[ 71.099182] Call Trace:
[ 71.099246] intel_uc_init_hw+0xc8/0x520 [i915]
[ 71.099303] i915_gem_init_hw+0x11f/0x2d0 [i915]
[ 71.099364] i915_gem_init+0x2b9/0x640 [i915]
[ 71.099413] i915_driver_load+0xb74/0x1110 [i915]
[ 71.099462] i915_pci_probe+0x2e/0x90 [i915]
[ 71.099476] pci_device_probe+0xa1/0x130
[ 71.099488] driver_probe_device+0x302/0x470
[ 71.099502] __driver_attach+0xb9/0xe0
[ 71.099513] ? driver_probe_device+0x470/0x470
[ 71.099525] ? driver_probe_device+0x470/0x470
[ 71.099538] bus_for_each_dev+0x64/0x90
[ 71.099550] bus_add_driver+0x164/0x260
[ 71.099561] ? 0xa04d6000
[ 71.099572] driver_register+0x57/0xc0
[ 71.099582] ? 0xa04d6000
[ 71.099593] do_one_initcall+0x3b/0x160
[ 71.099606] ? kmem_cache_alloc_trace+0x1c3/0x2a0
[ 71.099621] do_init_module+0x5b/0x1f9
[ 71.099635] load_module+0x2467/0x2a70
[ 71.099654] ? SyS_finit_module+0xbd/0xe0
[ 71.099668] SyS_finit_module+0xbd/0xe0
[ 71.099682] do_syscall_64+0x73/0x1c0
[ 71.099694] entry_SYSCALL_64_after_hwframe+0x26/0x9b
[ 71.099706] RIP: 0033:0x7f7f23fb40d9
[ 71.099717] RSP: 002b:7ffda7d67ed8 EFLAGS: 0246 ORIG_RAX:
0139
[ 71.099734] RAX: ffda RBX: 55f96e2a8870 RCX: 7f7f23fb40d9
[ 71.099748] RDX: RSI: 55f96e2a8260 RDI: 0003
[ 71.099763] RBP: 55f96e2a8260 R08: R09: 7ffda7d68088
[ 71.099777] R10: 0003 R11: 0246 R12:
[ 71.099791] R13: 55f96e2a8830 R14: R15: 55f96e2a8260
[ 71.099810] Code: 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55
41 54 49 89 f5 55 53 48 c7 c1 57 93 3e a0 48 8b 47 10 48 89 fb 4c 8b 07 <48> 8b
68 08 8b 47 28 85 c0 74 15 83 f8 01 48 c7 c1 5b 93 3e a0
[ 71.14] RIP: intel_uc_fw_upload+0x1f/0x360 [i915] RSP: c9417aa0
[ 71.100020] CR2: 0008
[ 71.100031] ---[ end trace d8ac93c30ceff5b2 ]--
Fixes: 6b0478fb722a ("drm/i915: Implement dynamic GuC WOPCM offset and size
calculation")
v2: don't assume it is always GuC FW (Michal)
v3: added a new variable to avoid exceeding the number of characters in the
line (Michal)
Signed-off-by: Piotr Piórkowski
Reported-by: Radoslaw Szwichtenberg
Cc: Michał Winiarski
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Joonas Lahtinen
Cc: Jackie Li
Cc: Radoslaw Szwichtenberg
Reviewed-by: Michal Wajdeczko
Reviewed-by: Jackie Li
---
drivers/gpu/drm/i915/intel_uc_fw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c
b/drivers/gpu/drm/i915/intel_uc_fw.c
index 30c73243f54d..93b0fc661b3a 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -199,9 +199,9 @@ int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
int (*xfer)(struct intel_uc_fw *uc_fw,
struct i915_vma *vma))
{
- struct drm_i915_private *i915 = to_i915(uc_fw->obj->base.dev);
struct i915_vma *vma;
int err;
+ u32 ggtt_pin_bias;
DRM_DEBUG_DRIVER("%s fw load %s\n",
intel_uc_fw_type_repr(uc_fw->type), uc_fw->path);
@@ -222,9 +222,9 @@ int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
goto fail;
}
+ ggtt_pin_bias = to_i915(uc_fw->obj->base.dev)->guc.ggtt_pin_bias;
vma = i915_gem_object_ggtt_pin(uc_fw->obj, NULL,
[Intel-gfx] [CI 2/2] HAX: Enable GuC for CI
Signed-off-by: Piotr Piórkowski --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c96360398072..53037b5eff22 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ struct drm_printer; param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook
On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
>
>
> Den 22.03.2018 21.27, skrev Ville Syrjala:
> > From: Ville Syrjälä
> >
> > mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
> > bowels of the .atomic_enable() hook. That prevents us from taking the
> > plane mutex in fb->dirty() unless we also plumb down the acquire
> > context.
> >
> > Instead it seems simpler to split the fb->dirty() into a tinydrm
> > specific lower level hook that can be called from
> > mipi_dbi_enable_flush() and from a generic higher level
> > tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
> > vfuncs table we'll just stick it into tinydrm_device directly
> > for now.
>
> The long term goal is to try and get rid of tinydrm.ko by moving stuff
> elsewhere as it's kind of a middle layer. So I'd really like to avoid
> adding a callback like this.
> Hopefully we can work out a solution based on my suggestion in the
> 'drm: Eliminate plane->fb/crtc usage for atomic drivers' thread.
I don't want to start redesigning the entire architecture at
this point. That would also cause a bigger risk of regression and
then we'd potentially have to try and revert the entire plane->fb
thing, which would not be fun if any significant changes have
occurred in the meantime.
>
> If we do need a hook, I prefer that we add it to
> drm_simple_display_pipe_funcs.
If you have plans to redesign tinydrm anyway it seems to me that
a temporary hook in tinydrm is may be a bit less intrusive than
inflicting it on the simple_kms_helper. But if you do prefer
drm_simple_display_pipe_funcs I can move it there of course.
>
> Noralf.
>
> > Cc: "Noralf Trønnes"
> > Cc: David Lechner
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30
> > ++
> > drivers/gpu/drm/tinydrm/ili9225.c | 23 ++--
> > drivers/gpu/drm/tinydrm/mi0283qt.c | 2 +-
> > drivers/gpu/drm/tinydrm/mipi-dbi.c | 30
> > ++
> > drivers/gpu/drm/tinydrm/repaper.c | 28
> >
> > drivers/gpu/drm/tinydrm/st7586.c | 23 ++--
> > drivers/gpu/drm/tinydrm/st7735r.c | 2 +-
> > include/drm/tinydrm/mipi-dbi.h | 4 +++-
> > include/drm/tinydrm/tinydrm-helpers.h | 5 +
> > include/drm/tinydrm/tinydrm.h | 4
> > 10 files changed, 76 insertions(+), 75 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > index d1c3ce9ab294..dcd390163a4a 100644
> > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > @@ -78,6 +78,36 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
> > }
> > EXPORT_SYMBOL(tinydrm_merge_clips);
> >
> > +int tinydrm_fb_dirty(struct drm_framebuffer *fb,
> > +struct drm_file *file_priv,
> > +unsigned int flags, unsigned int color,
> > +struct drm_clip_rect *clips,
> > +unsigned int num_clips)
> > +{
> > + struct tinydrm_device *tdev = fb->dev->dev_private;
> > + struct drm_plane *plane = &tdev->pipe.plane;
> > + int ret = 0;
> > +
> > + drm_modeset_lock(&plane->mutex, NULL);
> > +
> > + /* fbdev can flush even when we're not interested */
> > + if (plane->state->fb == fb) {
> > + mutex_lock(&tdev->dirty_lock);
> > + ret = tdev->fb_dirty(fb, file_priv, flags,
> > +color, clips, num_clips);
> > + mutex_unlock(&tdev->dirty_lock);
> > + }
> > +
> > + drm_modeset_unlock(&plane->mutex);
> > +
> > + if (ret)
> > + dev_err_once(fb->dev->dev,
> > +"Failed to update display %d\n", ret);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL(tinydrm_fb_dirty);
> > +
> > /**
> >* tinydrm_memcpy - Copy clip buffer
> >* @dst: Destination buffer
> > diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
> > b/drivers/gpu/drm/tinydrm/ili9225.c
> > index 089d22798c8b..0874e877b111 100644
> > --- a/drivers/gpu/drm/tinydrm/ili9225.c
> > +++ b/drivers/gpu/drm/tinydrm/ili9225.c
> > @@ -88,14 +88,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
> > bool full;
> > void *tr;
> >
> > - mutex_lock(&tdev->dirty_lock);
> > -
> > if (!mipi->enabled)
> > - goto out_unlock;
> > -
> > - /* fbdev can flush even when we're not interested */
> > - if (tdev->pipe.plane.fb != fb)
> > - goto out_unlock;
> > + return 0;
> >
> > full = tinydrm_merge_clips(&clip, clips, num_clips, flags,
> >fb->width, fb->height);
> > @@ -108,7 +102,7 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
> > tr = mipi->tx_buf;
> > ret = mipi_dbi_buf_copy(mi
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Actually flush interrupts on reset not just wedging (rev2)
== Series Details ==
Series: drm/i915: Actually flush interrupts on reset not just wedging (rev2)
URL : https://patchwork.freedesktop.org/series/40550/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a91768efb72a drm/i915: Actually flush interrupts on reset not just wedging
-:21: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#21:
References: 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
reset")
-:21: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 0f36a85c3bd5 ("drm/i915: Flush
pending interrupt following a GPU reset")'
#21:
References: 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
reset")
total: 1 errors, 1 warnings, 0 checks, 155 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Fix uabi regression by allowing garbage mode->type from userspace
On Thu, Mar 22, 2018 at 08:42:11AM +0100, Thomas Hellstrom wrote:
> On 03/21/2018 10:12 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Apparently xf86-video-vmware leaves the mode->type uninitialized
> > when feeding the mode to the kernel. Thus we have no choice but
> > to accept the garbage in. We'll just ignore any of the bits we
> > don't want. The mode type is just a hint anyway, and more
> > useful for the kernel->userspace direction.
> >
> > Reported-by: Thomas Hellstrom
> > CC: Thomas Hellstrom
> > Cc: Adam Jackson
> > Cc: Alex Deucher
> > Fixes: c6ed6dad5cfb ("drm/uapi: Validate the mode flags/type")
> > References:
> > https://lists.freedesktop.org/archives/dri-devel/2018-March/170213.html
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_modes.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index f6b7c0e36a1a..e82b61e08f8c 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1611,7 +1611,13 @@ int drm_mode_convert_umode(struct drm_device *dev,
> > out->vscan = in->vscan;
> > out->vrefresh = in->vrefresh;
> > out->flags = in->flags;
> > - out->type = in->type;
> > + /*
> > +* Old xf86-video-vmware (possibly others too) used to
> > +* leave 'type' unititialized. Just ignore any bits we
> > +* don't like. It's a just hint after all, and more
> > +* useful for the kernel->userspace direction anyway.
> > +*/
> > + out->type = in->type & DRM_MODE_TYPE_ALL;
> > strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> > out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> >
>
> Tested-by: Thomas Hellstrom
Thanks for the testing and reviews. And sorry for the extra hassle.
Pushed to drm-misc-next-fixes.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3 2/3] tests/gem_eio: Speed up test execution
From: Tvrtko Ursulin
If we stop relying on regular GPU hangs to be detected, but trigger them
manually as soon as we know our batch of interest is actually executing
on the GPU, we can dramatically speed up various subtests.
This is enabled by the pollable spin batch added in the previous patch.
v2:
* Test gem_wait after reset/wedge and with reset/wedge after a few
predefined intervals since gem_wait invocation. (Chris Wilson)
v3:
Chris Wilson:
* Decrease short test to 1us.
* Use POSIX timers instead of signals to avoid interrupting gem_wait.
* Improve comment.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Antonio Argenziano
---
tests/Makefile.am | 1 +
tests/gem_eio.c | 235 +-
tests/meson.build | 8 +-
3 files changed, 189 insertions(+), 55 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index dbc7be722eb9..f41ad5096349 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -130,6 +130,7 @@ gem_userptr_blits_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_userptr_blits_LDADD = $(LDADD) -lpthread
perf_pmu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
+gem_eio_LDADD = $(LDADD) -lrt
gem_wait_LDADD = $(LDADD) -lrt
kms_flip_LDADD = $(LDADD) -lrt -lpthread
pm_rc6_residency_LDADD = $(LDADD) -lrt
diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 4bcc5937db39..b824d9d4c9c0 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -35,6 +35,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -62,6 +64,10 @@ static bool i915_reset_control(bool enable)
static void trigger_reset(int fd)
{
+ struct timespec ts = { };
+
+ igt_nsec_elapsed(&ts);
+
igt_force_gpu_reset(fd);
/* And just check the gpu is indeed running again */
@@ -69,22 +75,12 @@ static void trigger_reset(int fd)
gem_test_engine(fd, ALL_ENGINES);
gem_quiescent_gpu(fd);
-}
-
-static void wedge_gpu(int fd)
-{
- /* First idle the GPU then disable GPU resets before injecting a hang */
- gem_quiescent_gpu(fd);
-
- igt_require(i915_reset_control(false));
-
- igt_debug("Wedging GPU by injecting hang\n");
- igt_post_hang_ring(fd, igt_hang_ring(fd, I915_EXEC_DEFAULT));
- igt_assert(i915_reset_control(true));
+ /* We expect forced reset and health check to be quick. */
+ igt_assert(igt_seconds_elapsed(&ts) < 2);
}
-static void wedgeme(int drm_fd)
+static void manual_hang(int drm_fd)
{
int dir = igt_debugfs_dir(drm_fd);
@@ -93,6 +89,16 @@ static void wedgeme(int drm_fd)
close(dir);
}
+static void wedge_gpu(int fd)
+{
+ /* First idle the GPU then disable GPU resets before injecting a hang */
+ gem_quiescent_gpu(fd);
+
+ igt_require(i915_reset_control(false));
+ manual_hang(fd);
+ igt_assert(i915_reset_control(true));
+}
+
static int __gem_throttle(int fd)
{
int err = 0;
@@ -149,26 +155,124 @@ static int __gem_wait(int fd, uint32_t handle, int64_t
timeout)
return err;
}
-static void test_wait(int fd)
+static igt_spin_t * __spin_poll(int fd, uint32_t ctx, unsigned long flags)
{
- igt_hang_t hang;
+ if (gem_can_store_dword(fd, flags))
+ return __igt_spin_batch_new_poll(fd, ctx, flags);
+ else
+ return __igt_spin_batch_new(fd, ctx, flags, 0);
+}
+
+static void __spin_wait(int fd, igt_spin_t *spin)
+{
+ if (spin->running) {
+ igt_spin_busywait_until_running(spin);
+ } else {
+ igt_debug("__spin_wait - usleep mode\n");
+ usleep(500e3); /* Better than nothing! */
+ }
+}
+
+static igt_spin_t * spin_sync(int fd, uint32_t ctx, unsigned long flags)
+{
+ igt_spin_t *spin = __spin_poll(fd, ctx, flags);
+
+ __spin_wait(fd, spin);
+
+ return spin;
+}
+
+struct hang_ctx {
+ int debugfs;
+ struct timespec ts;
+ timer_t timer;
+};
+
+static void hang_handler(union sigval arg)
+{
+ struct hang_ctx *ctx = arg.sival_ptr;
+
+ igt_debug("hang delay = %.2fus\n", igt_nsec_elapsed(&ctx->ts) / 1000.0);
+
+ igt_assert(igt_sysfs_set(ctx->debugfs, "i915_wedged", "-1"));
+
+ igt_assert_eq(timer_delete(ctx->timer), 0);
+ close(ctx->debugfs);
+ free(ctx);
+}
+
+static void hang_after(int fd, unsigned int us)
+{
+ struct sigevent sev = {
+ .sigev_notify = SIGEV_THREAD,
+ .sigev_notify_function = hang_handler
+ };
+ struct itimerspec its = {
+ .it_value.tv_sec = us / USEC_PER_SEC,
+ .it_value.tv_nsec = us % USEC_PER_SEC * 1000,
+ };
+ struct hang_ctx *ctx;
+
+ ctx = calloc(1, sizeof(*ctx));
+ igt_assert(ctx);
+
+ ctx->debugfs = igt_debugfs_dir(fd);
+ igt_assert_fd(ctx->debugfs);
+
+ sev.sigev_value.sival_ptr = ctx;
+
+ igt_assert_eq(timer_create(CLOCK_MONOTONIC, &sev, &ctx->timer), 0);
+
+
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Actually flush interrupts on reset not just wedging (rev2)
== Series Details == Series: drm/i915: Actually flush interrupts on reset not just wedging (rev2) URL : https://patchwork.freedesktop.org/series/40550/ State : failure == Summary == Series 40550v2 drm/i915: Actually flush interrupts on reset not just wedging https://patchwork.freedesktop.org/api/1.0/series/40550/revisions/2/mbox/ Possible new issues: Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a: pass -> INCOMPLETE (fi-elk-e7500) Known issues: Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:433s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:444s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:539s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:516s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:512s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:519s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:505s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:411s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:510s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:583s fi-elk-e7500 total:229 pass:180 dwarn:1 dfail:0 fail:0 skip:47 fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:318s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:534s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:224 dwarn:0 dfail:0 fail:1 skip:60 time:418s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:471s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:427s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:477s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:473s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:512s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:653s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:441s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:533s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:502s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:503s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:435s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:587s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:401s Blacklisted hosts: fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:568s fi-cnl-psr total:224 pass:198 dwarn:0 dfail:0 fail:1 skip:24 fi-glk-j4005 failed to collect. IGT log at Patchwork_8469/fi-glk-j4005/run0.log cd07c5746555228b6e288618b40f35c8cc5e1270 drm-tip: 2018y-03m-23d-10h-46m-36s UTC integration manifest a91768efb72a drm/i915: Actually flush interrupts on reset not just wedging == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8469/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 2/3] tests/gem_eio: Speed up test execution
Quoting Tvrtko Ursulin (2018-03-23 11:54:28) > From: Tvrtko Ursulin > > If we stop relying on regular GPU hangs to be detected, but trigger them > manually as soon as we know our batch of interest is actually executing > on the GPU, we can dramatically speed up various subtests. > > This is enabled by the pollable spin batch added in the previous patch. > > v2: > * Test gem_wait after reset/wedge and with reset/wedge after a few >predefined intervals since gem_wait invocation. (Chris Wilson) > > v3: > Chris Wilson: > * Decrease short test to 1us. > * Use POSIX timers instead of signals to avoid interrupting gem_wait. > * Improve comment. > > Signed-off-by: Tvrtko Ursulin > Suggested-by: Chris Wilson > Cc: Antonio Argenziano I can't think of anything else that might go wrong, so Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Actually flush interrupts on reset not just wedging (rev2)
Quoting Patchwork (2018-03-23 11:56:41) > == Series Details == > > Series: drm/i915: Actually flush interrupts on reset not just wedging (rev2) > URL : https://patchwork.freedesktop.org/series/40550/ > State : failure > > == Summary == > > Series 40550v2 drm/i915: Actually flush interrupts on reset not just wedging > https://patchwork.freedesktop.org/api/1.0/series/40550/revisions/2/mbox/ > > Possible new issues: > > Test kms_pipe_crc_basic: > Subgroup nonblocking-crc-pipe-a: > pass -> INCOMPLETE (fi-elk-e7500) You call that a failure! I call that an outright success after last time! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 1/2] drm/i915/guc: Fix null pointer dereference when GuC FW is not available
On 3/23/2018 4:53 PM, Piotr Piórkowski wrote:
If GuC firmware is not available on the system and we load i915 with enable
GuC, then we hit this null pointer dereference issue:
Patch looks good but I have query on usage of enable_guc modparam.
enable_guc modparam will enable GuC/HuC only if firmware is available.
If user sets to forcefully enable GuC/HuC on systems that don't have
firmware then it is user's fault.
Michal, could you please clarify.
Thanks,
Sagar
[ 71.098873] BUG: unable to handle kernel NULL pointer dereference at
0008
[ 71.098938] IP: intel_uc_fw_upload+0x1f/0x360 [i915]
[ 71.098947] PGD 0 P4D 0
[ 71.098956] Oops: [#1] PREEMPT SMP PTI
[ 71.098965] Modules linked in: i915(O+) netconsole x86_pkg_temp_thermal
intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
mei_me i2c_i801 prime_numbers mei [last unloaded: i915]
[ 71.099005] CPU: 2 PID: 1167 Comm: insmod Tainted: G U W O
4.16.0-rc1+ #337
[ 71.099018] Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0065.2018.0103.1000
01/03/2018
[ 71.099077] RIP: 0010:intel_uc_fw_upload+0x1f/0x360 [i915]
[ 71.099087] RSP: 0018:c9417aa0 EFLAGS: 00010282
[ 71.099097] RAX: RBX: 88084cad12f8 RCX: a03e9357
[ 71.099108] RDX: 0002 RSI: a034dba0 RDI: 88084cad12f8
[ 71.099118] RBP: 0002 R08: 88085344ca90 R09: 0001
[ 71.099128] R10: R11: R12: 88084cad
[ 71.099139] R13: a034dba0 R14: fff5 R15: 88084cad12b0
[ 71.099151] FS: 7f7f24ae2740() GS:88085e20()
knlGS:
[ 71.099162] CS: 0010 DS: ES: CR0: 80050033
[ 71.099171] CR2: 0008 CR3: 000855f48001 CR4: 003606e0
[ 71.099182] Call Trace:
[ 71.099246] intel_uc_init_hw+0xc8/0x520 [i915]
[ 71.099303] i915_gem_init_hw+0x11f/0x2d0 [i915]
[ 71.099364] i915_gem_init+0x2b9/0x640 [i915]
[ 71.099413] i915_driver_load+0xb74/0x1110 [i915]
[ 71.099462] i915_pci_probe+0x2e/0x90 [i915]
[ 71.099476] pci_device_probe+0xa1/0x130
[ 71.099488] driver_probe_device+0x302/0x470
[ 71.099502] __driver_attach+0xb9/0xe0
[ 71.099513] ? driver_probe_device+0x470/0x470
[ 71.099525] ? driver_probe_device+0x470/0x470
[ 71.099538] bus_for_each_dev+0x64/0x90
[ 71.099550] bus_add_driver+0x164/0x260
[ 71.099561] ? 0xa04d6000
[ 71.099572] driver_register+0x57/0xc0
[ 71.099582] ? 0xa04d6000
[ 71.099593] do_one_initcall+0x3b/0x160
[ 71.099606] ? kmem_cache_alloc_trace+0x1c3/0x2a0
[ 71.099621] do_init_module+0x5b/0x1f9
[ 71.099635] load_module+0x2467/0x2a70
[ 71.099654] ? SyS_finit_module+0xbd/0xe0
[ 71.099668] SyS_finit_module+0xbd/0xe0
[ 71.099682] do_syscall_64+0x73/0x1c0
[ 71.099694] entry_SYSCALL_64_after_hwframe+0x26/0x9b
[ 71.099706] RIP: 0033:0x7f7f23fb40d9
[ 71.099717] RSP: 002b:7ffda7d67ed8 EFLAGS: 0246 ORIG_RAX:
0139
[ 71.099734] RAX: ffda RBX: 55f96e2a8870 RCX: 7f7f23fb40d9
[ 71.099748] RDX: RSI: 55f96e2a8260 RDI: 0003
[ 71.099763] RBP: 55f96e2a8260 R08: R09: 7ffda7d68088
[ 71.099777] R10: 0003 R11: 0246 R12:
[ 71.099791] R13: 55f96e2a8830 R14: R15: 55f96e2a8260
[ 71.099810] Code: 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 41 54
49 89 f5 55 53 48 c7 c1 57 93 3e a0 48 8b 47 10 48 89 fb 4c 8b 07 <48> 8b 68 08
8b 47 28 85 c0 74 15 83 f8 01 48 c7 c1 5b 93 3e a0
[ 71.14] RIP: intel_uc_fw_upload+0x1f/0x360 [i915] RSP: c9417aa0
[ 71.100020] CR2: 0008
[ 71.100031] ---[ end trace d8ac93c30ceff5b2 ]--
Fixes: 6b0478fb722a ("drm/i915: Implement dynamic GuC WOPCM offset and size
calculation")
v2: don't assume it is always GuC FW (Michal)
v3: added a new variable to avoid exceeding the number of characters in the
line (Michal)
Signed-off-by: Piotr Piórkowski
Reported-by: Radoslaw Szwichtenberg
Cc: Michał Winiarski
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Joonas Lahtinen
Cc: Jackie Li
Cc: Radoslaw Szwichtenberg
Reviewed-by: Michal Wajdeczko
Reviewed-by: Jackie Li
---
drivers/gpu/drm/i915/intel_uc_fw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c
b/drivers/gpu/drm/i915/intel_uc_fw.c
index 30c73243f54d..93b0fc661b3a 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -199,9 +199,9 @@ int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
int (*xfer)(struct intel_uc_fw *uc_fw,
struct i915_vma *vma))
{
- struct drm_i915_private *i915 = to_i915(uc_fw->obj->base.dev);
struct i915_vma *vma;
int err;
+ u32 ggtt_pin_bias;
DRM_DEB
Re: [Intel-gfx] [PATCH v4 0/8] cgroup private data and DRM/i915 integration
Quoting Matt Roper (2018-03-17 02:08:57) > This is the fourth iteration of the work previously posted here: > (v1) > https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html > (v2) > https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html > (v3) https://lists.freedesktop.org/archives/intel-gfx/2018-March/157928.html > > The high level goal of this work is to allow non-cgroup-controller parts > of the kernel (e.g., device drivers) to register their own private > policy data for specific cgroups. That mechanism is then made use of in > the i915 graphics driver to allow GPU priority to be assigned according > to the cgroup membership of the owning process. Please see the v1 cover > letter linked above for a more in-depth explanation and justification. Hi Matt, For cross-subsystem changes such as this, it makes sense to Cc all relevant maintainers, especially if there have been previous comments to earlier revisions. Please, do include and keep a reference to the userspace portion of the changes when you suggest new uAPI to be added. At least I have some trouble trying to track down the relevant interface consumer here. I'm unsure how much sense it makes to commence with detailed i915 review if we will be blocked by lack of userspace after that? I'm assuming you've read through [1] already. Regards, Joonas [1] https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 1/2] drm/i915/guc: Fix null pointer dereference when GuC FW is not available
On Fri, 23 Mar 2018 13:07:15 +0100, Sagar Arun Kamble wrote: On 3/23/2018 4:53 PM, Piotr Piórkowski wrote: If GuC firmware is not available on the system and we load i915 with enable GuC, then we hit this null pointer dereference issue: Patch looks good but I have query on usage of enable_guc modparam. enable_guc modparam will enable GuC/HuC only if firmware is available. During modparam sanitization phase, code will only check for firmware name, code will attempt to check if firmware file exists. If user sets to forcefully enable GuC/HuC on systems that don't have firmware then it is user's fault. Sure its user's fault, but event in such case we should just gracefully abort driver load, without any NULL pointer BUG ;) And note, that we will hit this bug not only when user force GuC with: enable_guc=1 guc_firmware_path=/does/not/exist but also when user just specify auto mode: enable_guc=-1 when predefined firmwares are not present (not installed or removed) /m Michal, could you please clarify. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Include submission tasklet state in engine dump
For the off-chance we have an interrupt posted and haven't processed the CSB. v2: Include tasklet enable/disable state for good measure. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_engine_cs.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index de09fa42a509..12486d8f534b 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -1859,12 +1859,15 @@ static void intel_engine_print_registers(const struct intel_engine_cs *engine, ptr = I915_READ(RING_CONTEXT_STATUS_PTR(engine)); read = GEN8_CSB_READ_PTR(ptr); write = GEN8_CSB_WRITE_PTR(ptr); - drm_printf(m, "\tExeclist CSB read %d [%d cached], write %d [%d from hws], interrupt posted? %s\n", + drm_printf(m, "\tExeclist CSB read %d [%d cached], write %d [%d from hws], interrupt posted? %s, tasklet queued? %s (%s)\n", read, execlists->csb_head, write, intel_read_status_page(engine, intel_hws_csb_write_index(engine->i915)), yesno(test_bit(ENGINE_IRQ_EXECLIST, - &engine->irq_posted))); + &engine->irq_posted)), + yesno(test_bit(TASKLET_STATE_SCHED, + &engine->execlists.tasklet.state)), + enableddisabled(!atomic_read(&engine->execlists.tasklet.count))); if (read >= GEN8_CSB_ENTRIES) read = 0; if (write >= GEN8_CSB_ENTRIES) -- 2.16.2 ___ 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: Reorder early initialization
On Thu, 22 Mar 2018 21:48:16 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2018-03-22 20:36:57)
/snip/
@@ -962,8 +961,8 @@ static int i915_driver_init_early(struct
drm_i915_private *dev_priv,
*/
static void i915_driver_cleanup_early(struct drm_i915_private
*dev_priv)
{
- i915_gem_load_cleanup(dev_priv);
intel_irq_fini(dev_priv);
+ i915_gem_load_cleanup(dev_priv);
Ok, onion preserved.
For symmetry, I'll also rename this to i915_gem_cleanup_early
/m
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Skip logging impossible slices
Quoting Jani Nikula (2018-03-21 14:16:37)
> On Wed, 21 Mar 2018, Chris Wilson wrote:
> > Quoting Jani Nikula (2018-03-21 11:47:06)
> >>
> >> > Quoting Chris Wilson (2018-03-21 10:41:37)
> >> >>
> >> >> Just idly testing the waters...
> >> >>
> >> >> In yaml, this would be
> >> >> "- slice%d: { subslices: %u, mask: 0x%04x }\n"
> >> >
> >> > Or if we keep the node name the same for easier parsing:
> >> >
> >> > "- slice: { id:%u, subslices:%u, mask:0x%04x }\n"
> >>
> >> I'm not against doing this, especially for gpu dumps.
> >>
> >> Wouldn't json be easier to generate and parse? Or do you prefer the
> >> slightly better human readability of yaml?
> >
> > I think for any of the debug output preferring to keep it as readable as
> > possible is essential. libyaml isn't that hard to use, even for a
> > beginner like myself.
>
> Fair enough; I'm only familiar with json, and that's my natural reason
> to lean towards it.
JSON gets irritating to look at by plain eye. So I would agree that YAML
would serve better when developers are likely to scroll through the file
contents manually, too.
Then some more random thoughts:
This discussion will of course bring closer the can of forms that when
we've formalized the debugfs format, does somebody expect it to stay
more stable than not?
Having a counterpart in IGT and making that always match kernel, would
be the obvious way to keep things sane.
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915/guc: Move FW size sanity check back to fetch
While we need to know WOPCM size to do this sanity check, it has more to
do with FW than with WOPCM. Let's move the check to fetch phase, it's
not like WOPCM is going to grow in the meantime. We're also reducing
some of the code movement in following patches.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Jackie Li
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_uc_fw.c | 13 -
drivers/gpu/drm/i915/intel_wopcm.c | 12
2 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c
b/drivers/gpu/drm/i915/intel_uc_fw.c
index 30c73243f54d..2ec8ec1c8b95 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -46,6 +46,8 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
size_t size;
int err;
+ GEM_BUG_ON(!dev_priv->wopcm.size);
+
DRM_DEBUG_DRIVER("%s fw fetch %s\n",
intel_uc_fw_type_repr(uc_fw->type), uc_fw->path);
@@ -105,8 +107,17 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
uc_fw->rsa_offset = uc_fw->ucode_offset + uc_fw->ucode_size;
uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
+ /* Sanity check whether our fw is not larger than our whole memory */
+ size = uc_fw->header_size + uc_fw->ucode_size;
+ if (size >= dev_priv->wopcm.size) {
+ DRM_ERROR("%s: (%zuKiB) is too big to fit in WOPCM.",
+ intel_uc_fw_type_repr(uc_fw->type), size / 1024);
+ err = -E2BIG;
+ goto fail;
+ }
+
/* At least, it should have header, uCode and RSA. Size of all three. */
- size = uc_fw->header_size + uc_fw->ucode_size + uc_fw->rsa_size;
+ size += uc_fw->rsa_size;
if (fw->size < size) {
DRM_WARN("%s: Truncated firmware (%zu, expected %zu)\n",
intel_uc_fw_type_repr(uc_fw->type), fw->size, size);
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 4117886bfb05..42876f8890e7 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -163,18 +163,6 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
GEM_BUG_ON(!wopcm->size);
- if (guc_fw_size >= wopcm->size) {
- DRM_ERROR("GuC FW (%uKiB) is too big to fit in WOPCM.",
- guc_fw_size / 1024);
- return -E2BIG;
- }
-
- if (huc_fw_size >= wopcm->size) {
- DRM_ERROR("HuC FW (%uKiB) is too big to fit in WOPCM.",
- huc_fw_size / 1024);
- return -E2BIG;
- }
-
guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
GUC_WOPCM_OFFSET_ALIGNMENT);
if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915/guc: Use _FW variants for mmio access in GuC irq handler
We're seeing "RPM wakelock ref not held during HW access" warning otherwise. And since IRQ are synced for runtime suspend, we can use the variant without wakeref assert. Reported-by: Marta Löfstedt Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105710 Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Marta Löfstedt Cc: Michal Wajdeczko --- drivers/gpu/drm/i915/intel_guc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 8f93f5bef8fd..6787a3116783 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -391,9 +391,9 @@ void intel_guc_to_host_event_handler(struct intel_guc *guc) * clears out the bit on handling the 1st interrupt. */ spin_lock(&guc->irq_lock); - val = I915_READ(SOFT_SCRATCH(15)); + val = I915_READ_FW(SOFT_SCRATCH(15)); msg = val & guc->msg_enabled_mask; - I915_WRITE(SOFT_SCRATCH(15), val & ~msg); + I915_WRITE_FW(SOFT_SCRATCH(15), val & ~msg); spin_unlock(&guc->irq_lock); if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER | -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915/guc: Separate WOPCM partitioning from constraints check
In the following patches we're going to support constraints checking on
an already locked partitioning. Let's structure the code now to allow
for code reuse and reduce the churn later on.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Jackie Li
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_wopcm.c | 141 +++--
1 file changed, 102 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 50854a6b9493..52841d340002 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -84,6 +84,17 @@ static inline u32 context_reserved_size(struct
drm_i915_private *i915)
return 0;
}
+static inline u32 guc_fw_size_in_wopcm(u32 guc_fw_size)
+{
+ return ALIGN(guc_fw_size + GUC_WOPCM_RESERVED +
+GUC_WOPCM_STACK_RESERVED, PAGE_SIZE);
+}
+
+static inline u32 huc_fw_size_in_wopcm(u32 huc_fw_size)
+{
+ return huc_fw_size + WOPCM_RESERVED_SIZE;
+}
+
static u32
gen9_size_for_dword_gap_restriction(u32 guc_wopcm_base, u32 guc_wopcm_size)
{
@@ -121,19 +132,54 @@ gen9_size_for_huc_restriction(u32 guc_wopcm_size, u32
huc_fw_size)
return additional_size;
}
-static inline int check_hw_restriction(struct drm_i915_private *i915,
- u32 guc_wopcm_base, u32 guc_wopcm_size,
- u32 huc_fw_size)
+static int check_huc_fw_fits(struct intel_wopcm *wopcm, u32 huc_fw_size)
+{
+ if (huc_fw_size_in_wopcm(huc_fw_size) > wopcm->guc.base) {
+ DRM_ERROR("Need %uKiB WOPCM for HuC, %uKiB available.\n",
+ huc_fw_size_in_wopcm(huc_fw_size) / 1024,
+ wopcm->guc.base / 1024);
+ return -E2BIG;
+ }
+
+ return 0;
+}
+
+static int check_guc_fw_fits(struct intel_wopcm *wopcm, u32 guc_fw_size)
+{
+ if (guc_fw_size_in_wopcm(guc_fw_size) > wopcm->guc.size) {
+ DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
+ huc_fw_size_in_wopcm(guc_fw_size) / 1024,
+ wopcm->guc.size / 1024);
+ return -E2BIG;
+ }
+
+ return 0;
+}
+
+static int check_ctx_rsvd_fits(struct intel_wopcm *wopcm, u32 ctx_rsvd)
+{
+ if ((wopcm->guc.base + wopcm->guc.size + ctx_rsvd) > wopcm->size) {
+ DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
+ wopcm->guc.base / 1024);
+ return -E2BIG;
+ }
+
+ return 0;
+}
+
+static int wopcm_check_hw_restrictions(struct intel_wopcm *wopcm)
{
+ struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
+ u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
u32 size;
if (IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)) {
- size = gen9_size_for_dword_gap_restriction(guc_wopcm_base,
- guc_wopcm_size);
+ size = gen9_size_for_dword_gap_restriction(wopcm->guc.base,
+ wopcm->guc.size);
if (size)
goto err;
- size = gen9_size_for_huc_restriction(guc_wopcm_size,
+ size = gen9_size_for_huc_restriction(wopcm->guc.size,
huc_fw_size);
if (size)
goto err;
@@ -143,12 +189,54 @@ static inline int check_hw_restriction(struct
drm_i915_private *i915,
err:
DRM_ERROR("GuC WOPCM size %uKiB is too small. %uKiB more needed.\n",
- guc_wopcm_size / 1024,
+ wopcm->guc.size / 1024,
size / 1024);
return -E2BIG;
}
+static bool wopcm_check_components_fit(struct intel_wopcm *wopcm)
+{
+ struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
+ u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
+ u32 guc_fw_size = intel_uc_fw_get_upload_size(&i915->guc.fw);
+ u32 ctx_rsvd = context_reserved_size(i915);
+ int err;
+
+ err = check_huc_fw_fits(wopcm, huc_fw_size);
+ if (err)
+ return err;
+
+ err = check_guc_fw_fits(wopcm, guc_fw_size);
+ if (err)
+ return err;
+
+ err = check_ctx_rsvd_fits(wopcm, ctx_rsvd);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int wopcm_guc_init(struct intel_wopcm *wopcm)
+{
+ struct drm_i915_private *dev_priv = wopcm_to_i915(wopcm);
+ u32 huc_fw_size = intel_uc_fw_get_upload_size(&dev_priv->huc.fw);
+ u32 ctx_rsvd = context_reserved_size(dev_priv);
+
+ wopcm->guc.base = ALIGN_DOWN(huc_fw_size_in_wopcm(huc_fw_size),
+GUC_WOPCM_OFFSET_ALIGNMENT);
+
+ wopcm->guc.size = ALIGN(wopcm->size - wopcm->guc.
[Intel-gfx] [PATCH 3/8] drm/i915/guc: Extend the GEN9 WOPCM HW restrictions to early CNL
We imposed additional restrictions to GEN9 WOPCM partitioning. However,
we ignored early steppings of CNL, to which those restrictions also
apply. Let's also tweak the logic a bit by having separate helpers for
returning extra size needed for the restriction to be satisfied, and
handle the results in the caller.
References: 6b0478fb722a ("drm/i915: Implement dynamic GuC WOPCM offset and
size calculation")
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Jackie Li
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_wopcm.c | 63 ++
1 file changed, 37 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 42876f8890e7..50854a6b9493 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -84,58 +84,69 @@ static inline u32 context_reserved_size(struct
drm_i915_private *i915)
return 0;
}
-static inline int gen9_check_dword_gap(u32 guc_wopcm_base, u32 guc_wopcm_size)
+static u32
+gen9_size_for_dword_gap_restriction(u32 guc_wopcm_base, u32 guc_wopcm_size)
{
- u32 offset;
+ s32 additional_size;
/*
* GuC WOPCM size shall be at least a dword larger than the offset from
* WOPCM base (GuC WOPCM offset from WOPCM base + GEN9_GUC_WOPCM_OFFSET)
* due to hardware limitation on Gen9.
*/
- offset = guc_wopcm_base + GEN9_GUC_WOPCM_OFFSET;
- if (offset > guc_wopcm_size ||
- (guc_wopcm_size - offset) < sizeof(u32)) {
- DRM_ERROR("GuC WOPCM size %uKiB is too small. %uKiB needed.\n",
- guc_wopcm_size / 1024,
- (u32)(offset + sizeof(u32)) / 1024);
- return -E2BIG;
- }
+ additional_size = guc_wopcm_base + GEN9_GUC_WOPCM_OFFSET +
+ sizeof(u32) - guc_wopcm_size;
- return 0;
+ if (additional_size <= 0)
+ return 0;
+
+ return additional_size;
}
-static inline int gen9_check_huc_fw_fits(u32 guc_wopcm_size, u32 huc_fw_size)
+static u32
+gen9_size_for_huc_restriction(u32 guc_wopcm_size, u32 huc_fw_size)
{
+ s32 additional_size;
+
/*
* On Gen9 & CNL A0, hardware requires the total available GuC WOPCM
* size to be larger than or equal to HuC firmware size. Otherwise,
* firmware uploading would fail.
*/
- if (huc_fw_size > guc_wopcm_size - GUC_WOPCM_RESERVED) {
- DRM_ERROR("HuC FW (%uKiB) won't fit in GuC WOPCM (%uKiB).\n",
- huc_fw_size / 1024,
- (guc_wopcm_size - GUC_WOPCM_RESERVED) / 1024);
- return -E2BIG;
- }
+ additional_size = huc_fw_size - (guc_wopcm_size - GUC_WOPCM_RESERVED);
- return 0;
+ if (additional_size <= 0)
+ return 0;
+
+ return additional_size;
}
static inline int check_hw_restriction(struct drm_i915_private *i915,
u32 guc_wopcm_base, u32 guc_wopcm_size,
u32 huc_fw_size)
{
- int err = 0;
+ u32 size;
+
+ if (IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)) {
+ size = gen9_size_for_dword_gap_restriction(guc_wopcm_base,
+ guc_wopcm_size);
+ if (size)
+ goto err;
+
+ size = gen9_size_for_huc_restriction(guc_wopcm_size,
+huc_fw_size);
+ if (size)
+ goto err;
+ }
- if (IS_GEN9(i915))
- err = gen9_check_dword_gap(guc_wopcm_base, guc_wopcm_size);
+ return 0;
- if (!err &&
- (IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)))
- err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
+err:
+ DRM_ERROR("GuC WOPCM size %uKiB is too small. %uKiB more needed.\n",
+ guc_wopcm_size / 1024,
+ size / 1024);
- return err;
+ return -E2BIG;
}
/**
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915/guc: Use GuC FW size and HW restrictions to determine WOPCM partition
We need GuC to load HuC, but it's also possible for GuC to operate on
its own. We don't know what the size of HuC FW may be, so, not wanting
to make any platform-specific hardcoded guesses, we assume that its size
is 0... Which is a very bad approximation.
This has a very unfortunate consequence - once we've booted with GuC and
no HuC, we'll never be able to load HuC (unless we reboot, since the
registers are locked).
Rather than using unknown values in our computations - let's partition
based on GuC size.
We have one HW restriction where we're using HuC size (GuC size needs to
be roughly similar to HuC size - which may be unknown at this point),
luckily, another HW restriction makes it very unlikely to run in any
sort of issues in this case.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Jackie Li
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_wopcm.c | 60 +-
1 file changed, 34 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 52841d340002..295d302e97b9 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -167,7 +167,22 @@ static int check_ctx_rsvd_fits(struct intel_wopcm *wopcm,
u32 ctx_rsvd)
return 0;
}
-static int wopcm_check_hw_restrictions(struct intel_wopcm *wopcm)
+static inline void
+__guc_region_grow(struct intel_wopcm *wopcm, u32 size)
+{
+ /*
+* We're growing guc region in the direction of lower addresses.
+* We need to use multiples of base alignment, because it has more
+* strict alignment rules.
+*/
+ size = DIV_ROUND_UP(size, 2);
+ size = ALIGN(size, GUC_WOPCM_OFFSET_ALIGNMENT);
+
+ wopcm->guc.base -= size;
+ wopcm->guc.size += size;
+}
+
+static void wopcm_adjust_for_hw_restrictions(struct intel_wopcm *wopcm)
{
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
@@ -177,22 +192,18 @@ static int wopcm_check_hw_restrictions(struct intel_wopcm
*wopcm)
size = gen9_size_for_dword_gap_restriction(wopcm->guc.base,
wopcm->guc.size);
if (size)
- goto err;
+ __guc_region_grow(wopcm, size);
size = gen9_size_for_huc_restriction(wopcm->guc.size,
huc_fw_size);
if (size)
- goto err;
- }
-
- return 0;
+ __guc_region_grow(wopcm, size);
-err:
- DRM_ERROR("GuC WOPCM size %uKiB is too small. %uKiB more needed.\n",
- wopcm->guc.size / 1024,
- size / 1024);
-
- return -E2BIG;
+ GEM_BUG_ON(gen9_size_for_dword_gap_restriction(wopcm->guc.base,
+
wopcm->guc.size));
+ GEM_BUG_ON(gen9_size_for_huc_restriction(wopcm->guc.size,
+huc_fw_size));
+ }
}
static bool wopcm_check_components_fit(struct intel_wopcm *wopcm)
@@ -218,21 +229,16 @@ static bool wopcm_check_components_fit(struct intel_wopcm
*wopcm)
return 0;
}
-static int wopcm_guc_init(struct intel_wopcm *wopcm)
+static int wopcm_guc_region_init(struct intel_wopcm *wopcm)
{
struct drm_i915_private *dev_priv = wopcm_to_i915(wopcm);
- u32 huc_fw_size = intel_uc_fw_get_upload_size(&dev_priv->huc.fw);
+ u32 guc_fw_size = intel_uc_fw_get_upload_size(&dev_priv->guc.fw);
u32 ctx_rsvd = context_reserved_size(dev_priv);
- wopcm->guc.base = ALIGN_DOWN(huc_fw_size_in_wopcm(huc_fw_size),
-GUC_WOPCM_OFFSET_ALIGNMENT);
+ wopcm->guc.size = guc_fw_size_in_wopcm(guc_fw_size);
- wopcm->guc.size = ALIGN(wopcm->size - wopcm->guc.base - ctx_rsvd,
- PAGE_SIZE);
-
- DRM_DEBUG_DRIVER("GuC WOPCM Region: [%uKiB, %uKiB)\n",
-wopcm->guc.base / 1024,
-(wopcm->guc.base + wopcm->guc.size) / 1024);
+ wopcm->guc.base = ALIGN_DOWN(wopcm->size - ctx_rsvd - wopcm->guc.size,
+GUC_WOPCM_OFFSET_ALIGNMENT);
return 0;
}
@@ -255,18 +261,20 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
GEM_BUG_ON(!wopcm->size);
- err = wopcm_guc_init(wopcm);
+ err = wopcm_guc_region_init(wopcm);
if (err)
return err;
- err = wopcm_check_hw_restrictions(wopcm);
- if (err)
- return err;
+ wopcm_adjust_for_hw_restrictions(wopcm);
err = wopcm_check_components_fit(wopcm);
if (err)
return err;
+ DRM_DEBUG_DRIVER("GuC WOPCM Region: [%uKiB, %uKiB)\n",
+
[Intel-gfx] [PATCH 6/8] drm/i915/guc: Don't give up on WOPCM partitioning regs mismatch
It's possible that when we're being loaded, the write-once registers were
already programmed. It's also possible, that values present in those registers
match our FW size and HW restrictions.
Rather than failing the module load when we detect any differences from our
preferred values, let's replace them with what's present in the registers,
failing the load only if we're unable to satisfy the constraints.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Jackie Li
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_gem.c| 6 +--
drivers/gpu/drm/i915/intel_wopcm.c | 107 +++--
drivers/gpu/drm/i915/intel_wopcm.h | 6 ++-
3 files changed, 60 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 802df8e1a544..1b25eadc5940 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5154,11 +5154,7 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
goto out;
}
- ret = intel_wopcm_init_hw(&dev_priv->wopcm);
- if (ret) {
- DRM_ERROR("Enabling WOPCM failed (%d)\n", ret);
- goto out;
- }
+ intel_wopcm_init_hw(&dev_priv->wopcm);
/* We can't enable contexts until all firmware is loaded */
ret = intel_uc_init_hw(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 295d302e97b9..be8fca80aeca 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -182,7 +182,7 @@ __guc_region_grow(struct intel_wopcm *wopcm, u32 size)
wopcm->guc.size += size;
}
-static void wopcm_adjust_for_hw_restrictions(struct intel_wopcm *wopcm)
+static int wopcm_adjust_for_hw_restrictions(struct intel_wopcm *wopcm)
{
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
@@ -191,19 +191,29 @@ static void wopcm_adjust_for_hw_restrictions(struct
intel_wopcm *wopcm)
if (IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)) {
size = gen9_size_for_dword_gap_restriction(wopcm->guc.base,
wopcm->guc.size);
- if (size)
+ if (size) {
+ if (wopcm->guc.base_locked || wopcm->guc.size_locked)
+ return -E2BIG;
+
__guc_region_grow(wopcm, size);
+ }
size = gen9_size_for_huc_restriction(wopcm->guc.size,
huc_fw_size);
- if (size)
+ if (size) {
+ if (wopcm->guc.base_locked || wopcm->guc.size_locked)
+ return -E2BIG;
+
__guc_region_grow(wopcm, size);
+ }
GEM_BUG_ON(gen9_size_for_dword_gap_restriction(wopcm->guc.base,
wopcm->guc.size));
GEM_BUG_ON(gen9_size_for_huc_restriction(wopcm->guc.size,
huc_fw_size));
}
+
+ return 0;
}
static bool wopcm_check_components_fit(struct intel_wopcm *wopcm)
@@ -233,12 +243,30 @@ static int wopcm_guc_region_init(struct intel_wopcm
*wopcm)
{
struct drm_i915_private *dev_priv = wopcm_to_i915(wopcm);
u32 guc_fw_size = intel_uc_fw_get_upload_size(&dev_priv->guc.fw);
+ u32 huc_fw_size = intel_uc_fw_get_upload_size(&dev_priv->huc.fw);
u32 ctx_rsvd = context_reserved_size(dev_priv);
+ u32 reg_val;
- wopcm->guc.size = guc_fw_size_in_wopcm(guc_fw_size);
+ reg_val = I915_READ(GUC_WOPCM_SIZE);
+ if (reg_val & GUC_WOPCM_SIZE_LOCKED) {
+ wopcm->guc.size = (reg_val & GUC_WOPCM_SIZE_MASK);
+ wopcm->guc.size_locked = true;
+ } else {
+ wopcm->guc.size = guc_fw_size_in_wopcm(guc_fw_size);
+ }
- wopcm->guc.base = ALIGN_DOWN(wopcm->size - ctx_rsvd - wopcm->guc.size,
-GUC_WOPCM_OFFSET_ALIGNMENT);
+ reg_val = I915_READ(DMA_GUC_WOPCM_OFFSET);
+ if (reg_val & GUC_WOPCM_OFFSET_VALID) {
+ if (huc_fw_size && !(reg_val & HUC_LOADING_AGENT_GUC))
+ return -EIO;
+
+ wopcm->guc.base = (reg_val & GUC_WOPCM_OFFSET_MASK);
+ wopcm->guc.base_locked = true;
+ } else {
+ wopcm->guc.base = ALIGN_DOWN(wopcm->size - wopcm->guc.size -
+ctx_rsvd,
+GUC_WOPCM_OFFSET_ALIGNMENT);
+ }
return 0;
}
@@ -265,7 +293,9 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
if (err)
return err;
- wopcm_adjust_for_hw_restr
[Intel-gfx] [PATCH 7/8] drm/i915/guc: Don't touch WOPCM if we're not using GuC
We probably shouldn't print out WOPCM size on platforms that don't have
GuC. We also want to make sure we don't hit any asserts if user explicitly
sets enable_guc != 0 on non-guc platforms.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Jackie Li
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_wopcm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index be8fca80aeca..828800ca119c 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -69,6 +69,9 @@
*/
void intel_wopcm_init_early(struct intel_wopcm *wopcm)
{
+ if (!HAS_GUC(wopcm_to_i915(wopcm)))
+ return;
+
wopcm->size = GEN9_WOPCM_SIZE;
DRM_DEBUG_DRIVER("WOPCM size: %uKiB\n", wopcm->size / 1024);
@@ -285,8 +288,12 @@ static int wopcm_guc_region_init(struct intel_wopcm *wopcm)
*/
int intel_wopcm_init(struct intel_wopcm *wopcm)
{
+ struct drm_i915_private *dev_priv = wopcm_to_i915(wopcm);
int err;
+ if (!HAS_GUC(dev_priv) || !USES_GUC(dev_priv))
+ return 0;
+
GEM_BUG_ON(!wopcm->size);
err = wopcm_guc_region_init(wopcm);
@@ -319,10 +326,9 @@ void intel_wopcm_init_hw(struct intel_wopcm *wopcm)
{
struct drm_i915_private *dev_priv = wopcm_to_i915(wopcm);
- if (!USES_GUC(dev_priv))
+ if (!HAS_GUC(dev_priv) || !USES_GUC(dev_priv))
return;
- GEM_BUG_ON(!HAS_GUC(dev_priv));
GEM_BUG_ON(!wopcm->guc.size);
GEM_BUG_ON(!wopcm->guc.base);
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] HAX enable guc for CI
--- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c96360398072..53037b5eff22 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ struct drm_printer; param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Actually flush interrupts on reset not just wedging
Chris Wilson writes:
> Commit 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
> reset") got confused and only applied the flush to the set-wedge path
> (which itself is proving troublesome), but we also need the
> serialisation on the regular reset path. Oops.
>
> Move the interrupt into reset_irq() and make it common to the reset and
> final set-wedge.
>
> v2: reset_irq() after port cancellation, as we assert that
> execlists->active is sane for cancellation (and is being reset by
> reset_irq).
>
> References: 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
> reset")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Michel Thierry
> Cc: Michał Winiarski
> Cc: Jeff McGee
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 107
> +++
> 1 file changed, 53 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index ce09c5ad334f..b4ab06b05e58 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -740,6 +740,57 @@ execlists_cancel_port_requests(struct
> intel_engine_execlists * const execlists)
> }
> }
>
> +static void clear_gtiir(struct intel_engine_cs *engine)
> +{
> + static const u8 gtiir[] = {
> + [RCS] = 0,
> + [BCS] = 0,
> + [VCS] = 1,
> + [VCS2] = 1,
> + [VECS] = 3,
> + };
> + struct drm_i915_private *dev_priv = engine->i915;
> + int i;
> +
> + /* TODO: correctly reset irqs for gen11 */
> + if (WARN_ON_ONCE(INTEL_GEN(engine->i915) >= 11))
> + return;
> +
> + GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
> +
> + /*
> + * Clear any pending interrupt state.
> + *
> + * We do it twice out of paranoia that some of the IIR are
> + * double buffered, and so if we only reset it once there may
> + * still be an interrupt pending.
> + */
> + for (i = 0; i < 2; i++) {
> + I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
> +engine->irq_keep_mask);
> + POSTING_READ(GEN8_GT_IIR(gtiir[engine->id]));
> + }
> + GEM_BUG_ON(I915_READ(GEN8_GT_IIR(gtiir[engine->id])) &
> +engine->irq_keep_mask);
> +}
> +
> +static void reset_irq(struct intel_engine_cs *engine)
> +{
> + /* Mark all CS interrupts as complete */
> + smp_store_mb(engine->execlists.active, 0);
> + synchronize_hardirq(engine->i915->drm.irq);
> +
> + clear_gtiir(engine);
> +
> + /*
> + * The port is checked prior to scheduling a tasklet, but
> + * just in case we have suspended the tasklet to do the
> + * wedging make sure that when it wakes, it decides there
> + * is no work to do by clearing the irq_posted bit.
> + */
> + clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> +}
> +
> static void execlists_cancel_requests(struct intel_engine_cs *engine)
> {
> struct intel_engine_execlists * const execlists = &engine->execlists;
> @@ -767,6 +818,7 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
>
> /* Cancel the requests on the HW and clear the ELSP tracker. */
> execlists_cancel_port_requests(execlists);
> + reset_irq(engine);
>
> spin_lock(&engine->timeline->lock);
>
> @@ -805,18 +857,6 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
>
> spin_unlock(&engine->timeline->lock);
>
> - /* Mark all CS interrupts as complete */
> - smp_store_mb(execlists->active, 0);
> - synchronize_hardirq(engine->i915->drm.irq);
> -
> - /*
> - * The port is checked prior to scheduling a tasklet, but
> - * just in case we have suspended the tasklet to do the
> - * wedging make sure that when it wakes, it decides there
> - * is no work to do by clearing the irq_posted bit.
> - */
> - clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> -
> local_irq_restore(flags);
> }
>
> @@ -1566,14 +1606,6 @@ static int intel_init_workaround_bb(struct
> intel_engine_cs *engine)
> return ret;
> }
>
> -static u8 gtiir[] = {
> - [RCS] = 0,
> - [BCS] = 0,
> - [VCS] = 1,
> - [VCS2] = 1,
> - [VECS] = 3,
> -};
> -
> static void enable_execlists(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *dev_priv = engine->i915;
> @@ -1657,35 +1689,6 @@ static int gen9_init_render_ring(struct
> intel_engine_cs *engine)
> return init_workarounds_ring(engine);
> }
>
> -static void reset_irq(struct intel_engine_cs *engine)
> -{
> - struct drm_i915_private *dev_priv = engine->i915;
> - int i;
> -
> - /* TODO: correctly reset irqs for gen11 */
> - if (WARN_ON_ONCE(INTEL_GEN(engine->i915) >= 11))
> - return;
> -
> - GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
> -
> - /*
> - * Clear any pending in
Re: [Intel-gfx] [PATCH] drm/i915: Skip logging impossible slices
Quoting Joonas Lahtinen (2018-03-23 12:29:54)
> Quoting Jani Nikula (2018-03-21 14:16:37)
> > On Wed, 21 Mar 2018, Chris Wilson wrote:
> > > Quoting Jani Nikula (2018-03-21 11:47:06)
> > >>
> > >> > Quoting Chris Wilson (2018-03-21 10:41:37)
> > >> >>
> > >> >> Just idly testing the waters...
> > >> >>
> > >> >> In yaml, this would be
> > >> >> "- slice%d: { subslices: %u, mask: 0x%04x }\n"
> > >> >
> > >> > Or if we keep the node name the same for easier parsing:
> > >> >
> > >> > "- slice: { id:%u, subslices:%u, mask:0x%04x }\n"
> > >>
> > >> I'm not against doing this, especially for gpu dumps.
> > >>
> > >> Wouldn't json be easier to generate and parse? Or do you prefer the
> > >> slightly better human readability of yaml?
> > >
> > > I think for any of the debug output preferring to keep it as readable as
> > > possible is essential. libyaml isn't that hard to use, even for a
> > > beginner like myself.
> >
> > Fair enough; I'm only familiar with json, and that's my natural reason
> > to lean towards it.
>
> JSON gets irritating to look at by plain eye. So I would agree that YAML
> would serve better when developers are likely to scroll through the file
> contents manually, too.
>
> Then some more random thoughts:
>
> This discussion will of course bring closer the can of forms that when
> we've formalized the debugfs format, does somebody expect it to stay
> more stable than not?
The starting point is that we do want to transition to an
easier-to-extend file format for sysfs (the idea of it being
single-valued is long gone :) There having a stable interface is without
question, so getting the transition right is the challenge and then
maintaining the hierarchy such that it is backwards and forward
compatible with new content.
> Having a counterpart in IGT and making that always match kernel, would
> be the obvious way to keep things sane.
Imo, if we aren't parsing debugfs in igt, then they can be dead code
eliminated. So I expect yamlification to snow ball once we've got the
first few done and a good feel for how to design kernel/igt API to suite
us. Then it's just a matter of throwing each debugfs through a yamllint
:)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/3] HAX: Enable GuC for CI
Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/3] drm/i915/uc: Fetch uC firmware in init_early
We were fetching uC firmwares in separate uc_init_fw step, while
there is no reason why we can't fetch them during init_early.
This will also simplify upcoming patches, as size of the firmware
may be used for register initialization.
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 8 ++--
drivers/gpu/drm/i915/intel_guc_fw.c | 5 ++---
drivers/gpu/drm/i915/intel_huc_fw.c | 5 ++---
drivers/gpu/drm/i915/intel_uc.c | 37 ++---
drivers/gpu/drm/i915/intel_uc.h | 3 +--
5 files changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2561974..db22337 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -692,11 +692,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
- intel_uc_init_fw(dev_priv);
-
ret = i915_gem_init(dev_priv);
if (ret)
- goto cleanup_uc;
+ goto cleanup_irq;
intel_setup_overlay(dev_priv);
@@ -716,8 +714,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
i915_gem_fini(dev_priv);
-cleanup_uc:
- intel_uc_fini_fw(dev_priv);
cleanup_irq:
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev_priv);
@@ -962,6 +958,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
{
intel_irq_fini(dev_priv);
+ intel_uc_cleanup_early(dev_priv);
i915_gem_cleanup_early(dev_priv);
i915_workqueues_cleanup(dev_priv);
i915_engines_cleanup(dev_priv);
@@ -1457,7 +1454,6 @@ void i915_driver_unload(struct drm_device *dev)
i915_reset_error_state(dev_priv);
i915_gem_fini(dev_priv);
- intel_uc_fini_fw(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
intel_power_domains_fini(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
b/drivers/gpu/drm/i915/intel_guc_fw.c
index 978668c..a9e6fcc 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -275,9 +275,8 @@ static int guc_fw_xfer(struct intel_uc_fw *guc_fw, struct
i915_vma *vma)
* Called from intel_uc_init_hw() during driver load, resume from sleep and
* after a GPU reset.
*
- * The firmware image should have already been fetched into memory by the
- * earlier call to intel_uc_init_fw(), so here we need to only check that
- * fetch succeeded, and then transfer the image to the h/w.
+ * The firmware image should have already been fetched into memory, so only
+ * check that fetch succeeded, and then transfer the image to the h/w.
*
* Return: non-zero code on error
*/
diff --git a/drivers/gpu/drm/i915/intel_huc_fw.c
b/drivers/gpu/drm/i915/intel_huc_fw.c
index bb0f8b7..f93d238 100644
--- a/drivers/gpu/drm/i915/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/intel_huc_fw.c
@@ -155,9 +155,8 @@ static int huc_fw_xfer(struct intel_uc_fw *huc_fw, struct
i915_vma *vma)
* Called from intel_uc_init_hw() during driver load, resume from sleep and
* after a GPU reset. Note that HuC must be loaded before GuC.
*
- * The firmware image should have already been fetched into memory by the
- * earlier call to intel_uc_init_fw(), so here we need to only check that
- * fetch succeeded, and then transfer the image to the h/w.
+ * The firmware image should have already been fetched into memory, so only
+ * check that fetch succeeded, and then transfer the image to the h/w.
*
* Return: non-zero code on error
*/
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 34f8a2c..4aad844 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -162,36 +162,35 @@ static void sanitize_options_early(struct
drm_i915_private *dev_priv)
GEM_BUG_ON(i915_modparams.guc_log_level < 0);
}
-void intel_uc_init_early(struct drm_i915_private *dev_priv)
+void intel_uc_init_early(struct drm_i915_private *i915)
{
- intel_guc_init_early(&dev_priv->guc);
- intel_huc_init_early(&dev_priv->huc);
+ struct intel_guc *guc = &i915->guc;
+ struct intel_huc *huc = &i915->huc;
- sanitize_options_early(dev_priv);
-}
+ intel_guc_init_early(guc);
+ intel_huc_init_early(huc);
-void intel_uc_init_fw(struct drm_i915_private *dev_priv)
-{
- if (!USES_GUC(dev_priv))
- return;
+ sanitize_options_early(i915);
- if (USES_HUC(dev_priv))
- intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
+ if (USES_GUC(i915))
+ intel_uc_fw_fetch(i915, &guc->fw);
- intel_uc_
[Intel-gfx] [PATCH v4 1/3] drm/i915: Reorder early initialization
In upcoming patch, we want to perform more actions in early
initialization of the uC. This reordering will help resolve
new dependencies that will be introduced by future patch.
v2: s/i915_gem_load_init/i915_gem_init_early (Chris)
v3: s/i915_gem_load_cleanup/i915_gem_cleanup_early (Michal)
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson #2
---
drivers/gpu/drm/i915/i915_drv.c | 17 -
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gem.c | 5 ++---
3 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7d3275..2561974 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -919,17 +919,21 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
mutex_init(&dev_priv->wm.wm_mutex);
mutex_init(&dev_priv->pps_mutex);
- intel_wopcm_init_early(&dev_priv->wopcm);
- intel_uc_init_early(dev_priv);
i915_memcpy_init_early(dev_priv);
ret = i915_workqueues_init(dev_priv);
if (ret < 0)
goto err_engines;
+ ret = i915_gem_init_early(dev_priv);
+ if (ret < 0)
+ goto err_workqueues;
+
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev_priv);
+ intel_wopcm_init_early(&dev_priv->wopcm);
+ intel_uc_init_early(dev_priv);
intel_pm_setup(dev_priv);
intel_init_dpio(dev_priv);
intel_power_domains_init(dev_priv);
@@ -938,18 +942,13 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
intel_init_display_hooks(dev_priv);
intel_init_clock_gating_hooks(dev_priv);
intel_init_audio_hooks(dev_priv);
- ret = i915_gem_load_init(dev_priv);
- if (ret < 0)
- goto err_irq;
-
intel_display_crc_init(dev_priv);
intel_detect_preproduction_hw(dev_priv);
return 0;
-err_irq:
- intel_irq_fini(dev_priv);
+err_workqueues:
i915_workqueues_cleanup(dev_priv);
err_engines:
i915_engines_cleanup(dev_priv);
@@ -962,8 +961,8 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
*/
static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
{
- i915_gem_load_cleanup(dev_priv);
intel_irq_fini(dev_priv);
+ i915_gem_cleanup_early(dev_priv);
i915_workqueues_cleanup(dev_priv);
i915_engines_cleanup(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9c3b2b..28ab918 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2869,8 +2869,8 @@ int i915_gem_get_aperture_ioctl(struct drm_device *dev,
void *data,
int i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
void i915_gem_sanitize(struct drm_i915_private *i915);
-int i915_gem_load_init(struct drm_i915_private *dev_priv);
-void i915_gem_load_cleanup(struct drm_i915_private *dev_priv);
+int i915_gem_init_early(struct drm_i915_private *dev_priv);
+void i915_gem_cleanup_early(struct drm_i915_private *dev_priv);
void i915_gem_load_init_fences(struct drm_i915_private *dev_priv);
int i915_gem_freeze(struct drm_i915_private *dev_priv);
int i915_gem_freeze_late(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 802df8e..9650a7b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5502,8 +5502,7 @@ static void i915_gem_init__mm(struct drm_i915_private
*i915)
INIT_WORK(&i915->mm.free_work, __i915_gem_free_work);
}
-int
-i915_gem_load_init(struct drm_i915_private *dev_priv)
+int i915_gem_init_early(struct drm_i915_private *dev_priv)
{
int err = -ENOMEM;
@@ -5578,7 +5577,7 @@ static void i915_gem_init__mm(struct drm_i915_private
*i915)
return err;
}
-void i915_gem_load_cleanup(struct drm_i915_private *dev_priv)
+void i915_gem_cleanup_early(struct drm_i915_private *dev_priv)
{
i915_gem_drain_freed_objects(dev_priv);
GEM_BUG_ON(!llist_empty(&dev_priv->mm.free_list));
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnp: Properly handle VBT ddc pin out of bounds.
On 30.01.2018 00:12, Rodrigo Vivi wrote:
> On Mon, Jan 29, 2018 at 05:42:53AM +, Kai Heng Feng wrote:
>>
>>> On 26 Jan 2018, at 6:25 AM, Rodrigo Vivi wrote:
>>>
>>> If the table result is out of bounds on the array map
>>> there is something really wrong with VBT pin so we don't
>>> return that vbt_pin, but only return 0 instead.
>>>
>>> This basically reverts commit 'a8e6f3888b05 ("drm/i915/cnp:
>>> Ignore VBT request for know invalid DDC pin.")'
>>>
>>> Also this properly fixes commit 9c3b2689d01f ("drm/i915/cnl:
>>> Map VBT DDC Pin to BSpec DDC Pin.")
>>>
>>> v2: Do in a way that we don't break other platforms. (Jani)
>>>
>>> v3: Keep debug message (Jani)
>>>
>>> v4: Don't mess with 0 mapping was noticed by Jani and
>>>addressed with a simple solution suggested by Lucas
>>>that makes this even simpler.
>>>
>>> Fixes: a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC
>>> pin.")
>>> Fixes: 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
>>> Cc: Radhakrishna Sripada
>>> Cc: Jani Nikula
>>> Cc: Kai Heng Feng
>>> Cc: Lucas De Marchi
>>> Suggested-by: Lucas De Marchi
>>> Signed-off-by: Rodrigo Vivi
>>
>> Tested-by: Kai-Heng Feng
>
> merged. thanks for suggestions, reviews, tests and patience ;)
Shouldn't this and
drm/i915/cnp: Ignore VBT request for know invalid DDC pin.
be cc:stable? Though they aren't even in 4.16 yet.
--
t
___
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 [v3,1/3] drm/i915: Reorder early initialization
== Series Details == Series: series starting with [v3,1/3] drm/i915: Reorder early initialization URL : https://patchwork.freedesktop.org/series/40556/ State : success == Summary == Series 40556v1 series starting with [v3,1/3] drm/i915: Reorder early initialization https://patchwork.freedesktop.org/api/1.0/series/40556/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_chamelium: Subgroup dp-edid-read: pass -> FAIL (fi-kbl-7500u) fdo#102505 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:441s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:540s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:515s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:514s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:520s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:506s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:414s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:512s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:586s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:435s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:319s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:532s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:418s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:465s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:427s fi-kbl-7500u total:285 pass:259 dwarn:1 dfail:0 fail:1 skip:24 time:469s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:469s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:513s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:653s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:445s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:537s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:496s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:495s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:429s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:443s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:569s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:407s Blacklisted hosts: fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:569s fi-cnl-psr total:224 pass:198 dwarn:0 dfail:0 fail:1 skip:24 fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:487s 4ff2198305421dab54e106502c38de82813eb461 drm-tip: 2018y-03m-23d-11h-56m-39s UTC integration manifest ba4af34d6ba3 HAX: Enable GuC for CI ce36f61dfc1c drm/i915/uc: Fetch uC firmware in init_early 78356f1f956e drm/i915: Reorder early initialization == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8470/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/8] Force preemption
Quoting Bloomfield, Jon (2018-03-22 21:59:33) > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > > Of Jeff McGee > > Sent: Thursday, March 22, 2018 12:09 PM > > To: Tvrtko Ursulin > > Cc: Kondapally, Kalyan ; intel- > > g...@lists.freedesktop.org; b...@bwidawsk.net > > Subject: Re: [Intel-gfx] [RFC 0/8] Force preemption > > > > On Thu, Mar 22, 2018 at 05:41:57PM +, Tvrtko Ursulin wrote: > > > > > > On 22/03/2018 16:01, Jeff McGee wrote: > > > >On Thu, Mar 22, 2018 at 03:57:49PM +, Tvrtko Ursulin wrote: > > > >> > > > >>On 22/03/2018 14:34, Jeff McGee wrote: > > > >>>On Thu, Mar 22, 2018 at 09:28:00AM +, Chris Wilson wrote: > > > Quoting Tvrtko Ursulin (2018-03-22 09:22:55) > > > > > > > >On 21/03/2018 17:26, jeff.mc...@intel.com wrote: > > > >>From: Jeff McGee > > > >> > > > >>Force preemption uses engine reset to enforce a limit on the time > > > >>that a request targeted for preemption can block. This feature is > > > >>a requirement in automotive systems where the GPU may be > > shared by > > > >>clients of critically high priority and clients of low priority that > > > >>may not have been curated to be preemption friendly. There may > > be > > > >>more general applications of this feature. I'm sharing as an RFC to > > > >>stimulate that discussion and also to get any technical feedback > > > >>that I can before submitting to the product kernel that needs this. > > > >>I have developed the patches for ease of rebase, given that this is > > > >>for the moment considered a non-upstreamable feature. It would > > be > > > >>possible to refactor hangcheck to fully incorporate force > > preemption > > > >>as another tier of patience (or impatience) with the running > > request. > > > > > > > >Sorry if it was mentioned elsewhere and I missed it - but does this > > work > > > >only with stateless clients - or in other words, what would happen to > > > >stateful clients which would be force preempted? Or the answer is > > we > > > >don't care since they are misbehaving? > > > > > > They get notified of being guilty for causing a gpu reset; three > > > strikes > > > and they are out (banned from using the gpu) using the current rules. > > > This is a very blunt hammer that requires the rest of the system to be > > > robust; one might argue time spent making the system robust would > > be > > > better served making sure that the timer never expired in the first > > place > > > thereby eliminating the need for a forced gpu reset. > > > -Chris > > > >>> > > > >>>Yes, for simplication the policy applied to force preempted contexts > > > >>>is the same as for hanging contexts. It is known that this feature > > > >>>should not be required in a fully curated system. It's a requirement > > > >>>if end user will be alllowed to install 3rd party apps to run in the > > > >>>non-critical domain. > > > >> > > > >>My concern is whether it safe to call this force _preemption_, while > > > >>it is not really expected to work as preemption from the point of > > > >>view of preempted context. I may be missing some angle here, but I > > > >>think a better name would include words like maximum request > > > >>duration or something. > > > >> > > > >>I can see a difference between allowed maximum duration when there > > > >>is something else pending, and when it isn't, but I don't > > > >>immediately see that we should consider this distinction for any > > > >>real benefit? > > > >> > > > >>So should the feature just be "maximum request duration"? This would > > > >>perhaps make it just a special case of hangcheck, which ignores head > > > >>progress, or whatever we do in there. > > > >> > > > >>Regards, > > > >> > > > >>Tvrtko > > > > > > > >I think you might be unclear about how this works. We're not starting a > > > >preemption to see if we can cleanly remove a request who has begun to > > > >exceed its normal time slice, i.e. hangcheck. This is about bounding > > > >the time that a normal preemption can take. So first start preemption > > > >in response to higher-priority request arrival, then wait for preemption > > > >to complete within a certain amount of time. If it does not, resort to > > > >reset. > > > > > > > >So it's really "force the resolution of a preemption", shortened to > > > >"force preemption". > > > > > > You are right, I veered off in my thinking and ended up with > > > something different. :) > > > > > > I however still think the name is potentially misleading, since the > > > request/context is not getting preempted. It is getting effectively > > > killed (sooner or later, directly or indirectly). > > > > > > Maybe that is OK for the specific use case when everything is only > > > broken and not malicious. > > > > > > In a more general purpose system it would be a bit random when > > > something would work, and when it wouldn't, depending on
Re: [Intel-gfx] [PATCH] drm/i915: Fix hibernation with ACPI S0 target state
On Thu, Mar 22, 2018 at 04:36:42PM +0200, Imre Deak wrote:
> After
>
> commit dd9f31c7a3887950cbd0d49eb9d43f7a1518a356
> Author: Imre Deak
> Date: Wed Aug 16 17:46:07 2017 +0300
>
> drm/i915/gen9+: Set same power state before hibernation image
> save/restore
>
> during hibernation/suspend the power domain functionality got disabled,
> after which resume could leave it incorrectly disabled if the ACPI
> target state was S0 during suspend and i915 was not loaded by the loader
> kernel.
>
> This was caused by not considering if we resumed from hibernation as the
> condition for power domains reiniting.
>
> Fix this by simply tracking if we suspended power domains during system
> suspend and reinit power domains accordingly during resume. This will
> result in reiniting power domains always when resuming from hibernation,
> regardless of the platform and whether or not i915 is loaded by the
> loader kernel.
>
> The reason we didn't catch this earlier is that the enabled/disabled
> state of power domains during PMSG_FREEZE/PMSG_QUIESCE is platform
> and kernel config dependent: on my SKL the target state is S4
> during PMSG_FREEZE and (with the driver loaded in the loader kernel)
> S0 during PMSG_QUIESCE. On the reporter's machine it's S0 during
> PMSG_FREEZE but (contrary to this) power domains are not initialized
> during PMSG_QUIESCE since i915 is not loaded in the loader kernel, or
> it's loaded but without the DMC firmware being available.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105196
> Reported-and-tested-by: amn-...@hotmail.com
> Fixes: dd9f31c7a388 ("drm/i915/gen9+: Set same power state before hibernation
> image save/restore")
> Cc: amn-...@hotmail.com
> Cc: Ville Syrjälä
> Cc:
> Signed-off-by: Imre Deak
Make sense to me.
Reviewed-by: Ville Syrjälä
On thing I can't quite tell is what happens with switcheroo. Maybe it's
not even relevant for platforms with DC6 in which case I suppose it
should work correctly.
> ---
> drivers/gpu/drm/i915/i915_drv.c | 22 ++
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> 2 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index a7d3275f45d2..f706cff4f01b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1612,15 +1612,12 @@ static int i915_drm_suspend_late(struct drm_device
> *dev, bool hibernation)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct pci_dev *pdev = dev_priv->drm.pdev;
> - bool fw_csr;
> int ret;
>
> disable_rpm_wakeref_asserts(dev_priv);
>
> intel_display_set_init_power(dev_priv, false);
>
> - fw_csr = !IS_GEN9_LP(dev_priv) && !hibernation &&
> - suspend_to_idle(dev_priv) && dev_priv->csr.dmc_payload;
> /*
>* In case of firmware assisted context save/restore don't manually
>* deinit the power domains. This also means the CSR/DMC firmware will
> @@ -1628,8 +1625,11 @@ static int i915_drm_suspend_late(struct drm_device
> *dev, bool hibernation)
>* also enable deeper system power states that would be blocked if the
>* firmware was inactive.
>*/
> - if (!fw_csr)
> + if (IS_GEN9_LP(dev_priv) || hibernation || !suspend_to_idle(dev_priv) ||
> + dev_priv->csr.dmc_payload == NULL) {
> intel_power_domains_suspend(dev_priv);
> + dev_priv->power_domains_suspended = true;
> + }
>
> ret = 0;
> if (IS_GEN9_LP(dev_priv))
> @@ -1641,8 +1641,10 @@ static int i915_drm_suspend_late(struct drm_device
> *dev, bool hibernation)
>
> if (ret) {
> DRM_ERROR("Suspend complete failed: %d\n", ret);
> - if (!fw_csr)
> + if (dev_priv->power_domains_suspended) {
> intel_power_domains_init_hw(dev_priv, true);
> + dev_priv->power_domains_suspended = false;
> + }
>
> goto out;
> }
> @@ -1663,8 +1665,6 @@ static int i915_drm_suspend_late(struct drm_device
> *dev, bool hibernation)
> if (!(hibernation && INTEL_GEN(dev_priv) < 6))
> pci_set_power_state(pdev, PCI_D3hot);
>
> - dev_priv->suspended_to_idle = suspend_to_idle(dev_priv);
> -
> out:
> enable_rpm_wakeref_asserts(dev_priv);
>
> @@ -1831,8 +1831,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
> intel_uncore_resume_early(dev_priv);
>
> if (IS_GEN9_LP(dev_priv)) {
> - if (!dev_priv->suspended_to_idle)
> - gen9_sanitize_dc_state(dev_priv);
> + gen9_sanitize_dc_state(dev_priv);
> bxt_disable_dc9(dev_priv);
> } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> hsw_disable_pc8(dev_priv);
> @@ -1840,8 +1839,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
>
> intel_uncore_sanitize(dev_p
Re: [Intel-gfx] [PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook
Den 23.03.2018 12.31, skrev Ville Syrjälä:
On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
Den 22.03.2018 21.27, skrev Ville Syrjala:
From: Ville Syrjälä
mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us from taking the
plane mutex in fb->dirty() unless we also plumb down the acquire
context.
Instead it seems simpler to split the fb->dirty() into a tinydrm
specific lower level hook that can be called from
mipi_dbi_enable_flush() and from a generic higher level
tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
vfuncs table we'll just stick it into tinydrm_device directly
for now.
The long term goal is to try and get rid of tinydrm.ko by moving stuff
elsewhere as it's kind of a middle layer. So I'd really like to avoid
adding a callback like this.
Hopefully we can work out a solution based on my suggestion in the
'drm: Eliminate plane->fb/crtc usage for atomic drivers' thread.
I don't want to start redesigning the entire architecture at
this point. That would also cause a bigger risk of regression and
then we'd potentially have to try and revert the entire plane->fb
thing, which would not be fun if any significant changes have
occurred in the meantime.
If we do need a hook, I prefer that we add it to
drm_simple_display_pipe_funcs.
If you have plans to redesign tinydrm anyway it seems to me that
a temporary hook in tinydrm is may be a bit less intrusive than
inflicting it on the simple_kms_helper.
Yes you're right of course, what was I thinking.
You missed out on one call site:
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
index 11ae950b0fc9..7924eb59c2e1 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
@@ -124,11 +124,8 @@ void tinydrm_display_pipe_update(struct
drm_simple_display_pipe *pipe,
struct drm_framebuffer *fb = pipe->plane.state->fb;
struct drm_crtc *crtc = &tdev->pipe.crtc;
- if (fb && (fb != old_state->fb)) {
- pipe->plane.fb = fb;
- if (fb->funcs->dirty)
- fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
- }
+ if (fb && (fb != old_state->fb))
+ tdev->fb_dirty(fb, NULL, 0, 0, NULL, 0);
if (crtc->state->event) {
spin_lock_irq(&crtc->dev->event_lock);
With that fixed, series is:
Reviewed-by: Noralf Trønnes
To be honest I don't understand why it's necessary to wire through the
plane state to the enable hook instead of just looking it up on the pipe
object. You look it up on the pipe in tinydrm_fb_dirty(), and I look up
the new plane state and crtc state on the pipe in the update hook.
Noralf.
But if you do prefer
drm_simple_display_pipe_funcs I can move it there of course.
Noralf.
Cc: "Noralf Trønnes"
Cc: David Lechner
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30
++
drivers/gpu/drm/tinydrm/ili9225.c | 23 ++--
drivers/gpu/drm/tinydrm/mi0283qt.c | 2 +-
drivers/gpu/drm/tinydrm/mipi-dbi.c | 30
++
drivers/gpu/drm/tinydrm/repaper.c | 28
drivers/gpu/drm/tinydrm/st7586.c | 23 ++--
drivers/gpu/drm/tinydrm/st7735r.c | 2 +-
include/drm/tinydrm/mipi-dbi.h | 4 +++-
include/drm/tinydrm/tinydrm-helpers.h | 5 +
include/drm/tinydrm/tinydrm.h | 4
10 files changed, 76 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d1c3ce9ab294..dcd390163a4a 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -78,6 +78,36 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
}
EXPORT_SYMBOL(tinydrm_merge_clips);
+int tinydrm_fb_dirty(struct drm_framebuffer *fb,
+struct drm_file *file_priv,
+unsigned int flags, unsigned int color,
+struct drm_clip_rect *clips,
+unsigned int num_clips)
+{
+ struct tinydrm_device *tdev = fb->dev->dev_private;
+ struct drm_plane *plane = &tdev->pipe.plane;
+ int ret = 0;
+
+ drm_modeset_lock(&plane->mutex, NULL);
+
+ /* fbdev can flush even when we're not interested */
+ if (plane->state->fb == fb) {
+ mutex_lock(&tdev->dirty_lock);
+ ret = tdev->fb_dirty(fb, file_priv, flags,
+color, clips, num_clips);
+ mutex_unlock(&tdev->dirty_lock);
+ }
+
+ drm_modeset_unlock(&plane->mutex);
+
+ if (ret)
+ dev_err_once(fb->dev->dev,
+
Re: [Intel-gfx] [RFC 0/8] Force preemption
Quoting Joonas Lahtinen (2018-03-23 13:20:40) > So far nobody has been succesful in selling this to the userspace > compositors (the most likely user) or has somebody? I hadn't even contemplated selling it. However, it does seem applicable to the RealTime priorities for Vk and https://www.khronos.org/registry/EGL/extensions/NV/EGL_NV_context_priority_realtime.txt Gah. More fiddling with EGL... Personally I don't think I'd want X/gnome-shell/weston to adopt a RealTime or bust philosophy (i.e. I'm not planning to send a patch to raise weston from PRIORITY_HIGH to PRIORITY_RT), but that doesn't mean there aren't scenarios where it will be important. So a context param, say PREEMPT_TIMEOUT in ns with 0 meaning disable and bounded by CAP_SYS_NICE. Too soft? CAP_SYS_ADMIN, since it's about giving permission to nuke others? Implementation side, having it on the context is a fiddle, but we should be able to set a queue_timeout at the same time as setting queue_priority to save having to find the preempting context at irq time. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
Signed-off-by: Daniel Stone
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c | 15 ---
drivers/gpu/drm/i915/intel_drv.h | 3 +--
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 49b0772e9abc..e8100a4fc877 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13916,7 +13916,8 @@ static void intel_user_framebuffer_destroy(struct
drm_framebuffer *fb)
drm_framebuffer_cleanup(fb);
i915_gem_object_lock(obj);
- WARN_ON(!obj->framebuffer_references--);
+ WARN_ON(obj->framebuffer_references < fb->format->num_planes);
+ obj->framebuffer_references -= fb->format->num_planes;
i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
@@ -14176,9 +14177,9 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
i, fb->pitches[i], stride_alignment);
goto err;
}
- }
- intel_fb->obj = obj;
+ fb->obj[i] = &obj->base;
+ }
ret = intel_fill_fb_info(dev_priv, fb);
if (ret)
@@ -14190,6 +14191,14 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
goto err;
}
+ /* We already hold one reference to the fb, but in case it's
+* multi-planar and we've placed multiple pointers in
+* drm_framebuffer, hold extra refs.
+*/
+ i915_gem_object_lock(obj);
+ obj->framebuffer_references += fb->format->num_planes - 1;
+ i915_gem_object_unlock(obj);
+
return 0;
err:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 570f89b31544..d93ed9e59867 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -186,7 +186,6 @@ enum intel_output_type {
struct intel_framebuffer {
struct drm_framebuffer base;
- struct drm_i915_gem_object *obj;
struct intel_rotation_info rot_info;
/* for each plane in the normal GTT view */
@@ -985,7 +984,7 @@ struct cxsr_latency {
#define to_intel_framebuffer(x) container_of(x, struct intel_framebuffer, base)
#define to_intel_plane(x) container_of(x, struct intel_plane, base)
#define to_intel_plane_state(x) container_of(x, struct intel_plane_state, base)
-#define intel_fb_obj(x) (x ? to_intel_framebuffer(x)->obj : NULL)
+#define intel_fb_obj(x) (((x) && (x)->obj[0]) ? to_intel_bo((x)->obj[0]) :
NULL)
struct intel_hdmi {
i915_reg_t hdmi_reg;
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Use intel_fb_obj() everywhere
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.
Signed-off-by: Daniel Stone
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/intel_display.c | 19 ++-
drivers/gpu/drm/i915/intel_fbdev.c | 9 +
3 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7816cd53100a..68541df6f601 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1893,7 +1893,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
fbdev_fb->base.format->cpp[0] * 8,
fbdev_fb->base.modifier,
drm_framebuffer_read_refcount(&fbdev_fb->base));
- describe_obj(m, fbdev_fb->obj);
+ describe_obj(m, intel_fb_obj(&fbdev_fb->base));
seq_putc(m, '\n');
}
#endif
@@ -1911,7 +1911,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
fb->base.format->cpp[0] * 8,
fb->base.modifier,
drm_framebuffer_read_refcount(&fb->base));
- describe_obj(m, fb->obj);
+ describe_obj(m, intel_fb_obj(&fb->base));
seq_putc(m, '\n');
}
mutex_unlock(&dev->mode_config.fb_lock);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1b16b534871a..49b0772e9abc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2478,6 +2478,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
{
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct intel_rotation_info *rot_info = &intel_fb->rot_info;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
u32 gtt_offset_rotated = 0;
unsigned int max_size = 0;
int i, num_planes = fb->format->num_planes;
@@ -2542,7 +2543,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
* fb layout agrees with the fence layout. We already check
that the
* fb stride matches the fence stride elsewhere.
*/
- if (i == 0 && i915_gem_object_is_tiled(intel_fb->obj) &&
+ if (i == 0 && i915_gem_object_is_tiled(obj) &&
(x + width) * cpp > fb->pitches[i]) {
DRM_DEBUG_KMS("bad fb plane %d offset: 0x%x\n",
i, fb->offsets[i]);
@@ -2627,9 +2628,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
max_size = max(max_size, offset + size);
}
- if (max_size * tile_size > intel_fb->obj->base.size) {
+ if (max_size * tile_size > obj->base.size) {
DRM_DEBUG_KMS("fb too big for bo (need %u bytes, have %zu
bytes)\n",
- max_size * tile_size, intel_fb->obj->base.size);
+ max_size * tile_size, obj->base.size);
return -EINVAL;
}
@@ -13910,14 +13911,15 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
drm_framebuffer_cleanup(fb);
- i915_gem_object_lock(intel_fb->obj);
- WARN_ON(!intel_fb->obj->framebuffer_references--);
- i915_gem_object_unlock(intel_fb->obj);
+ i915_gem_object_lock(obj);
+ WARN_ON(!obj->framebuffer_references--);
+ i915_gem_object_unlock(obj);
- i915_gem_object_put(intel_fb->obj);
+ i915_gem_object_put(obj);
kfree(intel_fb);
}
@@ -13926,8 +13928,7 @@ static int intel_user_framebuffer_create_handle(struct
drm_framebuffer *fb,
struct drm_file *file,
unsigned int *handle)
{
- struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
- struct drm_i915_gem_object *obj = intel_fb->obj;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
if (obj->userptr.mm) {
DRM_DEBUG("attempting to use a userptr for a framebuffer,
denied\n");
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 65a3313723c9..fdef18488fb1 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -47,7 +47,7 @@
static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
{
- struct drm_i915_gem_object *obj = ifbdev->fb->obj;
+ struct drm_i915_gem_object *obj = int
Re: [Intel-gfx] [PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook
On Fri, Mar 23, 2018 at 02:37:23PM +0100, Noralf Trønnes wrote:
>
> Den 23.03.2018 12.31, skrev Ville Syrjälä:
> > On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
> >>
> >> Den 22.03.2018 21.27, skrev Ville Syrjala:
> >>> From: Ville Syrjälä
> >>>
> >>> mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
> >>> bowels of the .atomic_enable() hook. That prevents us from taking the
> >>> plane mutex in fb->dirty() unless we also plumb down the acquire
> >>> context.
> >>>
> >>> Instead it seems simpler to split the fb->dirty() into a tinydrm
> >>> specific lower level hook that can be called from
> >>> mipi_dbi_enable_flush() and from a generic higher level
> >>> tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
> >>> vfuncs table we'll just stick it into tinydrm_device directly
> >>> for now.
> >> The long term goal is to try and get rid of tinydrm.ko by moving stuff
> >> elsewhere as it's kind of a middle layer. So I'd really like to avoid
> >> adding a callback like this.
> >> Hopefully we can work out a solution based on my suggestion in the
> >> 'drm: Eliminate plane->fb/crtc usage for atomic drivers' thread.
> > I don't want to start redesigning the entire architecture at
> > this point. That would also cause a bigger risk of regression and
> > then we'd potentially have to try and revert the entire plane->fb
> > thing, which would not be fun if any significant changes have
> > occurred in the meantime.
> >
> >> If we do need a hook, I prefer that we add it to
> >> drm_simple_display_pipe_funcs.
> > If you have plans to redesign tinydrm anyway it seems to me that
> > a temporary hook in tinydrm is may be a bit less intrusive than
> > inflicting it on the simple_kms_helper.
>
> Yes you're right of course, what was I thinking.
>
> You missed out on one call site:
>
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> index 11ae950b0fc9..7924eb59c2e1 100644
> --- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> @@ -124,11 +124,8 @@ void tinydrm_display_pipe_update(struct
> drm_simple_display_pipe *pipe,
> struct drm_framebuffer *fb = pipe->plane.state->fb;
> struct drm_crtc *crtc = &tdev->pipe.crtc;
>
> - if (fb && (fb != old_state->fb)) {
> - pipe->plane.fb = fb;
> - if (fb->funcs->dirty)
> - fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
> - }
> + if (fb && (fb != old_state->fb))
> + tdev->fb_dirty(fb, NULL, 0, 0, NULL, 0);
>
> if (crtc->state->event) {
> spin_lock_irq(&crtc->dev->event_lock);
>
> With that fixed, series is:
>
> Reviewed-by: Noralf Trønnes
Awesome. Thanks. And thanks for catching that extra dirty() call. I'll
go and fix it up.
>
> To be honest I don't understand why it's necessary to wire through the
> plane state to the enable hook instead of just looking it up on the pipe
> object. You look it up on the pipe in tinydrm_fb_dirty(), and I look up
> the new plane state and crtc state on the pipe in the update hook.
The use of plane->state etc. isn't really the best practice. What
we really should be doing is plumbing down the drm_atomic_state
instead, which would allow us to look up the correct new state
explicitly. That said, I guess there is something in the helpers
to prevent the next swap_state() from overtaking the previous
commit, so supposedly using plane->state etc. does actually result
in the correct thing currently.
In this case since we were already plumbing down the new crtc
state I figured I'd just plumb down its friend as well.
>
> Noralf.
>
>
> > But if you do prefer
> > drm_simple_display_pipe_funcs I can move it there of course.
> >
> >> Noralf.
> >>
> >>> Cc: "Noralf Trønnes"
> >>> Cc: David Lechner
> >>> Signed-off-by: Ville Syrjälä
> >>> ---
> >>>drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30
> >>> ++
> >>>drivers/gpu/drm/tinydrm/ili9225.c | 23
> >>> ++--
> >>>drivers/gpu/drm/tinydrm/mi0283qt.c | 2 +-
> >>>drivers/gpu/drm/tinydrm/mipi-dbi.c | 30
> >>> ++
> >>>drivers/gpu/drm/tinydrm/repaper.c | 28
> >>>
> >>>drivers/gpu/drm/tinydrm/st7586.c | 23
> >>> ++--
> >>>drivers/gpu/drm/tinydrm/st7735r.c | 2 +-
> >>>include/drm/tinydrm/mipi-dbi.h | 4 +++-
> >>>include/drm/tinydrm/tinydrm-helpers.h | 5 +
> >>>include/drm/tinydrm/tinydrm.h | 4
> >>>10 files changed, 76 insertions(+), 75 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> >>> b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> >>> index d1c3ce9ab294..dcd390163a4a 100644
> >>> --- a/drivers/gpu/drm/tiny
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
On Thu, Mar 22, 2018 at 02:27:59PM -0700, Yaodong Li wrote:
> On 03/22/2018 01:38 PM, Michał Winiarski wrote:
> > On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
> > > In current code, we only compare the locked WOPCM register values with the
> > > calculated values. However, we can continue loading GuC/HuC firmware if
> > > the
> > > locked (or partially locked) values were valid for current GuC/HuC
> > > firmware
> > > sizes.
> > >
> > > This patch added a new code path to verify whether the locked register
> > > values can be used for GuC/HuC firmware loading, it will recalculate the
> > > verify the new values if these registers were partially locked, so that we
> > > won't fail the GuC/HuC firmware loading even if the locked register values
> > > are different from the calculated ones.
> > >
> > > Signed-off-by: Jackie Li
> > > Cc: Michal Wajdeczko
> > > Cc: Sagar Arun Kamble
> > > Cc: Michał Winiarski
> > > Cc: John Spotswood
> > > ---
> > > drivers/gpu/drm/i915/intel_wopcm.c | 183
> > > +++--
> > > 1 file changed, 157 insertions(+), 26 deletions(-)
> > [snip]
> >
> > > /**
> > >* intel_wopcm_init() - Initialize the WOPCM structure.
> > >* @wopcm: pointer to intel_wopcm.
> > > @@ -155,10 +202,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> > > struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
> > > u32 guc_fw_size = intel_uc_fw_get_upload_size(&i915->guc.fw);
> > > u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
> > > - u32 ctx_rsvd = context_reserved_size(i915);
> > > u32 guc_wopcm_base;
> > > u32 guc_wopcm_size;
> > > - u32 guc_wopcm_rsvd;
> > > int err;
> > > GEM_BUG_ON(!wopcm->size);
> > > @@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> > > return -E2BIG;
> > > }
> > > - guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
> > > -GUC_WOPCM_OFFSET_ALIGNMENT);
> > > - if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
> > > - DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
> > > - guc_wopcm_base / 1024);
> > > - return -E2BIG;
> > > - }
> > > -
> > > - guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
> > > - guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
> > > + guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
> > We already discussed this elsewhere, but just to have this part available
> > for wider audience:
> >
> > huc_fw_size is unknown (there may be no huc firmware present) - which means
> > we're still not able to handle module reload from guc-without-huc into
> > guc-with-huc
> >
> > Question remains whether we want to support this scenario, or whether we
> > should
> > tie GuC and HuC together and refuse to operate early on if either one is not
> > present. We could remove a lot of code this way...
> Thanks. As we discussed I think we should describe this problem in this way:
> we shall not make any assumption on either guc_fw_size and huc_fw_size.
We can make assumptions on guc_fw_size - it's known in all the relevant cases
(enable_guc=1,2,3).
(unless we want to support varying guc_fw_size - more on that later).
> On the other handle, we do need calculate the WOPCM layout based on
> both GuC and HuC FW sizes, especially when we want to support modparam
> enable_guc to enable/disable HuC FW loading dynamically. That's why I
> suggest
> to update the FW fetch code to report the FW size no matter we turn the HuC
> FW loading on or not.
We could do that, but we don't really *need* to do that.
If user doesn't want HuC, why are we reading HuC from the filesystem? (well,
because we decided we're going to base our paritioning around it).
> Other aspect of the discussion is whether we should support enable_guc
> switching
> from 1 to 3 + Adding new HuC FW to the filesystem without a system reboot.
> In another word whether we should support FW image updates
> (add/delete/update to a new version) in the filesystem without expecting a
> system
> reboot. My point is it's unlikely we can support this since the FW sizes
> would likely
> change and we need reconfigure the WO register with the latest FW available
> in
> the FS, and I think it worth to do it to 100% make sure we won't run into
> any
> module loading/init errors.
It's never going to be 100%, but we can at least try to work with 99% ;)
The only reason why you need HuC size is because you're building the
partitioning from the bottom (starting from HuC).
We could just as well start from the top (starting from GuC).
The only thing you gain by starting from the bottom, is that you're much more
tolerant for variations in GuC fw size (because you're paritioning HuC region
precisely, leaving the rest for GuC. Well, that, and the HW workaround).
The only thing that changes when you're starting from the top, is that you're
going the other way around (more
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
Quoting Yaodong Li (2018-03-22 23:27:59)
> On 03/22/2018 01:38 PM, Michał Winiarski wrote:
> > On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
> >> @@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> >> return -E2BIG;
> >> }
> >>
> >> -guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
> >> - GUC_WOPCM_OFFSET_ALIGNMENT);
> >> -if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
> >> -DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
> >> - guc_wopcm_base / 1024);
> >> -return -E2BIG;
> >> -}
> >> -
> >> -guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
> >> -guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
> >> +guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
> > We already discussed this elsewhere, but just to have this part available
> > for wider audience:
> >
> > huc_fw_size is unknown (there may be no huc firmware present) - which means
> > we're still not able to handle module reload from guc-without-huc into
> > guc-with-huc
> >
> > Question remains whether we want to support this scenario, or whether we
> > should
> > tie GuC and HuC together and refuse to operate early on if either one is not
> > present. We could remove a lot of code this way...
> Thanks. As we discussed I think we should describe this problem in this way:
> we shall not make any assumption on either guc_fw_size and huc_fw_size.
> On the other handle, we do need calculate the WOPCM layout based on
> both GuC and HuC FW sizes, especially when we want to support modparam
> enable_guc to enable/disable HuC FW loading dynamically. That's why I
> suggest
> to update the FW fetch code to report the FW size no matter we turn the HuC
> FW loading on or not.
> Other aspect of the discussion is whether we should support enable_guc
> switching
> from 1 to 3 + Adding new HuC FW to the filesystem without a system reboot.
> In another word whether we should support FW image updates
> (add/delete/update to a new version) in the filesystem without expecting
> a system
> reboot. My point is it's unlikely we can support this since the FW sizes
> would likely
> change and we need reconfigure the WO register with the latest FW
> available in
> the FS, and I think it worth to do it to 100% make sure we won't run
> into any
> module loading/init errors.
Did we ask the HW team about this? Surely the intention can't be to both
support dynamic enable/disable but yet having a write-once variable holding
the configuration?
Also, somebody mentioned that these were locked already before loading
i915, so if the firmware sizes have to do with the configuration, how
could that be? We'd have to match BIOS/whatever firmware, and that's not
likely to happen, is it.
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Don't spew errors when resetting HDMI scrambling/bit clock ratio fails (rev4)
On Thu, Mar 22, 2018 at 06:47:21PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Don't spew errors when resetting HDMI scrambling/bit clock > ratio fails (rev4) > URL : https://patchwork.freedesktop.org/series/40461/ > State : warning > > == Summary == > > Possible new issues: > > Test kms_flip: > Subgroup 2x-flip-vs-dpms: > pass -> DMESG-WARN (shard-hsw) Seems unrelated [ 1018.018832] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A [ 1018.019149] [drm:cpt_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun > > Known issues: > > Test kms_flip: > Subgroup 2x-plain-flip-ts-check-interruptible: > pass -> FAIL (shard-hsw) fdo#100368 +1 > Subgroup modeset-vs-vblank-race-interruptible: > pass -> FAIL (shard-hsw) fdo#103060 +2 > Test kms_sysfs_edid_timing: > warn -> PASS (shard-apl) fdo#100047 > > fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 > fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 > fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 > > shard-apltotal:3484 pass:1821 dwarn:1 dfail:0 fail:7 skip:1655 > time:13153s > shard-hswtotal:3484 pass:1770 dwarn:2 dfail:0 fail:4 skip:1707 > time:11827s > shard-snbtotal:3484 pass:1363 dwarn:1 dfail:0 fail:3 skip:2117 > time:7284s > Blacklisted hosts: > shard-kbltotal:3484 pass:1945 dwarn:1 dfail:0 fail:10 skip:1528 > time:9960s > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8453/shards.html -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree
Quoting Stephen Rothwell (2018-03-23 02:50:18)
> Hi all,
>
> On Thu, 22 Mar 2018 13:21:29 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the drm-intel tree got a conflict in:
> >
> > drivers/gpu/drm/i915/gvt/scheduler.c
> >
> > between commit:
> >
> > fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
> >
> > from Linus' tree and commit:
> >
> > b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is
> > pinned.")
> >
> > from the drm-intel tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
Hi Stephen,
Thanks for solving this, the resolution is correct.
You may want to replace Daniel, as the recipient here, with the current
i915 maintainers to get a faster feedback next time :)
> This is now a conflict between the drm tree and Linus' tree.
>
My bad for not highlighting the merge conflict in my PR to Dave. He
probably did not notice, getting the resolution automatically from
drm-rerere, I'd guess. I've noted it in the ever improving draft of
things to remember with the PRs.
I'm very much currently flying based on what the previous PR authors
have remembered to tell me. But after 4.17, the cycle is complete and we
all "have been there, done that", and you can expect less of a turbulence.
(We'll probably have more magnificent documentation, too.)
Regards, Joonas
> --
> Cheers,
> Stephen Rothwell
>
>
> ___
> 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] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/guc: Fix null pointer dereference when GuC FW is not available
== Series Details == Series: series starting with [CI,1/2] drm/i915/guc: Fix null pointer dereference when GuC FW is not available URL : https://patchwork.freedesktop.org/series/40559/ State : success == Summary == Series 40559v1 series starting with [CI,1/2] drm/i915/guc: Fix null pointer dereference when GuC FW is not available https://patchwork.freedesktop.org/api/1.0/series/40559/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:434s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:443s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:536s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:296s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:516s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:513s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:521s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:512s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:418s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:514s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:590s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:427s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:320s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:538s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:423s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:464s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:432s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:473s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:465s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:510s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:652s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:445s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:530s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:504s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:497s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:429s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:242 pass:208 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:399s Blacklisted hosts: fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:567s fi-cnl-psr total:224 pass:198 dwarn:0 dfail:0 fail:1 skip:24 fi-glk-j4005 failed to collect. IGT log at Patchwork_8471/fi-glk-j4005/run0.log 4ff2198305421dab54e106502c38de82813eb461 drm-tip: 2018y-03m-23d-11h-56m-39s UTC integration manifest 55082cf6341f HAX: Enable GuC for CI dc1ff4314559 drm/i915/guc: Fix null pointer dereference when GuC FW is not available == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8471/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
On Fri, Mar 23, 2018 at 04:02:47PM +0200, Joonas Lahtinen wrote:
> Quoting Yaodong Li (2018-03-22 23:27:59)
> > On 03/22/2018 01:38 PM, Michał Winiarski wrote:
> > > On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
> > >> @@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> > >> return -E2BIG;
> > >> }
> > >>
> > >> -guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
> > >> - GUC_WOPCM_OFFSET_ALIGNMENT);
> > >> -if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
> > >> -DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
> > >> - guc_wopcm_base / 1024);
> > >> -return -E2BIG;
> > >> -}
> > >> -
> > >> -guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
> > >> -guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
> > >> +guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
> > > We already discussed this elsewhere, but just to have this part available
> > > for wider audience:
> > >
> > > huc_fw_size is unknown (there may be no huc firmware present) - which
> > > means
> > > we're still not able to handle module reload from guc-without-huc into
> > > guc-with-huc
> > >
> > > Question remains whether we want to support this scenario, or whether we
> > > should
> > > tie GuC and HuC together and refuse to operate early on if either one is
> > > not
> > > present. We could remove a lot of code this way...
> > Thanks. As we discussed I think we should describe this problem in this way:
> > we shall not make any assumption on either guc_fw_size and huc_fw_size.
> > On the other handle, we do need calculate the WOPCM layout based on
> > both GuC and HuC FW sizes, especially when we want to support modparam
> > enable_guc to enable/disable HuC FW loading dynamically. That's why I
> > suggest
> > to update the FW fetch code to report the FW size no matter we turn the HuC
> > FW loading on or not.
> > Other aspect of the discussion is whether we should support enable_guc
> > switching
> > from 1 to 3 + Adding new HuC FW to the filesystem without a system reboot.
> > In another word whether we should support FW image updates
> > (add/delete/update to a new version) in the filesystem without expecting
> > a system
> > reboot. My point is it's unlikely we can support this since the FW sizes
> > would likely
> > change and we need reconfigure the WO register with the latest FW
> > available in
> > the FS, and I think it worth to do it to 100% make sure we won't run
> > into any
> > module loading/init errors.
>
> Did we ask the HW team about this? Surely the intention can't be to both
> support dynamic enable/disable but yet having a write-once variable holding
> the configuration?
>
> Also, somebody mentioned that these were locked already before loading
> i915, so if the firmware sizes have to do with the configuration, how
> could that be? We'd have to match BIOS/whatever firmware, and that's not
> likely to happen, is it.
That was me, and that was an error in my environment. We expect to see unlocked
regs on reboot. And even if we don't (e.g. because it's a module reload), trying
to fit isn't really that hard to do (we're reusing most of the code), so I
believe this is the right approach.
-Michał
> Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer
On Fri, Mar 23, 2018 at 01:45:50PM +, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass.
>
> Signed-off-by: Daniel Stone
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-gfx@lists.freedesktop.org
> ---
> drivers/gpu/drm/i915/intel_display.c | 15 ---
> drivers/gpu/drm/i915/intel_drv.h | 3 +--
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 49b0772e9abc..e8100a4fc877 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13916,7 +13916,8 @@ static void intel_user_framebuffer_destroy(struct
> drm_framebuffer *fb)
> drm_framebuffer_cleanup(fb);
>
> i915_gem_object_lock(obj);
> - WARN_ON(!obj->framebuffer_references--);
> + WARN_ON(obj->framebuffer_references < fb->format->num_planes);
> + obj->framebuffer_references -= fb->format->num_planes;
Hmm. I'm thinking we can stick to the single reference per fb.
IIRC this counter is there just to prevent changes of the obj
tiling mode as long as any fb exists that uses the object. So
doesn't actually matter how many planes the fb has.
Naturally the story would be slightly difference if we supported
fbs using multiple different BOs, as each BO would need to get its
framebuffer_references adjusted.
> i915_gem_object_unlock(obj);
>
> i915_gem_object_put(obj);
> @@ -14176,9 +14177,9 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
> i, fb->pitches[i], stride_alignment);
> goto err;
> }
> - }
>
> - intel_fb->obj = obj;
> + fb->obj[i] = &obj->base;
> + }
>
> ret = intel_fill_fb_info(dev_priv, fb);
> if (ret)
> @@ -14190,6 +14191,14 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
> goto err;
> }
>
> + /* We already hold one reference to the fb, but in case it's
> + * multi-planar and we've placed multiple pointers in
> + * drm_framebuffer, hold extra refs.
> + */
> + i915_gem_object_lock(obj);
> + obj->framebuffer_references += fb->format->num_planes - 1;
> + i915_gem_object_unlock(obj);
> +
> return 0;
>
> err:
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 570f89b31544..d93ed9e59867 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -186,7 +186,6 @@ enum intel_output_type {
>
> struct intel_framebuffer {
> struct drm_framebuffer base;
> - struct drm_i915_gem_object *obj;
> struct intel_rotation_info rot_info;
>
> /* for each plane in the normal GTT view */
> @@ -985,7 +984,7 @@ struct cxsr_latency {
> #define to_intel_framebuffer(x) container_of(x, struct intel_framebuffer,
> base)
> #define to_intel_plane(x) container_of(x, struct intel_plane, base)
> #define to_intel_plane_state(x) container_of(x, struct intel_plane_state,
> base)
> -#define intel_fb_obj(x) (x ? to_intel_framebuffer(x)->obj : NULL)
> +#define intel_fb_obj(x) (((x) && (x)->obj[0]) ? to_intel_bo((x)->obj[0]) :
> NULL)
Ah, I've had that "(x)" part coded up so many times, but never sent it
out :)
>
> struct intel_hdmi {
> i915_reg_t hdmi_reg;
> --
> 2.16.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 06/13] drm/i915/guc: Prepare to handle messages from CT RECV buffer
GuC can respond to our commands not only by updating SEND buffer
descriptor, but can also send a response message over RECV buffer.
Guc can also send unsolicited request messages over RECV buffer.
Let's start reading those messages and make placeholders
for actual response/request handlers.
v2: misc improvements (Michal)
v3: change response detection (Michal)
invalid status is protocol error (Michal)
v4: rebase
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_guc_ct.c | 139
1 file changed, 139 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index a54bf58..f029ff3 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -427,6 +427,143 @@ static int intel_guc_send_ct(struct intel_guc *guc, const
u32 *action, u32 len,
return ret;
}
+static inline unsigned int ct_header_get_len(u32 header)
+{
+ return (header >> GUC_CT_MSG_LEN_SHIFT) & GUC_CT_MSG_LEN_MASK;
+}
+
+static inline unsigned int ct_header_get_action(u32 header)
+{
+ return (header >> GUC_CT_MSG_ACTION_SHIFT) & GUC_CT_MSG_ACTION_MASK;
+}
+
+static inline bool ct_header_is_response(u32 header)
+{
+ return ct_header_get_action(header) == INTEL_GUC_ACTION_DEFAULT;
+}
+
+static int ctb_read(struct intel_guc_ct_buffer *ctb, u32 *data)
+{
+ struct guc_ct_buffer_desc *desc = ctb->desc;
+ u32 head = desc->head / 4; /* in dwords */
+ u32 tail = desc->tail / 4; /* in dwords */
+ u32 size = desc->size / 4; /* in dwords */
+ u32 *cmds = ctb->cmds;
+ s32 available; /* in dwords */
+ unsigned int len;
+ unsigned int i;
+
+ GEM_BUG_ON(desc->size % 4);
+ GEM_BUG_ON(desc->head % 4);
+ GEM_BUG_ON(desc->tail % 4);
+ GEM_BUG_ON(tail >= size);
+ GEM_BUG_ON(head >= size);
+
+ /* tail == head condition indicates empty */
+ available = tail - head;
+ if (unlikely(available == 0))
+ return -ENODATA;
+
+ /* beware of buffer wrap case */
+ if (unlikely(available < 0))
+ available += size;
+ GEM_BUG_ON(available < 0);
+
+ data[0] = cmds[head];
+ head = (head + 1) % size;
+
+ /* message len with header */
+ len = ct_header_get_len(data[0]) + 1;
+ if (unlikely(len > (u32)available)) {
+ DRM_ERROR("CT: incomplete message %*phn %*phn %*phn\n",
+ 4, data,
+ 4 * (head + available - 1 > size ?
+ size - head : available - 1), &cmds[head],
+ 4 * (head + available - 1 > size ?
+ available - 1 - size + head : 0), &cmds[0]);
+ return -EPROTO;
+ }
+
+ for (i = 1; i < len; i++) {
+ data[i] = cmds[head];
+ head = (head + 1) % size;
+ }
+
+ desc->head = head * 4;
+ return 0;
+}
+
+static int ct_handle_response(struct intel_guc_ct *ct, const u32 *msg)
+{
+ u32 header = msg[0];
+ u32 status = msg[2];
+ u32 len = ct_header_get_len(header) + 1; /* total len with header */
+
+ GEM_BUG_ON(!ct_header_is_response(header));
+
+ /* Response message shall at least include header, fence and status */
+ if (unlikely(len < 3)) {
+ DRM_ERROR("CT: corrupted response %*phn\n", 4*len, msg);
+ return -EPROTO;
+ }
+ /* Format of the status follows RESPONSE message */
+ if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
+ DRM_ERROR("CT: corrupted response %*phn\n", 4*len, msg);
+ return -EPROTO;
+ }
+
+ /* XXX */
+ return 0;
+}
+
+static int ct_handle_request(struct intel_guc_ct *ct, const u32 *msg)
+{
+ u32 header = msg[0];
+
+ GEM_BUG_ON(ct_header_is_response(header));
+
+ /* XXX */
+ return 0;
+}
+
+static void ct_process_host_channel(struct intel_guc_ct *ct)
+{
+ struct intel_guc_ct_channel *ctch = &ct->host_channel;
+ struct intel_guc_ct_buffer *ctb = &ctch->ctbs[CTB_RECV];
+ u32 msg[GUC_CT_MSG_LEN_MASK+1]; /* one extra dw for the header */
+ int err = 0;
+
+ if (!ctch_is_open(ctch))
+ return;
+
+ do {
+ err = ctb_read(ctb, msg);
+ if (err)
+ break;
+
+ if (ct_header_is_response(msg[0]))
+ err = ct_handle_response(ct, msg);
+ else
+ err = ct_handle_request(ct, msg);
+ } while (!err);
+
+ if (GEM_WARN_ON(err == -EPROTO)) {
+ DRM_ERROR("CT: corrupted message detected!\n");
+ ctb->desc->is_in_error = 1;
+ }
+}
+
+/*
+ * When we're communicating with the GuC over CT, GuC uses events
+ * to notif
[Intel-gfx] [PATCH v4 10/13] drm/i915/guc: Enable GuC interrupts when using CT
We will need them in G2H communication to properly handle responses and requests from the Guc. v2: keep irq enabled while disabling GuC logging (Oscar) v3: rebase. Signed-off-by: Michal Wajdeczko Cc: Oscar Mateo Cc: Daniele Ceraolo Spurio Cc: Michel Thierry Acked-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_uc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 8dc6a9c..9c20b1b 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -481,7 +481,7 @@ int intel_uc_resume(struct drm_i915_private *i915) if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) return 0; - if (i915_modparams.guc_log_level) + if (HAS_GUC_CT(i915) || i915_modparams.guc_log_level) gen9_enable_guc_interrupts(i915); err = intel_guc_resume(guc); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 13/13] HAX: Enable GuC for CI
Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 07/13] drm/i915/guc: Use better name for helper wait function
In next patch we will introduce another way of waiting for the response
that will use RECV buffer. To avoid misleading names, rename old wait
function to reflect the fact that it is based on descriptor update.
v2: fix comment style (Michal)
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_guc_ct.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index f029ff3..b1ab28f 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -332,16 +332,23 @@ static int ctb_write(struct intel_guc_ct_buffer *ctb,
return 0;
}
-/* Wait for the response from the GuC.
+/**
+ * wait_for_desc_update - Wait for the descriptor update.
+ * @desc: buffer descriptor
* @fence: response fence
* @status:placeholder for status
- * return: 0 response received (status is valid)
- * -ETIMEDOUT no response within hardcoded timeout
- * -EPROTO no response, ct buffer was in error
+ *
+ * Guc will update descriptor with new fence and status
+ * after processing the command.
+ *
+ * Return:
+ * * 0 response received (status is valid)
+ * * -ETIMEDOUT no response within hardcoded timeout
+ * * -EPROTO no response, ct buffer is in error
*/
-static int wait_for_response(struct guc_ct_buffer_desc *desc,
-u32 fence,
-u32 *status)
+static int wait_for_desc_update(struct guc_ct_buffer_desc *desc,
+ u32 fence,
+ u32 *status)
{
int err;
@@ -395,7 +402,7 @@ static int ctch_send(struct intel_guc *guc,
intel_guc_notify(guc);
- err = wait_for_response(desc, fence, status);
+ err = wait_for_desc_update(desc, fence, status);
if (unlikely(err))
return err;
if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status))
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 08/13] drm/i915/guc: Implement response handling in send_ct()
Instead of returning small data in response status dword,
GuC may append longer data as response message payload.
If caller provides response buffer, we will copy received
data and use number of received data dwords as new success
return value. We will WARN if response from GuC does not
match caller expectation.
v2: fix timeout and checkpatch warnings (Michal)
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_guc_ct.c | 137
drivers/gpu/drm/i915/intel_guc_ct.h | 5 ++
2 files changed, 128 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index b1ab28f..6a9aad0 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -24,6 +24,14 @@
#include "i915_drv.h"
#include "intel_guc_ct.h"
+struct ct_request {
+ struct list_head link;
+ u32 fence;
+ u32 status;
+ u32 response_len;
+ u32 *response_buf;
+};
+
enum { CTB_SEND = 0, CTB_RECV = 1 };
enum { CTB_OWNER_HOST = 0 };
@@ -36,6 +44,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
{
/* we're using static channel owners */
ct->host_channel.owner = CTB_OWNER_HOST;
+
+ spin_lock_init(&ct->lock);
+ INIT_LIST_HEAD(&ct->pending_requests);
}
static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
@@ -276,7 +287,8 @@ static u32 ctch_get_next_fence(struct intel_guc_ct_channel
*ctch)
static int ctb_write(struct intel_guc_ct_buffer *ctb,
const u32 *action,
u32 len /* in dwords */,
-u32 fence)
+u32 fence,
+bool want_response)
{
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head / 4; /* in dwords */
@@ -312,6 +324,7 @@ static int ctb_write(struct intel_guc_ct_buffer *ctb,
*/
header = (len << GUC_CT_MSG_LEN_SHIFT) |
(GUC_CT_MSG_WRITE_FENCE_TO_DESC) |
+(want_response ? GUC_CT_MSG_SEND_STATUS : 0) |
(action[0] << GUC_CT_MSG_ACTION_SHIFT);
cmds[tail] = header;
@@ -380,36 +393,104 @@ static int wait_for_desc_update(struct
guc_ct_buffer_desc *desc,
return err;
}
-static int ctch_send(struct intel_guc *guc,
+/**
+ * wait_for_response_msg - Wait for the Guc response.
+ * @req: pointer to pending request
+ * @status:placeholder for status
+ *
+ * We will update request status from the response message handler.
+ * Returns:
+ * * 0 response received (status is valid)
+ * * -ETIMEDOUT no response within hardcoded timeout
+ */
+static int wait_for_response_msg(struct ct_request *req, u32 *status)
+{
+ int err;
+
+ /*
+* Fast commands should complete in less than 10us, so sample quickly
+* up to that length of time, then switch to a slower sleep-wait loop.
+* No GuC command should ever take longer than 10ms.
+*/
+#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
+ err = wait_for_us(done, 10);
+ if (err)
+ err = wait_for(done, 10);
+#undef done
+
+ if (unlikely(err))
+ DRM_ERROR("CT: fence %u err %d\n", req->fence, err);
+
+ *status = req->status;
+ return err;
+}
+
+static int ctch_send(struct intel_guc_ct *ct,
struct intel_guc_ct_channel *ctch,
const u32 *action,
u32 len,
+u32 *response_buf,
+u32 response_buf_size,
u32 *status)
{
struct intel_guc_ct_buffer *ctb = &ctch->ctbs[CTB_SEND];
struct guc_ct_buffer_desc *desc = ctb->desc;
+ struct ct_request request;
+ unsigned long flags;
u32 fence;
int err;
GEM_BUG_ON(!ctch_is_open(ctch));
GEM_BUG_ON(!len);
GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
+ GEM_BUG_ON(!response_buf && response_buf_size);
fence = ctch_get_next_fence(ctch);
- err = ctb_write(ctb, action, len, fence);
+ request.fence = fence;
+ request.status = 0;
+ request.response_len = response_buf_size;
+ request.response_buf = response_buf;
+
+ spin_lock_irqsave(&ct->lock, flags);
+ list_add_tail(&request.link, &ct->pending_requests);
+ spin_unlock_irqrestore(&ct->lock, flags);
+
+ err = ctb_write(ctb, action, len, fence, !!response_buf);
if (unlikely(err))
- return err;
+ goto unlink;
- intel_guc_notify(guc);
+ intel_guc_notify(ct_to_guc(ct));
- err = wait_for_desc_update(desc, fence, status);
+ if (response_buf)
+ err = wait_for_response_msg(&request, status);
+ else
+ err = wait_for_desc_update(desc, fence, status);
if (unlikely(err))
- re
[Intel-gfx] [PATCH v4 03/13] drm/i915/guc: Prepare send() function to accept bigger response
This is a preparation step for the upcoming patches.
We already can return some small data decoded from the command
status, but we will need more in the future.
v2: add explicit response buf size
v3: squash with helper patch
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Daniele Ceraolo Spurio
Reviewed-by: Michel Thierry #1
---
drivers/gpu/drm/i915/intel_guc.c| 6 --
drivers/gpu/drm/i915/intel_guc.h| 18 ++
drivers/gpu/drm/i915/intel_guc_ct.c | 7 ---
3 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 77bf4e6..a533ff8 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -310,7 +310,8 @@ void intel_guc_init_params(struct intel_guc *guc)
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_BLITTER);
}
-int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len)
+int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len,
+ u32 *response_buf, u32 response_buf_size)
{
WARN(1, "Unexpected send: action=%#x\n", *action);
return -ENODEV;
@@ -319,7 +320,8 @@ int intel_guc_send_nop(struct intel_guc *guc, const u32
*action, u32 len)
/*
* This function implements the MMIO based host to GuC interface.
*/
-int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len)
+int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
+ u32 *response_buf, u32 response_buf_size)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
u32 status;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 13f3d1d..7ee0732 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -88,7 +88,8 @@ struct intel_guc {
struct mutex send_mutex;
/* GuC's FW specific send function */
- int (*send)(struct intel_guc *guc, const u32 *data, u32 len);
+ int (*send)(struct intel_guc *guc, const u32 *data, u32 len,
+ u32 *response_buf, u32 response_buf_size);
/* GuC's FW specific notify function */
void (*notify)(struct intel_guc *guc);
@@ -97,7 +98,14 @@ struct intel_guc {
static
inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)
{
- return guc->send(guc, action, len);
+ return guc->send(guc, action, len, NULL, 0);
+}
+
+static inline int
+intel_guc_send_and_receive(struct intel_guc *guc, const u32 *action, u32 len,
+ u32 *response_buf, u32 response_buf_size)
+{
+ return guc->send(guc, action, len, response_buf, response_buf_size);
}
static inline void intel_guc_notify(struct intel_guc *guc)
@@ -140,8 +148,10 @@ static inline u32 intel_guc_ggtt_offset(struct intel_guc
*guc,
void intel_guc_fini_wq(struct intel_guc *guc);
int intel_guc_init(struct intel_guc *guc);
void intel_guc_fini(struct intel_guc *guc);
-int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len);
-int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len);
+int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len,
+ u32 *response_buf, u32 response_buf_size);
+int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
+ u32 *response_buf, u32 response_buf_size);
void intel_guc_to_host_event_handler(struct intel_guc *guc);
int intel_guc_sample_forcewake(struct intel_guc *guc);
int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index fa52259..a54bf58 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -88,7 +88,7 @@ static int guc_action_register_ct_buffer(struct intel_guc
*guc,
int err;
/* Can't use generic send(), CT registration must go over MMIO */
- err = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action));
+ err = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
if (err)
DRM_ERROR("CT: register %s buffer failed; err=%d\n",
guc_ct_buffer_type_to_str(type), err);
@@ -107,7 +107,7 @@ static int guc_action_deregister_ct_buffer(struct intel_guc
*guc,
int err;
/* Can't use generic send(), CT deregistration must go over MMIO */
- err = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action));
+ err = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
if (err)
DRM_ERROR("CT: deregister %s buffer failed; owner=%d err=%d\n",
guc_ct_buffer_type_to_str(type), owner, err);
@@ -408,7 +408,8 @@ static int ctch_send(struct intel_guc *guc,
/*
* Command Transport (CT) buffer based GuC send function.
*/
-static int intel_guc_send_ct(st
[Intel-gfx] [PATCH v4 01/13] drm/i915/guc: Add documentation for MMIO based communication
As we are going to extend our use of MMIO based communication,
try to explain its mechanics and update corresponding definitions.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Kelvin Gardiner
---
drivers/gpu/drm/i915/intel_guc.c | 20
drivers/gpu/drm/i915/intel_guc_ct.c | 2 +-
drivers/gpu/drm/i915/intel_guc_fwif.h | 86 ---
3 files changed, 80 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 8f93f5b..28075e6 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -329,6 +329,9 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*action, u32 len)
GEM_BUG_ON(!len);
GEM_BUG_ON(len > guc->send_regs.count);
+ /* We expect only action code */
+ GEM_BUG_ON(*action & ~INTEL_GUC_MSG_CODE_MASK);
+
/* If CT is available, we expect to use MMIO only during init/fini */
GEM_BUG_ON(HAS_GUC_CT(dev_priv) &&
*action != INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER &&
@@ -350,18 +353,15 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*action, u32 len)
*/
ret = __intel_wait_for_register_fw(dev_priv,
guc_send_reg(guc, 0),
- INTEL_GUC_RECV_MASK,
- INTEL_GUC_RECV_MASK,
+ INTEL_GUC_MSG_TYPE_MASK,
+ INTEL_GUC_MSG_TYPE_RESPONSE <<
+ INTEL_GUC_MSG_TYPE_SHIFT,
10, 10, &status);
- if (status != INTEL_GUC_STATUS_SUCCESS) {
- /*
-* Either the GuC explicitly returned an error (which
-* we convert to -EIO here) or no response at all was
-* received within the timeout limit (-ETIMEDOUT)
-*/
- if (ret != -ETIMEDOUT)
- ret = -EIO;
+ /* If GuC explicitly returned an error, convert it to -EIO */
+ if (!ret && !INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(status))
+ ret = -EIO;
+ if (ret) {
DRM_DEBUG_DRIVER("INTEL_GUC_SEND: Action 0x%X failed;"
" ret=%d status=0x%08X response=0x%08X\n",
action[0], ret, status,
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index a726283..1dafa7a 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -398,7 +398,7 @@ static int ctch_send(struct intel_guc *guc,
err = wait_for_response(desc, fence, status);
if (unlikely(err))
return err;
- if (*status != INTEL_GUC_STATUS_SUCCESS)
+ if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status))
return -EIO;
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 72941bd..1701879 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -560,7 +560,68 @@ struct guc_shared_ctx_data {
struct guc_ctx_report preempt_ctx_report[GUC_MAX_ENGINES_NUM];
} __packed;
-/* This Action will be programmed in C180 - SOFT_SCRATCH_O_REG */
+/**
+ * DOC: MMIO based communication
+ *
+ * The MMIO based communication between Host and GuC uses software scratch
+ * registers, where first register holds data treated as message header,
+ * and other registers are used to hold message payload.
+ *
+ * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8
+ *
+ * +---+-+-+-+
+ * | MMIO[0] | MMIO[1] | ... | MMIO[n] |
+ * +---+-+-+-+
+ * | header| optional payload |
+ * +==++=+=+=+
+ * | 31:28|type| | | |
+ * +--++ | | |
+ * | 27:16|data| | | |
+ * +--++ | | |
+ * | 15:0|code| | | |
+ * +--++-+-+-+
+ *
+ * The message header consists of:
+ *
+ * - **type**, indicates message type
+ * - **code**, indicates message code, is specific for **type**
+ * - **data**, indicates message data, optional, depends on **code**
+ *
+ * The following message **types** are supported:
+ *
+ * - **REQUEST**, indicates Host-to-GuC request, requested GuC action code
+ * must be priovided in **code** field. Optional action specific parameters
+ * can be provided in remaining payload registers or **data** field.
+ *
+ * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC request,
+ * action response status will be provid
[Intel-gfx] [PATCH v4 00/13] drm/i915/guc: Support for Guc responses and requests
With this series we will be able to receive more data from the Guc. New Guc firmwares will be required to actually use that feature. v4: respin series after 1/2 year break Michal Wajdeczko (13): drm/i915/guc: Add documentation for MMIO based communication drm/i915/guc: Add support for data reporting in GuC responses drm/i915/guc: Prepare send() function to accept bigger response drm/i915/guc: Implement response handling in send_mmio() drm/i915/guc: Make event handler a virtual function drm/i915/guc: Prepare to handle messages from CT RECV buffer drm/i915/guc: Use better name for helper wait function drm/i915/guc: Implement response handling in send_ct() drm/i915/guc: Prepare to process incoming requests from CT drm/i915/guc: Enable GuC interrupts when using CT drm/i915/guc: Handle default action received over CT drm/i915/guc: Trace messages from CT while in debug HAX: Enable GuC for CI drivers/gpu/drm/i915/Kconfig.debug| 12 + drivers/gpu/drm/i915/i915_params.h| 2 +- drivers/gpu/drm/i915/intel_guc.c | 51 +++- drivers/gpu/drm/i915/intel_guc.h | 29 ++- drivers/gpu/drm/i915/intel_guc_ct.c | 430 +++--- drivers/gpu/drm/i915/intel_guc_ct.h | 9 + drivers/gpu/drm/i915/intel_guc_fwif.h | 86 +-- drivers/gpu/drm/i915/intel_uc.c | 4 +- 8 files changed, 551 insertions(+), 72 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 02/13] drm/i915/guc: Add support for data reporting in GuC responses
GuC may return additional data in the response message.
Format and meaning of this data is action specific. We will
use this non-negative data as a new success return value.
Currently used actions don't return data that way yet.
v2: fix prohibited space after '~' (Michel)
update commit message (Daniele)
v3: rebase
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Daniele Ceraolo Spurio
Reviewed-by: Michel Thierry #2
---
drivers/gpu/drm/i915/intel_guc.c| 3 +++
drivers/gpu/drm/i915/intel_guc_ct.c | 14 --
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 28075e6..77bf4e6 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -366,6 +366,9 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*action, u32 len)
" ret=%d status=0x%08X response=0x%08X\n",
action[0], ret, status,
I915_READ(SOFT_SCRATCH(15)));
+ } else {
+ /* Use data from the GuC response as our return value */
+ ret = INTEL_GUC_MSG_TO_DATA(status);
}
intel_uncore_forcewake_put(dev_priv, guc->send_regs.fw_domains);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 1dafa7a..fa52259 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -400,7 +400,9 @@ static int ctch_send(struct intel_guc *guc,
return err;
if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status))
return -EIO;
- return 0;
+
+ /* Use data from the GuC status as our return value */
+ return INTEL_GUC_MSG_TO_DATA(*status);
}
/*
@@ -410,18 +412,18 @@ static int intel_guc_send_ct(struct intel_guc *guc, const
u32 *action, u32 len)
{
struct intel_guc_ct_channel *ctch = &guc->ct.host_channel;
u32 status = ~0; /* undefined */
- int err;
+ int ret;
mutex_lock(&guc->send_mutex);
- err = ctch_send(guc, ctch, action, len, &status);
- if (unlikely(err)) {
+ ret = ctch_send(guc, ctch, action, len, &status);
+ if (unlikely(ret < 0)) {
DRM_ERROR("CT: send action %#X failed; err=%d status=%#X\n",
- action[0], err, status);
+ action[0], ret, status);
}
mutex_unlock(&guc->send_mutex);
- return err;
+ return ret;
}
/**
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 05/13] drm/i915/guc: Make event handler a virtual function
On platforms with CTB based GuC communications, we will handle
GuC events in a different way. Let's make event handler a virtual
function to allow easy switch between those variants.
Credits-to: Oscar Mateo
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Oscar Mateo
---
drivers/gpu/drm/i915/intel_guc.c | 8 +++-
drivers/gpu/drm/i915/intel_guc.h | 10 ++
drivers/gpu/drm/i915/intel_uc.c | 2 ++
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 9ce01e5..118db81 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -69,6 +69,7 @@ void intel_guc_init_early(struct intel_guc *guc)
mutex_init(&guc->send_mutex);
spin_lock_init(&guc->irq_lock);
guc->send = intel_guc_send_nop;
+ guc->handler = intel_guc_to_host_event_handler_nop;
guc->notify = gen8_guc_raise_irq;
}
@@ -317,6 +318,11 @@ int intel_guc_send_nop(struct intel_guc *guc, const u32
*action, u32 len,
return -ENODEV;
}
+void intel_guc_to_host_event_handler_nop(struct intel_guc *guc)
+{
+ WARN(1, "Unexpected event: no suitable handler\n");
+}
+
/*
* This function implements the MMIO based host to GuC interface.
*/
@@ -388,7 +394,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*action, u32 len,
return ret;
}
-void intel_guc_to_host_event_handler(struct intel_guc *guc)
+void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
u32 msg, val;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 7ee0732..6dc109a 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -91,6 +91,9 @@ struct intel_guc {
int (*send)(struct intel_guc *guc, const u32 *data, u32 len,
u32 *response_buf, u32 response_buf_size);
+ /* GuC's FW specific event handler function */
+ void (*handler)(struct intel_guc *guc);
+
/* GuC's FW specific notify function */
void (*notify)(struct intel_guc *guc);
};
@@ -113,6 +116,11 @@ static inline void intel_guc_notify(struct intel_guc *guc)
guc->notify(guc);
}
+static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
+{
+ guc->handler(guc);
+}
+
/* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
#define GUC_GGTT_TOP 0xFEE0
@@ -153,6 +161,8 @@ int intel_guc_send_nop(struct intel_guc *guc, const u32
*action, u32 len,
int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
u32 *response_buf, u32 response_buf_size);
void intel_guc_to_host_event_handler(struct intel_guc *guc);
+void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
+void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
int intel_guc_sample_forcewake(struct intel_guc *guc);
int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 34f8a2c..8dc6a9c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -234,6 +234,7 @@ static int guc_enable_communication(struct intel_guc *guc)
return intel_guc_ct_enable(&guc->ct);
guc->send = intel_guc_send_mmio;
+ guc->handler = intel_guc_to_host_event_handler_mmio;
return 0;
}
@@ -247,6 +248,7 @@ static void guc_disable_communication(struct intel_guc *guc)
gen9_disable_guc_interrupts(dev_priv);
guc->send = intel_guc_send_nop;
+ guc->handler = intel_guc_to_host_event_handler_nop;
}
int intel_uc_init_misc(struct drm_i915_private *dev_priv)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 09/13] drm/i915/guc: Prepare to process incoming requests from CT
Requests are read from CT in the irq handler, but actual processing
will be done in the work thread. Processing of specific actions will
be added in the upcoming patches.
v2: don't use GEM_BUG_ON (Chris)
don't kmalloc too large buffer (Michal)
v3: rebased
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_guc_ct.c | 72 -
drivers/gpu/drm/i915/intel_guc_ct.h | 4 +++
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 6a9aad0..90aff51 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -32,10 +32,17 @@ struct ct_request {
u32 *response_buf;
};
+struct ct_incoming_request {
+ struct list_head link;
+ u32 data[];
+};
+
enum { CTB_SEND = 0, CTB_RECV = 1 };
enum { CTB_OWNER_HOST = 0 };
+static void ct_incoming_request_worker_func(struct work_struct *w);
+
/**
* intel_guc_ct_init_early - Initialize CT state without requiring device
access
* @ct: pointer to CT struct
@@ -47,6 +54,8 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
spin_lock_init(&ct->lock);
INIT_LIST_HEAD(&ct->pending_requests);
+ INIT_LIST_HEAD(&ct->incoming_requests);
+ INIT_WORK(&ct->worker, ct_incoming_request_worker_func);
}
static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
@@ -632,13 +641,74 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
return 0;
}
+static void ct_dispatch_request(struct intel_guc_ct *ct,
+ u32 action, u32 len, const u32 *payload)
+{
+ switch (action) {
+ default:
+ DRM_ERROR("CT: unexpected request %x %*phn\n",
+ action, 4*len, payload);
+ break;
+ }
+}
+
+static bool ct_process_incoming_requests(struct intel_guc_ct *ct)
+{
+ unsigned long flags;
+ struct ct_incoming_request *request;
+ bool done;
+
+ spin_lock_irqsave(&ct->lock, flags);
+ request = list_first_entry_or_null(&ct->incoming_requests,
+ struct ct_incoming_request, link);
+ if (request)
+ list_del(&request->link);
+ done = !!list_empty(&ct->incoming_requests);
+ spin_unlock_irqrestore(&ct->lock, flags);
+
+ if (!request)
+ return true;
+
+ ct_dispatch_request(ct,
+ ct_header_get_action(request->data[0]),
+ ct_header_get_len(request->data[0]),
+ &request->data[1]);
+
+ kfree(request);
+ return done;
+}
+
+static void ct_incoming_request_worker_func(struct work_struct *w)
+{
+ struct intel_guc_ct *ct = container_of(w, struct intel_guc_ct, worker);
+ bool done;
+
+ done = ct_process_incoming_requests(ct);
+ if (!done)
+ queue_work(system_unbound_wq, &ct->worker);
+}
+
static int ct_handle_request(struct intel_guc_ct *ct, const u32 *msg)
{
u32 header = msg[0];
+ u32 len = ct_header_get_len(header) + 1; /* total len with header */
+ struct ct_incoming_request *request;
+ unsigned long flags;
GEM_BUG_ON(ct_header_is_response(header));
- /* XXX */
+ request = kmalloc(sizeof(*request) + 4*len, GFP_ATOMIC);
+ if (unlikely(!request)) {
+ DRM_ERROR("CT: dropping request %*phn\n", 4*len, msg);
+ return 0; /* XXX: -ENOMEM ? */
+ }
+ memcpy(request->data, msg, 4*len);
+
+ spin_lock_irqsave(&ct->lock, flags);
+ list_add_tail(&request->link, &ct->incoming_requests);
+ spin_unlock_irqrestore(&ct->lock, flags);
+
+ queue_work(system_unbound_wq, &ct->worker);
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.h
b/drivers/gpu/drm/i915/intel_guc_ct.h
index 905566b..0be4ce5 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/intel_guc_ct.h
@@ -73,6 +73,8 @@ struct intel_guc_ct_channel {
* @host_channel: main channel used by the host
* @lock: spin lock for pending requests list
* @pending_requests: list of pending requests
+ * @incoming_requests: list of incoming requests
+ * @worker: worker for handling incoming requests
*/
struct intel_guc_ct {
struct intel_guc_ct_channel host_channel;
@@ -80,6 +82,8 @@ struct intel_guc_ct {
spinlock_t lock;
struct list_head pending_requests;
+ struct list_head incoming_requests;
+ struct work_struct worker;
};
void intel_guc_ct_init_early(struct intel_guc_ct *ct);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 12/13] drm/i915/guc: Trace messages from CT while in debug
During debug we may want to investigate all communication
from the Guc. Add proper tracing macros in debug config.
v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal)
v3: use dedicated Kconfig (Daniele)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Acked-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Kconfig.debug | 12 ++
drivers/gpu/drm/i915/intel_guc_ct.c | 45 +++--
2 files changed, 45 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index dd5bf63..80efee1 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -90,6 +90,18 @@ config DRM_I915_SW_FENCE_CHECK_DAG
If in doubt, say "N".
+config DRM_I915_DEBUG_GUC
+bool "Enable additional driver debugging for GuC"
+depends on DRM_I915
+default n
+help
+ Choose this option to turn on extra driver debugging that may affect
+ performance but will help resolve GuC related issues.
+
+ Recommended for driver developers only.
+
+ If in doubt, say "N".
+
config DRM_I915_SELFTEST
bool "Enable selftests upon driver load"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 9bc8738..565502c 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -24,6 +24,12 @@
#include "i915_drv.h"
#include "intel_guc_ct.h"
+#ifdef CONFIG_DRM_I915_DEBUG_GUC
+#define CT_DEBUG_DRIVER(...) DRM_DEBUG_DRIVER(__VA_ARGS__)
+#else
+#define CT_DEBUG_DRIVER(...)
+#endif
+
struct ct_request {
struct list_head link;
u32 fence;
@@ -78,8 +84,8 @@ static inline const char *guc_ct_buffer_type_to_str(u32 type)
static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
u32 cmds_addr, u32 size, u32 owner)
{
- DRM_DEBUG_DRIVER("CT: desc %p init addr=%#x size=%u owner=%u\n",
-desc, cmds_addr, size, owner);
+ CT_DEBUG_DRIVER("CT: desc %p init addr=%#x size=%u owner=%u\n",
+ desc, cmds_addr, size, owner);
memset(desc, 0, sizeof(*desc));
desc->addr = cmds_addr;
desc->size = size;
@@ -88,8 +94,8 @@ static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc
*desc,
static void guc_ct_buffer_desc_reset(struct guc_ct_buffer_desc *desc)
{
- DRM_DEBUG_DRIVER("CT: desc %p reset head=%u tail=%u\n",
-desc, desc->head, desc->tail);
+ CT_DEBUG_DRIVER("CT: desc %p reset head=%u tail=%u\n",
+ desc, desc->head, desc->tail);
desc->head = 0;
desc->tail = 0;
desc->is_in_error = 0;
@@ -185,8 +191,8 @@ static int ctch_init(struct intel_guc *guc,
err = PTR_ERR(blob);
goto err_vma;
}
- DRM_DEBUG_DRIVER("CT: vma base=%#x\n",
-intel_guc_ggtt_offset(guc, ctch->vma));
+ CT_DEBUG_DRIVER("CT: vma base=%#x\n",
+ intel_guc_ggtt_offset(guc, ctch->vma));
/* store pointers to desc and cmds */
for (i = 0; i < ARRAY_SIZE(ctch->ctbs); i++) {
@@ -200,8 +206,8 @@ static int ctch_init(struct intel_guc *guc,
err_vma:
i915_vma_unpin_and_release(&ctch->vma);
err_out:
- DRM_DEBUG_DRIVER("CT: channel %d initialization failed; err=%d\n",
-ctch->owner, err);
+ CT_DEBUG_DRIVER("CT: channel %d initialization failed; err=%d\n",
+ ctch->owner, err);
return err;
}
@@ -221,8 +227,8 @@ static int ctch_open(struct intel_guc *guc,
int err;
int i;
- DRM_DEBUG_DRIVER("CT: channel %d reopen=%s\n",
-ctch->owner, yesno(ctch_is_open(ctch)));
+ CT_DEBUG_DRIVER("CT: channel %d reopen=%s\n",
+ ctch->owner, yesno(ctch_is_open(ctch)));
if (!ctch->vma) {
err = ctch_init(guc, ctch);
@@ -336,6 +342,10 @@ static int ctb_write(struct intel_guc_ct_buffer *ctb,
(want_response ? GUC_CT_MSG_SEND_STATUS : 0) |
(action[0] << GUC_CT_MSG_ACTION_SHIFT);
+ CT_DEBUG_DRIVER("CT: writing %*phn %*phn %*phn\n",
+ 4, &header, 4, &fence,
+ 4*(len - 1), &action[1]);
+
cmds[tail] = header;
tail = (tail + 1) % size;
@@ -520,6 +530,9 @@ static int intel_guc_send_ct(struct intel_guc *guc, const
u32 *action, u32 len,
if (unlikely(ret < 0)) {
DRM_ERROR("CT: send action %#X failed; err=%d status=%#X\n",
action[0], ret, status);
+ } else if (unlikely(ret)) {
+ CT_DEBUG_DRIVER("CT: send action %#x returned %d (%#x)\n",
+ action[0], ret, ret);
}
mutex_unlock(&guc->send_
[Intel-gfx] [PATCH v4 04/13] drm/i915/guc: Implement response handling in send_mmio()
We're using data encoded in the status MMIO as return value from send
function, but GuC may also write more data in remaining MMIO regs.
Let's copy content of these registers to the buffer provided by caller.
v2: new line (Michel)
v3: updated commit message
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Oscar Mateo
Reviewed-by: Michel Thierry #2
---
drivers/gpu/drm/i915/intel_guc.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index a533ff8..9ce01e5 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -368,11 +368,20 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*action, u32 len,
" ret=%d status=0x%08X response=0x%08X\n",
action[0], ret, status,
I915_READ(SOFT_SCRATCH(15)));
- } else {
- /* Use data from the GuC response as our return value */
- ret = INTEL_GUC_MSG_TO_DATA(status);
+ goto out;
}
+ if (response_buf) {
+ int count = min(response_buf_size, guc->send_regs.count - 1);
+
+ for (i = 0; i < count; i++)
+ response_buf[i] = I915_READ(guc_send_reg(guc, i + 1));
+ }
+
+ /* Use data from the GuC response as our return value */
+ ret = INTEL_GUC_MSG_TO_DATA(status);
+
+out:
intel_uncore_forcewake_put(dev_priv, guc->send_regs.fw_domains);
mutex_unlock(&guc->send_mutex);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 11/13] drm/i915/guc: Handle default action received over CT
When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
---
drivers/gpu/drm/i915/intel_guc.c| 5 +
drivers/gpu/drm/i915/intel_guc.h| 1 +
drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
3 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 118db81..b6d2778 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,11 @@ void intel_guc_to_host_event_handler_mmio(struct intel_guc
*guc)
I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
spin_unlock(&guc->irq_lock);
+ intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)
+{
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
intel_guc_log_handle_flush_event(&guc->log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*action, u32 len,
void intel_guc_to_host_event_handler(struct intel_guc *guc);
void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
int intel_guc_sample_forcewake(struct intel_guc *guc);
int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 90aff51..9bc8738 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -644,8 +644,17 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
static void ct_dispatch_request(struct intel_guc_ct *ct,
u32 action, u32 len, const u32 *payload)
{
+ struct intel_guc *guc = ct_to_guc(ct);
+
switch (action) {
+ case INTEL_GUC_ACTION_DEFAULT:
+ if (unlikely(len < 1))
+ goto fail_unexpected;
+ intel_guc_to_host_process_recv_msg(guc, *payload);
+ break;
+
default:
+fail_unexpected:
DRM_ERROR("CT: unexpected request %x %*phn\n",
action, 4*len, payload);
break;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer
Hi Ville, On 23 March 2018 at 14:42, Ville Syrjälä wrote: > On Fri, Mar 23, 2018 at 01:45:50PM +, Daniel Stone wrote: >> --- a/drivers/gpu/drm/i915/intel_display.c >> +++ b/drivers/gpu/drm/i915/intel_display.c >> @@ -13916,7 +13916,8 @@ static void intel_user_framebuffer_destroy(struct >> drm_framebuffer *fb) >> drm_framebuffer_cleanup(fb); >> >> i915_gem_object_lock(obj); >> - WARN_ON(!obj->framebuffer_references--); >> + WARN_ON(obj->framebuffer_references < fb->format->num_planes); >> + obj->framebuffer_references -= fb->format->num_planes; > > Hmm. I'm thinking we can stick to the single reference per fb. > IIRC this counter is there just to prevent changes of the obj > tiling mode as long as any fb exists that uses the object. So > doesn't actually matter how many planes the fb has. > > Naturally the story would be slightly difference if we supported > fbs using multiple different BOs, as each BO would need to get its > framebuffer_references adjusted. Yeah, fair enough. It looks a little bit weird (perhaps deserving of a comment) there. The reason to do that was just the general principle of having one reference per object pointer, especially when other drivers (ones which can have separate BOs in a single logical image) will and do refcount them separately. Having different refcounting semantics in shared structures depending on which driver is in use makes me itchy. Cheers, Daniel ___ 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: Actually flush interrupts on reset not just wedging (rev2)
== Series Details ==
Series: drm/i915: Actually flush interrupts on reset not just wedging (rev2)
URL : https://patchwork.freedesktop.org/series/40550/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b3648d43615e drm/i915: Actually flush interrupts on reset not just wedging
-:21: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#21:
References: 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
reset")
-:21: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 0f36a85c3bd5 ("drm/i915: Flush
pending interrupt following a GPU reset")'
#21:
References: 0f36a85c3bd5 ("drm/i915: Flush pending interrupt following a GPU
reset")
total: 1 errors, 1 warnings, 0 checks, 155 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 7/7] HAX: Enable GuC for CI
v2: except running with HYPERVISOR Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index e077c01..ce44299 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *i915) enable_guc |= ENABLE_GUC_LOAD_HUC; /* Any platform specific fine-tuning can be done here */ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + enable_guc = 0; return enable_guc; } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 4/7] drm/i915/uc: Use correct error code for GuC initialization failure
Since commit 6ca9a2beb54a ("drm/i915: Unwind i915_gem_init() failure")
we believed that we correctly handle all errors encountered during
GuC initialization, including special one that indicates request to
run driver with disabled GPU submission (-EIO).
Unfortunately since commit 121981fafe69 ("drm/i915/guc: Combine
enable_guc_loading|submission modparams") we stopped using that
error code to avoid unwanted fallback to execlist submission mode.
In result any GuC initialization failure was treated as non-recoverable
error leading to driver load abort, so we could not even read related
GuC error log to investigate cause of the problem.
Fix that by always returning -EIO on uC hardware related failure.
v2: don't allow -EIO from uc_init
don't call uc_fini[_misc] on -EIO
mark guc fw as failed on hw init failure
prepare uc_fini_hw to run after earlier -EIO
v3: update comments (Sagar)
use sanitize functions on failure in init_hw (Michal)
and also sanitize guc/huc fw in fini_hw (Michal)
v4: rebase
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Michal Winiarski
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_gem.c| 17 ++---
drivers/gpu/drm/i915/intel_guc.h | 5 +
drivers/gpu/drm/i915/intel_uc.c| 17 +
drivers/gpu/drm/i915/intel_uc_fw.h | 5 +
4 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7fad180..9b13b3e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5361,8 +5361,10 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
intel_init_gt_powersave(dev_priv);
ret = intel_uc_init(dev_priv);
- if (ret)
+ if (ret) {
+ GEM_BUG_ON(ret == -EIO);
goto err_pm;
+ }
ret = i915_gem_init_hw(dev_priv);
if (ret)
@@ -5409,7 +5411,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
i915_gem_contexts_lost(dev_priv);
intel_uc_fini_hw(dev_priv);
err_uc_init:
- intel_uc_fini(dev_priv);
+ if (ret != -EIO)
+ intel_uc_fini(dev_priv);
err_pm:
if (ret != -EIO) {
intel_cleanup_gt_powersave(dev_priv);
@@ -5423,15 +5426,15 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
mutex_unlock(&dev_priv->drm.struct_mutex);
- intel_uc_fini_misc(dev_priv);
-
- if (ret != -EIO)
+ if (ret != -EIO) {
+ intel_uc_fini_misc(dev_priv);
i915_gem_cleanup_userptr(dev_priv);
+ }
if (ret == -EIO) {
/*
-* Allow engine initialisation to fail by marking the GPU as
-* wedged. But we only want to do this where the GPU is angry,
+* Allow engines or uC initialization to fail by marking the GPU
+* as wedged. But we only want to do this when the GPU is angry,
* for all other failure, such as an allocation failure, bail.
*/
if (!i915_terminally_wedged(&dev_priv->gpu_error)) {
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 13f3d1d..7325b0e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -155,6 +155,11 @@ static inline int intel_guc_sanitize(struct intel_guc *guc)
return 0;
}
+static inline bool intel_guc_is_loaded(struct intel_guc *guc)
+{
+ return intel_uc_fw_is_loaded(&guc->fw);
+}
+
static inline void intel_guc_enable_msg(struct intel_guc *guc, u32 mask)
{
spin_lock_irq(&guc->irq_lock);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 9ff0c5a..fad9dde 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -427,15 +427,24 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
* Note that there is no fallback as either user explicitly asked for
* the GuC or driver default option was to run with the GuC enabled.
*/
- if (GEM_WARN_ON(ret == -EIO))
- ret = -EINVAL;
-
dev_err(dev_priv->drm.dev, "GuC initialization failed %d\n", ret);
- return ret;
+
+ /* Sanitize GuC/HuC to avoid clean-up on wedged */
+ intel_huc_sanitize(huc);
+ intel_guc_sanitize(guc);
+ GEM_BUG_ON(intel_guc_is_loaded(guc));
+
+ /* We want to disable GPU submission but keep KMS alive */
+ return -EIO;
}
void intel_uc_fini_hw(struct drm_i915_private *i915)
{
+ struct intel_guc *guc = &i915->guc;
+
+ if (!intel_guc_is_loaded(guc))
+ return;
+
intel_uc_sanitize(i915);
}
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h
b/drivers/gpu/drm/i915/intel_uc_fw.h
index dc33b12..77ad2aa 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu
[Intel-gfx] [PATCH v4 1/7] drm/i915: Correctly handle error path in i915_gem_init_hw
In function gem_init_hw() we are calling uc_init_hw() but in case of error later in function, we missed to call matching uc_fini_hw() Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 802df8e..7fad180 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -5171,9 +5171,15 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv) /* Only when the HW is re-initialised, can we replay the requests */ ret = __i915_gem_restart_engines(dev_priv); + if (ret) + goto cleanup_uc; out: intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL); return ret; + +cleanup_uc: + intel_uc_fini_hw(dev_priv); + goto out; } static int __intel_engines_record_defaults(struct drm_i915_private *i915) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 6/7] drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c
Some functions already use i915 name instead of dev_priv.
Let's rename this param in all remaining functions, except
those that still use legacy macros.
v2: don't forget about function descriptions (Sagar)
v3: rebased
Signed-off-by: Michal Wajdeczko
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_uc.c | 115
1 file changed, 57 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index d1ec948..e077c01 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -50,10 +50,10 @@ static int __intel_uc_reset_hw(struct drm_i915_private
*dev_priv)
return ret;
}
-static int __get_platform_enable_guc(struct drm_i915_private *dev_priv)
+static int __get_platform_enable_guc(struct drm_i915_private *i915)
{
- struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
- struct intel_uc_fw *huc_fw = &dev_priv->huc.fw;
+ struct intel_uc_fw *guc_fw = &i915->guc.fw;
+ struct intel_uc_fw *huc_fw = &i915->huc.fw;
int enable_guc = 0;
/* Default is to enable GuC/HuC if we know their firmwares */
@@ -67,11 +67,11 @@ static int __get_platform_enable_guc(struct
drm_i915_private *dev_priv)
return enable_guc;
}
-static int __get_default_guc_log_level(struct drm_i915_private *dev_priv)
+static int __get_default_guc_log_level(struct drm_i915_private *i915)
{
int guc_log_level;
- if (!HAS_GUC(dev_priv) || !intel_uc_is_using_guc())
+ if (!HAS_GUC(i915) || !intel_uc_is_using_guc())
guc_log_level = GUC_LOG_LEVEL_DISABLED;
else if (IS_ENABLED(CONFIG_DRM_I915_DEBUG) ||
IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
@@ -86,7 +86,7 @@ static int __get_default_guc_log_level(struct
drm_i915_private *dev_priv)
/**
* sanitize_options_early - sanitize uC related modparam options
- * @dev_priv: device private
+ * @i915: device private
*
* In case of "enable_guc" option this function will attempt to modify
* it only if it was initially set to "auto(-1)". Default value for this
@@ -101,14 +101,14 @@ static int __get_default_guc_log_level(struct
drm_i915_private *dev_priv)
* unless GuC is enabled on given platform and the driver is compiled with
* debug config when this modparam will default to "enable(1..4)".
*/
-static void sanitize_options_early(struct drm_i915_private *dev_priv)
+static void sanitize_options_early(struct drm_i915_private *i915)
{
- struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
- struct intel_uc_fw *huc_fw = &dev_priv->huc.fw;
+ struct intel_uc_fw *guc_fw = &i915->guc.fw;
+ struct intel_uc_fw *huc_fw = &i915->huc.fw;
/* A negative value means "use platform default" */
if (i915_modparams.enable_guc < 0)
- i915_modparams.enable_guc = __get_platform_enable_guc(dev_priv);
+ i915_modparams.enable_guc = __get_platform_enable_guc(i915);
DRM_DEBUG_DRIVER("enable_guc=%d (submission:%s huc:%s)\n",
i915_modparams.enable_guc,
@@ -119,28 +119,28 @@ static void sanitize_options_early(struct
drm_i915_private *dev_priv)
if (intel_uc_is_using_guc() && !intel_uc_fw_is_selected(guc_fw)) {
DRM_WARN("Incompatible option detected: %s=%d, %s!\n",
"enable_guc", i915_modparams.enable_guc,
-!HAS_GUC(dev_priv) ? "no GuC hardware" :
- "no GuC firmware");
+!HAS_GUC(i915) ? "no GuC hardware" :
+ "no GuC firmware");
}
/* Verify HuC firmware availability */
if (intel_uc_is_using_huc() && !intel_uc_fw_is_selected(huc_fw)) {
DRM_WARN("Incompatible option detected: %s=%d, %s!\n",
"enable_guc", i915_modparams.enable_guc,
-!HAS_HUC(dev_priv) ? "no HuC hardware" :
- "no HuC firmware");
+!HAS_HUC(i915) ? "no HuC hardware" :
+ "no HuC firmware");
}
/* A negative value means "use platform/config default" */
if (i915_modparams.guc_log_level < 0)
i915_modparams.guc_log_level =
- __get_default_guc_log_level(dev_priv);
+ __get_default_guc_log_level(i915);
if (i915_modparams.guc_log_level > 0 && !intel_uc_is_using_guc()) {
DRM_WARN("Incompatible option detected: %s=%d, %s!\n",
"guc_log_level", i915_modparams.guc_log_level,
-!HAS_GUC(dev_priv) ? "no GuC hardware" :
- "GuC not enabled");
+!HAS_GUC(i915) ? "no GuC hardware" :
+ "GuC not enabled");
i
[Intel-gfx] [PATCH v4 2/7] drm/i915/uc: Disable GuC submission during sanitize
We should not leave GuC submission enabled after sanitize, as we are going to reset all GuC/HuC hardware. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_uc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 34f8a2c..2389828 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -331,6 +331,9 @@ void intel_uc_sanitize(struct drm_i915_private *i915) GEM_BUG_ON(!HAS_GUC(i915)); + if (USES_GUC_SUBMISSION(dev_priv)) + intel_guc_submission_disable(guc); + guc_disable_communication(guc); intel_huc_sanitize(huc); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 5/7] drm/i915/uc: Use helper functions to detect fw load status
We don't have to check load status values. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_huc.c | 2 +- drivers/gpu/drm/i915/intel_uc.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c index 2912852..975ae61 100644 --- a/drivers/gpu/drm/i915/intel_huc.c +++ b/drivers/gpu/drm/i915/intel_huc.c @@ -51,7 +51,7 @@ int intel_huc_auth(struct intel_huc *huc) u32 status; int ret; - if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) + if (!intel_uc_fw_is_loaded(&huc->fw)) return -ENOEXEC; vma = i915_gem_object_ggtt_pin(huc->fw.obj, NULL, 0, 0, diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index fad9dde..d1ec948 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -456,7 +456,7 @@ int intel_uc_suspend(struct drm_i915_private *i915) if (!USES_GUC(i915)) return 0; - if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) + if (!intel_guc_is_loaded(guc)) return 0; err = intel_guc_suspend(guc); @@ -478,7 +478,7 @@ int intel_uc_resume(struct drm_i915_private *i915) if (!USES_GUC(i915)) return 0; - if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) + if (!intel_guc_is_loaded(guc)) return 0; if (i915_modparams.guc_log_level) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/7] drm/i915/uc: Fully sanitize uC in uc_fini_hw
Today uc_fini_hw is subset of uc_sanitize, but remaining
code in sanitize function is also desired for uc_fini_hw.
Instead of duplicating the code, just call uc_sanitize,
but leave as separate function to maintain symmetry with
uc_init_hw.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_uc.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 2389828..9ff0c5a 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -434,19 +434,9 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
return ret;
}
-void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
+void intel_uc_fini_hw(struct drm_i915_private *i915)
{
- struct intel_guc *guc = &dev_priv->guc;
-
- if (!USES_GUC(dev_priv))
- return;
-
- GEM_BUG_ON(!HAS_GUC(dev_priv));
-
- if (USES_GUC_SUBMISSION(dev_priv))
- intel_guc_submission_disable(guc);
-
- guc_disable_communication(guc);
+ intel_uc_sanitize(i915);
}
int intel_uc_suspend(struct drm_i915_private *i915)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
