Re: [Intel-gfx] linux-next: manual merge of the mfd tree with the drm-intel tree
Hi all,
On Thu, 26 Jul 2018 15:10:06 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the mfd tree got a conflict in:
>
> drivers/gpu/drm/i915/intel_display.h
>
> between commit:
>
> 6075546f57f8 ("drm/i915/icl: store the port type for TC ports")
>
> from the drm-intel tree and commit:
>
> 9c229127aee2 ("drm/i915: hdmi: add CEC notifier to intel_hdmi")
>
> from the mfd 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.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/i915/intel_display.h
> index 0a79a46d5805,1f176a71e081..
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@@ -126,24 -126,30 +126,48 @@@ enum port
>
> #define port_name(p) ((p) + 'A')
>
> + /*
> + * Ports identifier referenced from other drivers.
> + * Expected to remain stable over time
> + */
> + static inline const char *port_identifier(enum port port)
> + {
> + switch (port) {
> + case PORT_A:
> + return "Port A";
> + case PORT_B:
> + return "Port B";
> + case PORT_C:
> + return "Port C";
> + case PORT_D:
> + return "Port D";
> + case PORT_E:
> + return "Port E";
> + case PORT_F:
> + return "Port F";
> + default:
> + return "";
> + }
> + }
> +
> +enum tc_port {
> +PORT_TC_NONE = -1,
> +
> +PORT_TC1 = 0,
> +PORT_TC2,
> +PORT_TC3,
> +PORT_TC4,
> +
> +I915_MAX_TC_PORTS
> +};
> +
> +enum tc_port_type {
> +TC_PORT_UNKNOWN = 0,
> +TC_PORT_TYPEC,
> +TC_PORT_TBT,
> +TC_PORT_LEGACY,
> +};
> +
> enum dpio_channel {
> DPIO_CH0,
> DPIO_CH1
This is now a conflict between Linus' tree and the mfd tree.
--
Cheers,
Stephen Rothwell
pgpnHfwXy7pmF.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr: Remove wait_for_idle() for PSR2
On Mon, 2018-08-13 at 18:10 +, Pandiyan, Dhinakaran wrote:
> On Mon, 2018-08-13 at 09:57 -0700, Rodrigo Vivi wrote:
> > On Thu, Aug 09, 2018 at 05:41:35PM -0700, Dhinakaran Pandiyan
> > wrote:
> > > CI runs show PSR2 does not go to IDLE with selective update
> > > enabled
> > > on
> > > all PSR exit triggers. Specifically, logs indicate the hardware
> > > enters
> > > "SLEEP Selective Update" and not "IDLE Reset state' like the
> > > kernel
> > > expects. This check was added for PSR1 but incorrectly extended
> > > to
> > > PSR2,
> > > remove this check for PSR2 as there is a plan to test only PSR1
> > > on
> > > PSR2
> > > panels.
> > >
> > > Also add bspec reference to the comment about idle timeout.
> > >
> > > Cc: Tarun Vyas
> > > Cc: José Roberto de Souza
> > > Cc: Rodrigo Vivi
> > > Signed-off-by: Dhinakaran Pandiyan > > >
> > > ---
> > > drivers/gpu/drm/i915/intel_psr.c | 39 --
> > > --
> > > 1 file changed, 14 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 5686ddaa6a72..09be9bfee2be 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -722,37 +722,26 @@ int intel_psr_wait_for_idle(const struct
> > > intel_crtc_state *new_crtc_state,
> > > {
> > > struct intel_crtc *crtc = to_intel_crtc(new_crtc_state-
> > > > base.crtc);
> > >
> > > struct drm_i915_private *dev_priv = to_i915(crtc-
> > > > base.dev);
> > >
> > > - i915_reg_t reg;
> > > - u32 mask;
> > > -
> > > - if (!new_crtc_state->has_psr)
> > > - return 0;
> > >
> > > /*
> > > - * The sole user right now is intel_pipe_update_start(),
> > > - * which won't race with psr_enable/disable, which is
> > > - * where psr2_enabled is written to. So, we don't need
> > > - * to acquire the psr.lock. More importantly, we want
> > > the
> > > - * latency inside intel_pipe_update_start() to be as low
> > > - * as possible, so no need to acquire psr.lock when it
> > > is
> > > - * not needed and will induce latencies in the atomic
> > > - * update path.
> > > + * The sole user right now is intel_pipe_update_start(),
> > > which won't
> > > + * race with psr_enable/disable where psr2_enabled is
> > > written to. So, we
> > > + * don't need to acquire the psr.lock. More importantly,
> > > we want the
> > > + * latency inside intel_pipe_update_start() to be as low
> > > as possible, so
> > > + * no need to acquire psr.lock when it is not needed and
> > > will induce
> > > + * latencies in the atomic update path.
> > >*/
> >
> > I think we shouldn't change this format here to keep patch
> > cleaner...
> > if there is any change here I couldn't see because it is changing
> > all
> > lines and if there is no change I think it is better not to touch
> > because
> > it removes the focus of the real changes.
>
> Okay.
> >
> > > - if (dev_priv->psr.psr2_enabled) {
> > > - reg = EDP_PSR2_STATUS;
> > > - mask = EDP_PSR2_STATUS_STATE_MASK;
> > > - } else {
> > > - reg = EDP_PSR_STATUS;
> > > - mask = EDP_PSR_STATUS_STATE_MASK;
> > > - }
> > > + if (!new_crtc_state->has_psr || READ_ONCE(dev_priv-
> > > > psr.psr2_enabled))
> >
> > I now see that we are removing psr2 of the picture, but I don't see
> > how we are
> > improving psr2 situation here.
> > what am I missing?
> >
>
> When the patch was written, we did not have sufficient tests to tell
> us
> the wait_for_idle condition was wrong for PSR2. It was not known
> whether the wait was *necessary* for PSR2, think of this as a partial
> revert. Now that CI has pointed out, (and I checked with a PSR2
> panel)
> that the condition is wrong, we should be removing it for PSR2. If
> you
> think about it, it does improve PSR2 my removing irrelevant code.
>
I'll submit a new version without the comment diff if you are satisfied
with the above reasoning.
>
> > > + return 0;
> > >
> > > /*
> > > - * Max time for PSR to idle = Inverse of the refresh
> > > rate
> > > +
> > > - * 6 ms of exit training time + 1.5 ms of aux channel
> > > - * handshake. 50 msec is defesive enough to cover
> > > everything.
> > > + * From Bspec Panel Self Refresh (BDW+):
> >
> > This is another case, if we didn't change the format only this line
> > ^
> > would be in the patch and it would be cleaner and easier to review
> > the
> > changes.
> >
> > but my biggest concern with this patch is how do we check now
> > wait_psr2 idle
> >
> > > + * Max. time for PSR to idle = inverse of the refresh
> > > rate
> > > + 6 ms of
> > > + * exit training time + 1.5 ms of aux channel handshake.
> > > 50 ms is
> > > + * defensive enough to cover everything.
> > >*/
> > > -
> > > - return __intel_wait_for_register(dev_priv, reg, mask,
> > > + return __intel_wait_for_register(dev_priv,
> > > EDP_PSR_STATUS,
> > > + EDP_PSR_STATUS_STATE_MA
> > > SK
>
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit
== Series Details ==
Series: series starting with [1/2] drm/i915/psr: Add missing check for
I915_PSR_DEBUG_IRQ bit
URL : https://patchwork.freedesktop.org/series/48291/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4676 -> Patchwork_9959 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48291/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9959 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: PASS -> FAIL (fdo#106766)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-byt-clapper}: PASS -> FAIL (fdo#103191, fdo#107362)
Possible fixes
igt@drv_selftest@live_coherency:
fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS
igt@drv_selftest@live_hangcheck:
fi-kbl-7567u: DMESG-FAIL (fdo#106947, fdo#106560) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106766 https://bugs.freedesktop.org/show_bug.cgi?id=106766
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
== Participating hosts (53 -> 48) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4676 -> Patchwork_9959
CI_DRM_4676: 8171ee8227a2633ffb5808841f08cc1a3bfaffbb @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4599: 940cb5f46433a8ae48d21c6672e4d8ecd1358bbf @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9959: fbec1e114dac6cb4f7a3beff89271b5a7650a63d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
fbec1e114dac drm/i915/psr: Mask PSR irq bits when re-enabling interrupts.
d9cc16e9b591 drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9959/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/psr: Mask PSR irq bits when re-enabling interrupts.
gen8_de_irq_postinstall() wasn't masking the IRQ bit before passing the
debug flag to psr_irq_control(). This check was missed when new debug bits
were defined in 'commit c44301fce614 ("drm/i915: Allow control of PSR at
runtime through debugfs, v6")'. Instead of ANDing the irq bit in all the
callers, move it to the callee.
Cc: Maarten Lankhorst
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_psr.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b2c9838442bc..8084e35b25c5 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4048,7 +4048,7 @@ static int ironlake_irq_postinstall(struct drm_device
*dev)
if (IS_HASWELL(dev_priv)) {
gen3_assert_iir_is_zero(dev_priv, EDP_PSR_IIR);
- intel_psr_irq_control(dev_priv, dev_priv->psr.debug &
I915_PSR_DEBUG_IRQ);
+ intel_psr_irq_control(dev_priv, dev_priv->psr.debug);
display_mask |= DE_EDP_PSR_INT_HSW;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7b984aefce98..bc1c53c5f4dd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1944,7 +1944,7 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
void intel_psr_init(struct drm_i915_private *dev_priv);
void intel_psr_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state);
-void intel_psr_irq_control(struct drm_i915_private *dev_priv, bool debug);
+void intel_psr_irq_control(struct drm_i915_private *dev_priv, u32 debug);
void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 psr_iir);
void intel_psr_short_pulse(struct intel_dp *intel_dp);
int intel_psr_wait_for_idle(const struct intel_crtc_state *new_crtc_state);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 7560c65f50ad..df79020045a5 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -79,7 +79,7 @@ static bool intel_psr2_enabled(struct drm_i915_private
*dev_priv,
}
}
-void intel_psr_irq_control(struct drm_i915_private *dev_priv, bool debug)
+void intel_psr_irq_control(struct drm_i915_private *dev_priv, u32 debug)
{
u32 debug_mask, mask;
@@ -100,7 +100,7 @@ void intel_psr_irq_control(struct drm_i915_private
*dev_priv, bool debug)
EDP_PSR_PRE_ENTRY(TRANSCODER_C);
}
- if (debug)
+ if (debug & I915_PSR_DEBUG_IRQ)
mask |= debug_mask;
I915_WRITE(EDP_PSR_IMR, ~mask);
@@ -901,7 +901,7 @@ int intel_psr_set_debugfs_mode(struct drm_i915_private
*dev_priv,
if (crtc)
dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv,
crtc_state);
- intel_psr_irq_control(dev_priv, dev_priv->psr.debug &
I915_PSR_DEBUG_IRQ);
+ intel_psr_irq_control(dev_priv, dev_priv->psr.debug);
if (dev_priv->psr.prepared && enable)
intel_psr_enable_locked(dev_priv, crtc_state);
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit
We print the last attempted entry and last exit timestamps only when
IRQ debug is requested. This check was missed when new debug flags were
added in 'commit c44301fce614 ("drm/i915: Allow control of PSR at
runtime through debugfs, v6")
Cc: Maarten Lankhorst
Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 26b7e5276b15..374b550d9a4f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2735,7 +2735,7 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
psr_source_status(dev_priv, m);
mutex_unlock(_priv->psr.lock);
- if (READ_ONCE(dev_priv->psr.debug)) {
+ if (READ_ONCE(dev_priv->psr.debug) & I915_PSR_DEBUG_IRQ) {
seq_printf(m, "Last attempted entry at: %lld\n",
dev_priv->psr.last_entry_attempt);
seq_printf(m, "Last exit at: %lld\n",
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Only skip connector output for disable_display
== Series Details == Series: drm/i915: Only skip connector output for disable_display URL : https://patchwork.freedesktop.org/series/48283/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4673_full -> Patchwork_9958_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9958_full that come from known issues: === IGT changes === Issues hit igt@gem_softpin@noreloc-s3: shard-kbl: PASS -> INCOMPLETE (fdo#107556, fdo#103665) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_color@pipe-c-ctm-max: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +16 igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: FAIL (fdo#105454, fdo#106509) -> PASS igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: shard-snb: DMESG-WARN (fdo#102365) -> PASS fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4673 -> Patchwork_9958 CI_DRM_4673: f67334524375e4896c6fb75d28ecfa4ae3198231 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4599: 940cb5f46433a8ae48d21c6672e4d8ecd1358bbf @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9958: 1b44456f2940f281cd94fc180adef075b2f07cab @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9958/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove useless error return from intel_init_mocs_engine()
== Series Details == Series: drm/i915: Remove useless error return from intel_init_mocs_engine() URL : https://patchwork.freedesktop.org/series/48276/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4673_full -> Patchwork_9957_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9957_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-kbl: PASS -> FAIL (fdo#106886) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: PASS -> FAIL (fdo#107409, fdo#105703) Possible fixes igt@kms_color@pipe-c-ctm-max: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +16 igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: shard-snb: DMESG-WARN (fdo#102365) -> PASS igt@kms_setmode@basic: shard-glk: FAIL (fdo#99912) -> PASS fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#107409 https://bugs.freedesktop.org/show_bug.cgi?id=107409 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4673 -> Patchwork_9957 CI_DRM_4673: f67334524375e4896c6fb75d28ecfa4ae3198231 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4599: 940cb5f46433a8ae48d21c6672e4d8ecd1358bbf @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9957: 39a6ec518272a248cb850fa11e09480cdec1aa37 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9957/shards.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 1/3] igt/gem_sync: Exercise sync after context switch
On 15/08/18 10:24, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-15 18:20:10)
On 15/08/18 03:26, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-15 00:50:43)
On 10/08/18 04:01, Chris Wilson wrote:
This exercises a special case that may be of interest, waiting for a
context that may be preempted in order to reduce the wait.
Signed-off-by: Chris Wilson
---
+ cycles = 0;
+ elapsed = 0;
+ start = gettime();
+ do {
+ do {
+ double this;
+
+ gem_execbuf(fd, [0].execbuf);
+ gem_execbuf(fd, [1].execbuf);
I'm not sure where the preemption, mentioned in the commit message, is
coming in.
Internally. I've suggested that we reorder equivalent contexts in order
to satisfy client waits earlier. So having created two independent
request queues, userspace should be oblivious to the execution order.
But there isn't an assert because you don't want that to be part of the
contract between the driver and userspace, is that correct?
Correct. Userspace hasn't specified an order between the two contexts so
can't actually assert it happens in a particular order. We are free then
to do whatever we like, but that also means no assertion. Just the
figures look pretty and ofc we have to check that nothing actually
breaks.
The last question I have is about the batches, why not choosing a spin
batch so to make sure that context[0] (and [1]) hasn't completed by the
time it starts waiting.
Antonio
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
> On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wrote:
>
> First of all we need to fix the commit subject:
>
> drm/i915: Increase LSPCON timeout
>
> (this can be done when merging, no need to resend)
>
> > 100 ms is not enough time for the LSPCON adapter on Intel NUC devices to
> > settle. This causes dropped display modes at driver initialisation.
> >
> > Increase timeout to 1000 ms.
> >
> > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
>
> Missusage of "Fixes:" tag, please read
>
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
>
> But also no need for resending... could be fixed when merging
>
> The right one would be:
>
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode to
> settle")
> Cc: Shashank Sharma
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: # v4.11+
>
> Since initial 100 seemed to be empirical and this increase seems to
> help other cases I'm in favor of this move so
>
> Reviewed-by: Rodrigo Vivi
>
> However I will wait a bit before merging it
> so Imre, Shashank, and/or Jani can take a look here...
now, really cc'ing them...
>
> > Signed-off-by: Fredrik Schön
> > ---
> > drivers/gpu/drm/i915/intel_lspcon.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
> > b/drivers/gpu/drm/i915/intel_lspcon.c
> > index 8ae8f42f430a..be1b08f589a4 100644
> > --- a/drivers/gpu/drm/i915/intel_lspcon.c
> > +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> > @@ -74,7 +74,7 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct
> > intel_lspcon *lspcon,
> > DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
> > lspcon_mode_name(mode));
> >
> > - wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 100);
> > + wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode,
> > 1000);
> > if (current_mode != mode)
> > DRM_ERROR("LSPCON mode hasn't settled\n");
> >
> > --
> > 2.17.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wrote:
First of all we need to fix the commit subject:
drm/i915: Increase LSPCON timeout
(this can be done when merging, no need to resend)
> 100 ms is not enough time for the LSPCON adapter on Intel NUC devices to
> settle. This causes dropped display modes at driver initialisation.
>
> Increase timeout to 1000 ms.
>
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
Missusage of "Fixes:" tag, please read
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
But also no need for resending... could be fixed when merging
The right one would be:
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode to settle")
Cc: Shashank Sharma
Cc: Imre Deak
Cc: Jani Nikula
Cc: # v4.11+
Since initial 100 seemed to be empirical and this increase seems to
help other cases I'm in favor of this move so
Reviewed-by: Rodrigo Vivi
However I will wait a bit before merging it
so Imre, Shashank, and/or Jani can take a look here...
> Signed-off-by: Fredrik Schön
> ---
> drivers/gpu/drm/i915/intel_lspcon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
> b/drivers/gpu/drm/i915/intel_lspcon.c
> index 8ae8f42f430a..be1b08f589a4 100644
> --- a/drivers/gpu/drm/i915/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> @@ -74,7 +74,7 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct
> intel_lspcon *lspcon,
> DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
> lspcon_mode_name(mode));
>
> - wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 100);
> + wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode,
> 1000);
> if (current_mode != mode)
> DRM_ERROR("LSPCON mode hasn't settled\n");
>
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove useless error return from intel_init_mocs_engine()
Quoting Rodrigo Vivi (2018-08-15 23:19:50) > On Wed, Aug 15, 2018 at 07:42:51PM +0100, Chris Wilson wrote: > > As the only error is for a programming error in constructing the static > > tables describing the register values, replace the error code > > propagation with an assert. > > > > Signed-off-by: Chris Wilson > > Reviewed-by: Rodrigo Vivi Simple patch pushed, thanks for the review. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove useless error return from intel_init_mocs_engine()
On Wed, Aug 15, 2018 at 07:42:51PM +0100, Chris Wilson wrote:
> As the only error is for a programming error in constructing the static
> tables describing the register values, replace the error code
> propagation with an assert.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 6 +-
> drivers/gpu/drm/i915/intel_mocs.c | 11 +++
> drivers/gpu/drm/i915/intel_mocs.h | 2 +-
> 3 files changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 3f90c74038ef..841895cfb05f 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1769,11 +1769,7 @@ static bool unexpected_starting_state(struct
> intel_engine_cs *engine)
>
> static int gen8_init_common_ring(struct intel_engine_cs *engine)
> {
> - int ret;
> -
> - ret = intel_mocs_init_engine(engine);
> - if (ret)
> - return ret;
> + intel_mocs_init_engine(engine);
>
> intel_engine_reset_breadcrumbs(engine);
>
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> b/drivers/gpu/drm/i915/intel_mocs.c
> index 9f0bd6a4cb79..77e9871a8c9a 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -232,20 +232,17 @@ static i915_reg_t mocs_register(enum intel_engine_id
> engine_id, int index)
> *
> * This function simply emits a MI_LOAD_REGISTER_IMM command for the
> * given table starting at the given address.
> - *
> - * Return: 0 on success, otherwise the error status.
> */
> -int intel_mocs_init_engine(struct intel_engine_cs *engine)
> +void intel_mocs_init_engine(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *dev_priv = engine->i915;
> struct drm_i915_mocs_table table;
> unsigned int index;
>
> if (!get_mocs_settings(dev_priv, ))
> - return 0;
> + return;
>
> - if (WARN_ON(table.size > GEN9_NUM_MOCS_ENTRIES))
> - return -ENODEV;
> + GEM_BUG_ON(table.size > GEN9_NUM_MOCS_ENTRIES);
>
> for (index = 0; index < table.size; index++)
> I915_WRITE(mocs_register(engine->id, index),
> @@ -262,8 +259,6 @@ int intel_mocs_init_engine(struct intel_engine_cs *engine)
> for (; index < GEN9_NUM_MOCS_ENTRIES; index++)
> I915_WRITE(mocs_register(engine->id, index),
> table.table[0].control_value);
> -
> - return 0;
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_mocs.h
> b/drivers/gpu/drm/i915/intel_mocs.h
> index d1751f91c1a4..d89080d75b80 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.h
> +++ b/drivers/gpu/drm/i915/intel_mocs.h
> @@ -54,6 +54,6 @@
>
> int intel_rcs_context_init_mocs(struct i915_request *rq);
> void intel_mocs_init_l3cc_table(struct drm_i915_private *dev_priv);
> -int intel_mocs_init_engine(struct intel_engine_cs *engine);
> +void intel_mocs_init_engine(struct intel_engine_cs *engine);
>
> #endif
> --
> 2.18.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] docs: fix typo sharding->sharing
On Wed, Aug 15, 2018 at 2:09 AM Daniel Vetter wrote:
>
> On Tue, Aug 14, 2018 at 10:29:02AM -0700, Lucas De Marchi wrote:
> > On Fri, Aug 03, 2018 at 12:07:43PM +0300, Petri Latvala wrote:
> > > On Thu, Aug 02, 2018 at 03:09:37PM -0700, Lucas De Marchi wrote:
> > > > I was grepping for shard as the tests run on CI, but the only occurrence
> > > > was this one which seems to be a typo since it's about prime tests.
> > > >
> > > > Fixes: 76bce773 ("docs: Update documentation generation with missing
> > > > entries")
> > > > Signed-off-by: Lucas De Marchi
> > >
> > > Reviewed-by: Petri Latvala
> >
> > just a heads up that this is not yet applied...
>
> Sounds like time to fix you up with commit rights asap:
>
> https://www.freedesktop.org/wiki/AccountRequests/
>
> Please paste your account request here so we can move it forward (igt
> maintainers are on board too, I pinged them over irc).
I had an account created in 2015 for another project:
https://bugs.freedesktop.org/show_bug.cgi?id=89446
I still have the keys, so if the account wasn't dropped by inactivity
it should be good enough.
thanks
Lucas De Marchi
> -Daniel
>
> >
> > thanks
> > Lucas De Marchi
> >
> > >
> > >
> > > > ---
> > > > docs/reference/igt-gpu-tools/igt_test_programs.xml | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > > > b/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > > > index ec05d53e..95c4653e 100644
> > > > --- a/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > > > +++ b/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > > > @@ -229,7 +229,7 @@
> > > >
> > > >
> > > >Prime Tests
> > > > - Tests for buffer sharding
> > > > + Tests for buffer sharing
> > > >
> > > >
> > > >
> > > > --
> > > > 2.17.1
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm: Let userspace check if driver supports modeset
On Wed, 2018-08-15 at 14:15 -0700, Rodrigo Vivi wrote: > On Tue, Jul 17, 2018 at 09:04:45PM +0100, Chris Wilson wrote: > > Quoting Souza, Jose (2018-07-17 18:02:17) > > > On Tue, 2018-07-17 at 08:28 +0100, Chris Wilson wrote: > > > > Quoting José Roberto de Souza (2018-07-16 23:38:36) > > > > > GPU accelerators usually don't have display block or the > > > > > display > > > > > driver part can be disable when building driver(for servers > > > > > it save > > > > > some resources) so it is important let userspace check this > > > > > capability too. > > > > > > > > We currently communicate that by having no modeset resources. > > > > What > > > > does > > > > another cap bit accomplish that we don't already know? > > > > > > This is a hackish way to check if driver support modeset, > > > drmModeGetResources()/drm_mode_getresources() can fail and return > > > null > > > by other reasons and just check for the errno value can be > > > misleading > > > too. > > > > Do not confuse libdrm with the ioctl. You do not need to allocate > > anything for such a check, and it is being used directly without > > allocations as a has-kms check. > > > > More to the point existing userspace determines modeset capability > > through the reported resources. Your changelog needs to explain why > > they > > are inadequate and how you plan to coordinate your fix with > > userspace. > > As it stands you are introducing uABI with no user... > > I agree with Chris here. There is no indication on how this will > affect userspace here and this so far is just a uABI without user > that is a big blocker. The user would be IGT but I would only send the patch after get this merged. Okay, I can drop this patch without any changes in this series. > > And I also got confused because that modeset capability check > got introduced in a block that is for > "/* Only some caps make sense with UMS/render-only drivers. */" > > > -Chris > > ___ > > 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 1/6] drm: Let userspace check if driver supports modeset
On Tue, Jul 17, 2018 at 09:04:45PM +0100, Chris Wilson wrote: > Quoting Souza, Jose (2018-07-17 18:02:17) > > On Tue, 2018-07-17 at 08:28 +0100, Chris Wilson wrote: > > > Quoting José Roberto de Souza (2018-07-16 23:38:36) > > > > GPU accelerators usually don't have display block or the display > > > > driver part can be disable when building driver(for servers it save > > > > some resources) so it is important let userspace check this > > > > capability too. > > > > > > We currently communicate that by having no modeset resources. What > > > does > > > another cap bit accomplish that we don't already know? > > > > This is a hackish way to check if driver support modeset, > > drmModeGetResources()/drm_mode_getresources() can fail and return null > > by other reasons and just check for the errno value can be misleading > > too. > > Do not confuse libdrm with the ioctl. You do not need to allocate > anything for such a check, and it is being used directly without > allocations as a has-kms check. > > More to the point existing userspace determines modeset capability > through the reported resources. Your changelog needs to explain why they > are inadequate and how you plan to coordinate your fix with userspace. > As it stands you are introducing uABI with no user... I agree with Chris here. There is no indication on how this will affect userspace here and this so far is just a uABI without user that is a big blocker. And I also got confused because that modeset capability check got introduced in a block that is for "/* Only some caps make sense with UMS/render-only drivers. */" > -Chris > ___ > 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] drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit
On Tue, Aug 14, 2018 at 11:26:19AM +0200, Maarten Lankhorst wrote:
> Op 13-08-18 om 20:15 schreef Pandiyan, Dhinakaran:
> > On Mon, 2018-08-13 at 09:47 -0700, Rodrigo Vivi wrote:
> >> On Mon, Aug 13, 2018 at 03:47:20PM +0200, Maarten Lankhorst wrote:
> >>> Op 11-08-18 om 02:50 schreef Dhinakaran Pandiyan:
> We print the last attempted entry and last exit timestamps only
> when
> IRQ debug is requested. This check was missed when new debug
> flags were
> added in 'commit c44301fce614 ("drm/i915: Allow control of PSR at
> runtime through debugfs, v6")
>
> Cc: Maarten Lankhorst
> Signed-off-by: Dhinakaran Pandiyan ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 26b7e5276b15..374b550d9a4f 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2735,7 +2735,7 @@ static int i915_edp_psr_status(struct
> seq_file *m, void *data)
> psr_source_status(dev_priv, m);
> mutex_unlock(_priv->psr.lock);
>
> -if (READ_ONCE(dev_priv->psr.debug)) {
> +if (READ_ONCE(dev_priv->psr.debug) & I915_PSR_DEBUG_IRQ)
> {
> seq_printf(m, "Last attempted entry at: %lld\n",
> dev_priv->psr.last_entry_attempt);
> seq_printf(m, "Last exit at: %lld\n",
> >>> Oops indeed.
> >>>
> >>> Reviewed-by: Maarten Lankhorst
> >> before pushing to dinq please check the compilation there..
> >> kbuild bot raised an issue...
> >>
> >> so apparently we will need a backmerge before pushing this...
> > The failures are on
> >
> > [auto build test ERROR on drm-intel/for-linux-next]
> > [also build test ERROR on v4.18-rc8 next-20180810]
I don't expect this patch on any of this, so let's just ignore it ;)
now I'm asking myself why exactly kbuild bot is trying to apply
patches targeting 4.20 on branches targeting 4.18 and 4.19...
?! :/
> > Is a back-merge expected to fix that?
my concern was more about having this gap on dinq.
I checked and we are good to push this through dinq
no backmerge needed
so feel free to go ahead.
> and who does that back-merge?
maintainers per need bases
> Yes, this fix should have been pushed to drm-misc-next. So both branches need
> to be merged. :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] igt/pm_rpm: Close local fd before trying to unload module
Make sure everything we open in setup_environment() is paired to
teardown_environment().
Fixes: d8e78990aa2b ("igt/pm_rpm: Test reaquisition of runtime-pm after module
reload")
Signed-off-by: Chris Wilson
---
tests/pm_rpm.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index 65489bcdb..c0212ed70 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -717,21 +717,23 @@ out:
return wait_for_suspended();
}
-static void restore_environment(void)
+static void teardown_environment(void)
{
+ close(msr_fd);
+ if (has_pc8)
+ close(pc8_status_fd);
+
+ igt_restore_runtime_pm();
+
igt_pm_restore_sata_link_power_management(pm_data);
free(pm_data);
-}
-static void teardown_environment(void)
-{
- restore_environment();
fini_mode_set_data(_data);
+
close(debugfs);
- drmClose(drm_fd);
- close(msr_fd);
- if (has_pc8)
- close(pc8_status_fd);
+ close(drm_fd);
+
+ has_runtime_pm = false;
}
static void basic_subtest(void)
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] igt/pm_rpm: Avoid at_exit_drm_fd
Keep the drm_fd owned by pm_rpm as we need to relinquish all ownership of the device in order to unload the module. Signed-off-by: Chris Wilson --- tests/pm_rpm.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c index c0212ed70..f0781617c 100644 --- a/tests/pm_rpm.c +++ b/tests/pm_rpm.c @@ -697,7 +697,10 @@ static bool setup_environment(void) if (has_runtime_pm) goto out; - drm_fd = drm_open_driver_master(DRIVER_INTEL); + drm_fd = __drm_open_driver(DRIVER_INTEL); + igt_require(drm_fd != -1); + igt_device_set_master(drm_fd); + debugfs = igt_debugfs_dir(drm_fd); igt_require(debugfs != -1); -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-next-fixes
On Tue, Aug 14, 2018 at 03:31:40PM +0800, Zhenyu Wang wrote: > > Hi, > > This is initial gvt fixes for 4.19 with some accumulated fixes, > pls check details below. pulled, thanks. > > Thanks > -- > The following changes since commit 3237c0dbe21f8d2ca2feaa3891aff3619873cd30: > > drm/i915/kvmgt: Fix compilation error (2018-08-06 11:28:35 -0700) > > are available in the Git repository at: > > https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2018-08-14 > > for you to fetch changes up to 7590ebb8b456464e48840a6d106a0c07de6d723a: > > drm/i915/gvt: fix memory leak in intel_vgpu_ioctl() (2018-08-14 15:27:12 > +0800) > > > gvt-next-fixes-2018-08-14 > > - Fix an error code in gvt_dma_map_page() (Dan) > - Fix off by one error in intel_vgpu_write_fence() (Dan) > - Fix potential Spectre v1 (Gustavo) > - Fix workload free in vgpu release (Henry) > - Fix cleanup sequence in intel_gvt_clean_device (Henry) > - dmabuf mutex init place fix (Henry) > - possible memory leak in intel_vgpu_ioctl() err path (Yi) > - return error on cmd access check failure (Yan) > > > Dan Carpenter (2): > drm/i915/kvmgt: fix an error code in gvt_dma_map_page() > drm/i915/gvt: Off by one in intel_vgpu_write_fence() > > Gustavo A. R. Silva (1): > drm/i915/kvmgt: Fix potential Spectre v1 > > Hang Yuan (3): > drm/i915/gvt: free workload in vgpu release > drm/i915/gvt: fix cleanup sequence in intel_gvt_clean_device > drm/i915/gvt: initialize dmabuf mutex in vgpu_create > > Yi Wang (1): > drm/i915/gvt: fix memory leak in intel_vgpu_ioctl() > > Zhao Yan (1): > drm/i915/gvt: return error on cmd access > > drivers/gpu/drm/i915/gvt/aperture_gm.c | 2 +- > drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +- > drivers/gpu/drm/i915/gvt/gvt.c | 15 +++ > drivers/gpu/drm/i915/gvt/gvt.h | 4 +++- > drivers/gpu/drm/i915/gvt/kvmgt.c | 26 ++ > drivers/gpu/drm/i915/gvt/scheduler.c | 7 --- > drivers/gpu/drm/i915/gvt/scheduler.h | 3 +++ > drivers/gpu/drm/i915/gvt/vgpu.c| 23 +-- > 8 files changed, 58 insertions(+), 24 deletions(-) > > -- > Open Source Technology Center, Intel ltd. > > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 ___ 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: Only skip connector output for disable_display
== Series Details ==
Series: drm/i915: Only skip connector output for disable_display
URL : https://patchwork.freedesktop.org/series/48283/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4673 -> Patchwork_9958 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48283/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9958 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_coherency:
fi-gdg-551: PASS -> DMESG-FAIL (fdo#107164)
igt@drv_selftest@live_hangcheck:
fi-kbl-7560u: PASS -> DMESG-FAIL (fdo#106947, fdo#106560)
igt@kms_pipe_crc_basic@read-crc-pipe-a:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362)
{igt@kms_psr@primary_mmap_gtt}:
fi-cnl-psr: PASS -> DMESG-WARN (fdo#107372)
Possible fixes
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@drv_module_reload@basic-reload-inject:
fi-hsw-4770r: DMESG-WARN (fdo#107425) -> PASS
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
{fi-byt-clapper}: FAIL (fdo#107362, fdo#103191) -> PASS
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-FAIL (fdo#107372) -> DMESG-WARN (fdo#107372)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
== Participating hosts (53 -> 48) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4673 -> Patchwork_9958
CI_DRM_4673: f67334524375e4896c6fb75d28ecfa4ae3198231 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4599: 940cb5f46433a8ae48d21c6672e4d8ecd1358bbf @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9958: 1b44456f2940f281cd94fc180adef075b2f07cab @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
1b44456f2940 drm/i915: Only skip connector output for disable_display
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9958/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/20] drm: Let userspace check if driver supports modeset
Ping series review
On Wed, 2018-08-08 at 17:15 -0700, José Roberto de Souza wrote:
> GPU accelerators usually don't have display block or the display
> driver part can be disabled when building driver(for servers it saves
> some resources) so it is important let userspace check this
> capability too.
>
> Right now we are checking
> drmModeGetResources()/drm_mode_getresources() for a error to detect
> if display is enabled but it is a hackish way as it can fail for
> other reasons too.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_ioctl.c | 3 +++
> include/uapi/drm/drm.h | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c
> b/drivers/gpu/drm/drm_ioctl.c
> index ea10e9a26aad..3a8438ae9b51 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -244,6 +244,9 @@ static int drm_getcap(struct drm_device *dev,
> void *data, struct drm_file *file_
> case DRM_CAP_SYNCOBJ:
> req->value = drm_core_check_feature(dev,
> DRIVER_SYNCOBJ);
> return 0;
> + case DRM_CAP_MODESET:
> + req->value = drm_core_check_feature(dev,
> DRIVER_MODESET);
> + return 0;
> }
>
> /* Other caps only work with KMS drivers */
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 300f336633f2..85fae6ddbf48 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -649,6 +649,7 @@ struct drm_gem_open {
> #define DRM_CAP_PAGE_FLIP_TARGET 0x11
> #define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12
> #define DRM_CAP_SYNCOBJ 0x13
> +#define DRM_CAP_MODESET 0x14
>
> /** DRM_IOCTL_GET_CAP ioctl argument type */
> struct drm_get_cap {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: kill intel_display_power_well_is_enabled()
On Wed, Aug 08, 2018 at 03:16:11PM -0700, Paulo Zanoni wrote:
> Use the same coding pattern as we use in the other functions of the
> same file: just call lookup_power_well() directly in the only caller.
>
> Cc: Imre Deak
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 20 +++-
> 1 file changed, 3 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index e209edbc561d..e0947f662361 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -49,9 +49,6 @@
> * present for a given platform.
> */
>
> -bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
> - enum i915_power_well_id power_well_id);
> -
> static struct i915_power_well *
> lookup_power_well(struct drm_i915_private *dev_priv,
> enum i915_power_well_id power_well_id);
> @@ -678,8 +675,9 @@ static void assert_csr_loaded(struct drm_i915_private
> *dev_priv)
>
> static void assert_can_enable_dc5(struct drm_i915_private *dev_priv)
> {
> - bool pg2_enabled = intel_display_power_well_is_enabled(dev_priv,
> - SKL_DISP_PW_2);
> + struct i915_power_well *pg2 = lookup_power_well(dev_priv,
> + SKL_DISP_PW_2);
> + bool pg2_enabled = pg2->desc->ops->is_enabled(dev_priv, pg2);
>
> WARN_ONCE(pg2_enabled, "PG2 not disabled to enable DC5.\n");
>
> @@ -2302,18 +2300,6 @@ static const struct i915_power_well_desc
> chv_power_wells[] = {
> },
> };
>
> -bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
> - enum i915_power_well_id power_well_id)
> -{
> - struct i915_power_well *power_well;
> - bool ret;
> -
> - power_well = lookup_power_well(dev_priv, power_well_id);
> - ret = power_well->desc->ops->is_enabled(dev_priv, power_well);
> -
> - return ret;
> -}
> -
Or rather export a locked version of it and use that in intel_hdcp.c to
better hide the internals?
> static const struct i915_power_well_desc skl_power_wells[] = {
> {
> .name = "always-on",
> --
> 2.14.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Only skip connector output for disable_display
We want to add no connectors, encoders or crtcs if the display is disabled, but we still need to hook up any existing HW so that we can power it down. Signed-off-by: Chris Wilson Reviewed-by: Imre Deak --- I think it's better to trickle this one in by itself rather than send the series of 3 patches to fix the immediate issue with the set_init_power wakeref leak. -Chris --- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index dd6a6b49159b..690e1e816e77 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -14130,6 +14130,9 @@ static void intel_setup_outputs(struct drm_i915_private *dev_priv) intel_pps_init(dev_priv); + if (INTEL_INFO(dev_priv)->num_pipes == 0) + return; + /* * intel_edp_init_connector() depends on this completing first, to * prevent the registeration of both eDP and LVDS and the incorrect @@ -15208,9 +15211,6 @@ int intel_modeset_init(struct drm_device *dev) intel_init_pm(dev_priv); - if (INTEL_INFO(dev_priv)->num_pipes == 0) - return 0; - /* * There may be no VBT; and if the BIOS enabled SSC we can * just keep using it to avoid unnecessary flicker. Whereas if the -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/14] drm/i915: Only skip connector output for disable_display
On Sun, Aug 12, 2018 at 11:36:32PM +0100, Chris Wilson wrote: > We want to add no connectors, encoders or crtcs if the display is > disabled, but we still need to hook up any existing HW so that we can > power it down. > > Signed-off-by: Chris Wilson Yes, otherwise the dependent power domains are not claimed either and so we'd (normally) disable power wells with active outputs, which is wrong. Odd that it leads to system hang only on BSW (after the set_init_power refactoring). As you pointed out currently the refleak caused by the intel_display_set_init_power() logic hides this problem (we don't ever call intel_display_set_init_power(false) if i915.disable_display=1). Reviewed-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_display.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index cc3f21ddae9c..dbf3d80353b1 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -14128,6 +14128,9 @@ static void intel_setup_outputs(struct > drm_i915_private *dev_priv) > > intel_pps_init(dev_priv); > > + if (INTEL_INFO(dev_priv)->num_pipes == 0) > + return; > + > /* >* intel_edp_init_connector() depends on this completing first, to >* prevent the registeration of both eDP and LVDS and the incorrect > @@ -15206,9 +15209,6 @@ int intel_modeset_init(struct drm_device *dev) > > intel_init_pm(dev_priv); > > - if (INTEL_INFO(dev_priv)->num_pipes == 0) > - return 0; > - > /* >* There may be no VBT; and if the BIOS enabled SSC we can >* just keep using it to avoid unnecessary flicker. Whereas if the > -- > 2.18.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHv3] lib/ratelimit: Lockless ratelimiting
On Tue 2018-07-03 23:56:28, Dmitry Safonov wrote:
> Currently ratelimit_state is protected with spin_lock. If the .lock is
> taken at the moment of ___ratelimit() call, the message is suppressed to
> make ratelimiting robust.
>
> That results in the following issue issue:
> CPU0 CPU1
> -- --
> printk_ratelimit() printk_ratelimit()
> | |
> try_spin_lock() try_spin_lock()
> | |
> time_is_before_jiffies() return 0; // suppress
>
> So, concurrent call of ___ratelimit() results in silently suppressing
> one of the messages, regardless if the limit is reached or not.
> And rc->missed is not increased in such case so the issue is covered
> from user.
>
> Convert ratelimiting to use atomic counters and drop spin_lock.
>
> Note: That might be unexpected, but with the first interval of messages
> storm one can print up to burst*2 messages. So, it doesn't guarantee
> that in *any* interval amount of messages is lesser than burst.
> But, that differs lightly from previous behavior where one can start
> burst=5 interval and print 4 messages on the last milliseconds of
> interval + new 5 messages from new interval (totally 9 messages in
> lesser than interval value):
I am still confused by this paragraph. Does this patch change the
behavior? What is the original and what is the new one, please?
>msg0 msg1-msg4 msg0-msg4
> | | |
> | | |
> |--o-o-|-o|--> (t)
> <--->
>Lesser than burst
>
> Dropped dev/random patch since v1 version:
> lkml.kernel.org/r/<20180510125211.12583-1-d...@arista.com>
>
> Dropped `name' in as it's unused in RATELIMIT_STATE_INIT()
>
> diff --git a/lib/ratelimit.c b/lib/ratelimit.c
> index d01f47135239..d9b749d40108 100644
> --- a/lib/ratelimit.c
> +++ b/lib/ratelimit.c
> @@ -13,6 +13,18 @@
> #include
> #include
>
> +static void ratelimit_end_interval(struct ratelimit_state *rs, const char
> *func)
> +{
> + rs->begin = jiffies;
> +
> + if (!(rs->flags & RATELIMIT_MSG_ON_RELEASE)) {
> + unsigned int missed = atomic_xchg(>missed, 0);
> +
> + if (missed)
> + pr_warn("%s: %u callbacks suppressed\n", func, missed);
> + }
> +}
> +
> /*
> * __ratelimit - rate limiting
> * @rs: ratelimit_state data
> @@ -27,45 +39,30 @@
> */
> int ___ratelimit(struct ratelimit_state *rs, const char *func)
> {
> - unsigned long flags;
> - int ret;
> -
> if (!rs->interval)
> return 1;
>
> - /*
> - * If we contend on this state's lock then almost
> - * by definition we are too busy to print a message,
> - * in addition to the one that will be printed by
> - * the entity that is holding the lock already:
> - */
> - if (!raw_spin_trylock_irqsave(>lock, flags))
> + if (unlikely(!rs->burst)) {
> + atomic_add_unless(>missed, 1, -1);
> + if (time_is_before_jiffies(rs->begin + rs->interval))
> + ratelimit_end_interval(rs, func);
This is racy. time_is_before_jiffies() might be valid on two
CPUs in parallel. They would both call ratelimit_end_interval().
This is not longer atomic context. Therefore one might get scheduled
and set rs->begin = jiffies seconds later. I am sure that there might
be more crazy scenarios.
> +
> return 0;
> + }
>
> - if (!rs->begin)
> - rs->begin = jiffies;
> + if (atomic_add_unless(>printed, 1, rs->burst))
> + return 1;
>
> if (time_is_before_jiffies(rs->begin + rs->interval)) {
> - if (rs->missed) {
> - if (!(rs->flags & RATELIMIT_MSG_ON_RELEASE)) {
> - printk_deferred(KERN_WARNING
> - "%s: %d callbacks suppressed\n",
> - func, rs->missed);
> - rs->missed = 0;
> - }
> - }
> - rs->begin = jiffies;
> - rs->printed = 0;
> - }
> - if (rs->burst && rs->burst > rs->printed) {
> - rs->printed++;
> - ret = 1;
> - } else {
> - rs->missed++;
> - ret = 0;
> + if (atomic_cmpxchg(>printed, rs->burst, 0))
> + ratelimit_end_interval(rs, func);
> }
> - raw_spin_unlock_irqrestore(>lock, flags);
>
> - return ret;
> + if (atomic_add_unless(>printed, 1, rs->burst))
> + return 1;
The entire logic is complicated and hard to understand. Especially calling
ratelimit_end_interval() and atomic_add_unless(>printed) twice.
> + atomic_add_unless(>missed, 1, -1);
> +
> + return 0;
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915/execlists: Assert the queue is non-empty on unsubmitting
== Series Details == Series: series starting with [1/4] drm/i915/execlists: Assert the queue is non-empty on unsubmitting URL : https://patchwork.freedesktop.org/series/48269/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4672_full -> Patchwork_9956_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9956_full that come from known issues: === IGT changes === Issues hit igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-shrfb-plflip-blt: shard-glk: PASS -> FAIL (fdo#103167) igt@kms_setmode@basic: shard-glk: PASS -> FAIL (fdo#99912) fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4672 -> Patchwork_9956 CI_DRM_4672: 2a55ea192b780b798b8c5bf2e458694ba54a312d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9956: ed6c526c3084f8cfc3e2b0e21bacc513f49228d5 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9956/shards.html ___ 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: Remove useless error return from intel_init_mocs_engine()
== Series Details ==
Series: drm/i915: Remove useless error return from intel_init_mocs_engine()
URL : https://patchwork.freedesktop.org/series/48276/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4673 -> Patchwork_9957 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48276/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9957 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-cnl-psr: PASS -> DMESG-FAIL (fdo#106560)
{fi-cfl-8109u}: PASS -> DMESG-FAIL (fdo#106560)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927)
{igt@kms_psr@primary_mmap_gtt}:
fi-cnl-psr: PASS -> DMESG-WARN (fdo#107372)
Possible fixes
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@drv_module_reload@basic-reload-inject:
fi-hsw-4770r: DMESG-WARN (fdo#107425) -> PASS
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
{fi-byt-clapper}: FAIL (fdo#103191, fdo#107362) -> PASS
igt@pm_rpm@basic-pci-d3-state:
fi-skl-6600u: FAIL -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
== Participating hosts (53 -> 48) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4673 -> Patchwork_9957
CI_DRM_4673: f67334524375e4896c6fb75d28ecfa4ae3198231 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4599: 940cb5f46433a8ae48d21c6672e4d8ecd1358bbf @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9957: 39a6ec518272a248cb850fa11e09480cdec1aa37 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
39a6ec518272 drm/i915: Remove useless error return from intel_init_mocs_engine()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9957/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Remove useless error return from intel_init_mocs_engine()
As the only error is for a programming error in constructing the static
tables describing the register values, replace the error code
propagation with an assert.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 6 +-
drivers/gpu/drm/i915/intel_mocs.c | 11 +++
drivers/gpu/drm/i915/intel_mocs.h | 2 +-
3 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3f90c74038ef..841895cfb05f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1769,11 +1769,7 @@ static bool unexpected_starting_state(struct
intel_engine_cs *engine)
static int gen8_init_common_ring(struct intel_engine_cs *engine)
{
- int ret;
-
- ret = intel_mocs_init_engine(engine);
- if (ret)
- return ret;
+ intel_mocs_init_engine(engine);
intel_engine_reset_breadcrumbs(engine);
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 9f0bd6a4cb79..77e9871a8c9a 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -232,20 +232,17 @@ static i915_reg_t mocs_register(enum intel_engine_id
engine_id, int index)
*
* This function simply emits a MI_LOAD_REGISTER_IMM command for the
* given table starting at the given address.
- *
- * Return: 0 on success, otherwise the error status.
*/
-int intel_mocs_init_engine(struct intel_engine_cs *engine)
+void intel_mocs_init_engine(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
struct drm_i915_mocs_table table;
unsigned int index;
if (!get_mocs_settings(dev_priv, ))
- return 0;
+ return;
- if (WARN_ON(table.size > GEN9_NUM_MOCS_ENTRIES))
- return -ENODEV;
+ GEM_BUG_ON(table.size > GEN9_NUM_MOCS_ENTRIES);
for (index = 0; index < table.size; index++)
I915_WRITE(mocs_register(engine->id, index),
@@ -262,8 +259,6 @@ int intel_mocs_init_engine(struct intel_engine_cs *engine)
for (; index < GEN9_NUM_MOCS_ENTRIES; index++)
I915_WRITE(mocs_register(engine->id, index),
table.table[0].control_value);
-
- return 0;
}
/**
diff --git a/drivers/gpu/drm/i915/intel_mocs.h
b/drivers/gpu/drm/i915/intel_mocs.h
index d1751f91c1a4..d89080d75b80 100644
--- a/drivers/gpu/drm/i915/intel_mocs.h
+++ b/drivers/gpu/drm/i915/intel_mocs.h
@@ -54,6 +54,6 @@
int intel_rcs_context_init_mocs(struct i915_request *rq);
void intel_mocs_init_l3cc_table(struct drm_i915_private *dev_priv);
-int intel_mocs_init_engine(struct intel_engine_cs *engine);
+void intel_mocs_init_engine(struct intel_engine_cs *engine);
#endif
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] firmware/dmc/icl: load v1.07 on icelake.
>-Original Message-
>From: Deak, Imre
>Sent: Wednesday, August 15, 2018 4:35 AM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Yadav, Jyoti R ;
>Vivi, Rodrigo ; Zanoni, Paulo R
>
>Subject: Re: [PATCH 1/1] firmware/dmc/icl: load v1.07 on icelake.
>
>On Mon, Aug 13, 2018 at 11:45:32PM -0500, Anusha Srivatsa wrote:
>> Add Support to load DMC on Icelake.
>>
>> While at it, also add support to load the firmware during system
>> resume.
>>
>> v2: load firmware during system resume.(Imre)
>>
>> v3: enable has_csr for icelake.(Jyoti)
>>
>> Cc: Jyoti Yadav
>> Cc: Imre Deak
>> Cc: Rodrigo Vivi
>> Cc: Paulo Zanoni
>> Signed-off-by: Anusha Srivatsa
>> ---
>> drivers/gpu/drm/i915/i915_pci.c | 2 +-
>> drivers/gpu/drm/i915/intel_csr.c| 7 +++
>> drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++
>> 3 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_pci.c
>> b/drivers/gpu/drm/i915/i915_pci.c index e931b48369dd..bbd331f1d5d9
>> 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -600,7 +600,7 @@ static const struct intel_device_info
>intel_cannonlake_info = {
>> GEN10_FEATURES, \
>> GEN(11), \
>> .ddb_size = 2048, \
>> -.has_csr = 0, \
>> +.has_csr = 1, \
>
>The default is correct already, so it's enough not to reinit this field.
>Also could you send this one change separately after the following patch is
>merged:
>https://patchwork.freedesktop.org/patch/244656/
>
>That way we could see if not specifying the firmware doesn't break things.
>(This
>scenario is valid for a new platform.)
>
Sure. Thanks Imre.
Anusha
>Thanks,
>Imre
>
>> .has_logical_ring_elsq = 1
>>
>> static const struct intel_device_info intel_icelake_11_info = { diff
>> --git a/drivers/gpu/drm/i915/intel_csr.c
>> b/drivers/gpu/drm/i915/intel_csr.c
>> index cf9b600cca79..393d419afb91 100644
>> --- a/drivers/gpu/drm/i915/intel_csr.c
>> +++ b/drivers/gpu/drm/i915/intel_csr.c
>> @@ -34,6 +34,9 @@
>> * low-power state and comes back to normal.
>> */
>>
>> +#define I915_CSR_ICL "i915/icl_dmc_ver1_07.bin"
>> +#define ICL_CSR_VERSION_REQUIREDCSR_VERSION(1, 7)
>> +
>> #define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin"
>> MODULE_FIRMWARE(I915_CSR_GLK);
>> #define GLK_CSR_VERSION_REQUIREDCSR_VERSION(1, 4)
>> @@ -301,6 +304,8 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
>*dev_priv,
>> if (csr->fw_path == i915_modparams.dmc_firmware_path) {
>> /* Bypass version check for firmware override. */
>> required_version = csr->version;
>> +} else if (IS_ICELAKE(dev_priv)) {
>> +required_version = ICL_CSR_VERSION_REQUIRED;
>> } else if (IS_CANNONLAKE(dev_priv)) {
>> required_version = CNL_CSR_VERSION_REQUIRED;
>> } else if (IS_GEMINILAKE(dev_priv)) { @@ -458,6 +463,8 @@ void
>> intel_csr_ucode_init(struct drm_i915_private *dev_priv)
>>
>> if (i915_modparams.dmc_firmware_path)
>> csr->fw_path = i915_modparams.dmc_firmware_path;
>> +else if (IS_ICELAKE(dev_priv))
>> +csr->fw_path = I915_CSR_ICL;
>> else if (IS_CANNONLAKE(dev_priv))
>> csr->fw_path = I915_CSR_CNL;
>> else if (IS_GEMINILAKE(dev_priv))
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index e209edbc561d..7686f4d32533 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -3588,6 +3588,9 @@ static void icl_display_core_init(struct
>> drm_i915_private *dev_priv,
>>
>> /* 7. Setup MBUS. */
>> icl_mbus_init(dev_priv);
>> +
>> +if (resume && dev_priv->csr.dmc_payload)
>> +intel_csr_load_program(dev_priv);
>> }
>>
>> static void icl_display_core_uninit(struct drm_i915_private
>> *dev_priv)
>> --
>> 2.14.1
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Include reset depth in traces
== Series Details == Series: drm/i915/execlists: Include reset depth in traces URL : https://patchwork.freedesktop.org/series/48263/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4671_full -> Patchwork_9955_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9955_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9955_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9955_full: === IGT changes === Warnings igt@pm_rc6_residency@rc6-accuracy: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9955_full that come from known issues: === IGT changes === Issues hit igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4671 -> Patchwork_9955 CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9955: b5ab07b47b12915d45ef7148c264bd310255fb3b @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9955/shards.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 1/3] igt/gem_sync: Exercise sync after context switch
Quoting Antonio Argenziano (2018-08-15 18:20:10)
>
>
> On 15/08/18 03:26, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-08-15 00:50:43)
> >>
> >>
> >> On 10/08/18 04:01, Chris Wilson wrote:
> >>> This exercises a special case that may be of interest, waiting for a
> >>> context that may be preempted in order to reduce the wait.
> >>>
> >>> Signed-off-by: Chris Wilson
> >>> ---
> >>> + cycles = 0;
> >>> + elapsed = 0;
> >>> + start = gettime();
> >>> + do {
> >>> + do {
> >>> + double this;
> >>> +
> >>> + gem_execbuf(fd, [0].execbuf);
> >>> + gem_execbuf(fd, [1].execbuf);
> >>
> >> I'm not sure where the preemption, mentioned in the commit message, is
> >> coming in.
> >
> > Internally. I've suggested that we reorder equivalent contexts in order
> > to satisfy client waits earlier. So having created two independent
> > request queues, userspace should be oblivious to the execution order.
>
> But there isn't an assert because you don't want that to be part of the
> contract between the driver and userspace, is that correct?
Correct. Userspace hasn't specified an order between the two contexts so
can't actually assert it happens in a particular order. We are free then
to do whatever we like, but that also means no assertion. Just the
figures look pretty and ofc we have to check that nothing actually
breaks.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/3] igt/gem_sync: Exercise sync after context switch
On 15/08/18 03:26, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-15 00:50:43)
On 10/08/18 04:01, Chris Wilson wrote:
This exercises a special case that may be of interest, waiting for a
context that may be preempted in order to reduce the wait.
Signed-off-by: Chris Wilson
---
+ cycles = 0;
+ elapsed = 0;
+ start = gettime();
+ do {
+ do {
+ double this;
+
+ gem_execbuf(fd, [0].execbuf);
+ gem_execbuf(fd, [1].execbuf);
I'm not sure where the preemption, mentioned in the commit message, is
coming in.
Internally. I've suggested that we reorder equivalent contexts in order
to satisfy client waits earlier. So having created two independent
request queues, userspace should be oblivious to the execution order.
But there isn't an assert because you don't want that to be part of the
contract between the driver and userspace, is that correct?
Antonio
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/execlists: Assert the queue is non-empty on unsubmitting
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Assert the queue is non-empty on unsubmitting URL : https://patchwork.freedesktop.org/series/48262/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4671_full -> Patchwork_9954_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9954_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9954_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9954_full: === IGT changes === Possible regressions igt@gem_eio@reset-stress: shard-apl: PASS -> FAIL Warnings igt@kms_concurrent@pipe-b: shard-snb: PASS -> SKIP +2 == Known issues == Here are the changes found in Patchwork_9954_full that come from known issues: === IGT changes === Possible fixes igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4671 -> Patchwork_9954 CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9954: c7ea5bd17c233715270d95345ae5b335b50b0907 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9954/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix PM refcounting w/o DMC firmware (rev2)
== Series Details == Series: drm/i915: Fix PM refcounting w/o DMC firmware (rev2) URL : https://patchwork.freedesktop.org/series/48252/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4671_full -> Patchwork_9953_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9953_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9953_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9953_full: === IGT changes === Warnings igt@perf_pmu@rc6: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9953_full that come from known issues: === IGT changes === Issues hit igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_wait@await-default: shard-snb: INCOMPLETE (fdo#105411) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4671 -> Patchwork_9953 CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9953: a4a5d48f719b9e1c2f3fa9d91ee3204b3768bfe4 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9953/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev7)
== Series Details ==
Series: drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev7)
URL : https://patchwork.freedesktop.org/series/47067/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4671_full -> Patchwork_9952_full =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9952_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9952_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
== Possible new issues ==
Here are the unknown changes that may have been introduced in
Patchwork_9952_full:
=== IGT changes ===
Possible regressions
igt@drv_selftest@live_execlists:
shard-hsw: PASS -> DMESG-WARN +15
igt@drv_selftest@live_objects:
shard-glk: PASS -> DMESG-WARN +14
igt@gem_eio@execbuf:
shard-glk: PASS -> DMESG-FAIL +21
igt@gem_eio@in-flight-contexts-immediate:
shard-hsw: PASS -> DMESG-FAIL +19
igt@gem_eio@in-flight-immediate:
shard-apl: PASS -> DMESG-FAIL +20
igt@gem_eio@in-flight-internal-1us:
shard-hsw: SKIP -> DMESG-FAIL
igt@gem_eio@in-flight-suspend:
shard-kbl: PASS -> DMESG-FAIL +22
igt@gem_eio@throttle:
shard-snb: PASS -> DMESG-FAIL +18
igt@kms_draw_crc@draw-method-rgb565-render-xtiled:
shard-apl: SKIP -> FAIL +1
shard-glk: SKIP -> FAIL +1
shard-hsw: SKIP -> FAIL
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-gtt:
shard-snb: PASS -> FAIL +6
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-pwrite:
shard-hsw: PASS -> FAIL +50
igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render:
shard-snb: SKIP -> FAIL +1
igt@perf@sysctl-defaults:
shard-apl: PASS -> DMESG-WARN
shard-kbl: PASS -> DMESG-WARN
igt@pm_rpm@cursor-dpms:
shard-glk: PASS -> FAIL +6
igt@pm_rpm@gem-mmap-cpu:
shard-apl: PASS -> FAIL +10
igt@pm_rpm@pm-caching:
shard-kbl: PASS -> FAIL
Warnings
igt@gem_exec_reloc@basic-write-read:
shard-hsw: PASS -> SKIP +242
igt@gem_exec_store@basic-vebox:
shard-kbl: PASS -> SKIP +169
igt@gem_mocs_settings@mocs-reset-render:
shard-apl: PASS -> SKIP +219
igt@gem_pwrite_pread@snooped-pwrite-blt-cpu_mmap-correctness:
shard-snb: PASS -> SKIP +106
igt@gem_userptr_blits@map-fixed-invalidate-overlap:
shard-glk: PASS -> SKIP +277
== Known issues ==
Here are the changes found in Patchwork_9952_full that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_cursor_legacy@cursor-vs-flip-varying-size:
shard-hsw: PASS -> FAIL (fdo#103355)
igt@kms_draw_crc@draw-method-rgb565-render-xtiled:
shard-kbl: SKIP -> FAIL (fdo#106064)
igt@kms_draw_crc@draw-method-xrgb2101010-render-untiled:
shard-kbl: PASS -> FAIL (fdo#106064)
igt@kms_flip@2x-flip-vs-expired-vblank:
shard-glk: PASS -> FAIL (fdo#105363)
igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt:
shard-kbl: PASS -> FAIL (fdo#106067, fdo#107260) +4
igt@kms_frontbuffer_tracking@fbc-2p-rte:
shard-hsw: PASS -> FAIL (fdo#105682) +1
igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render:
shard-apl: PASS -> FAIL (fdo#107260) +22
igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render:
shard-glk: SKIP -> FAIL (fdo#107260)
shard-kbl: SKIP -> FAIL (fdo#106067, fdo#107260)
shard-apl: SKIP -> FAIL (fdo#107260)
igt@kms_plane_lowres@pipe-a-tiling-y:
shard-kbl: PASS -> FAIL (fdo#106066) +6
igt@kms_rotation_crc@sprite-rotation-90:
shard-glk: PASS -> FAIL (fdo#107260) +62
igt@kms_setmode@basic:
shard-apl: PASS -> FAIL (fdo#99912)
Possible fixes
igt@gem_exec_schedule@pi-ringfull-blt:
shard-glk: FAIL (fdo#103158) -> SKIP +1
shard-apl: FAIL (fdo#103158) -> SKIP +1
igt@gem_exec_schedule@pi-ringfull-render:
shard-kbl: FAIL (fdo#103158) -> SKIP +1
igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
shard-glk: FAIL (fdo#105363) -> PASS
igt@kms_setmode@basic:
shard-kbl: FAIL (fdo#99912) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103355
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/execlists: Assert the queue is non-empty on unsubmitting
== Series Details ==
Series: series starting with [1/4] drm/i915/execlists: Assert the queue is
non-empty on unsubmitting
URL : https://patchwork.freedesktop.org/series/48269/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4672 -> Patchwork_9956 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48269/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9956 that come from known issues:
=== IGT changes ===
Issues hit
{igt@amdgpu/amd_prime@amd-to-i915}:
{fi-kbl-8809g}: NOTRUN -> FAIL (fdo#107341)
igt@drv_selftest@live_hangcheck:
fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
fi-skl-6600u: PASS -> DMESG-FAIL (fdo#107174, fdo#106560)
fi-kbl-guc: PASS -> DMESG-FAIL (fdo#106947)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362, fdo#103191) +1
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: PASS -> FAIL (fdo#104008)
Possible fixes
{igt@amdgpu/amd_basic@userptr}:
{fi-kbl-8809g}: INCOMPLETE (fdo#107402) -> PASS
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: DMESG-FAIL (fdo#102614) -> PASS
{fi-byt-clapper}: FAIL (fdo#103167) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
{fi-cfl-8109u}: INCOMPLETE (fdo#106070) -> PASS
{igt@kms_psr@primary_mmap_gtt}:
fi-cnl-psr: DMESG-WARN (fdo#107372) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fdo#106070 https://bugs.freedesktop.org/show_bug.cgi?id=106070
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107341 https://bugs.freedesktop.org/show_bug.cgi?id=107341
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
fdo#107402 https://bugs.freedesktop.org/show_bug.cgi?id=107402
== Participating hosts (53 -> 48) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4672 -> Patchwork_9956
CI_DRM_4672: 2a55ea192b780b798b8c5bf2e458694ba54a312d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9956: ed6c526c3084f8cfc3e2b0e21bacc513f49228d5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ed6c526c3084 drm/i915/execlists: Use direct submission to restart HW after reset
da4b9a58392d drm/i915/execlists: Include reset depth in traces
1717e4384796 drm/i915/execlists: Reset queue_priority on cancellation
472fc90cb853 drm/i915/execlists: Assert the queue is non-empty on unsubmitting
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9956/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915/execlists: Assert the queue is non-empty on unsubmitting
== Series Details == Series: series starting with [1/4] drm/i915/execlists: Assert the queue is non-empty on unsubmitting URL : https://patchwork.freedesktop.org/series/48269/ State : warning == Summary == $ dim checkpatch origin/drm-tip 472fc90cb853 drm/i915/execlists: Assert the queue is non-empty on unsubmitting -:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #9: <0>[ 531.960431] drv_self-48067 527402570us : intel_gpu_reset: engine_mask=1, ret=0, retry=0 total: 0 errors, 1 warnings, 0 checks, 7 lines checked 1717e4384796 drm/i915/execlists: Reset queue_priority on cancellation da4b9a58392d drm/i915/execlists: Include reset depth in traces ed6c526c3084 drm/i915/execlists: Use direct submission to restart HW after reset ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Basic stress test for rapid context switching
== Series Details == Series: drm/i915/selftests: Basic stress test for rapid context switching URL : https://patchwork.freedesktop.org/series/48255/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4671_full -> Patchwork_9951_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9951_full that come from known issues: === IGT changes === Issues hit igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_wait@await-default: shard-snb: INCOMPLETE (fdo#105411) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4671 -> Patchwork_9951 CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9951: a5421de087ad8a419add8ea857f6bc841cdab971 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9951/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Include reset depth in traces
== Series Details ==
Series: drm/i915/execlists: Include reset depth in traces
URL : https://patchwork.freedesktop.org/series/48263/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4671 -> Patchwork_9955 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48263/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9955 that come from known issues:
=== IGT changes ===
Issues hit
igt@debugfs_test@read_all_entries:
fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713)
igt@drv_selftest@live_hangcheck:
fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
{fi-icl-u}: NOTRUN -> DMESG-WARN (fdo#107382) +4
{igt@kms_psr@primary_page_flip}:
{fi-icl-u}: NOTRUN -> FAIL (fdo#107383) +3
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107382 https://bugs.freedesktop.org/show_bug.cgi?id=107382
fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
== Participating hosts (53 -> 49) ==
Additional (1): fi-icl-u
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4671 -> Patchwork_9955
CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9955: b5ab07b47b12915d45ef7148c264bd310255fb3b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b5ab07b47b12 drm/i915/execlists: Include reset depth in traces
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9955/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for RFT: Do we detect WA_TAIL?
== Series Details == Series: RFT: Do we detect WA_TAIL? URL : https://patchwork.freedesktop.org/series/48247/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4671_full -> Patchwork_9949_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9949_full that come from known issues: === IGT changes === Issues hit igt@kms_plane_lowres@pipe-a-tiling-y: shard-glk: PASS -> FAIL (fdo#103166) igt@perf@polling: shard-hsw: PASS -> FAIL (fdo#102252) Possible fixes igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4671 -> Patchwork_9949 CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9949: ea2011cc92cd73536c59ac9392cfe108e10b13a8 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9949/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/execlists: Include reset depth in traces
Show the reset depth (the tasklet disable count) in the GEM_TRACE to
indicate when we might not expect tasklets to be flushed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submission.c | 3 ++-
drivers/gpu/drm/i915/intel_lrc.c| 6 --
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 195adbd0ebf7..8f43c2fe90ca 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -815,7 +815,8 @@ guc_reset_prepare(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = >execlists;
- GEM_TRACE("%s\n", engine->name);
+ GEM_TRACE("%s: depth<-%d\n", engine->name,
+ atomic_read(>tasklet.count));
/*
* Prevent request submission to the hardware until we have
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 178a74e29400..257d6f5f44d1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1834,7 +1834,8 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
struct i915_request *request, *active;
unsigned long flags;
- GEM_TRACE("%s\n", engine->name);
+ GEM_TRACE("%s: depth<-%d\n", engine->name,
+ atomic_read(>tasklet.count));
/*
* Prevent request submission to the hardware until we have
@@ -1982,7 +1983,8 @@ static void execlists_reset_finish(struct intel_engine_cs
*engine)
*/
__tasklet_enable_sync_once(>tasklet);
- GEM_TRACE("%s\n", engine->name);
+ GEM_TRACE("%s: depth->%d\n", engine->name,
+ atomic_read(>tasklet.count));
}
static int intel_logical_ring_emit_pdps(struct i915_request *rq)
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/execlists: Assert the queue is non-empty on unsubmitting
In the sequence <0>[ 531.960431] drv_self-48067 527402570us : intel_gpu_reset: engine_mask=1, ret=0, retry=0 <0>[ 531.960431] drv_self-48067 527402571us : execlists_reset: rcs0 request global=115de, current=71133 <0>[ 531.960431] drv_self-48067d..1 527402571us : execlists_cancel_port_requests: rcs0:port0 global=71134 (fence 826b:198), (current 71133) <0>[ 531.960431] drv_self-48067d..1 527402572us : execlists_cancel_port_requests: rcs0:port1 global=71135 (fence 826c:53), (current 71133) <0>[ 531.960431] drv_self-48067d..1 527402572us : __i915_request_unsubmit: rcs0 fence 826c:53 <- global=71135, current 71133 <0>[ 531.960431] drv_self-48067d..1 527402579us : __i915_request_unsubmit: rcs0 fence 826b:198 <- global=71134, current 71133 <0>[ 531.960431] drv_self-48067 527402613us : intel_engine_cancel_stop_cs: rcs0 <0>[ 531.960431] drv_self-48067 527402624us : execlists_reset_finish: rcs0 we are missing the execlists_submission_tasklet() invocation before the execlists_reset_fini() implying that either the queue is empty, or we failed to schedule and run the tasklet on finish. Add an assert so we are sure that on unsubmitting the incomplete request after reset, the queue is indeed populated. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 3f90c74038ef..0e90fd831c70 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -344,6 +344,7 @@ static void __unwind_incomplete_requests(struct intel_engine_cs *engine) last_prio = rq_prio(rq); p = lookup_priolist(engine, last_prio); } + GEM_BUG_ON(RB_EMPTY_ROOT(>execlists.queue.rb_root)); GEM_BUG_ON(p->priority != rq_prio(rq)); list_add(>sched.link, >requests); -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/execlists: Reset queue_priority on cancellation
If we have an available execlists port, the queue_priority should be INT_MIN to allow immediate direct submission. As we clear the ports in execlists_cancel_port_requests(), we should then reset queue_priority to show the available space. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 0e90fd831c70..178a74e29400 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -800,6 +800,7 @@ execlists_cancel_port_requests(struct intel_engine_execlists * const execlists) } execlists_clear_all_active(execlists); + execlists->queue_priority = INT_MIN; } static void reset_csb_pointers(struct intel_engine_execlists *execlists) -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/execlists: Use direct submission to restart HW after reset
We can bypass ksoftirqd for restarting our submission queue after a GPU
reset and so avoid any inscrutable delays.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submission.c | 24 +
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 8f43c2fe90ca..d9f9b12a0213 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -842,6 +842,29 @@ guc_reset_prepare(struct intel_engine_cs *engine)
return i915_gem_find_active_request(engine);
}
+static void guc_reset_finish(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists * const execlists = >execlists;
+
+ /* After a GPU reset, we may have requests to replay */
+ if (!RB_EMPTY_ROOT(>queue.rb_root))
+ tasklet_schedule(>tasklet);
+
+ /*
+* Flush the tasklet while we still have the forcewake to be sure
+* that it is not allowed to sleep before we restart and reload a
+* context.
+*
+* As before (with execlists_reset_prepare) we rely on the caller
+* serialising multiple attempts to reset so that we know that we
+* are the only one manipulating tasklet state.
+*/
+ __tasklet_enable_sync_once(>tasklet);
+
+ GEM_TRACE("%s: depth->%d\n", engine->name,
+ atomic_read(>tasklet.count));
+}
+
/*
* Everything below here is concerned with setup & teardown, and is
* therefore not part of the somewhat time-critical batch-submission
@@ -1289,6 +1312,7 @@ static void guc_set_default_submission(struct
intel_engine_cs *engine)
engine->unpark = guc_submission_unpark;
engine->reset.prepare = guc_reset_prepare;
+ engine->reset.finish = guc_reset_finish;
engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 257d6f5f44d1..4631d38f0b6e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1970,7 +1970,7 @@ static void execlists_reset_finish(struct intel_engine_cs
*engine)
/* After a GPU reset, we may have requests to replay */
if (!RB_EMPTY_ROOT(>queue.rb_root))
- tasklet_schedule(>tasklet);
+ execlists_submission_tasklet(execlists->tasklet.data);
/*
* Flush the tasklet while we still have the forcewake to be sure
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix PM refcounting w/o DMC firmware (rev2)
On Wed, Aug 15, 2018 at 01:46:01PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix PM refcounting w/o DMC firmware (rev2)
> URL : https://patchwork.freedesktop.org/series/48252/
> State : success
Pushed to -dinq, thanks for the review.
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4671 -> Patchwork_9953 =
>
> == Summary - SUCCESS ==
>
> No regressions found.
>
> External URL:
> https://patchwork.freedesktop.org/api/1.0/series/48252/revisions/2/mbox/
>
> == Possible new issues ==
>
> Here are the unknown changes that may have been introduced in
> Patchwork_9953:
>
> === IGT changes ===
>
> Possible regressions
>
> {igt@pm_rpm@module-reload}:
> fi-bxt-j4205: SKIP -> DMESG-FAIL
>
>
> == Known issues ==
>
> Here are the changes found in Patchwork_9953 that come from known issues:
>
> === IGT changes ===
>
> Issues hit
>
> {igt@amdgpu/amd_prime@i915-to-amd}:
> fi-bxt-j4205: SKIP -> INCOMPLETE (fdo#103927)
>
>
> Possible fixes
>
> igt@kms_frontbuffer_tracking@basic:
> fi-hsw-peppy: DMESG-FAIL (fdo#102614) -> PASS
>
>
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
> fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
>
>
> == Participating hosts (53 -> 47) ==
>
> Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
> fi-ctg-p8600 fi-gdg-551
>
>
> == Build changes ==
>
> * Linux: CI_DRM_4671 -> Patchwork_9953
>
> CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> Patchwork_9953: a4a5d48f719b9e1c2f3fa9d91ee3204b3768bfe4 @
> git://anongit.freedesktop.org/gfx-ci/linux
>
>
> == Linux commits ==
>
> a4a5d48f719b drm/i915: Fix PM refcounting w/o DMC firmware
>
> == Logs ==
>
> For more details see:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9953/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/execlists: Assert the queue is non-empty on unsubmitting
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Assert the queue is non-empty on unsubmitting URL : https://patchwork.freedesktop.org/series/48262/ State : warning == Summary == $ dim checkpatch origin/drm-tip e625d55cbe74 drm/i915/execlists: Assert the queue is non-empty on unsubmitting -:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #9: <0>[ 531.960431] drv_self-48067 527402570us : intel_gpu_reset: engine_mask=1, ret=0, retry=0 total: 0 errors, 1 warnings, 0 checks, 7 lines checked c7ea5bd17c23 drm/i915/execlists: Reset queue_priority on cancellation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Assert the queue is non-empty on unsubmitting
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Assert the queue is
non-empty on unsubmitting
URL : https://patchwork.freedesktop.org/series/48262/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4671 -> Patchwork_9954 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48262/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9954 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-byt-clapper}: PASS -> FAIL (fdo#103191, fdo#107362)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
{fi-icl-u}: NOTRUN -> DMESG-WARN (fdo#107382) +4
{igt@kms_psr@primary_page_flip}:
{fi-icl-u}: NOTRUN -> FAIL (fdo#107383) +3
Possible fixes
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: DMESG-FAIL (fdo#102614) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107382 https://bugs.freedesktop.org/show_bug.cgi?id=107382
fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
== Participating hosts (53 -> 49) ==
Additional (1): fi-icl-u
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4671 -> Patchwork_9954
CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9954: c7ea5bd17c233715270d95345ae5b335b50b0907 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c7ea5bd17c23 drm/i915/execlists: Reset queue_priority on cancellation
e625d55cbe74 drm/i915/execlists: Assert the queue is non-empty on unsubmitting
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9954/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Include reset depth in traces
Show the reset depth (the tasklet disable count) in the GEM_TRACE to
indicate when we might not expect tasklets to be flushed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 178a74e29400..257d6f5f44d1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1834,7 +1834,8 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
struct i915_request *request, *active;
unsigned long flags;
- GEM_TRACE("%s\n", engine->name);
+ GEM_TRACE("%s: depth<-%d\n", engine->name,
+ atomic_read(>tasklet.count));
/*
* Prevent request submission to the hardware until we have
@@ -1982,7 +1983,8 @@ static void execlists_reset_finish(struct intel_engine_cs
*engine)
*/
__tasklet_enable_sync_once(>tasklet);
- GEM_TRACE("%s\n", engine->name);
+ GEM_TRACE("%s: depth->%d\n", engine->name,
+ atomic_read(>tasklet.count));
}
static int intel_logical_ring_emit_pdps(struct i915_request *rq)
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix PM refcounting w/o DMC firmware (rev2)
== Series Details ==
Series: drm/i915: Fix PM refcounting w/o DMC firmware (rev2)
URL : https://patchwork.freedesktop.org/series/48252/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4671 -> Patchwork_9953 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48252/revisions/2/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9953:
=== IGT changes ===
Possible regressions
{igt@pm_rpm@module-reload}:
fi-bxt-j4205: SKIP -> DMESG-FAIL
== Known issues ==
Here are the changes found in Patchwork_9953 that come from known issues:
=== IGT changes ===
Issues hit
{igt@amdgpu/amd_prime@i915-to-amd}:
fi-bxt-j4205: SKIP -> INCOMPLETE (fdo#103927)
Possible fixes
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: DMESG-FAIL (fdo#102614) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
== Participating hosts (53 -> 47) ==
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-gdg-551
== Build changes ==
* Linux: CI_DRM_4671 -> Patchwork_9953
CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9953: a4a5d48f719b9e1c2f3fa9d91ee3204b3768bfe4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a4a5d48f719b drm/i915: Fix PM refcounting w/o DMC firmware
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9953/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Assert the queue is non-empty on unsubmitting
In the sequence <0>[ 531.960431] drv_self-48067 527402570us : intel_gpu_reset: engine_mask=1, ret=0, retry=0 <0>[ 531.960431] drv_self-48067 527402571us : execlists_reset: rcs0 request global=115de, current=71133 <0>[ 531.960431] drv_self-48067d..1 527402571us : execlists_cancel_port_requests: rcs0:port0 global=71134 (fence 826b:198), (current 71133) <0>[ 531.960431] drv_self-48067d..1 527402572us : execlists_cancel_port_requests: rcs0:port1 global=71135 (fence 826c:53), (current 71133) <0>[ 531.960431] drv_self-48067d..1 527402572us : __i915_request_unsubmit: rcs0 fence 826c:53 <- global=71135, current 71133 <0>[ 531.960431] drv_self-48067d..1 527402579us : __i915_request_unsubmit: rcs0 fence 826b:198 <- global=71134, current 71133 <0>[ 531.960431] drv_self-48067 527402613us : intel_engine_cancel_stop_cs: rcs0 <0>[ 531.960431] drv_self-48067 527402624us : execlists_reset_finish: rcs0 we are missing the execlists_submission_tasklet() invocation before the execlists_reset_fini() implying that either the queue is empty, or we failed to schedule and run the tasklet on finish. Add an assert so we are sure that on unsubmitting the incomplete request after reset, the queue is indeed populated. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 3f90c74038ef..0e90fd831c70 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -344,6 +344,7 @@ static void __unwind_incomplete_requests(struct intel_engine_cs *engine) last_prio = rq_prio(rq); p = lookup_priolist(engine, last_prio); } + GEM_BUG_ON(RB_EMPTY_ROOT(>execlists.queue.rb_root)); GEM_BUG_ON(p->priority != rq_prio(rq)); list_add(>sched.link, >requests); -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/execlists: Reset queue_priority on cancellation
If we have an available execlists port, the queue_priority should be INT_MIN to allow immediate direct submission. As we clear the ports in execlists_cancel_port_requests(), we should then reset queue_priority to show the available space. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 0e90fd831c70..178a74e29400 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -800,6 +800,7 @@ execlists_cancel_port_requests(struct intel_engine_execlists * const execlists) } execlists_clear_all_active(execlists); + execlists->queue_priority = INT_MIN; } static void reset_csb_pointers(struct intel_engine_execlists *execlists) -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix PM refcounting w/o DMC firmware (rev2)
== Series Details ==
Series: drm/i915: Fix PM refcounting w/o DMC firmware (rev2)
URL : https://patchwork.freedesktop.org/series/48252/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a4a5d48f719b drm/i915: Fix PM refcounting w/o DMC firmware
-:48: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"!csr->fw_path"
#48: FILE: drivers/gpu/drm/i915/intel_csr.c:478:
+ if (csr->fw_path == NULL) {
total: 0 errors, 0 warnings, 1 checks, 26 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev7)
== Series Details ==
Series: drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev7)
URL : https://patchwork.freedesktop.org/series/47067/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4671 -> Patchwork_9952 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/47067/revisions/7/mbox/
== Known issues ==
Here are the changes found in Patchwork_9952 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-cfl-s3: PASS -> DMESG-FAIL (fdo#106560)
igt@gem_exec_suspend@basic-s4-devices:
fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128, fdo#107139)
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: PASS -> FAIL (fdo#103841)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)
Possible fixes
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: DMESG-FAIL (fdo#102614) -> PASS
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-WARN (fdo#107372) -> DMESG-FAIL (fdo#107372)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
== Participating hosts (53 -> 48) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4671 -> Patchwork_9952
CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9952: a2eac6ecd61d49472c529e17117a72d44e3bfd0e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a2eac6ecd61d drm/i915: Skip repeated calls to i915_gem_set_wedged()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9952/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: Fix PM refcounting w/o DMC firmware
The case where the firmware isn't specified for a platform (although
runtime PM works only with DMC on this platform) is the same case where
the firmware is specified but can't be loaded for some reason. Hence we
need to get a display init power domain ref in the first case too to
keep the refcount bookkeeping in balance.
Also convert the related log message to be a debug one, since it's a
valid scenario for a new platform, where we need to have
dev_info->has_csr=1 set, but add support for actually loading the
firmware only later.
v2:
- In addition to the debug log, WARN on non-alpha support platforms,
since then the first case isn't valid scenario. (Chris)
References: https://bugs.freedesktop.org/show_bug.cgi?id=107382
Cc: Chris Wilson
Cc: Anusha Srivatsa
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_csr.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index cf9b600cca79..1ec4f09c61f6 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -468,12 +468,6 @@ void intel_csr_ucode_init(struct drm_i915_private
*dev_priv)
csr->fw_path = I915_CSR_SKL;
else if (IS_BROXTON(dev_priv))
csr->fw_path = I915_CSR_BXT;
- else {
- DRM_ERROR("Unexpected: no known CSR firmware for platform\n");
- return;
- }
-
- DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
/*
* Obtain a runtime pm reference, until CSR is loaded,
@@ -481,6 +475,14 @@ void intel_csr_ucode_init(struct drm_i915_private
*dev_priv)
*/
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
+ if (csr->fw_path == NULL) {
+ DRM_DEBUG_KMS("No known CSR firmware for platform, disabling
runtime PM\n");
+ WARN_ON(!IS_ALPHA_SUPPORT(INTEL_INFO(dev_priv)));
+
+ return;
+ }
+
+ DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
schedule_work(_priv->csr.work);
}
--
2.13.2
___
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: Skip repeated calls to i915_gem_set_wedged() (rev7)
== Series Details == Series: drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev7) URL : https://patchwork.freedesktop.org/series/47067/ State : warning == Summary == $ dim checkpatch origin/drm-tip a2eac6ecd61d drm/i915: Skip repeated calls to i915_gem_set_wedged() -:53: WARNING:MEMORY_BARRIER: memory barrier without comment #53: FILE: drivers/gpu/drm/i915/i915_gem.c:3380: + smp_mb__before_atomic(); total: 0 errors, 1 warnings, 0 checks, 109 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Basic stress test for rapid context switching
== Series Details ==
Series: drm/i915/selftests: Basic stress test for rapid context switching
URL : https://patchwork.freedesktop.org/series/48255/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4671 -> Patchwork_9951 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48255/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9951 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-cfl-s3: PASS -> DMESG-FAIL (fdo#106560)
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362, fdo#103191) +1
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-cfl-8109u}: PASS -> DMESG-WARN (k.org#200587, fdo#106107)
Possible fixes
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: DMESG-FAIL (fdo#102614) -> PASS
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-WARN (fdo#107372) -> DMESG-FAIL (fdo#107372)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#106107 https://bugs.freedesktop.org/show_bug.cgi?id=106107
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
k.org#200587 https://bugzilla.kernel.org/show_bug.cgi?id=200587
== Participating hosts (53 -> 48) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4671 -> Patchwork_9951
CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9951: a5421de087ad8a419add8ea857f6bc841cdab971 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a5421de087ad drm/i915/selftests: Basic stress test for rapid context switching
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9951/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/selftests: Basic stress test for rapid context switching
== Series Details == Series: drm/i915/selftests: Basic stress test for rapid context switching URL : https://patchwork.freedesktop.org/series/48255/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/selftests: Basic stress test for rapid context switching +./include/linux/slab.h:631:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/slab.h:631:13: warning: call with no type! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Skip repeated calls to i915_gem_set_wedged()
If we already wedged, i915_gem_set_wedged() becomes a complicated no-op.
v2: Make sure the double set-wedged is synchronous, a parallel call
should not return before the driver is indeed wedged.
v3: Use a real mutex (and fingers crossed that lockdep is ok!)
v4: Fix incorrect conversion to return false if unwedged.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107343
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 34 +--
drivers/gpu/drm/i915/i915_gpu_error.h | 4 ++-
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
3 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0453eb42a1a3..98a3e2601ab4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3300,10 +3300,15 @@ static void nop_complete_submit_request(struct
i915_request *request)
void i915_gem_set_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = >gpu_error;
struct intel_engine_cs *engine;
enum intel_engine_id id;
- GEM_TRACE("start\n");
+ mutex_lock(>wedge_mutex);
+ if (test_bit(I915_WEDGED, >flags)) {
+ mutex_unlock(>wedge_mutex);
+ return;
+ }
if (GEM_SHOW_DEBUG()) {
struct drm_printer p = drm_debug_printer(__func__);
@@ -3312,8 +3317,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_dump(engine, , "%s\n", engine->name);
}
- if (test_and_set_bit(I915_WEDGED, >gpu_error.flags))
- goto out;
+ GEM_TRACE("start\n");
/*
* First, stop submission to hw, but do not yet complete requests by
@@ -3373,20 +3377,28 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
i915_gem_reset_finish_engine(engine);
}
-out:
+ smp_mb__before_atomic();
+ set_bit(I915_WEDGED, >flags);
+
GEM_TRACE("end\n");
+ mutex_unlock(>wedge_mutex);
- wake_up_all(>gpu_error.reset_queue);
+ wake_up_all(>reset_queue);
}
bool i915_gem_unset_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = >gpu_error;
struct i915_timeline *tl;
+ bool ret = false;
lockdep_assert_held(>drm.struct_mutex);
- if (!test_bit(I915_WEDGED, >gpu_error.flags))
+
+ if (!test_bit(I915_WEDGED, >flags))
return true;
+ mutex_lock(>wedge_mutex);
+
GEM_TRACE("start\n");
/*
@@ -3420,7 +3432,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
*/
if (dma_fence_default_wait(>fence, true,
MAX_SCHEDULE_TIMEOUT) < 0)
- return false;
+ goto unlock;
}
i915_retire_requests(i915);
GEM_BUG_ON(i915->gt.active_requests);
@@ -3439,10 +3451,11 @@ bool i915_gem_unset_wedged(struct drm_i915_private
*i915)
GEM_TRACE("end\n");
- smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
- clear_bit(I915_WEDGED, >gpu_error.flags);
+ ret = true;
+unlock:
+ mutex_unlock(>gpu_error.wedge_mutex);
- return true;
+ return ret;
}
static void
@@ -5764,6 +5777,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
i915_gem_idle_work_handler);
init_waitqueue_head(_priv->gpu_error.wait_queue);
init_waitqueue_head(_priv->gpu_error.reset_queue);
+ mutex_init(_priv->gpu_error.wedge_mutex);
atomic_set(_priv->mm.bsd_engine_dispatch_index, 0);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index f893a4e8b783..49950b1231cf 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -267,8 +267,8 @@ struct i915_gpu_error {
#define I915_RESET_BACKOFF 0
#define I915_RESET_HANDOFF 1
#define I915_RESET_MODESET 2
+#define I915_RESET_ENGINE 3
#define I915_WEDGED(BITS_PER_LONG - 1)
-#define I915_RESET_ENGINE (I915_WEDGED - I915_NUM_ENGINES)
/** Number of times an engine has been reset */
u32 reset_engine_count[I915_NUM_ENGINES];
@@ -279,6 +279,8 @@ struct i915_gpu_error {
/** Reason for the current *global* reset */
const char *reason;
+ struct mutex wedge_mutex; /* serialises wedging/unwedging */
+
/**
* Waitqueue to signal when a hang is detected. Used to for waiters
* to release the struct_mutex for the reset to procede.
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 43ed8b28aeaa..6beb1f47e988 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Basic stress test for rapid context switching
== Series Details == Series: drm/i915/selftests: Basic stress test for rapid context switching URL : https://patchwork.freedesktop.org/series/48255/ State : warning == Summary == $ dim checkpatch origin/drm-tip a5421de087ad drm/i915/selftests: Basic stress test for rapid context switching -:120: WARNING:ALLOC_ARRAY_ARGS: kcalloc uses number as first arg, sizeof is generally wrong #120: FILE: drivers/gpu/drm/i915/selftests/i915_gem_context.c:127: + ctx = kcalloc(sizeof(*ctx), nctx, GFP_KERNEL); total: 0 errors, 1 warnings, 0 checks, 203 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix PM refcounting w/o DMC firmware
== Series Details ==
Series: drm/i915: Fix PM refcounting w/o DMC firmware
URL : https://patchwork.freedesktop.org/series/48252/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4671 -> Patchwork_9950 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48252/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9950 that come from known issues:
=== IGT changes ===
Issues hit
igt@debugfs_test@read_all_entries:
fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713)
igt@drv_selftest@live_hangcheck:
fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: PASS -> FAIL (fdo#103167)
Possible fixes
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: DMESG-FAIL (fdo#102614) -> PASS
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-WARN (fdo#107372) -> DMESG-FAIL (fdo#107372)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
== Participating hosts (53 -> 48) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4671 -> Patchwork_9950
CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9950: 1e467be0103c86450849414ae08a3b1aed3264a2 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
1e467be0103c drm/i915: Fix PM refcounting w/o DMC firmware
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9950/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Basic stress test for rapid context switching
We need to exercise the HW and submission paths for switching contexts
rapidly to check that features such as execlists' wa_tail are adequate.
Plus it's an interesting baseline latency metric.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 185 ++
1 file changed, 185 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 1c92560d35da..d8004bf5a4f0 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -22,6 +22,8 @@
*
*/
+#include
+
#include "../i915_selftest.h"
#include "i915_random.h"
#include "igt_flush_test.h"
@@ -32,6 +34,188 @@
#define DW_PER_PAGE (PAGE_SIZE / sizeof(u32))
+struct live_test {
+ struct drm_i915_private *i915;
+ const char *func;
+ const char *name;
+
+ unsigned int reset_count;
+};
+
+static int begin_live_test(struct live_test *t,
+ struct drm_i915_private *i915,
+ const char *func,
+ const char *name)
+{
+ int err;
+
+ t->i915 = i915;
+ t->func = func;
+ t->name = name;
+
+ err = i915_gem_wait_for_idle(i915,
+I915_WAIT_LOCKED,
+MAX_SCHEDULE_TIMEOUT);
+ if (err) {
+ pr_err("%s(%s): failed to idle before, with err=%d!",
+ func, name, err);
+ return err;
+ }
+
+ i915->gpu_error.missed_irq_rings = 0;
+ t->reset_count = i915_reset_count(>gpu_error);
+
+ return 0;
+}
+
+static int end_live_test(struct live_test *t)
+{
+ struct drm_i915_private *i915 = t->i915;
+
+ i915_retire_requests(i915);
+
+ if (wait_for(intel_engines_are_idle(i915), 10)) {
+ pr_err("%s(%s): GPU not idle\n", t->func, t->name);
+ return -EIO;
+ }
+
+ if (t->reset_count != i915_reset_count(>gpu_error)) {
+ pr_err("%s(%s): GPU was reset %d times!\n",
+ t->func, t->name,
+ i915_reset_count(>gpu_error) - t->reset_count);
+ return -EIO;
+ }
+
+ if (i915->gpu_error.missed_irq_rings) {
+ pr_err("%s(%s): Missed interrupts on engines %lx\n",
+ t->func, t->name, i915->gpu_error.missed_irq_rings);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int live_nop_switch(void *arg)
+{
+ const unsigned int nctx = 1024;
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context **ctx;
+ enum intel_engine_id id;
+ struct drm_file *file;
+ struct live_test t;
+ unsigned long n;
+ int err = -ENODEV;
+
+ /*
+* Create as many contexts as we can feasibly get away with
+* and check we can switch between them rapidly.
+*
+* Serves as very simple stress test for submission and HW switching
+* between contexts.
+*/
+
+ if (!DRIVER_CAPS(i915)->has_logical_contexts)
+ return 0;
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(>drm.struct_mutex);
+
+ ctx = kcalloc(sizeof(*ctx), nctx, GFP_KERNEL);
+ if (!ctx) {
+ err = -ENOMEM;
+ goto out_unlock;
+ }
+
+ for (n = 0; n < nctx; n++) {
+ ctx[n] = i915_gem_create_context(i915, file->driver_priv);
+ if (IS_ERR(ctx[n])) {
+ err = PTR_ERR(ctx[n]);
+ goto out_unlock;
+ }
+ }
+
+ for_each_engine(engine, i915, id) {
+ struct i915_request *request;
+ unsigned long end_time, prime;
+ ktime_t times[2] = {};
+
+ times[0] = ktime_get_raw();
+ for (n = 0; n < nctx; n++) {
+ request = i915_request_alloc(engine, ctx[n]);
+ i915_request_add(request);
+ }
+ i915_request_wait(request,
+ I915_WAIT_LOCKED,
+ MAX_SCHEDULE_TIMEOUT);
+ times[1] = ktime_get_raw();
+
+ pr_info("Populated %d contexts on %s in %lluns\n",
+ nctx, engine->name, ktime_to_ns(times[1] - times[0]));
+
+ err = begin_live_test(, i915, __func__, engine->name);
+ if (err)
+ goto out_unlock;
+
+ end_time = jiffies + i915_selftest.timeout_jiffies;
+ for_each_prime_number_from(prime, 2, 8192) {
+ times[1] = ktime_get_raw();
+
+ for (n = 0; n < prime; n++) {
+ request = i915_request_alloc(engine,
+
Re: [Intel-gfx] [PATCH i-g-t] igt/gem_ctx_switch: Show the combined ctx-switch latency
Chris Wilson writes:
> Quoting Chris Wilson (2018-08-15 12:15:53)
>> + if (ncpus > 1) {
>> + unsigned long total;
>
> Imagine the hidden = 0 here.
I did. With imagination realized,
Perhaps on some rainy day someone will move elapsed into lib.
Reviewed-by: Mika Kuoppala
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFT: Do we detect WA_TAIL?
Quoting Chris Wilson (2018-08-15 13:23:12) > Quoting Chris Wilson (2018-08-15 12:13:51) > > The answer is no. So either our wait-for-ack is the ultimate panacea, or > we just don't have the right pattern to trigger the bug. Fwiw, the small batch sizes for gem_concurrent_blit were good at hitting it on bdw/skl. -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: Fix PM refcounting w/o DMC firmware
== Series Details ==
Series: drm/i915: Fix PM refcounting w/o DMC firmware
URL : https://patchwork.freedesktop.org/series/48252/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1e467be0103c drm/i915: Fix PM refcounting w/o DMC firmware
-:44: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"!csr->fw_path"
#44: FILE: drivers/gpu/drm/i915/intel_csr.c:478:
+ if (csr->fw_path == NULL) {
total: 0 errors, 0 warnings, 1 checks, 24 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFT: Do we detect WA_TAIL?
Quoting Chris Wilson (2018-08-15 12:13:51) The answer is no. So either our wait-for-ack is the ultimate panacea, or we just don't have the right pattern to trigger the bug. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for RFT: Do we detect WA_TAIL?
== Series Details == Series: RFT: Do we detect WA_TAIL? URL : https://patchwork.freedesktop.org/series/48247/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4671 -> Patchwork_9949 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/48247/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9949 that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: fi-bxt-dsi: PASS -> DMESG-FAIL (fdo#106560) Possible fixes igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: DMESG-FAIL (fdo#102614) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 == Participating hosts (53 -> 48) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4671 -> Patchwork_9949 CI_DRM_4671: 77a98fa3e9b6eb29d513b1666ecddfdcfc424e86 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9949: ea2011cc92cd73536c59ac9392cfe108e10b13a8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ea2011cc92cd RFT: Do we detect WA_TAIL? == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9949/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for RFT: Do we detect WA_TAIL?
== Series Details == Series: RFT: Do we detect WA_TAIL? URL : https://patchwork.freedesktop.org/series/48247/ State : warning == Summary == $ dim checkpatch origin/drm-tip ea2011cc92cd RFT: Do we detect WA_TAIL? -:32: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 0 warnings, 0 checks, 20 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915/perf: lock powergating configuration to default when active
On 14/08/2018 15:59, Lionel Landwerlin wrote:
Hey Tvrtko,
Thanks for taking over this series.
I've been talking to developers using the i915/perf interface and from
their point of view, they expect the system to be in a stable
configuration when doing measurements.
One issue with this patch on Gen11 is that it will lock the system in a
configuration that isn't workable for media workloads (all subslices
enabled).
So I think we should set the value for the locked configuration per
generation (gen8-10: all slices/subslices, gen11: only subslices that
contain VME samplers) so that we always get a functional configurations
for all workloads.
Could we want to select that configuration when opening perf?
This would be via i915_perf.c/gen8_configure_all_contexts?
Sounds like an unfortunate but workable compromise. As long as there
doesn't appear another asymmetric slice feature in the future, which
doesn't align with VME. Like one workloads wants slices 0 & 2, another
wants 1 & 3, or whatever. If that happens then I don't know what we do
apart from locking out perf/OA.
Another question is how do we expose the selected value to the user. But
that can be solved in a different series.
SSEU get_param would cut it? Although it would be perhaps be unexpected
to get different results depending on whether perf/OA is active or not..
Hm... export device and available bitmasks via get param? Device bitmask
would be fixed and available would change depending on whether perf/OA
is active or not.
Regards,
Tvrtko
Cheers,
-
Lionel
On 14/08/18 15:40, Tvrtko Ursulin wrote:
From: Lionel Landwerlin
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.
Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.
Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active. There is no known issue with this apart from a performance
penality for some media workloads that benefit from running on a
partially powergated GPU. We already prevent RC6 from affecting the
programming so it doesn't sound completely unreasonable to hold on
powergating for the same reason.
v2: Leave RPCS programming in intel_lrc.c (Lionel)
v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 15 +++
drivers/gpu/drm/i915/i915_perf.c | 23 ++-
drivers/gpu/drm/i915/intel_lrc.c | 11 +++
drivers/gpu/drm/i915/intel_lrc.h | 3 +++
4 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index d6049c3f911b..5c12d2676435 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3851,4 +3851,19 @@ static inline int
intel_hws_csb_write_index(struct drm_i915_private *i915)
return I915_HWS_CSB_WRITE_INDEX;
}
+static inline struct intel_sseu
+intel_engine_prepare_sseu(struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ struct drm_i915_private *i915 = engine->i915;
+
+ /*
+ * If i915/perf is active, we want a stable powergating
configuration
+ * on the system. The most natural configuration to take in that
case
+ * is the default (i.e maximum the hardware can do).
+ */
+ return i915->perf.oa.exclusive_stream ?
+ intel_device_default_sseu(i915) : sseu;
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_perf.c
b/drivers/gpu/drm/i915/i915_perf.c
index ccb20230df2c..c2fc2399e0ed 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1631,7 +1631,8 @@ static void hsw_disable_metric_set(struct
drm_i915_private *dev_priv)
*/
static void gen8_update_reg_state_unlocked(struct i915_gem_context
*ctx,
u32 *reg_state,
- const
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add plane alpha blending support, v2.
== Series Details ==
Series: drm/i915: Add plane alpha blending support, v2.
URL : https://patchwork.freedesktop.org/series/48243/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/intel_display.o
drivers/gpu/drm/i915/intel_display.c: In function ‘skl_plane_ctl_alpha’:
drivers/gpu/drm/i915/intel_display.c:3528:27: error: ‘const struct
drm_plane_state’ has no member named ‘pixel_blend_mode’
switch (plane_state->base.pixel_blend_mode) {
^
drivers/gpu/drm/i915/intel_display.c:3529:7: error: ‘DRM_MODE_BLEND_PIXEL_NONE’
undeclared (first use in this function); did you mean ‘DRM_MODE_ENCODER_NONE’?
case DRM_MODE_BLEND_PIXEL_NONE:
^
DRM_MODE_ENCODER_NONE
drivers/gpu/drm/i915/intel_display.c:3529:7: note: each undeclared identifier
is reported only once for each function it appears in
drivers/gpu/drm/i915/intel_display.c:3531:7: error: ‘DRM_MODE_BLEND_PREMULTI’
undeclared (first use in this function); did you mean
‘DRM_MODE_BLEND_PIXEL_NONE’?
case DRM_MODE_BLEND_PREMULTI:
^~~
DRM_MODE_BLEND_PIXEL_NONE
drivers/gpu/drm/i915/intel_display.c:3533:7: error: ‘DRM_MODE_BLEND_COVERAGE’
undeclared (first use in this function); did you mean ‘DRM_MODE_BLEND_PREMULTI’?
case DRM_MODE_BLEND_COVERAGE:
^~~
DRM_MODE_BLEND_PREMULTI
In file included from ./arch/x86/include/asm/bug.h:83:0,
from ./include/linux/bug.h:5,
from ./include/linux/debug_locks.h:7,
from ./include/linux/lockdep.h:28,
from ./include/linux/spinlock_types.h:18,
from ./include/linux/mutex.h:16,
from ./include/linux/kernfs.h:13,
from ./include/linux/sysfs.h:16,
from ./include/linux/kobject.h:20,
from ./include/linux/dmi.h:6,
from drivers/gpu/drm/i915/intel_display.c:27:
drivers/gpu/drm/i915/intel_display.c:3536:33: error: ‘const struct
drm_plane_state’ has no member named ‘pixel_blend_mode’
MISSING_CASE(plane_state->base.pixel_blend_mode);
^
./include/asm-generic/bug.h:98:50: note: in definition of macro ‘__WARN_printf’
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
^~~
drivers/gpu/drm/i915/i915_utils.h:43:25: note: in expansion of macro ‘WARN’
#define MISSING_CASE(x) WARN(1, "Missing case (%s == %ld)\n", \
^~~~
drivers/gpu/drm/i915/intel_display.c:3536:3: note: in expansion of macro
‘MISSING_CASE’
MISSING_CASE(plane_state->base.pixel_blend_mode);
^~~~
drivers/gpu/drm/i915/intel_display.c: In function ‘glk_plane_color_ctl_alpha’:
drivers/gpu/drm/i915/intel_display.c:3546:27: error: ‘const struct
drm_plane_state’ has no member named ‘pixel_blend_mode’
switch (plane_state->base.pixel_blend_mode) {
^
drivers/gpu/drm/i915/intel_display.c:3547:7: error: ‘DRM_MODE_BLEND_PIXEL_NONE’
undeclared (first use in this function); did you mean ‘DRM_MODE_ENCODER_NONE’?
case DRM_MODE_BLEND_PIXEL_NONE:
^
DRM_MODE_ENCODER_NONE
drivers/gpu/drm/i915/intel_display.c:3549:7: error: ‘DRM_MODE_BLEND_PREMULTI’
undeclared (first use in this function); did you mean
‘DRM_MODE_BLEND_PIXEL_NONE’?
case DRM_MODE_BLEND_PREMULTI:
^~~
DRM_MODE_BLEND_PIXEL_NONE
drivers/gpu/drm/i915/intel_display.c:3551:7: error: ‘DRM_MODE_BLEND_COVERAGE’
undeclared (first use in this function); did you mean ‘DRM_MODE_BLEND_PREMULTI’?
case DRM_MODE_BLEND_COVERAGE:
^~~
DRM_MODE_BLEND_PREMULTI
In file included from ./arch/x86/include/asm/bug.h:83:0,
from ./include/linux/bug.h:5,
from ./include/linux/debug_locks.h:7,
from ./include/linux/lockdep.h:28,
from ./include/linux/spinlock_types.h:18,
from ./include/linux/mutex.h:16,
from ./include/linux/kernfs.h:13,
from ./include/linux/sysfs.h:16,
from ./include/linux/kobject.h:20,
from ./include/linux/dmi.h:6,
from drivers/gpu/drm/i915/intel_display.c:27:
drivers/gpu/drm/i915/intel_display.c:3554:33: error: ‘const struct
drm_plane_state’ has no member named ‘pixel_blend_mode’
MISSING_CASE(plane_state->base.pixel_blend_mode);
^
./include/asm-generic/bug.h:98:50: note: in definition of macro ‘__WARN_printf’
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
^~~
drivers/gpu/drm/i915/i915_utils.h:43:25: note: in expansion of macro ‘WARN’
#define MISSING_CASE(x) WARN(1, "Missing case (%s
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
Quoting Tvrtko Ursulin (2018-08-15 12:51:28) > > On 14/08/2018 16:22, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-08-14 15:40:58) > > Looks like we should be able to hook this up to a selftest to confirm > > the modification does land in the target context image, and a SRM to > > confirm it loaded. > > Lionel wrote an IGT which reads it back via SRM so that should be > covered. I will be posting the IGT counterpart at some point as well, > ideally when the agreement on the i915 side is there. Wouldn't you rather have both? I know I would :-p The emphasis is slightly different, IGT wants to cover the ABI behaviour, selftests looking towards the edge cases hard to reach otherwise. But even a trivial selftest would let us know the series functions as intended. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
On 14/08/2018 16:22, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-14 15:40:58)
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ struct drm_i915_private *i915 = ctx->i915;
+ struct i915_request *rq;
+ struct intel_ring *ring;
+ int ret;
+
+ lockdep_assert_held(>drm.struct_mutex);
+
+ /* Submitting requests etc needs the hw awake. */
+ intel_runtime_pm_get(i915);
+
+ i915_retire_requests(i915);
+
+ /* Now use the RCS to actually reconfigure. */
+ engine = i915->engine[RCS];
+
+ rq = i915_request_alloc(engine, i915->kernel_context);
+ if (IS_ERR(rq)) {
+ ret = PTR_ERR(rq);
+ goto out_put;
+ }
+
+ ret = engine->emit_rpcs_config(rq, ctx, sseu);
+ if (ret)
+ goto out_add;
+
+ /* Queue this switch after all other activity */
+ list_for_each_entry(ring, >gt.active_rings, active_link) {
+ struct i915_request *prev;
+
+ prev = last_request_on_engine(ring->timeline, engine);
+ if (prev)
+ i915_sw_fence_await_sw_fence_gfp(>submit,
+>submit,
+I915_FENCE_GFP);
+ }
+
+ i915_gem_set_global_barrier(i915, rq);
+
+out_add:
+ i915_request_add(rq);
+out_put:
+ intel_runtime_pm_put(i915);
+
+ return ret;
Looks like we should be able to hook this up to a selftest to confirm
the modification does land in the target context image, and a SRM to
confirm it loaded.
Lionel wrote an IGT which reads it back via SRM so that should be
covered. I will be posting the IGT counterpart at some point as well,
ideally when the agreement on the i915 side is there.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix PM refcounting w/o DMC firmware
On Wed, Aug 15, 2018 at 12:38:00PM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2018-08-15 12:35:29)
> > Quoting Imre Deak (2018-08-15 12:30:16)
> > > The case where the firmware isn't specified for a platform (although
> > > runtime PM works only with DMC on this platform) is the same case where
> > > the firmware is specified but can't be loaded for some reason. Hence we
> > > need to get a display init power domain ref in the first case too to
> > > keep the refcount bookkeeping in balance.
> > >
> > > Also convert the related log message to be a debug one, since it's a
> > > valid scenario for a new platform, where we need to have
> > > dev_info->has_csr=1 set, but add support for actually loading the
> > > firmware only later.
> > >
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=107382
> > > Cc: Chris Wilson
> > > Cc: Anusha Srivatsa
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/intel_csr.c | 12 ++--
> > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > > b/drivers/gpu/drm/i915/intel_csr.c
> > > index cf9b600cca79..b0384b9d1c58 100644
> > > --- a/drivers/gpu/drm/i915/intel_csr.c
> > > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > > @@ -468,12 +468,6 @@ void intel_csr_ucode_init(struct drm_i915_private
> > > *dev_priv)
> > > csr->fw_path = I915_CSR_SKL;
> > > else if (IS_BROXTON(dev_priv))
> > > csr->fw_path = I915_CSR_BXT;
> > > - else {
> > > - DRM_ERROR("Unexpected: no known CSR firmware for
> > > platform\n");
> > > - return;
> > > - }
> > > -
> > > - DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
> > >
> > > /*
> > > * Obtain a runtime pm reference, until CSR is loaded,
> > > @@ -481,6 +475,12 @@ void intel_csr_ucode_init(struct drm_i915_private
> > > *dev_priv)
> > > */
> > > intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
> > >
> > > + if (csr->fw_path == NULL) {
> > > + DRM_DEBUG_KMS("No known CSR firmware for platform,
> > > disabling runtime PM\n");
> >
> > WARN_ON(!INTEL_INFO(dev_priv)->is_alpha_support) ?
>
> I think it's a sensible reminder in case we forget before attempting to
> clear the alpha support flag,
Yep, makes sense, will add that.
> nevertheless
> Reviewed-by: Chris Wilson
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix PM refcounting w/o DMC firmware
Quoting Chris Wilson (2018-08-15 12:35:29)
> Quoting Imre Deak (2018-08-15 12:30:16)
> > The case where the firmware isn't specified for a platform (although
> > runtime PM works only with DMC on this platform) is the same case where
> > the firmware is specified but can't be loaded for some reason. Hence we
> > need to get a display init power domain ref in the first case too to
> > keep the refcount bookkeeping in balance.
> >
> > Also convert the related log message to be a debug one, since it's a
> > valid scenario for a new platform, where we need to have
> > dev_info->has_csr=1 set, but add support for actually loading the
> > firmware only later.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=107382
> > Cc: Chris Wilson
> > Cc: Anusha Srivatsa
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_csr.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > b/drivers/gpu/drm/i915/intel_csr.c
> > index cf9b600cca79..b0384b9d1c58 100644
> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > @@ -468,12 +468,6 @@ void intel_csr_ucode_init(struct drm_i915_private
> > *dev_priv)
> > csr->fw_path = I915_CSR_SKL;
> > else if (IS_BROXTON(dev_priv))
> > csr->fw_path = I915_CSR_BXT;
> > - else {
> > - DRM_ERROR("Unexpected: no known CSR firmware for
> > platform\n");
> > - return;
> > - }
> > -
> > - DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
> >
> > /*
> > * Obtain a runtime pm reference, until CSR is loaded,
> > @@ -481,6 +475,12 @@ void intel_csr_ucode_init(struct drm_i915_private
> > *dev_priv)
> > */
> > intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
> >
> > + if (csr->fw_path == NULL) {
> > + DRM_DEBUG_KMS("No known CSR firmware for platform,
> > disabling runtime PM\n");
>
> WARN_ON(!INTEL_INFO(dev_priv)->is_alpha_support) ?
I think it's a sensible reminder in case we forget before attempting to
clear the alpha support flag, nevertheless
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] firmware/dmc/icl: load v1.07 on icelake.
On Mon, Aug 13, 2018 at 11:45:32PM -0500, Anusha Srivatsa wrote:
> Add Support to load DMC on Icelake.
>
> While at it, also add support to load the firmware
> during system resume.
>
> v2: load firmware during system resume.(Imre)
>
> v3: enable has_csr for icelake.(Jyoti)
>
> Cc: Jyoti Yadav
> Cc: Imre Deak
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/i915_pci.c | 2 +-
> drivers/gpu/drm/i915/intel_csr.c| 7 +++
> drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index e931b48369dd..bbd331f1d5d9 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -600,7 +600,7 @@ static const struct intel_device_info
> intel_cannonlake_info = {
> GEN10_FEATURES, \
> GEN(11), \
> .ddb_size = 2048, \
> - .has_csr = 0, \
> + .has_csr = 1, \
The default is correct already, so it's enough not to reinit this field.
Also could you send this one change separately after the following patch
is merged:
https://patchwork.freedesktop.org/patch/244656/
That way we could see if not specifying the firmware doesn't break
things. (This scenario is valid for a new platform.)
Thanks,
Imre
> .has_logical_ring_elsq = 1
>
> static const struct intel_device_info intel_icelake_11_info = {
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index cf9b600cca79..393d419afb91 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -34,6 +34,9 @@
> * low-power state and comes back to normal.
> */
>
> +#define I915_CSR_ICL "i915/icl_dmc_ver1_07.bin"
> +#define ICL_CSR_VERSION_REQUIRED CSR_VERSION(1, 7)
> +
> #define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin"
> MODULE_FIRMWARE(I915_CSR_GLK);
> #define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 4)
> @@ -301,6 +304,8 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
> *dev_priv,
> if (csr->fw_path == i915_modparams.dmc_firmware_path) {
> /* Bypass version check for firmware override. */
> required_version = csr->version;
> + } else if (IS_ICELAKE(dev_priv)) {
> + required_version = ICL_CSR_VERSION_REQUIRED;
> } else if (IS_CANNONLAKE(dev_priv)) {
> required_version = CNL_CSR_VERSION_REQUIRED;
> } else if (IS_GEMINILAKE(dev_priv)) {
> @@ -458,6 +463,8 @@ void intel_csr_ucode_init(struct drm_i915_private
> *dev_priv)
>
> if (i915_modparams.dmc_firmware_path)
> csr->fw_path = i915_modparams.dmc_firmware_path;
> + else if (IS_ICELAKE(dev_priv))
> + csr->fw_path = I915_CSR_ICL;
> else if (IS_CANNONLAKE(dev_priv))
> csr->fw_path = I915_CSR_CNL;
> else if (IS_GEMINILAKE(dev_priv))
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index e209edbc561d..7686f4d32533 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -3588,6 +3588,9 @@ static void icl_display_core_init(struct
> drm_i915_private *dev_priv,
>
> /* 7. Setup MBUS. */
> icl_mbus_init(dev_priv);
> +
> + if (resume && dev_priv->csr.dmc_payload)
> + intel_csr_load_program(dev_priv);
> }
>
> static void icl_display_core_uninit(struct drm_i915_private *dev_priv)
> --
> 2.14.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix PM refcounting w/o DMC firmware
Quoting Imre Deak (2018-08-15 12:30:16)
> The case where the firmware isn't specified for a platform (although
> runtime PM works only with DMC on this platform) is the same case where
> the firmware is specified but can't be loaded for some reason. Hence we
> need to get a display init power domain ref in the first case too to
> keep the refcount bookkeeping in balance.
>
> Also convert the related log message to be a debug one, since it's a
> valid scenario for a new platform, where we need to have
> dev_info->has_csr=1 set, but add support for actually loading the
> firmware only later.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=107382
> Cc: Chris Wilson
> Cc: Anusha Srivatsa
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_csr.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index cf9b600cca79..b0384b9d1c58 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -468,12 +468,6 @@ void intel_csr_ucode_init(struct drm_i915_private
> *dev_priv)
> csr->fw_path = I915_CSR_SKL;
> else if (IS_BROXTON(dev_priv))
> csr->fw_path = I915_CSR_BXT;
> - else {
> - DRM_ERROR("Unexpected: no known CSR firmware for platform\n");
> - return;
> - }
> -
> - DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
>
> /*
> * Obtain a runtime pm reference, until CSR is loaded,
> @@ -481,6 +475,12 @@ void intel_csr_ucode_init(struct drm_i915_private
> *dev_priv)
> */
> intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
>
> + if (csr->fw_path == NULL) {
> + DRM_DEBUG_KMS("No known CSR firmware for platform, disabling
> runtime PM\n");
WARN_ON(!INTEL_INFO(dev_priv)->is_alpha_support) ?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix PM refcounting w/o DMC firmware
The case where the firmware isn't specified for a platform (although
runtime PM works only with DMC on this platform) is the same case where
the firmware is specified but can't be loaded for some reason. Hence we
need to get a display init power domain ref in the first case too to
keep the refcount bookkeeping in balance.
Also convert the related log message to be a debug one, since it's a
valid scenario for a new platform, where we need to have
dev_info->has_csr=1 set, but add support for actually loading the
firmware only later.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107382
Cc: Chris Wilson
Cc: Anusha Srivatsa
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_csr.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index cf9b600cca79..b0384b9d1c58 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -468,12 +468,6 @@ void intel_csr_ucode_init(struct drm_i915_private
*dev_priv)
csr->fw_path = I915_CSR_SKL;
else if (IS_BROXTON(dev_priv))
csr->fw_path = I915_CSR_BXT;
- else {
- DRM_ERROR("Unexpected: no known CSR firmware for platform\n");
- return;
- }
-
- DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
/*
* Obtain a runtime pm reference, until CSR is loaded,
@@ -481,6 +475,12 @@ void intel_csr_ucode_init(struct drm_i915_private
*dev_priv)
*/
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
+ if (csr->fw_path == NULL) {
+ DRM_DEBUG_KMS("No known CSR firmware for platform, disabling
runtime PM\n");
+ return;
+ }
+
+ DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
schedule_work(_priv->csr.work);
}
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt/gem_ctx_switch: Show the combined ctx-switch latency
Quoting Chris Wilson (2018-08-15 12:15:53)
> + if (ncpus > 1) {
> + unsigned long total;
Imagine the hidden = 0 here.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt/gem_ctx_switch: Show the combined ctx-switch latency
Since we submit from several processes to the same engine for the forked
tests, the total number of context switches is the sum of each process
and needs to be combined together to compute the individual cs latency.
Signed-off-by: Chris Wilson
---
tests/gem_ctx_switch.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/tests/gem_ctx_switch.c b/tests/gem_ctx_switch.c
index 6770e001f..58b9bfd3e 100644
--- a/tests/gem_ctx_switch.c
+++ b/tests/gem_ctx_switch.c
@@ -94,8 +94,15 @@ static void single(int fd, uint32_t handle,
struct drm_i915_gem_exec_object2 obj;
struct drm_i915_gem_relocation_entry reloc;
uint32_t contexts[64];
+ struct {
+ double elapsed;
+ unsigned long count;
+ } *shared;
int n;
+ shared = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
+ igt_assert(shared != MAP_FAILED);
+
gem_require_ring(fd, e->exec_id | e->flags);
for (n = 0; n < 64; n++) {
@@ -163,11 +170,31 @@ static void single(int fd, uint32_t handle,
igt_info("[%d] %s: %'u cycles: %.3fus%s\n",
child, e->name, count, elapsed(, )*1e6 /
count,
flags & INTERRUPTIBLE ? " (interruptible)" : "");
+
+ shared[child].elapsed = elapsed(, );
+ shared[child].count = count;
}
igt_waitchildren();
+ if (ncpus > 1) {
+ unsigned long total;
+ double max = 0;
+
+ for (n = 0; n < ncpus; n++) {
+ total += shared[n].count;
+ if (shared[n].elapsed > max)
+ max = shared[n].elapsed;
+ }
+
+ igt_info("Total %s: %'lu cycles: %.3fus%s\n",
+e->name, total, max*1e6 / total,
+flags & INTERRUPTIBLE ? " (interruptible)" : "");
+ }
+
for (n = 0; n < 64; n++)
gem_context_destroy(fd, contexts[n]);
+
+ munmap(shared, 4096);
}
static void all(int fd, uint32_t handle, unsigned flags, int timeout)
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
On 15/08/18 11:56, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-08-15 11:50:55)
On 15/08/18 09:49, Tvrtko Ursulin wrote:
On 14/08/2018 19:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-14 19:49:46)
On 13/08/2018 10:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
On 13/08/2018 09:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
From: Lionel Landwerlin
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 34
+++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c
b/drivers/gpu/drm/i915/i915_perf.c
index 49597cf31707..ccb20230df2c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -210,6 +210,7 @@
#include "i915_oa_cflgt3.h"
#include "i915_oa_cnl.h"
#include "i915_oa_icl.h"
+#include "intel_lrc_reg.h"
/* HW requires this to be a power of two, between 128k
and 16M, though driver
* is currently generally designed assuming the largest 16M
size is used such
@@ -1636,27 +1637,25 @@ static void
gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
u32 ctx_oactxctrl =
dev_priv->perf.oa.ctx_oactxctrl_offset;
u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
/* The MMIO offsets for Flex EU registers aren't
contiguous */
- u32 flex_mmio[] = {
- i915_mmio_reg_offset(EU_PERF_CNTL0),
- i915_mmio_reg_offset(EU_PERF_CNTL1),
- i915_mmio_reg_offset(EU_PERF_CNTL2),
- i915_mmio_reg_offset(EU_PERF_CNTL3),
- i915_mmio_reg_offset(EU_PERF_CNTL4),
- i915_mmio_reg_offset(EU_PERF_CNTL5),
- i915_mmio_reg_offset(EU_PERF_CNTL6),
+ i915_reg_t flex_regs[] = {
+ EU_PERF_CNTL0,
+ EU_PERF_CNTL1,
+ EU_PERF_CNTL2,
+ EU_PERF_CNTL3,
+ EU_PERF_CNTL4,
+ EU_PERF_CNTL5,
+ EU_PERF_CNTL6,
};
int i;
- reg_state[ctx_oactxctrl] =
i915_mmio_reg_offset(GEN8_OACTXCONTROL);
- reg_state[ctx_oactxctrl+1] =
(dev_priv->perf.oa.period_exponent <<
- GEN8_OA_TIMER_PERIOD_SHIFT) |
- (dev_priv->perf.oa.periodic ?
- GEN8_OA_TIMER_ENABLE : 0) |
- GEN8_OA_COUNTER_RESUME;
+ CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
+ (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
+ (dev_priv->perf.oa.periodic ?
GEN8_OA_TIMER_ENABLE : 0) |
+ GEN8_OA_COUNTER_RESUME);
I'll be honest but, I don't think it's CTX_REG() that helps
improve the
readability here.
The really odd part is that this sticks itself into a bare part
of the
register state not surrounded by any LRI and after a BB_END. This
routine can only work for established contexts, it should not
work for
execlists_init_reg_state.
Unless I am missing something change is completely mechanical, so any
question marks you have are already there, right? What do you
suggest is
the action here?
Sure, the only thing I question of this patch itself is whether
CTX_REG() is simply too much horrible obfuscating magic.
Turn a blind eye if the perceived badness factor is below some
threshold? Following patch depends on this one, so if I have to drop
this one, then I have to rework the next one etc.. well, it's not the
worst problem, so yeah, whatever. Make a call and let me know.
The patch was fine, just worrying about the surrounding code.
I misunderstood. So only about ctx_oactxctrl_offset and
ctx_flexeu0_offset from i915_perf.c? Maybe that is some OA magic, I
have not idea. CC-ing Lionel in case he can shed some light on it.
Those are the offsets at which the hardware will store the
OA_CTXCTRL/FLEX_EU registers values as documented.
I can see that's it's a bit odd not to have the MI_LRI written before we
do the first restore.
I'm 99% sure I've verified in practice that application started after
i915/perf is opened have the right values programmed.
Not completely sure that the IGT tests cover that case though.
So maybe there is a problem with the first restore...
What's the value set into most register that aren't explicitly
programmed in intel_lrc.c ?
That would be whatever was previously there
In practice, since we now initialise all real contexts from the default
state, the LRI will be there. execlists_init_reg_state() is wonderfully,
perhaps dangerously, misleading atm.
-Chris
Then I guess it's all fine :)
Thanks,
-
Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] RFT: Do we detect WA_TAIL?
---
drivers/gpu/drm/i915/intel_lrc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3f90c74038ef..fff2fbb6bac5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -161,7 +161,7 @@
/* Typical size of the average request (2 pipecontrols and a MI_BB) */
#define EXECLISTS_REQUEST_SIZE 64 /* bytes */
-#define WA_TAIL_DWORDS 2
+#define WA_TAIL_DWORDS 0
#define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
@@ -2195,8 +2195,10 @@ static int gen8_emit_flush_render(struct i915_request
*request,
static void gen8_emit_wa_tail(struct i915_request *request, u32 *cs)
{
/* Ensure there's always at least one preemption point per-request. */
- *cs++ = MI_ARB_CHECK;
- *cs++ = MI_NOOP;
+ if (WA_TAIL_DWORDS) {
+ *cs++ = MI_ARB_CHECK;
+ *cs++ = MI_NOOP;
+ }
request->wa_tail = intel_ring_offset(request, cs);
}
--
2.18.0
___
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] igt/pm_rpm: Close local fd before trying to unload module
Quoting Imre Deak (2018-08-15 12:01:31)
> On Wed, Aug 15, 2018 at 10:25:11AM +0100, Chris Wilson wrote:
> > Fixes: d8e78990aa2b ("igt/pm_rpm: Test reaquisition of runtime-pm after
> > module reload")
> > Signed-off-by: Chris Wilson
> > ---
> > tests/pm_rpm.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> > index 65489bcdb..a4f9f783e 100644
> > --- a/tests/pm_rpm.c
> > +++ b/tests/pm_rpm.c
> > @@ -2034,6 +2034,8 @@ int main(int argc, char *argv[])
> > teardown_environment();
> >
> > igt_subtest("module-reload") {
> > + teardown_environment();
> > +
>
> Why isn't the teardown_environment(); under igt_fixture enough?
Hmm, looks like I thought about it earlier. I guess we leak an fd...
-Chris
___
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] igt/pm_rpm: Close local fd before trying to unload module
On Wed, Aug 15, 2018 at 10:25:11AM +0100, Chris Wilson wrote:
> Fixes: d8e78990aa2b ("igt/pm_rpm: Test reaquisition of runtime-pm after
> module reload")
> Signed-off-by: Chris Wilson
> ---
> tests/pm_rpm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> index 65489bcdb..a4f9f783e 100644
> --- a/tests/pm_rpm.c
> +++ b/tests/pm_rpm.c
> @@ -2034,6 +2034,8 @@ int main(int argc, char *argv[])
> teardown_environment();
>
> igt_subtest("module-reload") {
> + teardown_environment();
> +
Why isn't the teardown_environment(); under igt_fixture enough?
> igt_debug("Reload w/o display\n");
> igt_i915_driver_unload();
> igt_assert_eq(igt_i915_driver_load("disable_display=1"), 0);
> --
> 2.18.0
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
Quoting Lionel Landwerlin (2018-08-15 11:50:55)
> On 15/08/18 09:49, Tvrtko Ursulin wrote:
> >
> > On 14/08/2018 19:57, Chris Wilson wrote:
> >> Quoting Tvrtko Ursulin (2018-08-14 19:49:46)
> >>>
> >>> On 13/08/2018 10:16, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
> >
> > On 13/08/2018 09:16, Chris Wilson wrote:
> >> Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
> >>> From: Lionel Landwerlin
> >>>
> >>> Abstract the context image access a bit.
> >>>
> >>> Signed-off-by: Lionel Landwerlin
> >>> Reviewed-by: Tvrtko Ursulin
> >>> ---
> >>> drivers/gpu/drm/i915/i915_perf.c | 34
> >>> +++-
> >>> 1 file changed, 16 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> >>> b/drivers/gpu/drm/i915/i915_perf.c
> >>> index 49597cf31707..ccb20230df2c 100644
> >>> --- a/drivers/gpu/drm/i915/i915_perf.c
> >>> +++ b/drivers/gpu/drm/i915/i915_perf.c
> >>> @@ -210,6 +210,7 @@
> >>> #include "i915_oa_cflgt3.h"
> >>> #include "i915_oa_cnl.h"
> >>> #include "i915_oa_icl.h"
> >>> +#include "intel_lrc_reg.h"
> >>> /* HW requires this to be a power of two, between 128k
> >>> and 16M, though driver
> >>> * is currently generally designed assuming the largest 16M
> >>> size is used such
> >>> @@ -1636,27 +1637,25 @@ static void
> >>> gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
> >>> u32 ctx_oactxctrl =
> >>> dev_priv->perf.oa.ctx_oactxctrl_offset;
> >>> u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> >>> /* The MMIO offsets for Flex EU registers aren't
> >>> contiguous */
> >>> - u32 flex_mmio[] = {
> >>> - i915_mmio_reg_offset(EU_PERF_CNTL0),
> >>> - i915_mmio_reg_offset(EU_PERF_CNTL1),
> >>> - i915_mmio_reg_offset(EU_PERF_CNTL2),
> >>> - i915_mmio_reg_offset(EU_PERF_CNTL3),
> >>> - i915_mmio_reg_offset(EU_PERF_CNTL4),
> >>> - i915_mmio_reg_offset(EU_PERF_CNTL5),
> >>> - i915_mmio_reg_offset(EU_PERF_CNTL6),
> >>> + i915_reg_t flex_regs[] = {
> >>> + EU_PERF_CNTL0,
> >>> + EU_PERF_CNTL1,
> >>> + EU_PERF_CNTL2,
> >>> + EU_PERF_CNTL3,
> >>> + EU_PERF_CNTL4,
> >>> + EU_PERF_CNTL5,
> >>> + EU_PERF_CNTL6,
> >>> };
> >>> int i;
> >>> - reg_state[ctx_oactxctrl] =
> >>> i915_mmio_reg_offset(GEN8_OACTXCONTROL);
> >>> - reg_state[ctx_oactxctrl+1] =
> >>> (dev_priv->perf.oa.period_exponent <<
> >>> - GEN8_OA_TIMER_PERIOD_SHIFT) |
> >>> - (dev_priv->perf.oa.periodic ?
> >>> - GEN8_OA_TIMER_ENABLE : 0) |
> >>> - GEN8_OA_COUNTER_RESUME;
> >>> + CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
> >>> + (dev_priv->perf.oa.period_exponent <<
> >>> GEN8_OA_TIMER_PERIOD_SHIFT) |
> >>> + (dev_priv->perf.oa.periodic ?
> >>> GEN8_OA_TIMER_ENABLE : 0) |
> >>> + GEN8_OA_COUNTER_RESUME);
> >>
> >> I'll be honest but, I don't think it's CTX_REG() that helps
> >> improve the
> >> readability here.
> >>
> >> The really odd part is that this sticks itself into a bare part
> >> of the
> >> register state not surrounded by any LRI and after a BB_END. This
> >> routine can only work for established contexts, it should not
> >> work for
> >> execlists_init_reg_state.
> >
> > Unless I am missing something change is completely mechanical, so any
> > question marks you have are already there, right? What do you
> > suggest is
> > the action here?
>
> Sure, the only thing I question of this patch itself is whether
> CTX_REG() is simply too much horrible obfuscating magic.
> >>>
> >>> Turn a blind eye if the perceived badness factor is below some
> >>> threshold? Following patch depends on this one, so if I have to drop
> >>> this one, then I have to rework the next one etc.. well, it's not the
> >>> worst problem, so yeah, whatever. Make a call and let me know.
> >>
> >> The patch was fine, just worrying about the surrounding code.
> >
> > I misunderstood. So only about ctx_oactxctrl_offset and
> > ctx_flexeu0_offset from i915_perf.c? Maybe that is some OA magic, I
> > have not idea. CC-ing Lionel in case he can shed some light on it.
>
> Those are the offsets at which the hardware will store the
> OA_CTXCTRL/FLEX_EU registers values as documented.
> I can see that's it's a bit odd not to have the MI_LRI written before we
> do the first restore.
>
> I'm 99% sure I've verified in practice that application started after
>
Re: [Intel-gfx] [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
On 15/08/18 09:49, Tvrtko Ursulin wrote:
On 14/08/2018 19:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-14 19:49:46)
On 13/08/2018 10:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
On 13/08/2018 09:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
From: Lionel Landwerlin
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 34
+++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c
b/drivers/gpu/drm/i915/i915_perf.c
index 49597cf31707..ccb20230df2c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -210,6 +210,7 @@
#include "i915_oa_cflgt3.h"
#include "i915_oa_cnl.h"
#include "i915_oa_icl.h"
+#include "intel_lrc_reg.h"
/* HW requires this to be a power of two, between 128k
and 16M, though driver
* is currently generally designed assuming the largest 16M
size is used such
@@ -1636,27 +1637,25 @@ static void
gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
u32 ctx_oactxctrl =
dev_priv->perf.oa.ctx_oactxctrl_offset;
u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
/* The MMIO offsets for Flex EU registers aren't
contiguous */
- u32 flex_mmio[] = {
- i915_mmio_reg_offset(EU_PERF_CNTL0),
- i915_mmio_reg_offset(EU_PERF_CNTL1),
- i915_mmio_reg_offset(EU_PERF_CNTL2),
- i915_mmio_reg_offset(EU_PERF_CNTL3),
- i915_mmio_reg_offset(EU_PERF_CNTL4),
- i915_mmio_reg_offset(EU_PERF_CNTL5),
- i915_mmio_reg_offset(EU_PERF_CNTL6),
+ i915_reg_t flex_regs[] = {
+ EU_PERF_CNTL0,
+ EU_PERF_CNTL1,
+ EU_PERF_CNTL2,
+ EU_PERF_CNTL3,
+ EU_PERF_CNTL4,
+ EU_PERF_CNTL5,
+ EU_PERF_CNTL6,
};
int i;
- reg_state[ctx_oactxctrl] =
i915_mmio_reg_offset(GEN8_OACTXCONTROL);
- reg_state[ctx_oactxctrl+1] =
(dev_priv->perf.oa.period_exponent <<
- GEN8_OA_TIMER_PERIOD_SHIFT) |
- (dev_priv->perf.oa.periodic ?
- GEN8_OA_TIMER_ENABLE : 0) |
- GEN8_OA_COUNTER_RESUME;
+ CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
+ (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
+ (dev_priv->perf.oa.periodic ?
GEN8_OA_TIMER_ENABLE : 0) |
+ GEN8_OA_COUNTER_RESUME);
I'll be honest but, I don't think it's CTX_REG() that helps
improve the
readability here.
The really odd part is that this sticks itself into a bare part
of the
register state not surrounded by any LRI and after a BB_END. This
routine can only work for established contexts, it should not
work for
execlists_init_reg_state.
Unless I am missing something change is completely mechanical, so any
question marks you have are already there, right? What do you
suggest is
the action here?
Sure, the only thing I question of this patch itself is whether
CTX_REG() is simply too much horrible obfuscating magic.
Turn a blind eye if the perceived badness factor is below some
threshold? Following patch depends on this one, so if I have to drop
this one, then I have to rework the next one etc.. well, it's not the
worst problem, so yeah, whatever. Make a call and let me know.
The patch was fine, just worrying about the surrounding code.
I misunderstood. So only about ctx_oactxctrl_offset and
ctx_flexeu0_offset from i915_perf.c? Maybe that is some OA magic, I
have not idea. CC-ing Lionel in case he can shed some light on it.
Those are the offsets at which the hardware will store the
OA_CTXCTRL/FLEX_EU registers values as documented.
I can see that's it's a bit odd not to have the MI_LRI written before we
do the first restore.
I'm 99% sure I've verified in practice that application started after
i915/perf is opened have the right values programmed.
Not completely sure that the IGT tests cover that case though.
So maybe there is a problem with the first restore...
What's the value set into most register that aren't explicitly
programmed in intel_lrc.c ?
-
Lionel
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add plane alpha blending support, v2.
Add plane alpha blending support with the different blend modes.
This has been tested on a icl to show the correct results,
on earlier platforms small rounding errors cause issues. But this
already happens case with fully transparant or fully opaque RGB
fb's.
The recommended HW workaround is to disable alpha blending when the
plane alpha is 0 (transparant, hide plane) or 0xff (opaque, disable blending).
This is easy to implement on any platform, so just do that.
The tests for userspace are also available, and pass on gen11.
Changes since v1:
- Change mistaken < 0xff0 to 0xff00.
- Only set PLANE_KEYMSK_ALPHA_ENABLE when plane alpha < 0xff00, ignore blend
mode.
- Rework disabling FBC when per pixel alpha is used.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 2 +
drivers/gpu/drm/i915/intel_display.c | 58 +++-
drivers/gpu/drm/i915/intel_fbc.c | 8
drivers/gpu/drm/i915/intel_sprite.c | 23 ++-
5 files changed, 73 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3fa56b960ef2..29f75da5fa8c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -545,6 +545,8 @@ struct intel_fbc {
int adjusted_y;
int y;
+
+ uint16_t pixel_blend_mode;
} plane;
struct {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0c9f03dda569..93a1d87cdeb2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6561,8 +6561,10 @@ enum {
#define _PLANE_KEYVAL_2_A 0x70294
#define _PLANE_KEYMSK_1_A 0x70198
#define _PLANE_KEYMSK_2_A 0x70298
+#define PLANE_KEYMSK_ALPHA_ENABLE (1 << 31)
#define _PLANE_KEYMAX_1_A 0x701a0
#define _PLANE_KEYMAX_2_A 0x702a0
+#define PLANE_KEYMAX_ALPHA_SHIFT 24
#define _PLANE_AUX_DIST_1_A0x701c0
#define _PLANE_AUX_DIST_2_A0x702c0
#define _PLANE_AUX_OFFSET_1_A 0x701c4
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a0345e7d3c2b..aedad3674b0d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3167,6 +3167,12 @@ int skl_check_plane_surface(const struct
intel_crtc_state *crtc_state,
return -EINVAL;
}
+ /* HW only has 8 bits pixel precision, disable plane if invisible */
+ if (!(plane_state->base.alpha >> 8)) {
+ plane_state->base.visible = false;
+ return 0;
+ }
+
if (!plane_state->base.visible)
return 0;
@@ -3512,30 +3518,39 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return 0;
}
-/*
- * XXX: For ARBG/ABGR formats we default to expecting scanout buffers
- * to be already pre-multiplied. We need to add a knob (or a different
- * DRM_FORMAT) for user-space to configure that.
- */
-static u32 skl_plane_ctl_alpha(uint32_t pixel_format)
+static u32 skl_plane_ctl_alpha(const struct intel_plane_state *plane_state)
{
- switch (pixel_format) {
- case DRM_FORMAT_ABGR:
- case DRM_FORMAT_ARGB:
+ if (!plane_state->base.fb->format->has_alpha)
+ return PLANE_CTL_ALPHA_DISABLE;
+
+ switch (plane_state->base.pixel_blend_mode) {
+ case DRM_MODE_BLEND_PIXEL_NONE:
+ return PLANE_CTL_ALPHA_DISABLE;
+ case DRM_MODE_BLEND_PREMULTI:
return PLANE_CTL_ALPHA_SW_PREMULTIPLY;
+ case DRM_MODE_BLEND_COVERAGE:
+ return PLANE_CTL_ALPHA_HW_PREMULTIPLY;
default:
- return PLANE_CTL_ALPHA_DISABLE;
+ MISSING_CASE(plane_state->base.pixel_blend_mode);
+ return 0;
}
}
-static u32 glk_plane_color_ctl_alpha(uint32_t pixel_format)
+static u32 glk_plane_color_ctl_alpha(const struct intel_plane_state
*plane_state)
{
- switch (pixel_format) {
- case DRM_FORMAT_ABGR:
- case DRM_FORMAT_ARGB:
+ if (!plane_state->base.fb->format->has_alpha)
+ return PLANE_COLOR_ALPHA_DISABLE;
+
+ switch (plane_state->base.pixel_blend_mode) {
+ case DRM_MODE_BLEND_PIXEL_NONE:
+ return PLANE_COLOR_ALPHA_DISABLE;
+ case DRM_MODE_BLEND_PREMULTI:
return PLANE_COLOR_ALPHA_SW_PREMULTIPLY;
+ case DRM_MODE_BLEND_COVERAGE:
+ return PLANE_COLOR_ALPHA_HW_PREMULTIPLY;
default:
- return PLANE_COLOR_ALPHA_DISABLE;
+ MISSING_CASE(plane_state->base.pixel_blend_mode);
+ return 0;
}
}
@@ -3611,7 +3626,7 @@ u32 skl_plane_ctl(const struct intel_crtc_state
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev6)
== Series Details ==
Series: drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev6)
URL : https://patchwork.freedesktop.org/series/47067/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4670 -> Patchwork_9947 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9947 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9947, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/47067/revisions/6/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9947:
=== IGT changes ===
Possible regressions
igt@drv_selftest@live_hangcheck:
{fi-bdw-samus}: PASS -> DMESG-FAIL
fi-hsw-peppy: PASS -> DMESG-FAIL
fi-cnl-psr: PASS -> DMESG-FAIL
fi-kbl-7500u: PASS -> DMESG-FAIL
fi-hsw-4770r: PASS -> DMESG-FAIL
fi-kbl-7560u: PASS -> DMESG-FAIL
fi-bdw-5557u: PASS -> DMESG-FAIL
fi-skl-6700hq: PASS -> DMESG-FAIL
fi-skl-gvtdvm: PASS -> DMESG-FAIL
fi-skl-6700k2: PASS -> DMESG-FAIL
fi-elk-e7500: PASS -> DMESG-FAIL
fi-byt-j1900: PASS -> DMESG-FAIL
fi-blb-e6850: PASS -> DMESG-FAIL
fi-cfl-guc: PASS -> DMESG-FAIL
fi-skl-guc: PASS -> DMESG-FAIL
fi-skl-6600u: PASS -> DMESG-FAIL
fi-pnv-d510:NOTRUN -> DMESG-FAIL
{fi-bsw-kefka}: PASS -> DMESG-FAIL
fi-cfl-8700k: PASS -> DMESG-FAIL
fi-kbl-r: PASS -> DMESG-FAIL
fi-byt-n2820: PASS -> DMESG-FAIL
{fi-byt-clapper}: PASS -> DMESG-FAIL
{fi-cfl-8109u}: PASS -> DMESG-FAIL
fi-kbl-guc: PASS -> DMESG-FAIL
fi-cfl-s3: PASS -> DMESG-FAIL
fi-gdg-551: PASS -> DMESG-FAIL
fi-bwr-2160:PASS -> DMESG-FAIL
fi-snb-2600:PASS -> DMESG-FAIL
fi-skl-6770hq: PASS -> DMESG-FAIL
fi-whl-u: PASS -> DMESG-FAIL
fi-ivb-3520m: PASS -> DMESG-FAIL
fi-hsw-4770:PASS -> DMESG-FAIL
fi-bxt-j4205: PASS -> DMESG-FAIL
fi-skl-6260u: PASS -> DMESG-FAIL
{fi-skl-iommu}: PASS -> DMESG-FAIL
fi-glk-j4005: PASS -> DMESG-FAIL
fi-ivb-3770:PASS -> DMESG-FAIL
fi-ilk-650: PASS -> DMESG-FAIL
fi-bsw-n3050: PASS -> DMESG-FAIL
fi-bdw-gvtdvm: PASS -> DMESG-FAIL
{fi-icl-u}: PASS -> DMESG-FAIL
fi-kbl-x1275: PASS -> DMESG-FAIL
fi-kbl-7567u: PASS -> DMESG-FAIL
fi-glk-dsi: PASS -> DMESG-FAIL
== Known issues ==
Here are the changes found in Patchwork_9947 that come from known issues:
=== IGT changes ===
Issues hit
{igt@amdgpu/amd_basic@userptr}:
{fi-kbl-8809g}: PASS -> INCOMPLETE (fdo#107402)
igt@drv_selftest@live_coherency:
fi-gdg-551: PASS -> DMESG-FAIL (fdo#107164)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362, fdo#103191)
Possible fixes
igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
fi-skl-6700k2: FAIL (fdo#103191) -> PASS
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
{fi-byt-clapper}: FAIL (fdo#107362, fdo#103191) -> PASS
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-FAIL (fdo#107372) -> DMESG-WARN (fdo#107372)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
fdo#107402 https://bugs.freedesktop.org/show_bug.cgi?id=107402
== Participating hosts (53 -> 48) ==
Additional (1): fi-pnv-d510
Missing(6): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600
== Build changes ==
* Linux: CI_DRM_4670 -> Patchwork_9947
CI_DRM_4670: 36137e724bdaee1ab5cee7142d06898d45b8aeb3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4598: 9c0f04355107a8693650b16756b6343a78501138 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9947: d5ec539e7d207822aba0c0a6671e0fbfbe31882d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d5ec539e7d20 drm/i915: Skip repeated calls to i915_gem_set_wedged()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9947/issues.html
Re: [Intel-gfx] [PATCH i-g-t 1/3] igt/gem_sync: Exercise sync after context switch
Quoting Antonio Argenziano (2018-08-15 00:50:43)
>
>
> On 10/08/18 04:01, Chris Wilson wrote:
> > This exercises a special case that may be of interest, waiting for a
> > context that may be preempted in order to reduce the wait.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > + cycles = 0;
> > + elapsed = 0;
> > + start = gettime();
> > + do {
> > + do {
> > + double this;
> > +
> > + gem_execbuf(fd, [0].execbuf);
> > + gem_execbuf(fd, [1].execbuf);
>
> I'm not sure where the preemption, mentioned in the commit message, is
> coming in.
Internally. I've suggested that we reorder equivalent contexts in order
to satisfy client waits earlier. So having created two independent
request queues, userspace should be oblivious to the execution order.
-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: Skip repeated calls to i915_gem_set_wedged() (rev6)
== Series Details == Series: drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev6) URL : https://patchwork.freedesktop.org/series/47067/ State : warning == Summary == $ dim checkpatch origin/drm-tip d5ec539e7d20 drm/i915: Skip repeated calls to i915_gem_set_wedged() -:52: WARNING:MEMORY_BARRIER: memory barrier without comment #52: FILE: drivers/gpu/drm/i915/i915_gem.c:3380: + smp_mb__before_atomic(); total: 0 errors, 1 warnings, 0 checks, 109 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Skip repeated calls to i915_gem_set_wedged()
Quoting Chris Wilson (2018-08-15 10:25:37) > If we already wedged, i915_gem_set_wedged() becomes a complicated no-op. > > v2: Make sure the double set-wedged is synchronous, a parallel call > should not return before the driver is indeed wedged. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=107343 > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala Fwiw, I actually a landed a different version of this patch earlier. The only advantage (esp. v3) is that we serialise the wedging more carefully. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Skip repeated calls to i915_gem_set_wedged()
If we already wedged, i915_gem_set_wedged() becomes a complicated no-op.
v2: Make sure the double set-wedged is synchronous, a parallel call
should not return before the driver is indeed wedged.
v3: Use a real mutex (and fingers crossed that lockdep is ok!)
References: https://bugs.freedesktop.org/show_bug.cgi?id=107343
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 36 +--
drivers/gpu/drm/i915/i915_gpu_error.h | 4 ++-
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
3 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0453eb42a1a3..d9e00705536d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3300,10 +3300,15 @@ static void nop_complete_submit_request(struct
i915_request *request)
void i915_gem_set_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = >gpu_error;
struct intel_engine_cs *engine;
enum intel_engine_id id;
- GEM_TRACE("start\n");
+ mutex_lock(>wedge_mutex);
+ if (test_bit(I915_WEDGED, >flags)) {
+ mutex_unlock(>wedge_mutex);
+ return;
+ }
if (GEM_SHOW_DEBUG()) {
struct drm_printer p = drm_debug_printer(__func__);
@@ -3312,8 +3317,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_dump(engine, , "%s\n", engine->name);
}
- if (test_and_set_bit(I915_WEDGED, >gpu_error.flags))
- goto out;
+ GEM_TRACE("start\n");
/*
* First, stop submission to hw, but do not yet complete requests by
@@ -3373,19 +3377,27 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
i915_gem_reset_finish_engine(engine);
}
-out:
+ smp_mb__before_atomic();
+ set_bit(I915_WEDGED, >flags);
+
GEM_TRACE("end\n");
+ mutex_unlock(>wedge_mutex);
- wake_up_all(>gpu_error.reset_queue);
+ wake_up_all(>reset_queue);
}
bool i915_gem_unset_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = >gpu_error;
struct i915_timeline *tl;
+ bool ret = false;
lockdep_assert_held(>drm.struct_mutex);
- if (!test_bit(I915_WEDGED, >gpu_error.flags))
- return true;
+
+ if (!test_bit(I915_WEDGED, >flags))
+ return false;
+
+ mutex_lock(>wedge_mutex);
GEM_TRACE("start\n");
@@ -3420,7 +3432,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
*/
if (dma_fence_default_wait(>fence, true,
MAX_SCHEDULE_TIMEOUT) < 0)
- return false;
+ goto unlock;
}
i915_retire_requests(i915);
GEM_BUG_ON(i915->gt.active_requests);
@@ -3439,10 +3451,11 @@ bool i915_gem_unset_wedged(struct drm_i915_private
*i915)
GEM_TRACE("end\n");
- smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
- clear_bit(I915_WEDGED, >gpu_error.flags);
+ ret = true;
+unlock:
+ mutex_unlock(>gpu_error.wedge_mutex);
- return true;
+ return ret;
}
static void
@@ -5764,6 +5777,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
i915_gem_idle_work_handler);
init_waitqueue_head(_priv->gpu_error.wait_queue);
init_waitqueue_head(_priv->gpu_error.reset_queue);
+ mutex_init(_priv->gpu_error.wedge_mutex);
atomic_set(_priv->mm.bsd_engine_dispatch_index, 0);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index f893a4e8b783..49950b1231cf 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -267,8 +267,8 @@ struct i915_gpu_error {
#define I915_RESET_BACKOFF 0
#define I915_RESET_HANDOFF 1
#define I915_RESET_MODESET 2
+#define I915_RESET_ENGINE 3
#define I915_WEDGED(BITS_PER_LONG - 1)
-#define I915_RESET_ENGINE (I915_WEDGED - I915_NUM_ENGINES)
/** Number of times an engine has been reset */
u32 reset_engine_count[I915_NUM_ENGINES];
@@ -279,6 +279,8 @@ struct i915_gpu_error {
/** Reason for the current *global* reset */
const char *reason;
+ struct mutex wedge_mutex; /* serialises wedging/unwedging */
+
/**
* Waitqueue to signal when a hang is detected. Used to for waiters
* to release the struct_mutex for the reset to procede.
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 43ed8b28aeaa..6beb1f47e988 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -186,6 +186,7 @@ struct
[Intel-gfx] [PATCH] drm/i915: Skip repeated calls to i915_gem_set_wedged()
If we already wedged, i915_gem_set_wedged() becomes a complicated no-op.
v2: Make sure the double set-wedged is synchronous, a parallel call
should not return before the driver is indeed wedged.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107343
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 33 ++-
drivers/gpu/drm/i915/i915_gpu_error.h | 3 ++-
2 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0453eb42a1a3..4778d324529e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3298,12 +3298,27 @@ static void nop_complete_submit_request(struct
i915_request *request)
spin_unlock_irqrestore(>engine->timeline.lock, flags);
}
+static void wait_for_wedged(struct i915_gpu_error *error)
+{
+ DEFINE_WAIT_BIT(wq_entry, >flags, I915_WEDGED);
+
+ __wait_on_bit(>reset_queue,
+ _entry, bit_wait, TASK_UNINTERRUPTIBLE);
+}
+
void i915_gem_set_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = >gpu_error;
struct intel_engine_cs *engine;
enum intel_engine_id id;
- GEM_TRACE("start\n");
+ if (test_bit(I915_WEDGED, >flags))
+ return;
+
+ if (test_and_set_bit(I915_WEDGE_IN_PROGRESS, >flags)) {
+ wait_for_wedged(error);
+ return;
+ }
if (GEM_SHOW_DEBUG()) {
struct drm_printer p = drm_debug_printer(__func__);
@@ -3312,8 +3327,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_dump(engine, , "%s\n", engine->name);
}
- if (test_and_set_bit(I915_WEDGED, >gpu_error.flags))
- goto out;
+ GEM_TRACE("start\n");
/*
* First, stop submission to hw, but do not yet complete requests by
@@ -3373,18 +3387,25 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
i915_gem_reset_finish_engine(engine);
}
-out:
+ smp_mb__before_atomic();
+ set_bit(I915_WEDGED, >flags);
+ clear_bit(I915_WEDGE_IN_PROGRESS, >flags);
+
GEM_TRACE("end\n");
- wake_up_all(>gpu_error.reset_queue);
+ wake_up_all(>reset_queue);
}
bool i915_gem_unset_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = >gpu_error;
struct i915_timeline *tl;
lockdep_assert_held(>drm.struct_mutex);
- if (!test_bit(I915_WEDGED, >gpu_error.flags))
+
+ if (test_bit(I915_WEDGE_IN_PROGRESS, >flags))
+ wait_for_wedged(error);
+ if (!test_bit(I915_WEDGED, >flags))
return true;
GEM_TRACE("start\n");
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index f893a4e8b783..1a78a8f330f2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -267,8 +267,9 @@ struct i915_gpu_error {
#define I915_RESET_BACKOFF 0
#define I915_RESET_HANDOFF 1
#define I915_RESET_MODESET 2
+#define I915_RESET_ENGINE 3
#define I915_WEDGED(BITS_PER_LONG - 1)
-#define I915_RESET_ENGINE (I915_WEDGED - I915_NUM_ENGINES)
+#define I915_WEDGE_IN_PROGRESS (I915_WEDGED - 1)
/** Number of times an engine has been reset */
u32 reset_engine_count[I915_NUM_ENGINES];
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt/pm_rpm: Close local fd before trying to unload module
Fixes: d8e78990aa2b ("igt/pm_rpm: Test reaquisition of runtime-pm after module
reload")
Signed-off-by: Chris Wilson
---
tests/pm_rpm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index 65489bcdb..a4f9f783e 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -2034,6 +2034,8 @@ int main(int argc, char *argv[])
teardown_environment();
igt_subtest("module-reload") {
+ teardown_environment();
+
igt_debug("Reload w/o display\n");
igt_i915_driver_unload();
igt_assert_eq(igt_i915_driver_load("disable_display=1"), 0);
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clear stop-engine for a pardoned reset
Quoting Mika Kuoppala (2018-08-15 10:08:09) > Chris Wilson writes: > > > Quoting Mika Kuoppala (2018-08-15 09:52:18) > >> Chris Wilson writes: > >> > >> > If we pardon a per-engine reset, we may leave the STOP_RING bit asserted > >> > in RING_MI_MODE resulting in the engine hanging. Unconditionally clear > >> > it on the per-engine exit path as we know that either we skipped the > >> > reset and so need the cancellation, or the reset was successful and the > >> > cancellation is a no-op, or there was an error and we will follow up > >> > with a full-reset or wedging (both of which will stop the engines again > >> > as required). > >> > > >> > Signed-off-by: Chris Wilson > >> > Cc: Mika Kuoppala > >> > --- > >> > drivers/gpu/drm/i915/i915_drv.c | 1 + > >> > drivers/gpu/drm/i915/intel_engine_cs.c | 10 ++ > >> > drivers/gpu/drm/i915/intel_ringbuffer.h | 1 + > >> > 3 files changed, 12 insertions(+) > >> > > >> > diff --git a/drivers/gpu/drm/i915/i915_drv.c > >> > b/drivers/gpu/drm/i915/i915_drv.c > >> > index 9dce55182c3a..4f2a9c39 100644 > >> > --- a/drivers/gpu/drm/i915/i915_drv.c > >> > +++ b/drivers/gpu/drm/i915/i915_drv.c > >> > @@ -2079,6 +2079,7 @@ int i915_reset_engine(struct intel_engine_cs > >> > *engine, const char *msg) > >> > goto out; > >> > > >> > out: > >> > + intel_engine_cancel_stop_cs(engine); > >> > i915_gem_reset_finish_engine(engine); > >> > >> Should we just lift the whole stop/start dance into > >> gem_reset_prepare|finish_engine()s? > > > > No, because it is also used by wedging where we do want the asymmetry. > > Been there, done that, have the gem_eio bruises. > > On wedge the submission path is blocked but yeah, > gpu can be in any state and enabling the engine at that > point is asking for trouble. > > Reviewed-by: Mika Kuoppala Grabbed, pushed, and scarpered. Although this should fix the silly STOP_RING hangs that have been plaguing us for the last few months, there still seems to be more fun to be had here. /o\ -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
On 14/08/2018 19:53, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-14 19:44:09)
On 14/08/2018 15:59, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-14 15:40:58)
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.
The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.
We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,
struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
.instance = 0, };
memset(, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t)
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
sseu.packed.subslice_mask = 0;
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
}
could be used to disable all subslices where supported.
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context (Chris)
v7: Synchronize the requests following a powergating setting change using a
global
dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users (Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Cc: Dmitry Rogozhkin
Cc: Tvrtko Ursulin
Cc: Zhipeng Gong
Cc: Joonas Lahtinen
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 187 +++-
drivers/gpu/drm/i915/intel_lrc.c| 55 +++
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
include/uapi/drm/i915_drm.h | 43 ++
4 files changed, 288 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8a12984e7495..6d6220634e9e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -773,6 +773,91 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
return 0;
}
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ struct drm_i915_private *i915 = ctx->i915;
+ struct i915_request *rq;
+ struct intel_ring *ring;
+ int ret;
+
+ lockdep_assert_held(>drm.struct_mutex);
+
+ /* Submitting requests etc needs the hw awake. */
+ intel_runtime_pm_get(i915);
+
+ i915_retire_requests(i915);
?
I wondered myself but did not make myself dig through all the history of
the series. Cannot think that it does anything useful in the current design.
+
+ /* Now use the RCS to actually reconfigure. */
+
Re: [Intel-gfx] [PATCH i-g-t] docs: fix typo sharding->sharing
On Tue, Aug 14, 2018 at 10:29:02AM -0700, Lucas De Marchi wrote:
> On Fri, Aug 03, 2018 at 12:07:43PM +0300, Petri Latvala wrote:
> > On Thu, Aug 02, 2018 at 03:09:37PM -0700, Lucas De Marchi wrote:
> > > I was grepping for shard as the tests run on CI, but the only occurrence
> > > was this one which seems to be a typo since it's about prime tests.
> > >
> > > Fixes: 76bce773 ("docs: Update documentation generation with missing
> > > entries")
> > > Signed-off-by: Lucas De Marchi
> >
> > Reviewed-by: Petri Latvala
>
> just a heads up that this is not yet applied...
Sounds like time to fix you up with commit rights asap:
https://www.freedesktop.org/wiki/AccountRequests/
Please paste your account request here so we can move it forward (igt
maintainers are on board too, I pinged them over irc).
-Daniel
>
> thanks
> Lucas De Marchi
>
> >
> >
> > > ---
> > > docs/reference/igt-gpu-tools/igt_test_programs.xml | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > > b/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > > index ec05d53e..95c4653e 100644
> > > --- a/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > > +++ b/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > > @@ -229,7 +229,7 @@
> > >
> > >
> > >Prime Tests
> > > - Tests for buffer sharding
> > > + Tests for buffer sharing
> > >
> > >
> > >
> > > --
> > > 2.17.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clear stop-engine for a pardoned reset
Chris Wilson writes: > Quoting Mika Kuoppala (2018-08-15 09:52:18) >> Chris Wilson writes: >> >> > If we pardon a per-engine reset, we may leave the STOP_RING bit asserted >> > in RING_MI_MODE resulting in the engine hanging. Unconditionally clear >> > it on the per-engine exit path as we know that either we skipped the >> > reset and so need the cancellation, or the reset was successful and the >> > cancellation is a no-op, or there was an error and we will follow up >> > with a full-reset or wedging (both of which will stop the engines again >> > as required). >> > >> > Signed-off-by: Chris Wilson >> > Cc: Mika Kuoppala >> > --- >> > drivers/gpu/drm/i915/i915_drv.c | 1 + >> > drivers/gpu/drm/i915/intel_engine_cs.c | 10 ++ >> > drivers/gpu/drm/i915/intel_ringbuffer.h | 1 + >> > 3 files changed, 12 insertions(+) >> > >> > diff --git a/drivers/gpu/drm/i915/i915_drv.c >> > b/drivers/gpu/drm/i915/i915_drv.c >> > index 9dce55182c3a..4f2a9c39 100644 >> > --- a/drivers/gpu/drm/i915/i915_drv.c >> > +++ b/drivers/gpu/drm/i915/i915_drv.c >> > @@ -2079,6 +2079,7 @@ int i915_reset_engine(struct intel_engine_cs >> > *engine, const char *msg) >> > goto out; >> > >> > out: >> > + intel_engine_cancel_stop_cs(engine); >> > i915_gem_reset_finish_engine(engine); >> >> Should we just lift the whole stop/start dance into >> gem_reset_prepare|finish_engine()s? > > No, because it is also used by wedging where we do want the asymmetry. > Been there, done that, have the gem_eio bruises. On wedge the submission path is blocked but yeah, gpu can be in any state and enabling the engine at that point is asking for trouble. Reviewed-by: Mika Kuoppala > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clear stop-engine for a pardoned reset
Quoting Mika Kuoppala (2018-08-15 09:52:18) > Chris Wilson writes: > > > If we pardon a per-engine reset, we may leave the STOP_RING bit asserted > > in RING_MI_MODE resulting in the engine hanging. Unconditionally clear > > it on the per-engine exit path as we know that either we skipped the > > reset and so need the cancellation, or the reset was successful and the > > cancellation is a no-op, or there was an error and we will follow up > > with a full-reset or wedging (both of which will stop the engines again > > as required). > > > > Signed-off-by: Chris Wilson > > Cc: Mika Kuoppala > > --- > > drivers/gpu/drm/i915/i915_drv.c | 1 + > > drivers/gpu/drm/i915/intel_engine_cs.c | 10 ++ > > drivers/gpu/drm/i915/intel_ringbuffer.h | 1 + > > 3 files changed, 12 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > b/drivers/gpu/drm/i915/i915_drv.c > > index 9dce55182c3a..4f2a9c39 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.c > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > @@ -2079,6 +2079,7 @@ int i915_reset_engine(struct intel_engine_cs *engine, > > const char *msg) > > goto out; > > > > out: > > + intel_engine_cancel_stop_cs(engine); > > i915_gem_reset_finish_engine(engine); > > Should we just lift the whole stop/start dance into > gem_reset_prepare|finish_engine()s? No, because it is also used by wedging where we do want the asymmetry. Been there, done that, have the gem_eio bruises. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] docs: fix typo sharding->sharing
On 08/14/2018 08:29 PM, Lucas De Marchi wrote:
On Fri, Aug 03, 2018 at 12:07:43PM +0300, Petri Latvala wrote:
On Thu, Aug 02, 2018 at 03:09:37PM -0700, Lucas De Marchi wrote:
I was grepping for shard as the tests run on CI, but the only occurrence
was this one which seems to be a typo since it's about prime tests.
Fixes: 76bce773 ("docs: Update documentation generation with missing entries")
Signed-off-by: Lucas De Marchi
Reviewed-by: Petri Latvala
just a heads up that this is not yet applied...
Thanks for the heads up. Now it is. :)
--
Petri Latvala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clear stop-engine for a pardoned reset
Chris Wilson writes:
> If we pardon a per-engine reset, we may leave the STOP_RING bit asserted
> in RING_MI_MODE resulting in the engine hanging. Unconditionally clear
> it on the per-engine exit path as we know that either we skipped the
> reset and so need the cancellation, or the reset was successful and the
> cancellation is a no-op, or there was an error and we will follow up
> with a full-reset or wedging (both of which will stop the engines again
> as required).
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.c | 1 +
> drivers/gpu/drm/i915/intel_engine_cs.c | 10 ++
> drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
> 3 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9dce55182c3a..4f2a9c39 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2079,6 +2079,7 @@ int i915_reset_engine(struct intel_engine_cs *engine,
> const char *msg)
> goto out;
>
> out:
> + intel_engine_cancel_stop_cs(engine);
> i915_gem_reset_finish_engine(engine);
Should we just lift the whole stop/start dance into
gem_reset_prepare|finish_engine()s?
-Mika
> return ret;
> }
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 99d5a24219c1..8628567d8f6e 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -788,6 +788,16 @@ int intel_engine_stop_cs(struct intel_engine_cs *engine)
> return err;
> }
>
> +void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine)
> +{
> + struct drm_i915_private *dev_priv = engine->i915;
> +
> + GEM_TRACE("%s\n", engine->name);
> +
> + I915_WRITE_FW(RING_MI_MODE(engine->mmio_base),
> + _MASKED_BIT_DISABLE(STOP_RING));
> +}
> +
> const char *i915_cache_level_str(struct drm_i915_private *i915, int type)
> {
> switch (type) {
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 9090885d57de..3f6920dd7880 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -906,6 +906,7 @@ int intel_init_blt_ring_buffer(struct intel_engine_cs
> *engine);
> int intel_init_vebox_ring_buffer(struct intel_engine_cs *engine);
>
> int intel_engine_stop_cs(struct intel_engine_cs *engine);
> +void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
>
> u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
> u64 intel_engine_get_last_batch_head(const struct intel_engine_cs *engine);
> --
> 2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
On 14/08/2018 19:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-14 19:49:46)
On 13/08/2018 10:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
On 13/08/2018 09:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
From: Lionel Landwerlin
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 34 +++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 49597cf31707..ccb20230df2c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -210,6 +210,7 @@
#include "i915_oa_cflgt3.h"
#include "i915_oa_cnl.h"
#include "i915_oa_icl.h"
+#include "intel_lrc_reg.h"
/* HW requires this to be a power of two, between 128k and 16M, though driver
* is currently generally designed assuming the largest 16M size is used
such
@@ -1636,27 +1637,25 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
/* The MMIO offsets for Flex EU registers aren't contiguous */
- u32 flex_mmio[] = {
- i915_mmio_reg_offset(EU_PERF_CNTL0),
- i915_mmio_reg_offset(EU_PERF_CNTL1),
- i915_mmio_reg_offset(EU_PERF_CNTL2),
- i915_mmio_reg_offset(EU_PERF_CNTL3),
- i915_mmio_reg_offset(EU_PERF_CNTL4),
- i915_mmio_reg_offset(EU_PERF_CNTL5),
- i915_mmio_reg_offset(EU_PERF_CNTL6),
+ i915_reg_t flex_regs[] = {
+ EU_PERF_CNTL0,
+ EU_PERF_CNTL1,
+ EU_PERF_CNTL2,
+ EU_PERF_CNTL3,
+ EU_PERF_CNTL4,
+ EU_PERF_CNTL5,
+ EU_PERF_CNTL6,
};
int i;
- reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
- reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
- GEN8_OA_TIMER_PERIOD_SHIFT) |
-(dev_priv->perf.oa.periodic ?
- GEN8_OA_TIMER_ENABLE : 0) |
-GEN8_OA_COUNTER_RESUME;
+ CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
+ (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
+ (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
+ GEN8_OA_COUNTER_RESUME);
I'll be honest but, I don't think it's CTX_REG() that helps improve the
readability here.
The really odd part is that this sticks itself into a bare part of the
register state not surrounded by any LRI and after a BB_END. This
routine can only work for established contexts, it should not work for
execlists_init_reg_state.
Unless I am missing something change is completely mechanical, so any
question marks you have are already there, right? What do you suggest is
the action here?
Sure, the only thing I question of this patch itself is whether
CTX_REG() is simply too much horrible obfuscating magic.
Turn a blind eye if the perceived badness factor is below some
threshold? Following patch depends on this one, so if I have to drop
this one, then I have to rework the next one etc.. well, it's not the
worst problem, so yeah, whatever. Make a call and let me know.
The patch was fine, just worrying about the surrounding code.
I misunderstood. So only about ctx_oactxctrl_offset and
ctx_flexeu0_offset from i915_perf.c? Maybe that is some OA magic, I have
not idea. CC-ing Lionel in case he can shed some light on it.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
