[Intel-gfx] ✓ Fi.CI.BAT: success for drm/modes: Prevent division by zero htotal
== Series Details ==
Series: drm/modes: Prevent division by zero htotal
URL : https://patchwork.freedesktop.org/series/55610/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5468 -> Patchwork_12012
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55610/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12012 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: PASS -> INCOMPLETE [fdo#108602] / [fdo#108744]
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1
{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#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
Participating hosts (46 -> 40)
--
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ivb-3770 fi-snb-2600
Build changes
-
* Linux: CI_DRM_5468 -> Patchwork_12012
CI_DRM_5468: fc4e30d30d90ed5d5bd467de0439e9522d34cdf0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4784: 1c5a4432293369f85859c748c08155e79d92c4ce @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12012: daea462cce0cd3d56ab143701960bf39acef551c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
daea462cce0c drm/modes: Prevent division by zero htotal
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12012/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915/sdvo: switch to kernel types
On Mon, 21 Jan 2019, Jani Nikula wrote: > On Fri, 18 Jan 2019, Jani Nikula wrote: >> Mixed C99 and kernel types use is getting ugly. Prefer kernel types. >> >> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' >> >> v2: rebase >> >> Acked-by: Chris Wilson >> Acked-by: Tvrtko Ursulin >> Reviewed-by: Ville Syrjälä >> Reviewed-by: José Roberto de Souza >> Signed-off-by: Jani Nikula > > Thanks for the reviews and acks. Pushed everything *except* this patch, > which seems to need a drm-next backmerge for the avi infoframe stuff. And now pushed. We no longer have any C99 uint types left. \o/ BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: do a posting read after irq install
Quoting Daniele Ceraolo Spurio (2019-01-23 02:32:27) > When reading GEN11_GT_INTR_DWx closely after enabling the interrupts > in gen11_irq_postinstall, the returned value is garbage. This can > cause other parts of the setup code (e.g. gen11_reset_one_iir) to > think that there are interrupts to be cleared when there are none. > > The garbage value is only seen on the first read done after the enable, > so this looks like a posting issue. Adding a posting read after enabling > the interrupts does indeed fix the problem. > > Note that the posting read has been purposely added outside of > gen11_master_intr_enable since the issue has only been observed when the > full interrupt setup is performed. > > Cc: Mika Kuoppala > Signed-off-by: Daniele Ceraolo Spurio irq regs and flushing stale results (side effect or double buffering? or maybe latching?), seem to go hand in hand. Acked-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 08/34] drm/i915: Make all GPU resets atomic
John Harrison writes:
> On 1/21/2019 14:20, Chris Wilson wrote:
>> In preparation for the next few commits, make resetting the GPU atomic.
>> Currently, we have prepared gen6+ for atomic resetting of individual
>> engines, but now there is a requirement to perform the whole device
>> level reset (just the register poking) from inside an atomic context.
>>
>> Signed-off-by: Chris Wilson
>> Reviewed-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/i915_reset.c | 50 +--
>> 1 file changed, 27 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reset.c
>> b/drivers/gpu/drm/i915/i915_reset.c
>> index 342d9ee42601..b9d0ea70361c 100644
>> --- a/drivers/gpu/drm/i915/i915_reset.c
>> +++ b/drivers/gpu/drm/i915/i915_reset.c
>> @@ -144,14 +144,14 @@ static int i915_do_reset(struct drm_i915_private *i915,
>>
>> /* Assert reset for at least 20 usec, and wait for acknowledgement. */
>> pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
>> -usleep_range(50, 200);
>> -err = wait_for(i915_in_reset(pdev), 500);
>> +udelay(50);
>> +err = wait_for_atomic(i915_in_reset(pdev), 50);
> Is it known to be safe to reduce all of these time out values? Where did
> the originally 500ms value come from? Is there any chance of getting
> sporadic failures because 50ms is borderline in the worst case scenario?
> It still sounds huge but an order of magnitude change in a timeout
> always seems worrying!
>
>>
>> /* Clear the reset request. */
>> pci_write_config_byte(pdev, I915_GDRST, 0);
>> -usleep_range(50, 200);
>> +udelay(50);
>> if (!err)
>> -err = wait_for(!i915_in_reset(pdev), 500);
>> +err = wait_for_atomic(!i915_in_reset(pdev), 50);
>>
>> return err;
>> }
>> @@ -171,7 +171,7 @@ static int g33_do_reset(struct drm_i915_private *i915,
>> struct pci_dev *pdev = i915->drm.pdev;
>>
>> pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
>> -return wait_for(g4x_reset_complete(pdev), 500);
>> +return wait_for_atomic(g4x_reset_complete(pdev), 50);
>> }
>>
>> static int g4x_do_reset(struct drm_i915_private *dev_priv,
>> @@ -182,13 +182,13 @@ static int g4x_do_reset(struct drm_i915_private
>> *dev_priv,
>> int ret;
>>
>> /* WaVcpClkGateDisableForMediaReset:ctg,elk */
>> -I915_WRITE(VDECCLK_GATE_D,
>> - I915_READ(VDECCLK_GATE_D) | VCP_UNIT_CLOCK_GATE_DISABLE);
>> -POSTING_READ(VDECCLK_GATE_D);
>> +I915_WRITE_FW(VDECCLK_GATE_D,
>> + I915_READ(VDECCLK_GATE_D) | VCP_UNIT_CLOCK_GATE_DISABLE);
>> +POSTING_READ_FW(VDECCLK_GATE_D);
>>
>> pci_write_config_byte(pdev, I915_GDRST,
>>GRDOM_MEDIA | GRDOM_RESET_ENABLE);
>> -ret = wait_for(g4x_reset_complete(pdev), 500);
>> +ret = wait_for_atomic(g4x_reset_complete(pdev), 50);
>> if (ret) {
>> DRM_DEBUG_DRIVER("Wait for media reset failed\n");
>> goto out;
>> @@ -196,7 +196,7 @@ static int g4x_do_reset(struct drm_i915_private
>> *dev_priv,
>>
>> pci_write_config_byte(pdev, I915_GDRST,
>>GRDOM_RENDER | GRDOM_RESET_ENABLE);
>> -ret = wait_for(g4x_reset_complete(pdev), 500);
>> +ret = wait_for_atomic(g4x_reset_complete(pdev), 50);
>> if (ret) {
>> DRM_DEBUG_DRIVER("Wait for render reset failed\n");
>> goto out;
>> @@ -205,9 +205,9 @@ static int g4x_do_reset(struct drm_i915_private
>> *dev_priv,
>> out:
>> pci_write_config_byte(pdev, I915_GDRST, 0);
>>
>> -I915_WRITE(VDECCLK_GATE_D,
>> - I915_READ(VDECCLK_GATE_D) & ~VCP_UNIT_CLOCK_GATE_DISABLE);
>> -POSTING_READ(VDECCLK_GATE_D);
>> +I915_WRITE_FW(VDECCLK_GATE_D,
>> + I915_READ(VDECCLK_GATE_D) & ~VCP_UNIT_CLOCK_GATE_DISABLE);
>> +POSTING_READ_FW(VDECCLK_GATE_D);
>>
>> return ret;
>> }
>> @@ -218,27 +218,29 @@ static int ironlake_do_reset(struct drm_i915_private
>> *dev_priv,
>> {
>> int ret;
>>
>> -I915_WRITE(ILK_GDSR, ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
>> -ret = intel_wait_for_register(dev_priv,
>> - ILK_GDSR, ILK_GRDOM_RESET_ENABLE, 0,
>> - 500);
>> +I915_WRITE_FW(ILK_GDSR, ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
>> +ret = __intel_wait_for_register_fw(dev_priv, ILK_GDSR,
>> + ILK_GRDOM_RESET_ENABLE, 0,
>> + 5000, 0,
>> + NULL);
> These two timeouts are now two orders of magnitude smaller? It was 500ms
> but is now 5000us (=5ms)?
Agreed. I indirecty raised same concern on previous round of
review by saying that it would be nice if we had some statistics
from CI.
The original ballooning of these numbers, from the little
that is available on documentation, is the fact that
Re: [Intel-gfx] [RFC] drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
Op 22-01-2019 om 22:12 schreef Manasi Navare:
> On Gen 11 platform, to enable resolutions like 5K@120 where
> the pixel clock is greater than pipe pixel rate, we need to split it across
> 2 pipes and enable it using DSC and big joiner. In order to support this
> dual pipe single port mode, we need to link two crtcs involved in this
> ganged mode.
>
> This patch is a RFC patch that links two crtcs using linked_crtc pointer
> in intel_crtc_state and slave to indicate if the crtc is a master or slave.
> Here the HW necessitates the first CRTC to be the master CRTC through which
> the final output will be driven and the next consecutive CRTC should be
> slave crtc.
>
> This is currently not tested, but I wanted to get some inputs on this
> approach.
> The idea is to follow the same approach used in Ganged plane mode for NV12
> planes.
>
> Suggested-by: Maarten Lankhorst ,
> Matt Roper
> Cc: Ville Syrjälä
> Cc: Matt Roper
> Cc: Maarten Lankhorst
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_display.c | 63
> drivers/gpu/drm/i915/intel_drv.h | 6 +++
> 2 files changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2fa9f4aec08e..9910dad7371b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10900,6 +10900,63 @@ static bool check_single_encoder_cloning(struct
> drm_atomic_state *state,
> return true;
> }
>
> +static bool icl_dual_pipe_mode(struct drm_i915_private *dev_priv,
> +struct drm_crtc_state *crtc_state)
> +{
> + if (crtc_state->mode.clock <= 2 * dev_priv->max_cdclk_freq)
> + return false;
> +
> + return true;
> +}
> +
> +static int icl_set_linked_crtcs(struct drm_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->dev);
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + struct intel_crtc_state *linked_state = NULL;
> + struct intel_crtc *slave_crtc = NULL;
> + int i;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + struct intel_crtc_state *pipe_config =
> + to_intel_crtc_state(crtc_state);
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> +
> + if (crtc_state->active)
> + continue;
> +
> + if (!icl_dual_pipe_mode(dev_priv, crtc_state))
> + continue;
> +
> + if (!pipe_config->linked_crtc) {
> + slave_crtc = intel_get_crtc_for_pipe(dev_priv,
> + intel_crtc->pipe +
> 1);
> + if (!slave_crtc)
> + return PTR_ERR(slave_crtc);
> +
> + linked_state = intel_atomic_get_crtc_state(state,
> slave_crtc);
> + if (IS_ERR(linked_state))
> + return PTR_ERR(linked_state);
> +
> + pipe_config->linked_crtc = slave_crtc;
> + pipe_config->slave = false;
> + linked_state->linked_crtc = intel_crtc;
> + linked_state->slave = true;
> + // Update the intel_state->active_crtcs if needed
> +
> + DRM_DEBUG_KMS("Using [CRTC:%d:%s] as master and
> [CRTC:%d:%s] as slave\n",
> + intel_crtc->base.base.id,
> intel_crtc->base.name,
> + slave_crtc->base.base.id,
> slave_crtc->base.name);
> +
> + break;
> + }
> + }
> +
> + return 0;
> +
> +}
> +
> static int icl_add_linked_planes(struct intel_atomic_state *state)
> {
> struct intel_plane *plane, *linked;
> @@ -12702,6 +12759,12 @@ static int intel_atomic_check(struct drm_device *dev,
> if (ret)
> return ret;
>
> + if (INTEL_GEN(dev_priv) >= 11) {
> + ret = icl_set_linked_crtcs(state);
> + if (ret)
> + return ret;
> + }
> +
> for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, crtc_state,
> i) {
> struct intel_crtc_state *pipe_config =
> to_intel_crtc_state(crtc_state);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 33b733d37706..f8bbed525ec3 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -959,6 +959,12 @@ struct intel_crtc_state {
>
> /* Forward Error correction State */
> bool fec_enable;
> +
> + /* Pointer to linked crtc in dual pipe mode */
> + struct intel_crtc *linked_crtc;
> +
> + /* Flag to indicate whether this crtc is master or slave */
> + bool slave;
> };
>
> struct intel_crtc {
Hey,
Looks good for a first iteration, and I think with some tweaks
Re: [Intel-gfx] [PATCH 28/34] drm/i915: Replace global breadcrumbs with per-context interrupt tracking
On 21/01/2019 22:21, Chris Wilson wrote:
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled, without incurring any cpu overhead.
To handle certain fragility of our hw meant that we could not do a
simple check inside the irq handler (some generations required almost
unbounded delays before we could be sure of seqno coherency) and so
request completion checking required delegation.
Before commit 688e6c725816, the solution was simple. Every client waking
on a request would be woken on every interrupt and each would do a
heavyweight check to see if their request was complete. Commit
688e6c725816 introduced an rbtree so that only the earliest waiter on
the global timeline would woken, and would wake the next and so on.
(Along with various complications to handle requests being reordered
along the global timeline, and also a requirement for kthread to provide
a delegate for fence signaling that had no process context.)
The global rbtree depends on knowing the execution timeline (and global
seqno). Without knowing that order, we must instead check all contexts
queued to the HW to see which may have advanced. We trim that list by
only checking queued contexts that are being waited on, but still we
keep a list of all active contexts and their active signalers that we
inspect from inside the irq handler. By moving the waiters onto the fence
signal list, we can combine the client wakeup with the dma_fence
signaling (a dramatic reduction in complexity, but does require the HW
being coherent, the seqno must be visible from the cpu before the
interrupt is raised - we keep a timer backup just in case).
Having previously fixed all the issues with irq-seqno serialisation (by
inserting delays onto the GPU after each request instead of random delays
on the CPU after each interrupt), we can rely on the seqno state to
perfom direct wakeups from the interrupt handler. This allows us to
preserve our single context switch behaviour of the current routine,
with the only downside that we lose the RT priority sorting of wakeups.
In general, direct wakeup latency of multiple clients is about the same
(about 10% better in most cases) with a reduction in total CPU time spent
in the waiter (about 20-50% depending on gen). Average herd behaviour is
improved, but at the cost of not delegating wakeups on task_prio.
References: 688e6c725816 ("drm/i915: Slaughter the thundering i915_wait_request
herd")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 28 +-
drivers/gpu/drm/i915/i915_gem_context.h | 5 +
drivers/gpu/drm/i915/i915_gpu_error.c | 73 --
drivers/gpu/drm/i915/i915_gpu_error.h | 8 -
drivers/gpu/drm/i915/i915_irq.c | 87 +-
drivers/gpu/drm/i915/i915_request.c | 128 +--
drivers/gpu/drm/i915/i915_request.h | 22 +-
drivers/gpu/drm/i915/i915_reset.c | 13 +-
drivers/gpu/drm/i915/intel_breadcrumbs.c | 797 +-
drivers/gpu/drm/i915/intel_engine_cs.c| 34 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 95 +--
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
drivers/gpu/drm/i915/selftests/i915_request.c | 398 +
drivers/gpu/drm/i915/selftests/igt_spinner.c | 5 -
.../drm/i915/selftests/intel_breadcrumbs.c| 470 ---
.../gpu/drm/i915/selftests/intel_hangcheck.c | 2 +-
drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 54 ++
drivers/gpu/drm/i915/selftests/lib_sw_fence.h | 3 +
drivers/gpu/drm/i915/selftests/mock_engine.c | 16 +-
drivers/gpu/drm/i915/selftests/mock_engine.h | 6 -
21 files changed, 774 insertions(+), 1477 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2a6e4044f25b..d7764e62e9b4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1315,29 +1315,16 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
seq_printf(m, "GT active? %s\n", yesno(dev_priv->gt.awake));
for_each_engine(engine, dev_priv, id) {
- struct intel_breadcrumbs *b = &engine->breadcrumbs;
- struct rb_node *rb;
-
seq_printf(m, "%s:\n", engine->name);
seq_printf(m, "\tseqno = %x [current %x, last %x], %dms ago\n",
engine->hangcheck.seqno, seqno[id],
intel_engine_last_submit(engine),
jiffies_to_msecs(jiffies -
engine->hangcheck.action_timestamp));
- seq_printf(m, "\t
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: correct the pitch check for NV12 framebuffer (rev3)
== Series Details ==
Series: drm/i915: correct the pitch check for NV12 framebuffer (rev3)
URL : https://patchwork.freedesktop.org/series/53928/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5468_full -> Patchwork_12011_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12011_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_crc@cursor-64x21-onscreen:
- shard-glk: PASS -> FAIL [fdo#103232] +1
* igt@kms_flip@2x-modeset-vs-vblank-race:
- shard-glk: PASS -> FAIL [fdo#103060]
* igt@kms_flip@modeset-vs-vblank-race:
- shard-hsw: PASS -> DMESG-WARN [fdo#102614]
* igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk: PASS -> FAIL [fdo#108948]
- shard-apl: PASS -> FAIL [fdo#108948]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-none:
- shard-apl: PASS -> FAIL [fdo#103166]
Possible fixes
* igt@i915_suspend@forcewake:
- shard-kbl: INCOMPLETE [fdo#103665] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-kbl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-apl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-glk: FAIL [fdo#103232] -> PASS +1
* igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-glk: FAIL [fdo#105363] -> PASS +1
* igt@kms_flip@dpms-vs-vblank-race:
- shard-kbl: FAIL [fdo#103060] -> PASS
- shard-glk: FAIL [fdo#103060] -> PASS
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: FAIL [fdo#103166] -> PASS +1
* igt@kms_plane_multiple@atomic-pipe-a-tiling-yf:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_setmode@basic:
- shard-hsw: 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#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 4)
--
Missing(3): shard-snb shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5468 -> Patchwork_12011
CI_DRM_5468: fc4e30d30d90ed5d5bd467de0439e9522d34cdf0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4784: 1c5a4432293369f85859c748c08155e79d92c4ce @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12011: 27aba8615f29290773c979725346ee45761a17a0 @
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_12011/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 28/34] drm/i915: Replace global breadcrumbs with per-context interrupt tracking
Quoting Tvrtko Ursulin (2019-01-23 09:21:45)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > -static void error_record_engine_waiters(struct intel_engine_cs *engine,
> > - struct drm_i915_error_engine *ee)
> > -{
> > - struct intel_breadcrumbs *b = &engine->breadcrumbs;
> > - struct drm_i915_error_waiter *waiter;
> > - struct rb_node *rb;
> > - int count;
> > -
> > - ee->num_waiters = 0;
> > - ee->waiters = NULL;
> > -
> > - if (RB_EMPTY_ROOT(&b->waiters))
> > - return;
> > -
> > - if (!spin_trylock_irq(&b->rb_lock)) {
> > - ee->waiters = ERR_PTR(-EDEADLK);
> > - return;
> > - }
> > -
> > - count = 0;
> > - for (rb = rb_first(&b->waiters); rb != NULL; rb = rb_next(rb))
> > - count++;
> > - spin_unlock_irq(&b->rb_lock);
> > -
> > - waiter = NULL;
> > - if (count)
> > - waiter = kmalloc_array(count,
> > -sizeof(struct drm_i915_error_waiter),
> > -GFP_ATOMIC);
> > - if (!waiter)
> > - return;
> > -
> > - if (!spin_trylock_irq(&b->rb_lock)) {
> > - kfree(waiter);
> > - ee->waiters = ERR_PTR(-EDEADLK);
> > - return;
> > - }
> > -
> > - ee->waiters = waiter;
> > - for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
> > - struct intel_wait *w = rb_entry(rb, typeof(*w), node);
> > -
> > - strcpy(waiter->comm, w->tsk->comm);
> > - waiter->pid = w->tsk->pid;
> > - waiter->seqno = w->seqno;
> > - waiter++;
> > -
> > - if (++ee->num_waiters == count)
> > - break;
> > - }
> > - spin_unlock_irq(&b->rb_lock);
> > -}
>
> Capturing context waiters is not interesting for error state?
Not really, we don't have a direct link to the process. We could dig it
out by identifying our special wait_cb inside the fence->signal_list,
but I couldn't be bothered. Who's waiting at the time of the error has
never been that interesting for error debugging, just provides an
overview of the system state.
Who issued the hanging command is much more of interest for the hunting
posse than their victim.
However, storing fence->flag (i.e. the DMA_FENCE_FLAG_SIGNAL_ENABLE_BIT
+ DMA_FENCE_FLAG_SIGNALED_BIT) seems like it would come in handy.
> > -static bool __i915_spin_request(const struct i915_request *rq,
> > - u32 seqno, int state, unsigned long
> > timeout_us)
> > +static bool __i915_spin_request(const struct i915_request * const rq,
> > + int state, unsigned long timeout_us)
> > {
> > - struct intel_engine_cs *engine = rq->engine;
> > - unsigned int irq, cpu;
> > -
> > - GEM_BUG_ON(!seqno);
> > + unsigned int cpu;
> >
> > /*
> >* Only wait for the request if we know it is likely to complete.
> > @@ -1050,7 +1046,7 @@ static bool __i915_spin_request(const struct
> > i915_request *rq,
> >* it is a fair assumption that it will not complete within our
> >* relatively short timeout.
> >*/
> > - if (!intel_engine_has_started(engine, seqno))
> > + if (!i915_request_started(rq))
>
> Might be more wasteful the more preemption is going on. Probably not the
> most important thing to try a fix straight away, but something to put
> down on some to do list.
Actually... That would be cheap to fix here as we do a test_bit(ACTIVE).
Hmm, I wonder if that makes sense for all callers.
Maybe i915_request_is_running(rq) as a followup.
> Above comment is also outdated now (engine order).
I left a comment! Silly me.
> > +enum {
> > + I915_FENCE_FLAG_ACTIVE = DMA_FENCE_FLAG_USER_BITS,
> > + I915_FENCE_FLAG_SIGNAL,
>
> Describe in comments what these mean please.
Mean, you expect them to have meaning outside of their use? :)
> > +bool intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
> > +{
> > + struct intel_breadcrumbs *b = &engine->breadcrumbs;
>
> How can you afford to have this per engine? I guess I might figure out
> later in the patch/series.
Hmm, it's always been per engine... What cost are you considering?
> > + struct intel_context *ce, *cn;
> > + struct i915_request *rq, *rn;
> > + LIST_HEAD(signal);
> > +
> > + spin_lock(&b->irq_lock);
> > +
> > + b->irq_fired = true;
> > + if (b->irq_armed && list_empty(&b->signalers))
> > + __intel_breadcrumbs_disarm_irq(b);
> > +
> > + list_for_each_entry_safe(ce, cn, &b->signalers, signal_link) {
> > + GEM_BUG_ON(list_empty(&ce->signals));
> > +
> > + list_for_each_entry_safe(rq, rn, &ce->signals, signal_link) {
> > + if (!__request_completed(rq))
> > + break;
> > +
> > + GEM_BUG_ON(!test_bit(I915_FENCE_FLAG_SIGNAL,
> > +
Re: [Intel-gfx] [PATCH 13/15] drm/i915/tv: Generate better pipe timings for TV encoder
On Tue, Jan 22, 2019 at 07:34:55PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 22, 2019 at 07:22:24PM +0200, Imre Deak wrote:
> > On Mon, Nov 12, 2018 at 06:59:58PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > To make vblank timestamps work better with the TV encoder let's
> > > scale the pipe timings such that the relationship between the
> > > TV active and TV blanking periods is mirrored in the
> > > corresponding pipe timings.
> > >
> > > Note that in reality the pipe runs at a faster speed during the
> > > TV vblank, and correspondigly there are periods when the pipe
> > > is enitrely stopped. We pretend that this isn't the case and
> > > as such we incur some error in the vblank timestamps during
> > > the TV vblank. Further explanation of the issues in a big
> > > comment in the code.
> > >
> > > This makes the vblank timestamps good enough to make
> > > i965gm (which doesn't have a working frame counter with
> > > the TV encoder) report correct frame numbers. Previously
> > > you could get all kinds of nonsense which resulted in
> > > eg. glxgears reporting that it's running at twice the
> > > actual framerate in most cases.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > > drivers/gpu/drm/i915/intel_tv.c | 322 +++-
> > > 2 files changed, 278 insertions(+), 45 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index fe4b913e46ac..10813ae7bee7 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -4848,6 +4848,7 @@ enum {
> > > # define TV_OVERSAMPLE_NONE (2 << 18)
> > > /* Selects 8x oversampling */
> > > # define TV_OVERSAMPLE_8X(3 << 18)
> > > +# define TV_OVERSAMPLE_MASK (3 << 18)
> > > /* Selects progressive mode rather than interlaced */
> > > # define TV_PROGRESSIVE (1 << 17)
> > > /* Sets the colorburst to PAL mode. Required for non-M PAL modes. */
> > > diff --git a/drivers/gpu/drm/i915/intel_tv.c
> > > b/drivers/gpu/drm/i915/intel_tv.c
> > > index 216525dd144a..75126fce655d 100644
> > > --- a/drivers/gpu/drm/i915/intel_tv.c
> > > +++ b/drivers/gpu/drm/i915/intel_tv.c
> > > @@ -340,7 +340,6 @@ struct tv_mode {
> > > const struct video_levels *composite_levels, *svideo_levels;
> > > const struct color_conversion *composite_color, *svideo_color;
> > > const u32 *filter_table;
> > > - u16 max_srcw;
> > > };
> > >
> > >
> > > @@ -729,7 +728,6 @@ static const struct tv_mode tv_modes[] = {
> > > .burst_ena = false,
> > >
> > > .filter_table = filter_table,
> > > - .max_srcw = 800
> > > },
> > > {
> > > .name = "1080i@50Hz",
> > > @@ -947,13 +945,183 @@ intel_tv_mode_vdisplay(const struct tv_mode
> > > *tv_mode)
> > > return 2 * (tv_mode->nbr_end + 1);
> > > }
> > >
> > > +static void
> > > +intel_tv_mode_to_mode(struct drm_display_mode *mode,
> > > + const struct tv_mode *tv_mode)
> > > +{
> > > + mode->clock = tv_mode->clock /
> > > + (tv_mode->oversample >> !tv_mode->progressive);
> > > +
> > > + /*
> > > + * tv_mode horizontal timings:
> > > + *
> > > + * hsync_end
> > > + *| hblank_end
> > > + *|| hblank_start
> > > + *|| | htotal
> > > + *| ___|
> > > + * / \___
> > > + * \__/\
> > > + */
> > > + mode->hdisplay =
> > > + tv_mode->hblank_start - tv_mode->hblank_end;
> > > + mode->hsync_start = mode->hdisplay +
> > > + tv_mode->htotal - tv_mode->hblank_start;
> > > + mode->hsync_end = mode->hsync_start +
> > > + tv_mode->hsync_end;
> > > + mode->htotal = tv_mode->htotal + 1;
> > > +
> > > + /*
> > > + * tv_mode vertical timings:
> > > + *
> > > + * vsync_start
> > > + *| vsync_end
> > > + *| | vi_end nbr_end
> > > + *| || |
> > > + *| | ___
> > > + * \__/ \
> > > + *\__/
> > > + */
> > > + mode->vdisplay = intel_tv_mode_vdisplay(tv_mode);
> > > + if (tv_mode->progressive) {
> > > + mode->vsync_start = mode->vdisplay +
> > > + tv_mode->vsync_start_f1 + 1;
> > > + mode->vsync_end = mode->vsync_start +
> > > + tv_mode->vsync_len;
> > > + mode->vtotal = mode->vdisplay +
> > > + tv_mode->vi_end_f1 + 1;
> > > + } else {
> > > + mode->vsync_start = mode->vdisplay +
> > > + tv_mode->vsync_start_f1 + 1 +
> > > + tv_mode->vsync_start_f2 + 1;
> > > + mode->vsync_end = mode->vsync_start +
> > > + 2 * tv_mode->vsync_len;
> > > + mode->vtotal = mode->vdisplay +
> > > + tv_mode->vi_end_f1 + 1 +
> > > + tv_mode->vi_end_f2 + 1;
> > > + }
> > > +
> > > + /* TV has it's own notion of
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/modes: Prevent division by zero htotal
== Series Details ==
Series: drm/modes: Prevent division by zero htotal
URL : https://patchwork.freedesktop.org/series/55610/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5468_full -> Patchwork_12012_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12012_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_wait@write-busy-bsd:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_cursor_crc@cursor-256x85-onscreen:
- shard-glk: PASS -> FAIL [fdo#103232] +1
* igt@kms_flip@2x-modeset-vs-vblank-race:
- shard-hsw: PASS -> DMESG-WARN [fdo#102614]
* igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk: PASS -> FAIL [fdo#108948]
- shard-apl: PASS -> FAIL [fdo#108948]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166]
Possible fixes
* igt@i915_suspend@forcewake:
- shard-kbl: INCOMPLETE [fdo#103665] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-hsw: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-glk: FAIL [fdo#105363] -> PASS +1
* igt@kms_flip@dpms-vs-vblank-race:
- shard-kbl: FAIL [fdo#103060] -> PASS
- shard-glk: FAIL [fdo#103060] -> PASS
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: FAIL [fdo#103166] -> PASS +2
* igt@kms_plane_multiple@atomic-pipe-c-tiling-none:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-apl: DMESG-FAIL [fdo#108950] -> PASS
Warnings
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-glk: DMESG-FAIL [fdo#105763] / [fdo#106538] -> FAIL
[fdo#109381]
{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#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
[fdo#106538]: https://bugs.freedesktop.org/show_bug.cgi?id=106538
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948
[fdo#108950]: https://bugs.freedesktop.org/show_bug.cgi?id=108950
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109381]: https://bugs.freedesktop.org/show_bug.cgi?id=109381
Participating hosts (7 -> 4)
--
Missing(3): shard-snb shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5468 -> Patchwork_12012
CI_DRM_5468: fc4e30d30d90ed5d5bd467de0439e9522d34cdf0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4784: 1c5a4432293369f85859c748c08155e79d92c4ce @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12012: daea462cce0cd3d56ab143701960bf39acef551c @
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_12012/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/modes: Prevent division by zero htotal
On Wed, Jan 23, 2019 at 03:28:59PM +0800, Tina Zhang wrote: > This patch prevents division by zero htotal. How did you manage to get here with htotal == 0? This needs backtraces (or if this is just about static checkers, a mention of that). -Daniel > > Signed-off-by: Tina Zhang > Cc: Adam Jackson > Cc: Dave Airlie > Cc: Daniel Vetter > --- > drivers/gpu/drm/drm_modes.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index adce9a2..59b92b1 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -751,7 +751,7 @@ int drm_mode_hsync(const struct drm_display_mode *mode) > if (mode->hsync) > return mode->hsync; > > - if (mode->htotal < 0) > + if (mode->htotal <= 0) > return 0; > > calc_val = (mode->clock * 1000) / mode->htotal; /* hsync in Hz */ > -- > 2.7.4 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi Dave, Daniel, Here is the PR for drm-misc-next for this week. Let me know if there's anything wrong. Thanks! Maxime drm-misc-next-2019-01-23: drm-misc-next for 5.1: UAPI Changes: - Addition of the Allwinner tiled format modifier Cross-subsystem Changes: Core Changes: - dma-buf documentation improvements - Removal of now unused fbdev helpers - Addition of new drm fbdev helpers - Improvements to tinydrm - Addition of new drm_fourcc helpers - Impromevents to i2c-over-aux to handle I2C_M_STOP Driver Changes: - Add support for the TI DS90C185 LVDS bridge - Improvements to the thc63lvdm83d bridge - Improvements to sun4i YUV and scaler support - Fix to the powerdown sequence of panel-innolux The following changes since commit 94520db52fc0e931327bb77fe79a952a0e9dd2b0: drm: fix alpha build after drm_util.h change (2019-01-16 11:16:17 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-01-23 for you to fetch changes up to 46f3ceaffa81e846677bca8668e0ad40e643cffd: drm/panel: panel-innolux: set display off in innolux_panel_unprepare (2019-01-22 16:49:15 -0500) drm-misc-next for 5.1: UAPI Changes: - Addition of the Allwinner tiled format modifier Cross-subsystem Changes: Core Changes: - dma-buf documentation improvements - Removal of now unused fbdev helpers - Addition of new drm fbdev helpers - Improvements to tinydrm - Addition of new drm_fourcc helpers - Impromevents to i2c-over-aux to handle I2C_M_STOP Driver Changes: - Add support for the TI DS90C185 LVDS bridge - Improvements to the thc63lvdm83d bridge - Improvements to sun4i YUV and scaler support - Fix to the powerdown sequence of panel-innolux Hsin-Yi, Wang (1): drm/panel: panel-innolux: set display off in innolux_panel_unprepare Jani Nikula (1): drm/dp: use DRM_DEBUG_DP() instead of drm_dbg for logging Jonathan Corbet (1): dma-buf: Fix kerneldoc comment for struct dma_fence_array Maxime Ripard (5): drm/sun4i: Move access control before setting the register as documented drm/sun4i: frontend: Add a quirk structure drm/sun4i: Set the coef_rdy bit right after the coef have been set drm/sun4i: Make COEF_RDY conditional drm/sun4i: frontend: Move the FIR filter phases to our quirks Noralf Trønnes (6): drm/cma-helper: Remove unused fbdev code drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty() drm/damage-helper: Add drm_atomic_helper_damage_merged() drm/tinydrm: Use struct drm_rect drm/tinydrm: Use damage helper for dirtyfb drm/todo: Tick off some tinydrm entries Paul Kocialkowski (18): drm/fourcc: Add format info helpers for checking YUV planes disposition drm/fourcc: Add format info helpers for checking YUV sub-sampling drm/sun4i: backend: Use explicit fourcc helpers for packed YUV422 check drm/sun4i: frontend: Pass DRM format info to input format helpers drm/sun4i: frontend: Determine input format based on colorspace drm/sun4i: Move the BT.601 CSC coefficients to the frontend drm/sun4i: frontend: Configure and enable YUV to RGB CSC when needed drm/sun4i: frontend: Add support for packed YUV422 input formats drm/sun4i: frontend: Add support for semi-planar YUV input formats drm/sun4i: frontend: Add support for planar YUV input formats drm/fourcc: Add definitions for Allwinner vendor and VPU tiled format drm/sun4i: frontend: Add support for tiled YUV input mode configuration drm/sun4i: Add buffer stride and offset configuration for tiling mode drm/sun4i: frontend: Add and use helper for checking tiling support drm/sun4i: layer: Add tiled modifier support and helper drm/sun4i: drv: Allow framebuffer modifiers in mode config drm/sun4i: frontend: Hook-in support for the A10, with specific quirks drm/sun4i: frontend: Hook-in support for the A20 Peter Rosin (5): dt-bindings: display: bridge: fork out ti, ds90c185 from lvds-transmitter dt-bindings: display: bridge: lvds-transmitter: cleanup example dt-bindings: display: bridge: thc63lvdm83d: use standard powerdown-gpios drm/bridge: lvds-encoder: add dev helper variable in .probe() drm/bridge: lvds-encoder: add powerdown-gpios support Sam Ravnborg (1): drm: fix drm_can_sleep() comment Ville Syrjälä (1): drm/dp: Implement I2C_M_STOP for i2c-over-aux YueHaibing (1): drm/stm: ltdc: remove set but not used variable 'src_h' .../bindings/display/bridge/lvds-transmitter.txt | 12 +- .../bindings/display/bridge/thine,thc63lvdm83d.txt | 2 +- .../bindings/display/bridge/ti,ds90c185.txt| 55 Documentation/gpu/todo.rst | 35 -- drivers/gpu/drm/Kconfig| 4 - drivers/gpu/drm/b
[Intel-gfx] [PATCH 3/3] lib: Introduce test_stackinit module
Adds test for stack initialization coverage. We have several build options that control the level of stack variable initialization. This test lets us visualize which options cover which cases, and provide tests for options that are currently not available (padding initialization). All options pass the explicit initialization cases and the partial initializers (even with padding): test_stackinit: u8_zero ok test_stackinit: u16_zero ok test_stackinit: u32_zero ok test_stackinit: u64_zero ok test_stackinit: char_array_zero ok test_stackinit: small_hole_zero ok test_stackinit: big_hole_zero ok test_stackinit: packed_zero ok test_stackinit: small_hole_dynamic_partial ok test_stackinit: big_hole_dynamic_partial ok test_stackinit: packed_static_partial ok test_stackinit: small_hole_static_partial ok test_stackinit: big_hole_static_partial ok The results of the other tests (which contain no explicit initialization), change based on the build's configured compiler instrumentation. No options: test_stackinit: small_hole_static_all FAIL (uninit bytes: 3) test_stackinit: big_hole_static_all FAIL (uninit bytes: 61) test_stackinit: small_hole_dynamic_all FAIL (uninit bytes: 3) test_stackinit: big_hole_dynamic_all FAIL (uninit bytes: 61) test_stackinit: small_hole_runtime_partial FAIL (uninit bytes: 23) test_stackinit: big_hole_runtime_partial FAIL (uninit bytes: 127) test_stackinit: small_hole_runtime_all FAIL (uninit bytes: 3) test_stackinit: big_hole_runtime_all FAIL (uninit bytes: 61) test_stackinit: u8 FAIL (uninit bytes: 1) test_stackinit: u16 FAIL (uninit bytes: 2) test_stackinit: u32 FAIL (uninit bytes: 4) test_stackinit: u64 FAIL (uninit bytes: 8) test_stackinit: char_array FAIL (uninit bytes: 16) test_stackinit: small_hole FAIL (uninit bytes: 24) test_stackinit: big_hole FAIL (uninit bytes: 128) test_stackinit: user FAIL (uninit bytes: 32) test_stackinit: failures: 16 CONFIG_GCC_PLUGIN_STRUCTLEAK=y This only tries to initialize structs with __user markings: test_stackinit: small_hole_static_all FAIL (uninit bytes: 3) test_stackinit: big_hole_static_all FAIL (uninit bytes: 61) test_stackinit: small_hole_dynamic_all FAIL (uninit bytes: 3) test_stackinit: big_hole_dynamic_all FAIL (uninit bytes: 61) test_stackinit: small_hole_runtime_partial FAIL (uninit bytes: 23) test_stackinit: big_hole_runtime_partial FAIL (uninit bytes: 127) test_stackinit: small_hole_runtime_all FAIL (uninit bytes: 3) test_stackinit: big_hole_runtime_all FAIL (uninit bytes: 61) test_stackinit: u8 FAIL (uninit bytes: 1) test_stackinit: u16 FAIL (uninit bytes: 2) test_stackinit: u32 FAIL (uninit bytes: 4) test_stackinit: u64 FAIL (uninit bytes: 8) test_stackinit: char_array FAIL (uninit bytes: 16) test_stackinit: small_hole FAIL (uninit bytes: 24) test_stackinit: big_hole FAIL (uninit bytes: 128) test_stackinit: user ok test_stackinit: failures: 15 CONFIG_GCC_PLUGIN_STRUCTLEAK=y CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y This initializes all structures passed by reference (scalars and strings remain uninitialized, but padding is wiped): test_stackinit: small_hole_static_all ok test_stackinit: big_hole_static_all ok test_stackinit: small_hole_dynamic_all ok test_stackinit: big_hole_dynamic_all ok test_stackinit: small_hole_runtime_partial ok test_stackinit: big_hole_runtime_partial ok test_stackinit: small_hole_runtime_all ok test_stackinit: big_hole_runtime_all ok test_stackinit: u8 FAIL (uninit bytes: 1) test_stackinit: u16 FAIL (uninit bytes: 2) test_stackinit: u32 FAIL (uninit bytes: 4) test_stackinit: u64 FAIL (uninit bytes: 8) test_stackinit: char_array FAIL (uninit bytes: 16) test_stackinit: small_hole ok test_stackinit: big_hole ok test_stackinit: user ok test_stackinit: failures: 5 CONFIG_GCC_PLUGIN_STACKINIT=y This initializes all variables, but has no special padding handling: test_stackinit: small_hole_static_all FAIL (uninit bytes: 3) test_stackinit: big_hole_static_all FAIL (uninit bytes: 61) test_stackinit: small_hole_dynamic_all FAIL (uninit bytes: 3) test_stackinit: big_hole_dynamic_all FAIL (uninit bytes: 61) test_stackinit: small_hole_runtime_partial ok test_stackinit: big_hole_runtime_partial ok test_stackinit: small_hole_runtime_all ok test_stackinit: big_hole_runtime_all ok test_stackinit: u8 ok test_stackinit: u16 ok test_stackinit: u32 ok test_stackinit: u64 ok test_stackinit: char_array ok test_stackinit: small_hole ok test_stackinit: big_hole ok test_stackinit: user ok test_stackinit: failures: 4 Signed-off-by: Kees Cook --- lib/Kconfig.debug| 9 ++ lib/Makefile | 1 + lib/test_stackinit.c | 327 +++ 3 files changed, 337 insertions(+) create mode 100644 lib/test_stackinit.c diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index d4df5b24d75e..09788af9 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -2001,6 +2001,15 @@ config TEST_OBJAGG If unsure, say N. +config TEST_STACKINIT + tristate "Test level of stack variabl
[Intel-gfx] [PATCH 0/3] gcc-plugins: Introduce stackinit plugin
This adds a new plugin "stackinit" that attempts to perform unconditional initialization of all stack variables[1]. It has wider effects than GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y since BYREF_ALL does not consider non-structures. A notable weakness is that padding bytes in many cases remain uninitialized since GCC treats these bytes as "undefined". I'm hoping we can improve the compiler (or the plugin) to cover that too. (It's worth noting that BYREF_ALL actually does handle the padding -- I think this is due to the different method of detecting if initialization is needed.) Included is a tree-wide change to move switch variables up and out of their switch and into the top-level variable declarations. Included is a set of test cases for evaluating stack initialization, which checks for padding, different types, etc. Feedback welcome! :) -Kees [1] https://lkml.kernel.org/r/CA+55aFykZL+cSBJjBBts7ebEFfyGPdMzTmLSxKnT_29=j94...@mail.gmail.com Kees Cook (3): treewide: Lift switch variables out of switches gcc-plugins: Introduce stackinit plugin lib: Introduce test_stackinit module arch/x86/xen/enlighten_pv.c | 7 +- drivers/char/pcmcia/cm4000_cs.c | 2 +- drivers/char/ppdev.c | 20 +- drivers/gpu/drm/drm_edid.c| 4 +- drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 4 +- drivers/net/ethernet/intel/e1000/e1000_main.c | 3 +- drivers/tty/n_tty.c | 3 +- drivers/usb/gadget/udc/net2280.c | 5 +- fs/fcntl.c| 3 +- lib/Kconfig.debug | 9 + lib/Makefile | 1 + lib/test_stackinit.c | 327 ++ mm/shmem.c| 5 +- net/core/skbuff.c | 4 +- net/ipv6/ip6_gre.c| 4 +- net/ipv6/ip6_tunnel.c | 4 +- net/openvswitch/flow_netlink.c| 7 +- scripts/Makefile.gcc-plugins | 6 + scripts/gcc-plugins/Kconfig | 9 + scripts/gcc-plugins/gcc-common.h | 11 +- scripts/gcc-plugins/stackinit_plugin.c| 79 + security/tomoyo/common.c | 3 +- security/tomoyo/condition.c | 7 +- security/tomoyo/util.c| 4 +- 25 files changed, 484 insertions(+), 49 deletions(-) create mode 100644 lib/test_stackinit.c create mode 100644 scripts/gcc-plugins/stackinit_plugin.c -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] gcc-plugins: Introduce stackinit plugin
This attempts to duplicate the proposed gcc option -finit-local-vars[1]
in an effort to implement the "always initialize local variables" kernel
development goal[2].
Enabling CONFIG_GCC_PLUGIN_STACKINIT should stop all "uninitialized
stack variable" flaws as long as they don't depend on being zero. :)
[1] https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00615.html
[2]
https://lkml.kernel.org/r/CA+55aFykZL+cSBJjBBts7ebEFfyGPdMzTmLSxKnT_29=j94...@mail.gmail.com
Signed-off-by: Kees Cook
---
scripts/Makefile.gcc-plugins | 6 ++
scripts/gcc-plugins/Kconfig| 9 +++
scripts/gcc-plugins/gcc-common.h | 11 +++-
scripts/gcc-plugins/stackinit_plugin.c | 79 ++
4 files changed, 102 insertions(+), 3 deletions(-)
create mode 100644 scripts/gcc-plugins/stackinit_plugin.c
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 35042d96cf5d..2483121d781c 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -12,6 +12,12 @@ export DISABLE_LATENT_ENTROPY_PLUGIN
gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV) += sancov_plugin.so
+gcc-plugin-$(CONFIG_GCC_PLUGIN_STACKINIT) += stackinit_plugin.so
+ifdef CONFIG_GCC_PLUGIN_STACKINIT
+DISABLE_STACKINIT_PLUGIN += -fplugin-arg-stackinit_plugin-disable
+endif
+export DISABLE_STACKINIT_PLUGIN
+
gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += structleak_plugin.so
gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE) \
+= -fplugin-arg-structleak_plugin-verbose
diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig
index d45f7f36b859..b117fe83f1d3 100644
--- a/scripts/gcc-plugins/Kconfig
+++ b/scripts/gcc-plugins/Kconfig
@@ -66,6 +66,15 @@ config GCC_PLUGIN_LATENT_ENTROPY
* https://grsecurity.net/
* https://pax.grsecurity.net/
+config GCC_PLUGIN_STACKINIT
+ bool "Initialize all stack variables to zero by default"
+ depends on GCC_PLUGINS
+ depends on !GCC_PLUGIN_STRUCTLEAK
+ help
+ This plugin zero-initializes all stack variables. This is more
+ comprehensive than GCC_PLUGIN_STRUCTLEAK, and attempts to
+ duplicate the proposed -finit-local-vars gcc build flag.
+
config GCC_PLUGIN_STRUCTLEAK
bool "Force initialization of variables containing userspace addresses"
# Currently STRUCTLEAK inserts initialization out of live scope of
diff --git a/scripts/gcc-plugins/gcc-common.h b/scripts/gcc-plugins/gcc-common.h
index 552d5efd7cb7..f690b4deeabd 100644
--- a/scripts/gcc-plugins/gcc-common.h
+++ b/scripts/gcc-plugins/gcc-common.h
@@ -76,6 +76,14 @@
#include "c-common.h"
#endif
+#if BUILDING_GCC_VERSION > 4005
+#include "c-tree.h"
+#else
+/* should come from c-tree.h if only it were installed for gcc 4.5... */
+#define C_TYPE_FIELDS_READONLY(TYPE) TREE_LANG_FLAG_1(TYPE)
+extern bool global_bindings_p (void);
+#endif
+
#if BUILDING_GCC_VERSION <= 4008
#include "tree-flow.h"
#else
@@ -158,9 +166,6 @@ void dump_gimple_stmt(pretty_printer *, gimple, int, int);
#define TYPE_NAME_POINTER(node) IDENTIFIER_POINTER(TYPE_NAME(node))
#define TYPE_NAME_LENGTH(node) IDENTIFIER_LENGTH(TYPE_NAME(node))
-/* should come from c-tree.h if only it were installed for gcc 4.5... */
-#define C_TYPE_FIELDS_READONLY(TYPE) TREE_LANG_FLAG_1(TYPE)
-
static inline tree build_const_char_string(int len, const char *str)
{
tree cstr, elem, index, type;
diff --git a/scripts/gcc-plugins/stackinit_plugin.c
b/scripts/gcc-plugins/stackinit_plugin.c
new file mode 100644
index ..41055cd7098e
--- /dev/null
+++ b/scripts/gcc-plugins/stackinit_plugin.c
@@ -0,0 +1,79 @@
+/* SPDX-License: GPLv2 */
+/*
+ * This will zero-initialize local stack variables. (Though structure
+ * padding may remain uninitialized in certain cases.)
+ *
+ * Implements Florian Weimer's "-finit-local-vars" gcc patch as a plugin:
+ * https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00615.html
+ *
+ * Plugin skeleton code thanks to PaX Team.
+ *
+ * Options:
+ * -fplugin-arg-stackinit_plugin-disable
+ */
+
+#include "gcc-common.h"
+
+__visible int plugin_is_GPL_compatible;
+
+static struct plugin_info stackinit_plugin_info = {
+ .version= "20190122",
+ .help = "disable\tdo not activate plugin\n",
+};
+
+static void finish_decl(void *event_data, void *data)
+{
+ tree decl = (tree)event_data;
+ tree type;
+
+ if (TREE_CODE (decl) != VAR_DECL)
+ return;
+
+ if (DECL_EXTERNAL (decl))
+ return;
+
+ if (DECL_INITIAL (decl) != NULL_TREE)
+ return;
+
+ if (global_bindings_p ())
+ return;
+
+ type = TREE_TYPE (decl);
+ if (AGGREGATE_TYPE_P (type))
+ DECL_INITIAL (decl) = build_constructor (type, NULL);
+ else
+ DECL_INITIAL (decl) = fold_convert (type, integer_zero_node);
+}
+
+__visible int plugin_init(struct plugin_name_args *plu
[Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches
Variables declared in a switch statement before any case statements
cannot be initialized, so move all instances out of the switches.
After this, future always-initialized stack variables will work
and not throw warnings like this:
fs/fcntl.c: In function ‘send_sigio_to_task’:
fs/fcntl.c:738:13: warning: statement will never be executed
[-Wswitch-unreachable]
siginfo_t si;
^~
Signed-off-by: Kees Cook
---
arch/x86/xen/enlighten_pv.c | 7 ---
drivers/char/pcmcia/cm4000_cs.c | 2 +-
drivers/char/ppdev.c | 20 ---
drivers/gpu/drm/drm_edid.c| 4 ++--
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
drivers/net/ethernet/intel/e1000/e1000_main.c | 3 ++-
drivers/tty/n_tty.c | 3 +--
drivers/usb/gadget/udc/net2280.c | 5 ++---
fs/fcntl.c| 3 ++-
mm/shmem.c| 5 +++--
net/core/skbuff.c | 4 ++--
net/ipv6/ip6_gre.c| 4 ++--
net/ipv6/ip6_tunnel.c | 4 ++--
net/openvswitch/flow_netlink.c| 7 +++
security/tomoyo/common.c | 3 ++-
security/tomoyo/condition.c | 7 ---
security/tomoyo/util.c| 4 ++--
18 files changed, 45 insertions(+), 46 deletions(-)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index c54a493e139a..a79d4b548a08 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -907,14 +907,15 @@ static u64 xen_read_msr_safe(unsigned int msr, int *err)
static int xen_write_msr_safe(unsigned int msr, unsigned low, unsigned high)
{
int ret;
+#ifdef CONFIG_X86_64
+ unsigned which;
+ u64 base;
+#endif
ret = 0;
switch (msr) {
#ifdef CONFIG_X86_64
- unsigned which;
- u64 base;
-
case MSR_FS_BASE: which = SEGBASE_FS; goto set;
case MSR_KERNEL_GS_BASE:which = SEGBASE_GS_USER; goto set;
case MSR_GS_BASE: which = SEGBASE_GS_KERNEL; goto set;
diff --git a/drivers/char/pcmcia/cm4000_cs.c b/drivers/char/pcmcia/cm4000_cs.c
index 7a4eb86aedac..7211dc0e6f4f 100644
--- a/drivers/char/pcmcia/cm4000_cs.c
+++ b/drivers/char/pcmcia/cm4000_cs.c
@@ -663,6 +663,7 @@ static void monitor_card(struct timer_list *t)
{
struct cm4000_dev *dev = from_timer(dev, t, timer);
unsigned int iobase = dev->p_dev->resource[0]->start;
+ unsigned char flags0;
unsigned short s;
struct ptsreq ptsreq;
int i, atrc;
@@ -731,7 +732,6 @@ static void monitor_card(struct timer_list *t)
}
switch (dev->mstate) {
- unsigned char flags0;
case M_CARDOFF:
DEBUGP(4, dev, "M_CARDOFF\n");
flags0 = inb(REG_FLAGS0(iobase));
diff --git a/drivers/char/ppdev.c b/drivers/char/ppdev.c
index 1ae77b41050a..d77c97e4f996 100644
--- a/drivers/char/ppdev.c
+++ b/drivers/char/ppdev.c
@@ -359,14 +359,19 @@ static int pp_do_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
struct pp_struct *pp = file->private_data;
struct parport *port;
void __user *argp = (void __user *)arg;
+ struct ieee1284_info *info;
+ unsigned char reg;
+ unsigned char mask;
+ int mode;
+ s32 time32[2];
+ s64 time64[2];
+ struct timespec64 ts;
+ int ret;
/* First handle the cases that don't take arguments. */
switch (cmd) {
case PPCLAIM:
{
- struct ieee1284_info *info;
- int ret;
-
if (pp->flags & PP_CLAIMED) {
dev_dbg(&pp->pdev->dev, "you've already got it!\n");
return -EINVAL;
@@ -517,15 +522,6 @@ static int pp_do_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
port = pp->pdev->port;
switch (cmd) {
- struct ieee1284_info *info;
- unsigned char reg;
- unsigned char mask;
- int mode;
- s32 time32[2];
- s64 time64[2];
- struct timespec64 ts;
- int ret;
-
case PPRSTATUS:
reg = parport_read_status(port);
if (copy_to_user(argp, ®, sizeof(reg)))
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b506e3622b08..8f93956c1628 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3942,12 +3942,12 @@ static void drm_edid_to_eld(struct drm_connector
*connector, struct edid *edid)
}
for_each_cea_db(cea, i, start, end) {
+ int sad_count;
+
db = &cea[i];
[Intel-gfx] ✗ Fi.CI.BAT: failure for gcc-plugins: Introduce stackinit plugin
== Series Details == Series: gcc-plugins: Introduce stackinit plugin URL : https://patchwork.freedesktop.org/series/55630/ State : failure == Summary == Applying: treewide: Lift switch variables out of switches Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_edid.c M drivers/gpu/drm/i915/intel_display.c M drivers/gpu/drm/i915/intel_pm.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_pm.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_pm.c Auto-merging drivers/gpu/drm/i915/intel_display.c Auto-merging drivers/gpu/drm/drm_edid.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 treewide: Lift switch variables out of switches When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 28/38] drm/i915: Create/destroy VM (ppGTT) for use with contexts
On 18/01/2019 14:00, Chris Wilson wrote:
In preparation to making the ppGTT binding for a context explicit (to
facilitate reusing the same ppGTT between different contexts), allow the
user to create and destroy named ppGTT.
Needs some more text to explain uAPI usage, or even better kerneldoc in
i915_drm.h.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_gem_context.c | 83 +
drivers/gpu/drm/i915/i915_gem_context.h | 5 ++
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +
include/uapi/drm/i915_drm.h | 10 +++
6 files changed, 105 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f462a4d28af4..56bd087f1c4e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -3003,6 +3003,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG,
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_VM_CREATE, i915_gem_vm_create_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_VM_DESTROY, i915_gem_vm_destroy_ioctl,
DRM_RENDER_ALLOW),
};
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 74bccb153359..cb11c23823c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -217,6 +217,9 @@ struct drm_i915_file_private {
} mm;
struct idr context_idr;
+ struct mutex vm_lock;
+ struct idr vm_idr;
+
struct intel_rps_client {
atomic_t boosts;
} rps_client;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index e8334c4bc130..7c90981704bf 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -598,19 +598,29 @@ static int context_idr_cleanup(int id, void *p, void
*data)
return 0;
}
+static int vm_idr_cleanup(int id, void *p, void *data)
+{
+ i915_ppgtt_put(p);
+ return 0;
+}
+
int i915_gem_context_open(struct drm_i915_private *i915,
struct drm_file *file)
{
struct drm_i915_file_private *file_priv = file->driver_priv;
struct i915_gem_context *ctx;
+ mutex_init(&file_priv->vm_lock);
+
idr_init(&file_priv->context_idr);
+ idr_init_base(&file_priv->vm_idr, 1);
mutex_lock(&i915->drm.struct_mutex);
ctx = i915_gem_create_context(i915, file_priv);
mutex_unlock(&i915->drm.struct_mutex);
if (IS_ERR(ctx)) {
idr_destroy(&file_priv->context_idr);
+ idr_destroy(&file_priv->vm_idr);
return PTR_ERR(ctx);
}
@@ -627,6 +637,79 @@ void i915_gem_context_close(struct drm_file *file)
idr_for_each(&file_priv->context_idr, context_idr_cleanup, NULL);
idr_destroy(&file_priv->context_idr);
+
+ idr_for_each(&file_priv->vm_idr, vm_idr_cleanup, NULL);
+ idr_destroy(&file_priv->vm_idr);
+
+ mutex_destroy(&file_priv->vm_lock);
+}
+
+int i915_gem_vm_create_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct drm_i915_gem_vm_create *args = data;
+ struct drm_i915_file_private *file_priv = file->driver_priv;
+ struct i915_hw_ppgtt *ppgtt;
+ int err;
+
+ if (!HAS_FULL_PPGTT(i915))
+ return -ENODEV;
+
+ if (args->flags)
+ return -EINVAL;
+
+ if (args->extensions)
+ return -EINVAL;
+
+ ppgtt = i915_ppgtt_create(i915, file_priv);
+ if (IS_ERR(ppgtt))
+ return PTR_ERR(ppgtt);
+
+ err = mutex_lock_interruptible(&file_priv->vm_lock);
+ if (err)
+ goto err_put;
+
+ err = idr_alloc(&file_priv->vm_idr, ppgtt, 0, 0, GFP_KERNEL);
+ mutex_unlock(&file_priv->vm_lock);
+ if (err < 0)
+ goto err_put;
else if (GEM_WARN_ON(err == 0) {
err = -EINVAL;
goto err_put;
}
?
Or a GEM_BUG_ON(err == 0) if you must. :)
+
+ ppgtt->user_handle = err;
+ args->id = err;
+ return 0;
+
+err_put:
+ i915_ppgtt_put(ppgtt);
+ return err;
+}
+
+int i915_gem_vm_destroy_ioctl(struct drm_device *dev, void *data,
Can we cheat and declare data as u32 * here and so avoid need for the
local, since there are only two dereferences?
+ struct drm_file *file)
+{
+ struct drm_i915_file_private *file_priv = file->driver_priv;
+
[Intel-gfx] [PATCH] drm/i915: Replace global breadcrumbs with per-context interrupt tracking
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled, without incurring any cpu overhead.
To handle certain fragility of our hw meant that we could not do a
simple check inside the irq handler (some generations required almost
unbounded delays before we could be sure of seqno coherency) and so
request completion checking required delegation.
Before commit 688e6c725816, the solution was simple. Every client waking
on a request would be woken on every interrupt and each would do a
heavyweight check to see if their request was complete. Commit
688e6c725816 introduced an rbtree so that only the earliest waiter on
the global timeline would woken, and would wake the next and so on.
(Along with various complications to handle requests being reordered
along the global timeline, and also a requirement for kthread to provide
a delegate for fence signaling that had no process context.)
The global rbtree depends on knowing the execution timeline (and global
seqno). Without knowing that order, we must instead check all contexts
queued to the HW to see which may have advanced. We trim that list by
only checking queued contexts that are being waited on, but still we
keep a list of all active contexts and their active signalers that we
inspect from inside the irq handler. By moving the waiters onto the fence
signal list, we can combine the client wakeup with the dma_fence
signaling (a dramatic reduction in complexity, but does require the HW
being coherent, the seqno must be visible from the cpu before the
interrupt is raised - we keep a timer backup just in case).
Having previously fixed all the issues with irq-seqno serialisation (by
inserting delays onto the GPU after each request instead of random delays
on the CPU after each interrupt), we can rely on the seqno state to
perfom direct wakeups from the interrupt handler. This allows us to
preserve our single context switch behaviour of the current routine,
with the only downside that we lose the RT priority sorting of wakeups.
In general, direct wakeup latency of multiple clients is about the same
(about 10% better in most cases) with a reduction in total CPU time spent
in the waiter (about 20-50% depending on gen). Average herd behaviour is
improved, but at the cost of not delegating wakeups on task_prio.
v2: Capture fence signaling state for error state and add comments to
warm even the most cold of hearts.
v3: Check if the request is still active before busywaiting
References: 688e6c725816 ("drm/i915: Slaughter the thundering i915_wait_request
herd")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 28 +-
drivers/gpu/drm/i915/i915_gem_context.h | 5 +
drivers/gpu/drm/i915/i915_gpu_error.c | 83 +-
drivers/gpu/drm/i915/i915_gpu_error.h | 9 +-
drivers/gpu/drm/i915/i915_irq.c | 87 +-
drivers/gpu/drm/i915/i915_request.c | 140 +--
drivers/gpu/drm/i915/i915_request.h | 72 +-
drivers/gpu/drm/i915/i915_reset.c | 13 +-
drivers/gpu/drm/i915/intel_breadcrumbs.c | 811 +-
drivers/gpu/drm/i915/intel_engine_cs.c| 34 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 94 +-
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
drivers/gpu/drm/i915/selftests/i915_request.c | 420 +
drivers/gpu/drm/i915/selftests/igt_spinner.c | 5 -
.../drm/i915/selftests/intel_breadcrumbs.c| 470 --
.../gpu/drm/i915/selftests/intel_hangcheck.c | 2 +-
drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 54 ++
drivers/gpu/drm/i915/selftests/lib_sw_fence.h | 3 +
drivers/gpu/drm/i915/selftests/mock_engine.c | 16 +-
drivers/gpu/drm/i915/selftests/mock_engine.h | 6 -
21 files changed, 877 insertions(+), 1482 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c88cb566fe10..7bcb9cbfeae8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1315,29 +1315,16 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
seq_printf(m, "GT active? %s\n", yesno(dev_priv->gt.awake));
for_each_engine(engine, dev_priv, id) {
- struct intel_breadcrumbs *b = &engine->breadcrumbs;
- struct rb_node *rb;
-
seq_printf(m, "%s:\n", engine->name);
seq_printf(m, "\tseqno = %x [current %x, last %x], %dms ago\n",
engine->hangcheck.seqno, seqno[id],
intel_engine_last_submit(engine),
jiffies_to_msecs(jiffi
Re: [Intel-gfx] [PATCH] drm/i915/icl: do a posting read after irq install
Daniele Ceraolo Spurio writes: > On 1/22/2019 6:32 PM, Daniele Ceraolo Spurio wrote: >> When reading GEN11_GT_INTR_DWx closely after enabling the interrupts >> in gen11_irq_postinstall, the returned value is garbage. This can > > To clarify, this only happens (or at least I've only seen it) during > runtime_resume. > How did you notice? > Daniele > >> cause other parts of the setup code (e.g. gen11_reset_one_iir) to >> think that there are interrupts to be cleared when there are none. >> >> The garbage value is only seen on the first read done after the enable, >> so this looks like a posting issue. Adding a posting read after enabling >> the interrupts does indeed fix the problem. >> >> Note that the posting read has been purposely added outside of >> gen11_master_intr_enable since the issue has only been observed when the >> full interrupt setup is performed. Scary enough that maybe it would have been warranted inside it. But well we know where to escalate if it shows up elsewhere. Acked-by: Mika Kuoppala >> >> Cc: Mika Kuoppala >> Signed-off-by: Daniele Ceraolo Spurio >> --- >> drivers/gpu/drm/i915/i915_irq.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c >> b/drivers/gpu/drm/i915/i915_irq.c >> index 5fd5080c4ccb..7056ae2d1e0e 100644 >> --- a/drivers/gpu/drm/i915/i915_irq.c >> +++ b/drivers/gpu/drm/i915/i915_irq.c >> @@ -4089,6 +4089,7 @@ static int gen11_irq_postinstall(struct drm_device >> *dev) >> I915_WRITE(GEN11_DISPLAY_INT_CTL, GEN11_DISPLAY_IRQ_ENABLE); >> >> gen11_master_intr_enable(dev_priv->regs); >> +POSTING_READ(GEN11_GFX_MSTR_IRQ); >> >> return 0; >> } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 28/38] drm/i915: Create/destroy VM (ppGTT) for use with contexts
Quoting Tvrtko Ursulin (2019-01-23 11:30:39)
> > +int i915_gem_vm_create_ioctl(struct drm_device *dev, void *data,
> > + struct drm_file *file)
> > +{
> > + struct drm_i915_private *i915 = to_i915(dev);
> > + struct drm_i915_gem_vm_create *args = data;
> > + struct drm_i915_file_private *file_priv = file->driver_priv;
> > + struct i915_hw_ppgtt *ppgtt;
> > + int err;
> > +
> > + if (!HAS_FULL_PPGTT(i915))
> > + return -ENODEV;
> > +
> > + if (args->flags)
> > + return -EINVAL;
> > +
> > + if (args->extensions)
> > + return -EINVAL;
> > +
> > + ppgtt = i915_ppgtt_create(i915, file_priv);
> > + if (IS_ERR(ppgtt))
> > + return PTR_ERR(ppgtt);
> > +
> > + err = mutex_lock_interruptible(&file_priv->vm_lock);
> > + if (err)
> > + goto err_put;
> > +
> > + err = idr_alloc(&file_priv->vm_idr, ppgtt, 0, 0, GFP_KERNEL);
> > + mutex_unlock(&file_priv->vm_lock);
> > + if (err < 0)
> > + goto err_put;
>
> else if (GEM_WARN_ON(err == 0) {
> err = -EINVAL;
> goto err_put;
> }
>
> ?
>
> Or a GEM_BUG_ON(err == 0) if you must. :)
Not our bug :) We told it never to return 0.
> > +
> > + ppgtt->user_handle = err;
> > + args->id = err;
> > + return 0;
> > +
> > +err_put:
> > + i915_ppgtt_put(ppgtt);
> > + return err;
> > +}
> > +
> > +int i915_gem_vm_destroy_ioctl(struct drm_device *dev, void *data,
>
> Can we cheat and declare data as u32 * here and so avoid need for the
> local, since there are only two dereferences?
Tempting, we need to cook up the macros to hide the function pointer
differences for the ioctl tables.
> > + struct drm_file *file)
> > +{
> > + struct drm_i915_file_private *file_priv = file->driver_priv;
> > + struct i915_hw_ppgtt *ppgtt;
> > + int err;
> > + u32 id;
> > +
> > + id = *(u32 *)data;
Oh crikey, did I write this?
Remember, do it right the first time as I won't remember when I was
cutting corners.
> > + if (!id)
> > + return -ENOENT;
> > +
> > + err = mutex_lock_interruptible(&file_priv->vm_lock);
> > + if (err)
> > + return err;
> > +
> > + ppgtt = idr_remove(&file_priv->vm_idr, id);
> > + if (ppgtt)
>
> GEM_WARN_ON(id != ppgtt->user_handle) too much paranoia?
BUG_ON then!
> > + ppgtt->user_handle = 0;
> > +
> > + mutex_unlock(&file_priv->vm_lock);
> > + if (!ppgtt)
> > + return -ENOENT;
> > +
> > + i915_ppgtt_put(ppgtt);
> > + return 0;
>
> Or end with simply:
>
> i915_ppgtt_put(ppgtt);
>
> return ppgtt ? 0 : -ENOENT;
>
> ?
I feel a slight disappointment at the anticlimatic nature of this
function, leaving a gap, nay, a yearning, for more.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches
On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
>
> fs/fcntl.c: In function ‘send_sigio_to_task’:
> fs/fcntl.c:738:13: warning: statement will never be executed
> [-Wswitch-unreachable]
>siginfo_t si;
> ^~
That's a pain, so this means we can't have any new variables in { }
scope except for at the top of a function?
That's going to be a hard thing to keep from happening over time, as
this is valid C :(
greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/34] drm/i915/execlists: Mark up priority boost on preemption (rev2)
== Series Details ==
Series: series starting with [01/34] drm/i915/execlists: Mark up priority boost
on preemption (rev2)
URL : https://patchwork.freedesktop.org/series/55528/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a3cfcd69db36 drm/i915/execlists: Mark up priority boost on preemption
10d459a62e38 drm/i915/execlists: Suppress preempting self
-:18: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#18:
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the
current context")
-:18: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit a2bf92e8cc16
("drm/i915/execlists: Avoid kicking priority on the current context")'
#18:
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the
current context")
total: 1 errors, 1 warnings, 0 checks, 92 lines checked
dcf4a4c2fe84 drm/i915: Make all GPU resets atomic
-:24: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.txt
#24: FILE: drivers/gpu/drm/i915/i915_reset.c:147:
+ udelay(50);
-:30: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.txt
#30: FILE: drivers/gpu/drm/i915/i915_reset.c:152:
+ udelay(50);
total: 0 errors, 0 warnings, 2 checks, 111 lines checked
4a03a5667d92 drm/i915/guc: Disable global reset
3476465681a2 drm/i915: Remove GPU reset dependence on struct_mutex
-:878: WARNING:MEMORY_BARRIER: memory barrier without comment
#878: FILE: drivers/gpu/drm/i915/i915_reset.c:692:
+ smp_store_mb(i915->gpu_error.restart, NULL);
-:1031: WARNING:IF_0: Consider removing the code enclosed by this #if 0 and its
#endif
#1031: FILE: drivers/gpu/drm/i915/i915_reset.c:920:
+#if 0
-:1302: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool
bitfields as unsigned int or u<8|16|32>
#1302: FILE: drivers/gpu/drm/i915/intel_hangcheck.c:35:
+ bool wedged:1;
-:1303: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool
bitfields as unsigned int or u<8|16|32>
#1303: FILE: drivers/gpu/drm/i915/intel_hangcheck.c:36:
+ bool stalled:1;
total: 0 errors, 4 warnings, 0 checks, 1729 lines checked
12191ab875dc drm/i915/selftests: Trim struct_mutex duration for set-wedged
selftest
00a3c0fb6b45 drm/i915: Issue engine resets onto idle engines
399e8162cc6e drm/i915: Stop tracking MRU activity on VMA
efdf8e2689a2 drm/i915: Pull VM lists under the VM mutex.
a1a65ee34602 drm/i915: Move vma lookup to its own lock
-:161: WARNING:USE_SPINLOCK_T: struct spinlock should be spinlock_t
#161: FILE: drivers/gpu/drm/i915/i915_gem_object.h:94:
+ struct spinlock lock;
total: 0 errors, 1 warnings, 0 checks, 290 lines checked
da04ace11678 drm/i915: Always allocate an object/vma for the HWSP
a1911268d4ef drm/i915: Move list of timelines under its own lock
951f23aae0b5 drm/i915: Introduce concept of per-timeline (context) HWSP
095b07e9d68d drm/i915: Enlarge vma->pin_count
0747da7f8236 drm/i915: Allocate a status page for each timeline
e19bdb2707c7 drm/i915: Share per-timeline HWSP using a slab suballocator
-:80: CHECK:SPACING: No space is necessary after a cast
#80: FILE: drivers/gpu/drm/i915/i915_timeline.c:44:
+ BUILD_BUG_ON(BITS_PER_TYPE(u64) * CACHELINE_BYTES > PAGE_SIZE);
total: 0 errors, 0 warnings, 1 checks, 416 lines checked
e996dc446d99 drm/i915: Track the context's seqno in its own timeline HWSP
-:225: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#225: FILE: drivers/gpu/drm/i915/intel_lrc.c:2073:
}
+static const int gen8_emit_breadcrumb_sz = 10 + WA_TAIL_DWORDS;
-:256: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#256: FILE: drivers/gpu/drm/i915/intel_lrc.c:2099:
}
+static const int gen8_emit_breadcrumb_rcs_sz = 14 + WA_TAIL_DWORDS;
-:282: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#282: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:344:
}
+static const int gen6_rcs_emit_breadcrumb_sz = 18;
-:305: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#305: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:451:
}
+static const int gen7_rcs_emit_breadcrumb_sz = 10;
-:326: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#326: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:469:
}
+static const int gen6_xcs_emit_breadcrumb_sz = 8;
-:354: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#354: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:499:
}
+static const int gen7_xcs_emit_breadcrumb_sz = 10 + GEN7_XCS_WA * 3;
-:404: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#404: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:945:
}
+static const int
Re: [Intel-gfx] [PATCH] drm/i915/icl: do a posting read after irq install
Chris Wilson writes: > Quoting Daniele Ceraolo Spurio (2019-01-23 02:32:27) >> When reading GEN11_GT_INTR_DWx closely after enabling the interrupts >> in gen11_irq_postinstall, the returned value is garbage. This can >> cause other parts of the setup code (e.g. gen11_reset_one_iir) to >> think that there are interrupts to be cleared when there are none. >> >> The garbage value is only seen on the first read done after the enable, >> so this looks like a posting issue. Adding a posting read after enabling >> the interrupts does indeed fix the problem. >> >> Note that the posting read has been purposely added outside of >> gen11_master_intr_enable since the issue has only been observed when the >> full interrupt setup is performed. >> >> Cc: Mika Kuoppala >> Signed-off-by: Daniele Ceraolo Spurio > > irq regs and flushing stale results (side effect or double buffering? or > maybe latching?), seem to go hand in hand. > > Acked-by: Chris Wilson Pushed. Thank you for patch and ack. -Mika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/38] drm/i915: Expose user control over the ppGTT associated with a context
On 18/01/2019 14:01, Chris Wilson wrote:
Allow the user to share ppGTT between contexts on the same fd. This
gives the user the ability to relax their context isolation to share vm
between their own contexts, but does not allow them to import a vm from
another fd. The use case for sharing a vm is for the proposed virtual
engine work where a context may be created explicitly to setup a load
balancing engine, but always be run in conjunction with a second context
for rcs/compute etc. By giving control to the user on how they setup the
vm allows for them to have a single vm between all kernel contexts being
used to emulate a single client context, similarly to how we use a
single vm across all engines within a single kernel context today. It
also allows for future specification a separate vm between engines
inside a single kernel context should that be desired.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 118 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 17 +-
drivers/gpu/drm/i915/i915_gem_gtt.h | 14 +-
drivers/gpu/drm/i915/selftests/huge_pages.c | 1 -
.../gpu/drm/i915/selftests/i915_gem_context.c | 247 ++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 1 -
drivers/gpu/drm/i915/selftests/mock_context.c | 8 +-
include/uapi/drm/i915_drm.h | 1 +
8 files changed, 339 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 7c90981704bf..f707241dbc78 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -109,6 +109,8 @@ static void lut_close(struct i915_gem_context *ctx)
struct i915_vma *vma = rcu_dereference_raw(*slot);
radix_tree_iter_delete(&ctx->handles_vma, &iter, slot);
+
+ vma->open_count--;
I did not figure out what is this. A) why open coded vma management
without any comments, and b) rest of the patch doesn't seem to touch
this tree.
__i915_gem_object_release_unless_active(vma->obj);
}
rcu_read_unlock();
@@ -291,7 +293,7 @@ static void context_close(struct i915_gem_context *ctx)
*/
lut_close(ctx);
if (ctx->ppgtt)
- i915_ppgtt_close(&ctx->ppgtt->vm);
+ i915_ppgtt_close(ctx->ppgtt);
I'll need to figure out if it is okay for context to close the ppgtt
instead of just dropping references to it. Like two contexts sharing
ppgtt and one closes it, the other one should continue to work fine, no?
Or even a third context is created sharing the same ppgtt.
ctx->file_priv = ERR_PTR(-EBADF);
i915_gem_context_put(ctx);
@@ -401,6 +403,23 @@ static void __destroy_hw_context(struct i915_gem_context
*ctx,
context_close(ctx);
}
+static void __set_ppgtt(struct i915_gem_context *ctx,
+ struct i915_hw_ppgtt *ppgtt)
+{
+ if (ppgtt == ctx->ppgtt)
+ return;
+
+ if (ctx->ppgtt) {
+ i915_ppgtt_close(ctx->ppgtt);
Feels incorrect to close it if it could be shared and in use elsewhere.
+ i915_ppgtt_put(ctx->ppgtt);
+ }
+
+ i915_ppgtt_open(ppgtt);
Do we need some protection against trying to re-open a closed ppgtt here?
+ ctx->ppgtt = i915_ppgtt_get(ppgtt);
+
+ ctx->desc_template = default_desc_template(ctx->i915, ppgtt);
+}
+
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *dev_priv,
struct drm_i915_file_private *file_priv)
@@ -427,8 +446,8 @@ i915_gem_create_context(struct drm_i915_private *dev_priv,
return ERR_CAST(ppgtt);
}
- ctx->ppgtt = ppgtt;
- ctx->desc_template = default_desc_template(dev_priv, ppgtt);
+ __set_ppgtt(ctx, ppgtt);
+ i915_ppgtt_put(ppgtt);
}
trace_i915_context_create(ctx);
@@ -784,6 +803,87 @@ int i915_gem_switch_to_kernel_context(struct
drm_i915_private *i915)
return 0;
}
+static int get_ppgtt(struct i915_gem_context *ctx, u64 *out)
u32 *out ?
+{
+ struct drm_i915_file_private *file_priv = ctx->file_priv;
+ struct i915_hw_ppgtt *ppgtt;
+ int ret;
+
+ /* XXX rcu acquire? */
+ ppgtt = ctx->ppgtt;
+ if (!ppgtt)
+ return -ENODEV;
+
+ ret = mutex_lock_interruptible(&file_priv->vm_lock);
+ if (ret)
+ return ret;
+
+ ret = ppgtt->user_handle;
+ if (!ret) {
+ ret = idr_alloc(&file_priv->vm_idr, ppgtt, 0, 0, GFP_KERNEL);
GEM_WARN_ON(ret == 0) just in case?
+ if (ret > 0) {
+ ppgtt->user_handle = ret;
+ i915_ppgtt_get(ppgtt);
+ }
+ }
+
+ mutex_unlock(&file_priv->vm_lock);
+ if (ret < 0)
+ return ret;
Re: [Intel-gfx] [PATCH] drm/i915/icl: Adding few more device IDs for Ice Lake
"Souza, Jose" writes: > On Thu, 2019-01-17 at 21:59 -0800, Rodrigo Vivi wrote: >> We just got aware that there was more IDs available >> at spec, so let's add them already. > > Reviewed-by: José Roberto de Souza Pushed. Thank you for patch and review. -Mika > >> >> Cc: James Ausmus >> Cc: José Roberto de Souza >> Signed-off-by: Rodrigo Vivi >> --- >> include/drm/i915_pciids.h | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h >> index 192667144693..df72be7e8b88 100644 >> --- a/include/drm/i915_pciids.h >> +++ b/include/drm/i915_pciids.h >> @@ -457,9 +457,13 @@ >> INTEL_VGA_DEVICE(0x8A51, info), \ >> INTEL_VGA_DEVICE(0x8A5C, info), \ >> INTEL_VGA_DEVICE(0x8A5D, info), \ >> +INTEL_VGA_DEVICE(0x8A59, info), \ >> +INTEL_VGA_DEVICE(0x8A58, info), \ >> INTEL_VGA_DEVICE(0x8A52, info), \ >> INTEL_VGA_DEVICE(0x8A5A, info), \ >> INTEL_VGA_DEVICE(0x8A5B, info), \ >> +INTEL_VGA_DEVICE(0x8A57, info), \ >> +INTEL_VGA_DEVICE(0x8A56, info), \ >> INTEL_VGA_DEVICE(0x8A71, info), \ >> INTEL_VGA_DEVICE(0x8A70, info) >> > ___ > 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 28/38] drm/i915: Create/destroy VM (ppGTT) for use with contexts
On 23/01/2019 11:51, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-23 11:30:39)
+int i915_gem_vm_create_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct drm_i915_gem_vm_create *args = data;
+ struct drm_i915_file_private *file_priv = file->driver_priv;
+ struct i915_hw_ppgtt *ppgtt;
+ int err;
+
+ if (!HAS_FULL_PPGTT(i915))
+ return -ENODEV;
+
+ if (args->flags)
+ return -EINVAL;
+
+ if (args->extensions)
+ return -EINVAL;
+
+ ppgtt = i915_ppgtt_create(i915, file_priv);
+ if (IS_ERR(ppgtt))
+ return PTR_ERR(ppgtt);
+
+ err = mutex_lock_interruptible(&file_priv->vm_lock);
+ if (err)
+ goto err_put;
+
+ err = idr_alloc(&file_priv->vm_idr, ppgtt, 0, 0, GFP_KERNEL);
+ mutex_unlock(&file_priv->vm_lock);
+ if (err < 0)
+ goto err_put;
else if (GEM_WARN_ON(err == 0) {
err = -EINVAL;
goto err_put;
}
?
Or a GEM_BUG_ON(err == 0) if you must. :)
Not our bug :) We told it never to return 0.
+
+ ppgtt->user_handle = err;
+ args->id = err;
+ return 0;
+
+err_put:
+ i915_ppgtt_put(ppgtt);
+ return err;
+}
+
+int i915_gem_vm_destroy_ioctl(struct drm_device *dev, void *data,
Can we cheat and declare data as u32 * here and so avoid need for the
local, since there are only two dereferences?
Tempting, we need to cook up the macros to hide the function pointer
differences for the ioctl tables.
Probably not then, I was hoping that we could get away with function
declaration and definition not being exactly the same and that would be
all that's needed. If not never mind.
Regards,
Tvrtko
+ struct drm_file *file)
+{
+ struct drm_i915_file_private *file_priv = file->driver_priv;
+ struct i915_hw_ppgtt *ppgtt;
+ int err;
+ u32 id;
+
+ id = *(u32 *)data;
Oh crikey, did I write this?
Remember, do it right the first time as I won't remember when I was
cutting corners.
+ if (!id)
+ return -ENOENT;
+
+ err = mutex_lock_interruptible(&file_priv->vm_lock);
+ if (err)
+ return err;
+
+ ppgtt = idr_remove(&file_priv->vm_idr, id);
+ if (ppgtt)
GEM_WARN_ON(id != ppgtt->user_handle) too much paranoia?
BUG_ON then!
+ ppgtt->user_handle = 0;
+
+ mutex_unlock(&file_priv->vm_lock);
+ if (!ppgtt)
+ return -ENOENT;
+
+ i915_ppgtt_put(ppgtt);
+ return 0;
Or end with simply:
i915_ppgtt_put(ppgtt);
return ppgtt ? 0 : -ENOENT;
?
I feel a slight disappointment at the anticlimatic nature of this
function, leaving a gap, nay, a yearning, for more.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/34] drm/i915/execlists: Mark up priority boost on preemption (rev2)
== Series Details == Series: series starting with [01/34] drm/i915/execlists: Mark up priority boost on preemption (rev2) URL : https://patchwork.freedesktop.org/series/55528/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Mark up priority boost on preemption +drivers/gpu/drm/i915/intel_ringbuffer.h:602:23: warning: expression using sizeof(void) Commit: drm/i915/execlists: Suppress preempting self Okay! Commit: drm/i915: Make all GPU resets atomic Okay! Commit: drm/i915/guc: Disable global reset Okay! Commit: drm/i915: Remove GPU reset dependence on struct_mutex -drivers/gpu/drm/i915/selftests/../i915_drv.h:3546:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3541:16: warning: expression using sizeof(void) Commit: drm/i915/selftests: Trim struct_mutex duration for set-wedged selftest Okay! Commit: drm/i915: Issue engine resets onto idle engines Okay! Commit: drm/i915: Stop tracking MRU activity on VMA Okay! Commit: drm/i915: Pull VM lists under the VM mutex. Okay! Commit: drm/i915: Move vma lookup to its own lock Okay! Commit: drm/i915: Always allocate an object/vma for the HWSP Okay! Commit: drm/i915: Move list of timelines under its own lock -drivers/gpu/drm/i915/selftests/../i915_drv.h:3541:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3544:16: warning: expression using sizeof(void) Commit: drm/i915: Introduce concept of per-timeline (context) HWSP Okay! Commit: drm/i915: Enlarge vma->pin_count Okay! Commit: drm/i915: Allocate a status page for each timeline +./include/linux/mm.h:619:13: error: not a function +./include/linux/mm.h:619:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/mm.h:619:13: warning: call with no type! Commit: drm/i915: Share per-timeline HWSP using a slab suballocator -drivers/gpu/drm/i915/selftests/../i915_drv.h:3544:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3548:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_timeline.c:89:38: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_timeline.c:89:38: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_timeline.c:92:44: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_timeline.c:92:44: warning: expression using sizeof(void) +./include/linux/slab.h:664:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/slab.h:664:13: warning: call with no type! Commit: drm/i915: Track the context's seqno in its own timeline HWSP Okay! Commit: drm/i915: Track active timelines Okay! Commit: drm/i915: Identify active requests Okay! Commit: drm/i915: Remove the intel_engine_notify tracepoint Okay! Commit: drm/i915: Replace global breadcrumbs with per-context interrupt tracking +drivers/gpu/drm/i915/selftests/i915_request.c:283:40: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_request.c:283:40: warning: expression using sizeof(void) -./include/linux/mm.h:619:13: error: not a function -./include/linux/mm.h:619:13: error: not a function -./include/linux/mm.h:619:13: error: undefined identifier '__builtin_mul_overflow' -./include/linux/mm.h:619:13: warning: call with no type! +./include/linux/slab.h:664:13: error: not a function +./include/linux/slab.h:664:13: error: not a function Commit: drm/i915: Drop fake breadcrumb irq Okay! Commit: drm/i915: Keep timeline HWSP allocated until the system is idle -drivers/gpu/drm/i915/selftests/../i915_drv.h:3548:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3550:16: warning: expression using sizeof(void) Commit: drm/i915/execlists: Refactor out can_merge_rq() Okay! Commit: drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+ Okay! Commit: drm/i915: Prioritise non-busywait semaphore workloads Okay! Commit: drm/i915: Replace global_seqno with a hangcheck heartbeat seqno Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/38] drm/i915: Expose user control over the ppGTT associated with a context
Quoting Tvrtko Ursulin (2019-01-23 12:00:49)
>
> On 18/01/2019 14:01, Chris Wilson wrote:
> > Allow the user to share ppGTT between contexts on the same fd. This
> > gives the user the ability to relax their context isolation to share vm
> > between their own contexts, but does not allow them to import a vm from
> > another fd. The use case for sharing a vm is for the proposed virtual
> > engine work where a context may be created explicitly to setup a load
> > balancing engine, but always be run in conjunction with a second context
> > for rcs/compute etc. By giving control to the user on how they setup the
> > vm allows for them to have a single vm between all kernel contexts being
> > used to emulate a single client context, similarly to how we use a
> > single vm across all engines within a single kernel context today. It
> > also allows for future specification a separate vm between engines
> > inside a single kernel context should that be desired.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
> > ---
> > drivers/gpu/drm/i915/i915_gem_context.c | 118 -
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 17 +-
> > drivers/gpu/drm/i915/i915_gem_gtt.h | 14 +-
> > drivers/gpu/drm/i915/selftests/huge_pages.c | 1 -
> > .../gpu/drm/i915/selftests/i915_gem_context.c | 247 ++
> > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 1 -
> > drivers/gpu/drm/i915/selftests/mock_context.c | 8 +-
> > include/uapi/drm/i915_drm.h | 1 +
> > 8 files changed, 339 insertions(+), 68 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 7c90981704bf..f707241dbc78 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -109,6 +109,8 @@ static void lut_close(struct i915_gem_context *ctx)
> > struct i915_vma *vma = rcu_dereference_raw(*slot);
> >
> > radix_tree_iter_delete(&ctx->handles_vma, &iter, slot);
> > +
> > + vma->open_count--;
>
> I did not figure out what is this. A) why open coded vma management
> without any comments, and b) rest of the patch doesn't seem to touch
> this tree.
As the vm may be shared between multiple contexts, we may then open the
same vma and record it in the different context lut. Each instance needs
to be accounted for.
> > __i915_gem_object_release_unless_active(vma->obj);
> > }
> > rcu_read_unlock();
> > @@ -291,7 +293,7 @@ static void context_close(struct i915_gem_context *ctx)
> >*/
> > lut_close(ctx);
> > if (ctx->ppgtt)
> > - i915_ppgtt_close(&ctx->ppgtt->vm);
> > + i915_ppgtt_close(ctx->ppgtt);
>
> I'll need to figure out if it is okay for context to close the ppgtt
> instead of just dropping references to it. Like two contexts sharing
> ppgtt and one closes it, the other one should continue to work fine, no?
> Or even a third context is created sharing the same ppgtt.
ppgtt->open_count? We don't close until everyone agrees.
> > ctx->file_priv = ERR_PTR(-EBADF);
> > i915_gem_context_put(ctx);
> > @@ -401,6 +403,23 @@ static void __destroy_hw_context(struct
> > i915_gem_context *ctx,
> > context_close(ctx);
> > }
> >
> > +static void __set_ppgtt(struct i915_gem_context *ctx,
> > + struct i915_hw_ppgtt *ppgtt)
> > +{
> > + if (ppgtt == ctx->ppgtt)
> > + return;
> > +
> > + if (ctx->ppgtt) {
> > + i915_ppgtt_close(ctx->ppgtt);
>
> Feels incorrect to close it if it could be shared and in use elsewhere.
>
> > + i915_ppgtt_put(ctx->ppgtt);
> > + }
> > +
> > + i915_ppgtt_open(ppgtt);
>
> Do we need some protection against trying to re-open a closed ppgtt here?
We BUG_ON as a closed ppgtt shouldn't have been accessible via the file_priv.
> > + ctx->ppgtt = i915_ppgtt_get(ppgtt);
> > +
> > + ctx->desc_template = default_desc_template(ctx->i915, ppgtt);
> > +}
> > +
> > static struct i915_gem_context *
> > i915_gem_create_context(struct drm_i915_private *dev_priv,
> > struct drm_i915_file_private *file_priv)
> > @@ -427,8 +446,8 @@ i915_gem_create_context(struct drm_i915_private
> > *dev_priv,
> > return ERR_CAST(ppgtt);
> > }
> >
> > - ctx->ppgtt = ppgtt;
> > - ctx->desc_template = default_desc_template(dev_priv, ppgtt);
> > + __set_ppgtt(ctx, ppgtt);
> > + i915_ppgtt_put(ppgtt);
> > }
> >
> > trace_i915_context_create(ctx);
> > @@ -784,6 +803,87 @@ int i915_gem_switch_to_kernel_context(struct
> > drm_i915_private *i915)
> > return 0;
> > }
> >
> > +static int get_ppgtt(struct i915_gem_context *ctx, u64 *out)
>
> u32 *out ?
Oh, left over from planning for setting different vm on each engine. In
[Intel-gfx] [PATCH 1/3] drm/i915/execlists: Mark up priority boost on preemption
Record the priority boost we giving to the preempted client or else we
may end up in a situation where the priority queue no longer matches the
request priority order and so we can end up in an infinite loop of
preempting the same pair of requests.
Fixes: e9eaf82d97a2 ("drm/i915: Priority boost for waiting clients")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 436e59724900..8aa8a4862543 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -302,6 +302,7 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
*/
if (!(prio & I915_PRIORITY_NEWCLIENT)) {
prio |= I915_PRIORITY_NEWCLIENT;
+ active->sched.attr.priority = prio;
list_move_tail(&active->sched.link,
i915_sched_lookup_priolist(engine, prio));
}
@@ -625,6 +626,9 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
int i;
priolist_for_each_request_consume(rq, rn, p, i) {
+ GEM_BUG_ON(last &&
+ need_preempt(engine, last, rq_prio(rq)));
+
/*
* Can we combine this request with the current port?
* It has to be the same context/ringbuffer and not
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/execlists: Suppress preempting self
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes a tasklet_schedule triggering the same evaluation to
preempt the active context with itself.
To avoid the extra complications, after deciding that we have
potentially queued a request with higher priority than the currently
executing request, inspect the head of the queue to see if it is indeed
higher priority from another context.
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the
current context")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 20 ++--
drivers/gpu/drm/i915/intel_lrc.c | 67 ---
2 files changed, 76 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 340faea6c08a..fb5d953430e5 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -239,6 +239,18 @@ sched_lock_engine(struct i915_sched_node *node, struct
intel_engine_cs *locked)
return engine;
}
+static bool inflight(const struct i915_request *rq,
+const struct intel_engine_cs *engine)
+{
+ const struct i915_request *active;
+
+ if (!rq->global_seqno)
+ return false;
+
+ active = port_request(engine->execlists.port);
+ return active->hw_context == rq->hw_context;
+}
+
static void __i915_schedule(struct i915_request *rq,
const struct i915_sched_attr *attr)
{
@@ -328,6 +340,7 @@ static void __i915_schedule(struct i915_request *rq,
INIT_LIST_HEAD(&dep->dfs_link);
engine = sched_lock_engine(node, engine);
+ lockdep_assert_held(&engine->timeline.lock);
/* Recheck after acquiring the engine->timeline.lock */
if (prio <= node->attr.priority || node_signaled(node))
@@ -356,17 +369,16 @@ static void __i915_schedule(struct i915_request *rq,
if (prio <= engine->execlists.queue_priority)
continue;
+ engine->execlists.queue_priority = prio;
+
/*
* If we are already the currently executing context, don't
* bother evaluating if we should preempt ourselves.
*/
- if (node_to_request(node)->global_seqno &&
-
i915_seqno_passed(port_request(engine->execlists.port)->global_seqno,
- node_to_request(node)->global_seqno))
+ if (inflight(node_to_request(node), engine))
continue;
/* Defer (tasklet) submission until after all of our updates. */
- engine->execlists.queue_priority = prio;
tasklet_hi_schedule(&engine->execlists.tasklet);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8aa8a4862543..d9d744f6ab2c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -182,12 +182,64 @@ static inline int rq_prio(const struct i915_request *rq)
}
static inline bool need_preempt(const struct intel_engine_cs *engine,
- const struct i915_request *last,
- int prio)
+ const struct i915_request *rq,
+ int q_prio)
{
- return (intel_engine_has_preemption(engine) &&
- __execlists_need_preempt(prio, rq_prio(last)) &&
- !i915_request_completed(last));
+ const struct intel_context *ctx = rq->hw_context;
+ const int last_prio = rq_prio(rq);
+ struct rb_node *rb;
+ int idx;
+
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
+ if (i915_request_completed(rq))
+ return false;
+
+ if (!__execlists_need_preempt(q_prio, last_prio))
+ return false;
+
+ /*
+* The queue_priority is a mere hint that we may need to preempt.
+* If that hint is stale or we may be trying to preempt ourselves,
+* ignore the request.
+*/
+
+ list_for_each_entry_continue(rq, &engine->timeline.requests, link) {
+ GEM_BUG_ON(rq->hw_context == ctx);
+ if (rq_prio(rq) > last_prio)
+ return true;
+ }
+
+ rb = rb_first_cached(&engine->execlists.queue);
+ if (!rb)
+ return false;
+
+ priolist_for_each_request(rq, to_priolist(rb), idx)
+ return rq->hw_context != ctx && rq_prio(rq) > last_prio;
+
+ return false;
+}
+
+__maybe_unused static inline bool
+assert_priority_queue(cons
[Intel-gfx] [PATCH 3/3] drm/i915/execlists: Suppress redundant preemption
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We can avoid this if we take the boost into account when
checking if the preemption request is valid.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d9d744f6ab2c..74726f647e47 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -163,6 +163,8 @@
#define WA_TAIL_DWORDS 2
#define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
+#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT)
+
static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
struct intel_engine_cs *engine,
struct intel_context *ce);
@@ -181,13 +183,31 @@ static inline int rq_prio(const struct i915_request *rq)
return rq->sched.attr.priority;
}
+static inline int active_prio(const struct i915_request *rq)
+{
+ int prio = rq_prio(rq);
+
+ /*
+* On unwinding the active request, we give it a priority bump
+* equivalent to a freshly submitted request. This protects it from
+* being gazumped again, but it would be preferrable if we didn't
+* let it be gazumped in the first place!
+*
+* See __unwind_incomplete_requests()
+*/
+ if (i915_request_started(rq))
+ prio |= ACTIVE_PRIORITY;
+
+ return prio;
+}
+
static inline bool need_preempt(const struct intel_engine_cs *engine,
const struct i915_request *rq,
int q_prio)
{
const struct intel_context *ctx = rq->hw_context;
- const int last_prio = rq_prio(rq);
struct rb_node *rb;
+ int last_prio;
int idx;
if (!intel_engine_has_preemption(engine))
@@ -196,6 +216,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
if (i915_request_completed(rq))
return false;
+ last_prio = active_prio(rq);
if (!__execlists_need_preempt(q_prio, last_prio))
return false;
@@ -320,7 +341,7 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
{
struct i915_request *rq, *rn, *active = NULL;
struct list_head *uninitialized_var(pl);
- int prio = I915_PRIORITY_INVALID | I915_PRIORITY_NEWCLIENT;
+ int prio = I915_PRIORITY_INVALID | ACTIVE_PRIORITY;
lockdep_assert_held(&engine->timeline.lock);
@@ -352,8 +373,8 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
* stream, so give it the equivalent small priority bump to prevent
* it being gazumped a second time by another peer.
*/
- if (!(prio & I915_PRIORITY_NEWCLIENT)) {
- prio |= I915_PRIORITY_NEWCLIENT;
+ if ((prio & ACTIVE_PRIORITY) != ACTIVE_PRIORITY) {
+ prio |= ACTIVE_PRIORITY;
active->sched.attr.priority = prio;
list_move_tail(&active->sched.link,
i915_sched_lookup_priolist(engine, prio));
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/34] drm/i915/execlists: Mark up priority boost on preemption (rev2)
== Series Details ==
Series: series starting with [01/34] drm/i915/execlists: Mark up priority boost
on preemption (rev2)
URL : https://patchwork.freedesktop.org/series/55528/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5469 -> Patchwork_12014
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12014 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12014, 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/55528/revisions/2/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12014:
### IGT changes ###
Possible regressions
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: PASS -> FAIL
Known issues
Here are the changes found in Patchwork_12014 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927]
Possible fixes
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Participating hosts (44 -> 41)
--
Additional (1): fi-hsw-peppy
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5469 -> Patchwork_12014
CI_DRM_5469: 388cbc6121c1bd3d9846789bfef0a3e08c346461 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4785: 70749c70926f12043d3408b160606e1e6238ed3a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12014: 39186577611a8b3fd4cef8a860a6c82dc2c11736 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
39186577611a drm/i915: Replace global_seqno with a hangcheck heartbeat seqno
cb287c2a9e41 drm/i915: Prioritise non-busywait semaphore workloads
4ae5953452b9 drm/i915: Use HW semaphores for inter-engine synchronisation on
gen8+
eca588a4e40b drm/i915/execlists: Refactor out can_merge_rq()
6f083f333e1b drm/i915: Keep timeline HWSP allocated until the system is idle
0e4b16cc65d1 drm/i915: Drop fake breadcrumb irq
779d269c1c4a drm/i915: Replace global breadcrumbs with per-context interrupt
tracking
4ceaaf382a3a drm/i915: Remove the intel_engine_notify tracepoint
c16ba49bd4fb drm/i915: Identify active requests
de57462d995b drm/i915: Track active timelines
e996dc446d99 drm/i915: Track the context's seqno in its own timeline HWSP
e19bdb2707c7 drm/i915: Share per-timeline HWSP using a slab suballocator
0747da7f8236 drm/i915: Allocate a status page for each timeline
095b07e9d68d drm/i915: Enlarge vma->pin_count
951f23aae0b5 drm/i915: Introduce concept of per-timeline (context) HWSP
a1911268d4ef drm/i915: Move list of timelines under its own lock
da04ace11678 drm/i915: Always allocate an object/vma for the HWSP
a1a65ee34602 drm/i915: Move vma lookup to its own lock
efdf8e2689a2 drm/i915: Pull VM lists under the VM mutex.
399e8162cc6e drm/i915: Stop tracking MRU activity on VMA
00a3c0fb6b45 drm/i915: Issue engine resets onto idle engines
12191ab875dc drm/i915/selftests: Trim struct_mutex duration for set-wedged
selftest
3476465681a2 drm/i915: Remove GPU reset dependence on struct_mutex
4a03a5667d92 drm/i915/guc: Disable global reset
dcf4a4c2fe84 drm/i915: Make all GPU resets atomic
10d459a62e38 drm/i915/execlists: Suppress preempting self
a3cfcd69db36 drm/i915/execlists: Mark up priority boost on preemption
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12014/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/34] drm/i915: Remove the intel_engine_notify tracepoint
Quoting Tvrtko Ursulin (2019-01-22 15:50:27)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > The global seqno is defunct and so we have no meaningful indicator of
> > forward progress for an engine. You need to listen to the request
> > signaling tracepoints instead.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 2 --
> > drivers/gpu/drm/i915/i915_trace.h | 25 -
> > 2 files changed, 27 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 5fd5080c4ccb..71d11dc2c235 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1209,8 +1209,6 @@ static void notify_ring(struct intel_engine_cs
> > *engine)
> > wake_up_process(tsk);
> >
> > rcu_read_unlock();
> > -
> > - trace_intel_engine_notify(engine, wait);
> > }
> >
> > static void vlv_c0_read(struct drm_i915_private *dev_priv,
> > diff --git a/drivers/gpu/drm/i915/i915_trace.h
> > b/drivers/gpu/drm/i915/i915_trace.h
> > index 33d90eca9cdd..cb5bc65d575d 100644
> > --- a/drivers/gpu/drm/i915/i915_trace.h
> > +++ b/drivers/gpu/drm/i915/i915_trace.h
> > @@ -750,31 +750,6 @@ trace_i915_request_out(struct i915_request *rq)
> > #endif
> > #endif
> >
> > -TRACE_EVENT(intel_engine_notify,
> > - TP_PROTO(struct intel_engine_cs *engine, bool waiters),
> > - TP_ARGS(engine, waiters),
> > -
> > - TP_STRUCT__entry(
> > - __field(u32, dev)
> > - __field(u16, class)
> > - __field(u16, instance)
> > - __field(u32, seqno)
> > - __field(bool, waiters)
> > - ),
> > -
> > - TP_fast_assign(
> > -__entry->dev = engine->i915->drm.primary->index;
> > -__entry->class = engine->uabi_class;
> > -__entry->instance = engine->instance;
> > -__entry->seqno = intel_engine_get_seqno(engine);
> > -__entry->waiters = waiters;
> > -),
> > -
> > - TP_printk("dev=%u, engine=%u:%u, seqno=%u, waiters=%u",
> > - __entry->dev, __entry->class, __entry->instance,
> > - __entry->seqno, __entry->waiters)
> > -);
> > -
> > DEFINE_EVENT(i915_request, i915_request_retire,
> > TP_PROTO(struct i915_request *rq),
> > TP_ARGS(rq)
> >
>
> I cannot decide if keeping what we can would make it useful. Certainly
> not for debugging intel_engine_breadcrumbs_irq.. a sequence of
> intel_engine_notify(dev, class, instance) -> dma_fence_signaled would be
> a very unreliable trace of what engine actually executed something. What
> do you think?
All we get is a tracepoint to say an user-interrupt occurred, but nothing to
tie it to any request. We are debugging interrupt generation at that
point, and I feel a tracepoint ill-suited. We want something geared
towards CI instead, so a bunch of selftests... That would be sensible!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/34] drm/i915: Remove the intel_engine_notify tracepoint
On 23/01/2019 12:54, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-22 15:50:27)
On 21/01/2019 22:21, Chris Wilson wrote:
The global seqno is defunct and so we have no meaningful indicator of
forward progress for an engine. You need to listen to the request
signaling tracepoints instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 --
drivers/gpu/drm/i915/i915_trace.h | 25 -
2 files changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5fd5080c4ccb..71d11dc2c235 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1209,8 +1209,6 @@ static void notify_ring(struct intel_engine_cs *engine)
wake_up_process(tsk);
rcu_read_unlock();
-
- trace_intel_engine_notify(engine, wait);
}
static void vlv_c0_read(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 33d90eca9cdd..cb5bc65d575d 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -750,31 +750,6 @@ trace_i915_request_out(struct i915_request *rq)
#endif
#endif
-TRACE_EVENT(intel_engine_notify,
- TP_PROTO(struct intel_engine_cs *engine, bool waiters),
- TP_ARGS(engine, waiters),
-
- TP_STRUCT__entry(
- __field(u32, dev)
- __field(u16, class)
- __field(u16, instance)
- __field(u32, seqno)
- __field(bool, waiters)
- ),
-
- TP_fast_assign(
-__entry->dev = engine->i915->drm.primary->index;
-__entry->class = engine->uabi_class;
-__entry->instance = engine->instance;
-__entry->seqno = intel_engine_get_seqno(engine);
-__entry->waiters = waiters;
-),
-
- TP_printk("dev=%u, engine=%u:%u, seqno=%u, waiters=%u",
- __entry->dev, __entry->class, __entry->instance,
- __entry->seqno, __entry->waiters)
-);
-
DEFINE_EVENT(i915_request, i915_request_retire,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq)
I cannot decide if keeping what we can would make it useful. Certainly
not for debugging intel_engine_breadcrumbs_irq.. a sequence of
intel_engine_notify(dev, class, instance) -> dma_fence_signaled would be
a very unreliable trace of what engine actually executed something. What
do you think?
All we get is a tracepoint to say an user-interrupt occurred, but nothing to
tie it to any request. We are debugging interrupt generation at that
point, and I feel a tracepoint ill-suited. We want something geared
towards CI instead, so a bunch of selftests... That would be sensible!
We get the engine as well, so could look at sequence of dma fence
signaling happening following that and imply something, sometimes. Like
which physical engine executed what. Since the signaling is done
directly from the interrupt handler and engines are handled in serial
fashion.
Regards,
Tvrtko
___
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/3] drm/i915/execlists: Mark up priority boost on preemption
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption
URL : https://patchwork.freedesktop.org/series/55638/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6817512a013e drm/i915/execlists: Mark up priority boost on preemption
7085cc180979 drm/i915/execlists: Suppress preempting self
-:18: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#18:
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the
current context")
-:18: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit a2bf92e8cc16
("drm/i915/execlists: Avoid kicking priority on the current context")'
#18:
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the
current context")
-:138: WARNING:TYPO_SPELLING: 'premption' may be misspelled - perhaps
'preemption'?
#138: FILE: drivers/gpu/drm/i915/intel_lrc.c:236:
+* Even with premption, there are times when we think it is better not
total: 1 errors, 2 warnings, 0 checks, 131 lines checked
97e0a1959b72 drm/i915/execlists: Suppress redundant preemption
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption URL : https://patchwork.freedesktop.org/series/55638/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Mark up priority boost on preemption +drivers/gpu/drm/i915/intel_ringbuffer.h:602:23: warning: expression using sizeof(void) Commit: drm/i915/execlists: Suppress preempting self -drivers/gpu/drm/i915/intel_ringbuffer.h:602:23: warning: expression using sizeof(void) Commit: drm/i915/execlists: Suppress redundant preemption Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/34] drm/i915: Remove the intel_engine_notify tracepoint
Quoting Tvrtko Ursulin (2019-01-23 13:18:43)
>
> On 23/01/2019 12:54, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-22 15:50:27)
> >>
> >> On 21/01/2019 22:21, Chris Wilson wrote:
> >>> The global seqno is defunct and so we have no meaningful indicator of
> >>> forward progress for an engine. You need to listen to the request
> >>> signaling tracepoints instead.
> >>>
> >>> Signed-off-by: Chris Wilson
> >>> ---
> >>>drivers/gpu/drm/i915/i915_irq.c | 2 --
> >>>drivers/gpu/drm/i915/i915_trace.h | 25 -
> >>>2 files changed, 27 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >>> b/drivers/gpu/drm/i915/i915_irq.c
> >>> index 5fd5080c4ccb..71d11dc2c235 100644
> >>> --- a/drivers/gpu/drm/i915/i915_irq.c
> >>> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >>> @@ -1209,8 +1209,6 @@ static void notify_ring(struct intel_engine_cs
> >>> *engine)
> >>>wake_up_process(tsk);
> >>>
> >>>rcu_read_unlock();
> >>> -
> >>> - trace_intel_engine_notify(engine, wait);
> >>>}
> >>>
> >>>static void vlv_c0_read(struct drm_i915_private *dev_priv,
> >>> diff --git a/drivers/gpu/drm/i915/i915_trace.h
> >>> b/drivers/gpu/drm/i915/i915_trace.h
> >>> index 33d90eca9cdd..cb5bc65d575d 100644
> >>> --- a/drivers/gpu/drm/i915/i915_trace.h
> >>> +++ b/drivers/gpu/drm/i915/i915_trace.h
> >>> @@ -750,31 +750,6 @@ trace_i915_request_out(struct i915_request *rq)
> >>>#endif
> >>>#endif
> >>>
> >>> -TRACE_EVENT(intel_engine_notify,
> >>> - TP_PROTO(struct intel_engine_cs *engine, bool waiters),
> >>> - TP_ARGS(engine, waiters),
> >>> -
> >>> - TP_STRUCT__entry(
> >>> - __field(u32, dev)
> >>> - __field(u16, class)
> >>> - __field(u16, instance)
> >>> - __field(u32, seqno)
> >>> - __field(bool, waiters)
> >>> - ),
> >>> -
> >>> - TP_fast_assign(
> >>> -__entry->dev = engine->i915->drm.primary->index;
> >>> -__entry->class = engine->uabi_class;
> >>> -__entry->instance = engine->instance;
> >>> -__entry->seqno = intel_engine_get_seqno(engine);
> >>> -__entry->waiters = waiters;
> >>> -),
> >>> -
> >>> - TP_printk("dev=%u, engine=%u:%u, seqno=%u, waiters=%u",
> >>> - __entry->dev, __entry->class, __entry->instance,
> >>> - __entry->seqno, __entry->waiters)
> >>> -);
> >>> -
> >>>DEFINE_EVENT(i915_request, i915_request_retire,
> >>>TP_PROTO(struct i915_request *rq),
> >>>TP_ARGS(rq)
> >>>
> >>
> >> I cannot decide if keeping what we can would make it useful. Certainly
> >> not for debugging intel_engine_breadcrumbs_irq.. a sequence of
> >> intel_engine_notify(dev, class, instance) -> dma_fence_signaled would be
> >> a very unreliable trace of what engine actually executed something. What
> >> do you think?
> >
> > All we get is a tracepoint to say an user-interrupt occurred, but nothing to
> > tie it to any request. We are debugging interrupt generation at that
> > point, and I feel a tracepoint ill-suited. We want something geared
> > towards CI instead, so a bunch of selftests... That would be sensible!
>
> We get the engine as well, so could look at sequence of dma fence
> signaling happening following that and imply something, sometimes. Like
> which physical engine executed what. Since the signaling is done
> directly from the interrupt handler and engines are handled in serial
> fashion.
Oh, but fence signaling so rarely happens from an irq handler ;)
Or rather we so often signal fences as we do the next execbuf (or
otherwise) that the irq handler has nothing to do.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/execlists: Mark up priority boost on preemption
On 23/01/2019 12:36, Chris Wilson wrote:
Record the priority boost we giving to the preempted client or else we
may end up in a situation where the priority queue no longer matches the
request priority order and so we can end up in an infinite loop of
preempting the same pair of requests.
Fixes: e9eaf82d97a2 ("drm/i915: Priority boost for waiting clients")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 436e59724900..8aa8a4862543 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -302,6 +302,7 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
*/
if (!(prio & I915_PRIORITY_NEWCLIENT)) {
prio |= I915_PRIORITY_NEWCLIENT;
+ active->sched.attr.priority = prio;
list_move_tail(&active->sched.link,
i915_sched_lookup_priolist(engine, prio));
}
@@ -625,6 +626,9 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
int i;
priolist_for_each_request_consume(rq, rn, p, i) {
+ GEM_BUG_ON(last &&
+ need_preempt(engine, last, rq_prio(rq)));
+
/*
* Can we combine this request with the current port?
* It has to be the same context/ringbuffer and not
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption
URL : https://patchwork.freedesktop.org/series/55638/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5470 -> Patchwork_12015
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12015 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12015, 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/55638/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12015:
### IGT changes ###
Possible regressions
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: PASS -> FAIL
Known issues
Here are the changes found in Patchwork_12015 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> DMESG-WARN [fdo#108622]
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: PASS -> DMESG-FAIL [fdo#103841]
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: PASS -> FAIL [fdo#103167]
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u3}:FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-hsw-4770:{SKIP} [fdo#109271] -> PASS +3
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103841]: https://bugs.freedesktop.org/show_bug.cgi?id=103841
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Participating hosts (45 -> 40)
--
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-pnv-d510
Build changes
-
* Linux: CI_DRM_5470 -> Patchwork_12015
CI_DRM_5470: bfac8844379563353df6f77b0cde827ed74653eb @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4785: 70749c70926f12043d3408b160606e1e6238ed3a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12015: 97e0a1959b722739a349f620c1e83e12359923e6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
97e0a1959b72 drm/i915/execlists: Suppress redundant preemption
7085cc180979 drm/i915/execlists: Suppress preempting self
6817512a013e drm/i915/execlists: Mark up priority boost on preemption
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12015/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Suppress redundant preemption
Quoting Chris Wilson (2019-01-23 12:36:02)
> On unwinding the active request we give it a small (limited to internal
> priority levels) boost to prevent it from being gazumped a second time.
> However, this means that it can be promoted to above the request that
> triggered the preemption request, causing a preempt-to-idle cycle for no
> change. We can avoid this if we take the boost into account when
> checking if the preemption request is valid.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 29 +
> 1 file changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index d9d744f6ab2c..74726f647e47 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -163,6 +163,8 @@
> #define WA_TAIL_DWORDS 2
> #define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
>
> +#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT)
> +
> static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
> struct intel_engine_cs *engine,
> struct intel_context *ce);
> @@ -181,13 +183,31 @@ static inline int rq_prio(const struct i915_request *rq)
> return rq->sched.attr.priority;
> }
>
> +static inline int active_prio(const struct i915_request *rq)
> +{
> + int prio = rq_prio(rq);
> +
> + /*
> +* On unwinding the active request, we give it a priority bump
> +* equivalent to a freshly submitted request. This protects it from
> +* being gazumped again, but it would be preferrable if we didn't
> +* let it be gazumped in the first place!
> +*
> +* See __unwind_incomplete_requests()
> +*/
> + if (i915_request_started(rq))
> + prio |= ACTIVE_PRIORITY;
Hmm, actually we are put to the tail of that priolist so we don't get
rerun ahead of the preemptee if we end up at the same priority.
ACTIVE_PRIORITY - 1 would seem to be the right compromise.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915/tv: Fix >1024 modes on gen3
On Mon, Nov 12, 2018 at 06:59:59PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On gen3 we must disable the TV encoder vertical filter for >1024
> pixel wide sources. Once that's done all we can is try to center
> the image on the screen. Naturally the TV mode vertical resolution
> must be equal or larger than the user mode vertical resolution
> or else we'd have to cut off part of the user mode.
>
> And while we may not be able to respect the user's choice of
> top and bottom borders exactly (or we'd have to reject he mode
> most likely), we can try to maintain the relative sizes of the
> top and bottom border with respect to each orher.
>
> Additionally we must configure the pipe as interlaced if the
> TV mode is interlaced.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_tv.c | 100 +---
> 1 file changed, 92 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 75126fce655d..7099d837e31a 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -861,6 +861,44 @@ static const struct tv_mode tv_modes[] = {
> },
> };
>
> +struct intel_tv_connector_state {
> + struct drm_connector_state base;
> +
> + /*
> + * May need to override the user margins for
> + * gen3 >1024 wide source vertical centering.
> + */
> + struct {
> + u16 top, bottom;
> + } margins;
> +
> + bool bypass_vfilter;
> +};
> +
> +#define to_intel_tv_connector_state(x) container_of(x, struct
> intel_tv_connector_state, base)
> +
> +/**
> + * intel_digital_connector_duplicate_state - duplicate connector state
^intel_tv_connector_duplicate_state
> + * @connector: digital connector
^tv connector?
> + *
> + * Allocates and returns a copy of the connector state (both common and
> + * digital connector specific) for the specified connector.
> + *
> + * Returns: The newly allocated connector state, or NULL on failure.
> + */
> +struct drm_connector_state *
> +intel_tv_connector_duplicate_state(struct drm_connector *connector)
> +{
> + struct intel_tv_connector_state *state;
> +
> + state = kmemdup(connector->state, sizeof(*state), GFP_KERNEL);
> + if (!state)
> + return NULL;
> +
> + __drm_atomic_helper_connector_duplicate_state(connector, &state->base);
> + return &state->base;
> +}
You didn't add the corresponding checks for the new
intel_tv_connector_state fields to intel_tv_atomic_check(). I suppose
that's ok since something resulting in a change in those will force a
modeset anyway:
Reviewed-by: Imre Deak
> +
> static struct intel_tv *enc_to_tv(struct intel_encoder *encoder)
> {
> return container_of(encoder, struct intel_tv, base);
> @@ -1129,6 +1167,9 @@ intel_tv_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state)
> {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_tv_connector_state *tv_conn_state =
> + to_intel_tv_connector_state(conn_state);
> const struct tv_mode *tv_mode = intel_tv_mode_find(conn_state);
> struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
> @@ -1149,6 +1190,43 @@ intel_tv_compute_config(struct intel_encoder *encoder,
> pipe_config->port_clock = tv_mode->clock;
>
> intel_tv_mode_to_mode(adjusted_mode, tv_mode);
> + drm_mode_set_crtcinfo(adjusted_mode, 0);
> +
> + if (IS_GEN3(dev_priv) && hdisplay > 1024) {
> + int extra, top, bottom;
> +
> + extra = adjusted_mode->crtc_vdisplay - vdisplay;
> +
> + if (extra < 0) {
> + DRM_DEBUG_KMS("No vertical scaling for >1024 pixel wide
> modes\n");
> + return false;
> + }
> +
> + /* Need to turn off the vertical filter and center the image */
> +
> + /* Attempt to maintain the relative sizes of the margins */
> + top = conn_state->tv.margins.top;
> + bottom = conn_state->tv.margins.bottom;
> +
> + if (top + bottom)
> + top = extra * top / (top + bottom);
> + else
> + top = extra / 2;
> + bottom = extra - top;
> +
> + tv_conn_state->margins.top = top;
> + tv_conn_state->margins.bottom = bottom;
> +
> + tv_conn_state->bypass_vfilter = true;
> +
> + if (!tv_mode->progressive)
> + adjusted_mode->flags |= DRM_MODE_FLAG_INTERLACE;
> + } else {
> + tv_conn_state->margins.top = conn_state->tv.margins.top;
> + tv_conn_state->margins.bottom = conn_state->tv.margins.bottom;
> +
> + tv_conn_state->bypass_vfilter = false;
> + }
>
> DRM_DE
Re: [Intel-gfx] [PATCH 15/15] drm/i915/tv: Filter out >1024 wide modes that would need vertical scaling on gen3
On Mon, Nov 12, 2018 at 07:00:00PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Since gen3 can't handle >1024 wide sources with vertical scaling
> let's not advertize such modes in the mode list. Less tempetation
> to the user to try out things that won't work.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 7099d837e31a..89c537839273 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1738,6 +1738,7 @@ intel_tv_set_mode_type(struct drm_display_mode *mode,
> static int
> intel_tv_get_modes(struct drm_connector *connector)
> {
> + struct drm_i915_private *dev_priv = to_i915(connector->dev);
> const struct tv_mode *tv_mode = intel_tv_mode_find(connector->state);
> int i, count = 0;
>
> @@ -1750,6 +1751,11 @@ intel_tv_get_modes(struct drm_connector *connector)
> !tv_mode->component_only)
> continue;
>
> + /* no vertical scaling with wide sources on gen3 */
> + if (IS_GEN3(dev_priv) && input->w > 1024 &&
> + input->h > intel_tv_mode_vdisplay(tv_mode))
> + continue;
> +
> mode = drm_mode_create(connector->dev);
> if (!mode)
> continue;
> --
> 2.18.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] [CI] drm/i915/execlists: Mark up priority boost on preemption
Record the priority boost we giving to the preempted client or else we
may end up in a situation where the priority queue no longer matches the
request priority order and so we can end up in an infinite loop of
preempting the same pair of requests.
Fixes: e9eaf82d97a2 ("drm/i915: Priority boost for waiting clients")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 436e59724900..8aa8a4862543 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -302,6 +302,7 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
*/
if (!(prio & I915_PRIORITY_NEWCLIENT)) {
prio |= I915_PRIORITY_NEWCLIENT;
+ active->sched.attr.priority = prio;
list_move_tail(&active->sched.link,
i915_sched_lookup_priolist(engine, prio));
}
@@ -625,6 +626,9 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
int i;
priolist_for_each_request_consume(rq, rn, p, i) {
+ GEM_BUG_ON(last &&
+ need_preempt(engine, last, rq_prio(rq)));
+
/*
* Can we combine this request with the current port?
* It has to be the same context/ringbuffer and not
--
2.20.1
___
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/execlists: Mark up priority boost on preemption
== Series Details == Series: drm/i915/execlists: Mark up priority boost on preemption URL : https://patchwork.freedesktop.org/series/55641/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Mark up priority boost on preemption +drivers/gpu/drm/i915/intel_ringbuffer.h:602:23: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/execlists: Suppress preempting self
On 23/01/2019 12:36, Chris Wilson wrote:
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes a tasklet_schedule triggering the same evaluation to
preempt the active context with itself.
To avoid the extra complications, after deciding that we have
potentially queued a request with higher priority than the currently
executing request, inspect the head of the queue to see if it is indeed
higher priority from another context.
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the current
context")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 20 ++--
drivers/gpu/drm/i915/intel_lrc.c | 67 ---
2 files changed, 76 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 340faea6c08a..fb5d953430e5 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -239,6 +239,18 @@ sched_lock_engine(struct i915_sched_node *node, struct
intel_engine_cs *locked)
return engine;
}
+static bool inflight(const struct i915_request *rq,
+const struct intel_engine_cs *engine)
+{
+ const struct i915_request *active;
+
+ if (!rq->global_seqno)
+ return false;
+
+ active = port_request(engine->execlists.port);
+ return active->hw_context == rq->hw_context;
+}
+
static void __i915_schedule(struct i915_request *rq,
const struct i915_sched_attr *attr)
{
@@ -328,6 +340,7 @@ static void __i915_schedule(struct i915_request *rq,
INIT_LIST_HEAD(&dep->dfs_link);
engine = sched_lock_engine(node, engine);
+ lockdep_assert_held(&engine->timeline.lock);
/* Recheck after acquiring the engine->timeline.lock */
if (prio <= node->attr.priority || node_signaled(node))
@@ -356,17 +369,16 @@ static void __i915_schedule(struct i915_request *rq,
if (prio <= engine->execlists.queue_priority)
continue;
+ engine->execlists.queue_priority = prio;
+
/*
* If we are already the currently executing context, don't
* bother evaluating if we should preempt ourselves.
*/
- if (node_to_request(node)->global_seqno &&
-
i915_seqno_passed(port_request(engine->execlists.port)->global_seqno,
- node_to_request(node)->global_seqno))
+ if (inflight(node_to_request(node), engine))
continue;
/* Defer (tasklet) submission until after all of our updates. */
- engine->execlists.queue_priority = prio;
tasklet_hi_schedule(&engine->execlists.tasklet);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8aa8a4862543..d9d744f6ab2c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -182,12 +182,64 @@ static inline int rq_prio(const struct i915_request *rq)
}
static inline bool need_preempt(const struct intel_engine_cs *engine,
- const struct i915_request *last,
- int prio)
+ const struct i915_request *rq,
+ int q_prio)
{
- return (intel_engine_has_preemption(engine) &&
- __execlists_need_preempt(prio, rq_prio(last)) &&
- !i915_request_completed(last));
+ const struct intel_context *ctx = rq->hw_context;
+ const int last_prio = rq_prio(rq);
+ struct rb_node *rb;
+ int idx;
+
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
+ if (i915_request_completed(rq))
+ return false;
+
+ if (!__execlists_need_preempt(q_prio, last_prio))
+ return false;
+
+ /*
+* The queue_priority is a mere hint that we may need to preempt.
+* If that hint is stale or we may be trying to preempt ourselves,
+* ignore the request.
+*/
+
+ list_for_each_entry_continue(rq, &engine->timeline.requests, link) {
+ GEM_BUG_ON(rq->hw_context == ctx);
Why would there be no more requests belonging to the same context on the
engine timeline after the first one? Did you mean "if (rq->hw_context ==
ctx) continue;" ?
+ if (rq_prio(rq) > last_prio)
+ return true;
+ }
+
+ rb = rb_first_cached(&engine->execlists.queue);
+ if (!rb)
+ return false;
+
+ priolist_for_each_request(r
Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Suppress redundant preemption
Quoting Chris Wilson (2019-01-23 13:47:29)
> Quoting Chris Wilson (2019-01-23 12:36:02)
> > On unwinding the active request we give it a small (limited to internal
> > priority levels) boost to prevent it from being gazumped a second time.
> > However, this means that it can be promoted to above the request that
> > triggered the preemption request, causing a preempt-to-idle cycle for no
> > change. We can avoid this if we take the boost into account when
> > checking if the preemption request is valid.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 29 +
> > 1 file changed, 25 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index d9d744f6ab2c..74726f647e47 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -163,6 +163,8 @@
> > #define WA_TAIL_DWORDS 2
> > #define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
> >
> > +#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT)
> > +
> > static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
> > struct intel_engine_cs *engine,
> > struct intel_context *ce);
> > @@ -181,13 +183,31 @@ static inline int rq_prio(const struct i915_request
> > *rq)
> > return rq->sched.attr.priority;
> > }
> >
> > +static inline int active_prio(const struct i915_request *rq)
> > +{
> > + int prio = rq_prio(rq);
> > +
> > + /*
> > +* On unwinding the active request, we give it a priority bump
> > +* equivalent to a freshly submitted request. This protects it from
> > +* being gazumped again, but it would be preferrable if we didn't
> > +* let it be gazumped in the first place!
> > +*
> > +* See __unwind_incomplete_requests()
> > +*/
> > + if (i915_request_started(rq))
> > + prio |= ACTIVE_PRIORITY;
>
> Hmm, actually we are put to the tail of that priolist so we don't get
> rerun ahead of the preemptee if we end up at the same priority.
> ACTIVE_PRIORITY - 1 would seem to be the right compromise.
gem_sync/switch-default says ACTIVE_PRIORITY though. Hmm.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches
On Wed, 23 Jan 2019, Greg KH wrote:
> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>> Variables declared in a switch statement before any case statements
>> cannot be initialized, so move all instances out of the switches.
>> After this, future always-initialized stack variables will work
>> and not throw warnings like this:
>>
>> fs/fcntl.c: In function ‘send_sigio_to_task’:
>> fs/fcntl.c:738:13: warning: statement will never be executed
>> [-Wswitch-unreachable]
>>siginfo_t si;
>> ^~
>
> That's a pain, so this means we can't have any new variables in { }
> scope except for at the top of a function?
>
> That's going to be a hard thing to keep from happening over time, as
> this is valid C :(
Not all valid C is meant to be used! ;)
Anyway, I think you're mistaking the limitation to arbitrary blocks
while it's only about the switch block IIUC.
Can't have:
switch (i) {
int j;
case 0:
/* ... */
}
because it can't be turned into:
switch (i) {
int j = 0; /* not valid C */
case 0:
/* ... */
}
but can have e.g.:
switch (i) {
case 0:
{
int j = 0;
/* ... */
}
}
I think Kees' approach of moving such variable declarations to the
enclosing block scope is better than adding another nesting block.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: always return something
The subject of this patch could really be bit more specific "... on DDI clock
selection".
Regards, Joonas
Quoting Lucas De Marchi (2019-01-17 22:21:10)
> Even if we don't have the correct clock and get a warning, we should not
> skip the return.
>
> Fixes: 1fa11ee2d9d0 ("drm/i915/icl: start adding the TBT pll")
> Cc: Paulo Zanoni
> Cc: # v4.19+
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 8dbf6c9e22fb..4dc03e8c6c10 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1021,7 +1021,7 @@ static uint32_t icl_pll_to_ddi_pll_sel(struct
> intel_encoder *encoder,
> return DDI_CLK_SEL_TBT_810;
> default:
> MISSING_CASE(clock);
> - break;
> + return DDI_CLK_SEL_NONE;
> }
> case DPLL_ID_ICL_MGPLL1:
> case DPLL_ID_ICL_MGPLL2:
> --
> 2.20.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Mark up priority boost on preemption
== Series Details ==
Series: drm/i915/execlists: Mark up priority boost on preemption
URL : https://patchwork.freedesktop.org/series/55641/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5470 -> Patchwork_12016
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55641/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12016 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-hsw-4770:{SKIP} [fdo#109271] -> PASS +3
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Participating hosts (45 -> 38)
--
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-pnv-d510 fi-icl-y
Build changes
-
* Linux: CI_DRM_5470 -> Patchwork_12016
CI_DRM_5470: bfac8844379563353df6f77b0cde827ed74653eb @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4785: 70749c70926f12043d3408b160606e1e6238ed3a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12016: a7bd4c8911e69e3ef9b0c0ab279d3ddf07c7a089 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a7bd4c8911e6 drm/i915/execlists: Mark up priority boost on preemption
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12016/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches
On Wed, 23 Jan 2019, Jani Nikula wrote:
> On Wed, 23 Jan 2019, Greg KH wrote:
>> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>>> Variables declared in a switch statement before any case statements
>>> cannot be initialized, so move all instances out of the switches.
>>> After this, future always-initialized stack variables will work
>>> and not throw warnings like this:
>>>
>>> fs/fcntl.c: In function ‘send_sigio_to_task’:
>>> fs/fcntl.c:738:13: warning: statement will never be executed
>>> [-Wswitch-unreachable]
>>>siginfo_t si;
>>> ^~
>>
>> That's a pain, so this means we can't have any new variables in { }
>> scope except for at the top of a function?
>>
>> That's going to be a hard thing to keep from happening over time, as
>> this is valid C :(
>
> Not all valid C is meant to be used! ;)
>
> Anyway, I think you're mistaking the limitation to arbitrary blocks
> while it's only about the switch block IIUC.
>
> Can't have:
>
> switch (i) {
> int j;
> case 0:
> /* ... */
> }
>
> because it can't be turned into:
>
> switch (i) {
> int j = 0; /* not valid C */
> case 0:
> /* ... */
> }
>
> but can have e.g.:
>
> switch (i) {
> case 0:
> {
> int j = 0;
> /* ... */
> }
> }
>
> I think Kees' approach of moving such variable declarations to the
> enclosing block scope is better than adding another nesting block.
PS. The patch is
Reviewed-by: Jani Nikula
and the drivers/gpu/drm/i915/* parts are
Acked-by: Jani Nikula
for merging via whichever tree is appropriate. (There'll be minor
conflicts with in-flight work in our -next tree, but no biggie.)
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/execlists: Suppress preempting self
Quoting Tvrtko Ursulin (2019-01-23 14:08:56)
>
> On 23/01/2019 12:36, Chris Wilson wrote:
> > In order to avoid preempting ourselves, we currently refuse to schedule
> > the tasklet if we reschedule an inflight context. However, this glosses
> > over a few issues such as what happens after a CS completion event and
> > we then preempt the newly executing context with itself, or if something
> > else causes a tasklet_schedule triggering the same evaluation to
> > preempt the active context with itself.
> >
> > To avoid the extra complications, after deciding that we have
> > potentially queued a request with higher priority than the currently
> > executing request, inspect the head of the queue to see if it is indeed
> > higher priority from another context.
> >
> > References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on
> > the current context")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_scheduler.c | 20 ++--
> > drivers/gpu/drm/i915/intel_lrc.c | 67 ---
> > 2 files changed, 76 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> > b/drivers/gpu/drm/i915/i915_scheduler.c
> > index 340faea6c08a..fb5d953430e5 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler.c
> > +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> > @@ -239,6 +239,18 @@ sched_lock_engine(struct i915_sched_node *node, struct
> > intel_engine_cs *locked)
> > return engine;
> > }
> >
> > +static bool inflight(const struct i915_request *rq,
> > + const struct intel_engine_cs *engine)
> > +{
> > + const struct i915_request *active;
> > +
> > + if (!rq->global_seqno)
> > + return false;
> > +
> > + active = port_request(engine->execlists.port);
> > + return active->hw_context == rq->hw_context;
> > +}
> > +
> > static void __i915_schedule(struct i915_request *rq,
> > const struct i915_sched_attr *attr)
> > {
> > @@ -328,6 +340,7 @@ static void __i915_schedule(struct i915_request *rq,
> > INIT_LIST_HEAD(&dep->dfs_link);
> >
> > engine = sched_lock_engine(node, engine);
> > + lockdep_assert_held(&engine->timeline.lock);
> >
> > /* Recheck after acquiring the engine->timeline.lock */
> > if (prio <= node->attr.priority || node_signaled(node))
> > @@ -356,17 +369,16 @@ static void __i915_schedule(struct i915_request *rq,
> > if (prio <= engine->execlists.queue_priority)
> > continue;
> >
> > + engine->execlists.queue_priority = prio;
> > +
> > /*
> >* If we are already the currently executing context, don't
> >* bother evaluating if we should preempt ourselves.
> >*/
> > - if (node_to_request(node)->global_seqno &&
> > -
> > i915_seqno_passed(port_request(engine->execlists.port)->global_seqno,
> > - node_to_request(node)->global_seqno))
> > + if (inflight(node_to_request(node), engine))
> > continue;
> >
> > /* Defer (tasklet) submission until after all of our updates.
> > */
> > - engine->execlists.queue_priority = prio;
> > tasklet_hi_schedule(&engine->execlists.tasklet);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 8aa8a4862543..d9d744f6ab2c 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -182,12 +182,64 @@ static inline int rq_prio(const struct i915_request
> > *rq)
> > }
> >
> > static inline bool need_preempt(const struct intel_engine_cs *engine,
> > - const struct i915_request *last,
> > - int prio)
> > + const struct i915_request *rq,
> > + int q_prio)
> > {
> > - return (intel_engine_has_preemption(engine) &&
> > - __execlists_need_preempt(prio, rq_prio(last)) &&
> > - !i915_request_completed(last));
> > + const struct intel_context *ctx = rq->hw_context;
> > + const int last_prio = rq_prio(rq);
> > + struct rb_node *rb;
> > + int idx;
> > +
> > + if (!intel_engine_has_preemption(engine))
> > + return false;
> > +
> > + if (i915_request_completed(rq))
> > + return false;
> > +
> > + if (!__execlists_need_preempt(q_prio, last_prio))
> > + return false;
> > +
> > + /*
> > + * The queue_priority is a mere hint that we may need to preempt.
> > + * If that hint is stale or we may be trying to preempt ourselves,
> > + * ignore the request.
> > + */
> > +
> > + list_for_each_entry_continue(rq, &engine->timeline.requests, link) {
> >
Re: [Intel-gfx] [PATCH i-g-t] lib/draw: Align mmap requests to page boundaries
Quoting Chris Wilson (2019-01-07 12:56:36) > Since we trust fb->size as either calculated by calc_fb_size() or the > supplied by the user, it invariably isn't page aligned. The mmap > routines and ioctls only deal in pages... > > Not sure if fb->size should be page aligned, but that may break > some other drawing tests, so opt to just fix up the mmap requests. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/draw: Align mmap requests to page boundaries
Quoting Joonas Lahtinen (2019-01-23 14:22:54) > Quoting Chris Wilson (2019-01-07 12:56:36) > > Since we trust fb->size as either calculated by calc_fb_size() or the > > supplied by the user, it invariably isn't page aligned. The mmap > > routines and ioctls only deal in pages... > > > > Not sure if fb->size should be page aligned, but that may break > > some other drawing tests, so opt to just fix up the mmap requests. > > > > Signed-off-by: Chris Wilson > > Cc: Joonas Lahtinen > > Reviewed-by: Joonas Lahtinen Pushed, so that should clear the board for your mmap-wc fix. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for gcc-plugins: Introduce stackinit plugin
On Wed, 23 Jan 2019, Patchwork wrote: > == Series Details == > > Series: gcc-plugins: Introduce stackinit plugin > URL : https://patchwork.freedesktop.org/series/55630/ > State : failure > > == Summary == > > Applying: treewide: Lift switch variables out of switches > Using index info to reconstruct a base tree... > M drivers/gpu/drm/drm_edid.c > M drivers/gpu/drm/i915/intel_display.c > M drivers/gpu/drm/i915/intel_pm.c > Falling back to patching base and 3-way merge... > Auto-merging drivers/gpu/drm/i915/intel_pm.c > CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_pm.c > Auto-merging drivers/gpu/drm/i915/intel_display.c > Auto-merging drivers/gpu/drm/drm_edid.c > error: Failed to merge in the changes. > hint: Use 'git am --show-current-patch' to see the failed patch > Patch failed at 0001 treewide: Lift switch variables out of switches > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". This obviously fails because the patch is against upstream rather than our development tree. No worries. BR, Jani. > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Suppress redundant preemption
Quoting Chris Wilson (2019-01-23 14:14:05)
> Quoting Chris Wilson (2019-01-23 13:47:29)
> > Quoting Chris Wilson (2019-01-23 12:36:02)
> > > On unwinding the active request we give it a small (limited to internal
> > > priority levels) boost to prevent it from being gazumped a second time.
> > > However, this means that it can be promoted to above the request that
> > > triggered the preemption request, causing a preempt-to-idle cycle for no
> > > change. We can avoid this if we take the boost into account when
> > > checking if the preemption request is valid.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/intel_lrc.c | 29 +
> > > 1 file changed, 25 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > > b/drivers/gpu/drm/i915/intel_lrc.c
> > > index d9d744f6ab2c..74726f647e47 100644
> > > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > > @@ -163,6 +163,8 @@
> > > #define WA_TAIL_DWORDS 2
> > > #define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
> > >
> > > +#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT)
> > > +
> > > static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
> > > struct intel_engine_cs
> > > *engine,
> > > struct intel_context *ce);
> > > @@ -181,13 +183,31 @@ static inline int rq_prio(const struct i915_request
> > > *rq)
> > > return rq->sched.attr.priority;
> > > }
> > >
> > > +static inline int active_prio(const struct i915_request *rq)
> > > +{
> > > + int prio = rq_prio(rq);
> > > +
> > > + /*
> > > +* On unwinding the active request, we give it a priority bump
> > > +* equivalent to a freshly submitted request. This protects it
> > > from
> > > +* being gazumped again, but it would be preferrable if we didn't
> > > +* let it be gazumped in the first place!
> > > +*
> > > +* See __unwind_incomplete_requests()
> > > +*/
> > > + if (i915_request_started(rq))
> > > + prio |= ACTIVE_PRIORITY;
> >
> > Hmm, actually we are put to the tail of that priolist so we don't get
> > rerun ahead of the preemptee if we end up at the same priority.
> > ACTIVE_PRIORITY - 1 would seem to be the right compromise.
>
> gem_sync/switch-default says ACTIVE_PRIORITY though. Hmm.
The answer is don't be lazy.
- if (i915_request_started(rq))
+ if ((prio & ACTIVE_PRIORITY) != ACTIVE_PRIORITY &&
+ i915_request_started(rq)) {
prio |= ACTIVE_PRIORITY;
+ prio--;
+ }
That doesn't break switch-default while providing a more accurate
estimate of prio after preemption.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
Quoting Joerg Roedel (2019-01-22 18:51:35) > On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote: > > According to our IOMMU folks there exists some desire to be able to assign > > the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off > > due to how the devices might be grouped in IOMMU groups. Even when you > > would not be using the iGFX device. > > You can force the igfx device into a SI domain, or does that also > trigger the iommu issues on the chipset? To be honest, we've had a mixture different issues on different SKUs that have not been hit in the past when intel_iommu was just disabled by default. I know that in one group of the problems, the issue has been debugged into the GPU having its own set of virtualization mapping translation hardware with caching and it fails to track changes to the mapping. So if a identity mapping was established and never changed, I'd assume that to fix at least that class of problems. Would just passing intel_iommu=on already cause a non-identity mapping to possibly be used for the integrated GPU? If it did, then it would explain quite few of the issues. We have many reports where just having intel_iommu=on (and using the system normally, without any virtualization stuff going on) will cause unexplained GPU hangs. For those users, simply switching to intel_iommu=igfx_off solves the problems, and the debug often ends there. Regards, Joonas > In any case, if iommu=on breaks these systems I want to make them work > again with opt-out, even at the cost of breaking assignability. > > Regards, > > Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/execlists: Suppress redundant preemption
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We can avoid this if we take the boost into account when
checking if the preemption request is valid.
v2: After preemption the active request will be after the preemptee if
they end up with equal priority.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 39
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d9d744f6ab2c..65997ed055b2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -163,6 +163,8 @@
#define WA_TAIL_DWORDS 2
#define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
+#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT)
+
static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
struct intel_engine_cs *engine,
struct intel_context *ce);
@@ -181,13 +183,41 @@ static inline int rq_prio(const struct i915_request *rq)
return rq->sched.attr.priority;
}
+static inline int active_prio(const struct i915_request *rq)
+{
+ int prio = rq_prio(rq);
+
+ /*
+* On unwinding the active request, we give it a priority bump
+* equivalent to a freshly submitted request. This protects it from
+* being gazumped again, but it would be preferable if we didn't
+* let it be gazumped in the first place!
+*
+* See __unwind_incomplete_requests()
+*/
+ if ((prio & ACTIVE_PRIORITY) != ACTIVE_PRIORITY &&
+ i915_request_started(rq)) {
+ /*
+* After preemption, we insert the active request at the
+* end of the new priority level. This means that we will be
+* _lower_ priority than the preemptee all things equal (and
+* so the preemption is valid), so adjust our comparison
+* accordingly.
+*/
+ prio |= ACTIVE_PRIORITY;
+ prio--;
+ }
+
+ return prio;
+}
+
static inline bool need_preempt(const struct intel_engine_cs *engine,
const struct i915_request *rq,
int q_prio)
{
const struct intel_context *ctx = rq->hw_context;
- const int last_prio = rq_prio(rq);
struct rb_node *rb;
+ int last_prio;
int idx;
if (!intel_engine_has_preemption(engine))
@@ -196,6 +226,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
if (i915_request_completed(rq))
return false;
+ last_prio = active_prio(rq);
if (!__execlists_need_preempt(q_prio, last_prio))
return false;
@@ -320,7 +351,7 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
{
struct i915_request *rq, *rn, *active = NULL;
struct list_head *uninitialized_var(pl);
- int prio = I915_PRIORITY_INVALID | I915_PRIORITY_NEWCLIENT;
+ int prio = I915_PRIORITY_INVALID | ACTIVE_PRIORITY;
lockdep_assert_held(&engine->timeline.lock);
@@ -352,8 +383,8 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
* stream, so give it the equivalent small priority bump to prevent
* it being gazumped a second time by another peer.
*/
- if (!(prio & I915_PRIORITY_NEWCLIENT)) {
- prio |= I915_PRIORITY_NEWCLIENT;
+ if ((prio & ACTIVE_PRIORITY) != ACTIVE_PRIORITY) {
+ prio |= ACTIVE_PRIORITY;
active->sched.attr.priority = prio;
list_move_tail(&active->sched.link,
i915_sched_lookup_priolist(engine, prio));
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] intel-ci: Drop gem_exec_nop from BAT
This pair, gem_exec_nop/{series,parallel}, are very light stress tests
of which we already perform the same sequence inside
i915_selftests/live_requests. We keep basic uABI coverage (i.e. plain
old gem_execbuf) via the likes of gem_exec_basic and gem_exec_reloc so
all gem_exec_nop adds are nefarious HW details, much less likely to spot
if a test is of sound quality for further testing (and again, we have
alternate coverage of the same HW stress).
Between the pair of subtests, gem_exec_nop takes about 20s of BAT.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Petri Latvala
Cc: Tomi Sarvela
---
tests/intel-ci/fast-feedback.testlist | 2 --
1 file changed, 2 deletions(-)
diff --git a/tests/intel-ci/fast-feedback.testlist
b/tests/intel-ci/fast-feedback.testlist
index da3c4c8ed..a95d2e95c 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -43,8 +43,6 @@ igt@gem_exec_fence@basic-wait-default
igt@gem_exec_fence@basic-await-default
igt@gem_exec_fence@nb-await-default
igt@gem_exec_gttfill@basic
-igt@gem_exec_nop@basic-parallel
-igt@gem_exec_nop@basic-series
igt@gem_exec_parallel@basic
igt@gem_exec_parse@basic-allowed
igt@gem_exec_parse@basic-rejected
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2)
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption (rev2)
URL : https://patchwork.freedesktop.org/series/55638/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8de30aea3cc3 drm/i915/execlists: Mark up priority boost on preemption
49059512f804 drm/i915/execlists: Suppress preempting self
-:18: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#18:
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the
current context")
-:18: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit a2bf92e8cc16
("drm/i915/execlists: Avoid kicking priority on the current context")'
#18:
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the
current context")
-:138: WARNING:TYPO_SPELLING: 'premption' may be misspelled - perhaps
'preemption'?
#138: FILE: drivers/gpu/drm/i915/intel_lrc.c:236:
+* Even with premption, there are times when we think it is better not
total: 1 errors, 2 warnings, 0 checks, 131 lines checked
81300ac71039 drm/i915/execlists: Suppress redundant preemption
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2)
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2) URL : https://patchwork.freedesktop.org/series/55638/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Mark up priority boost on preemption +drivers/gpu/drm/i915/intel_ringbuffer.h:602:23: warning: expression using sizeof(void) Commit: drm/i915/execlists: Suppress preempting self -drivers/gpu/drm/i915/intel_ringbuffer.h:602:23: warning: expression using sizeof(void) Commit: drm/i915/execlists: Suppress redundant preemption Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches
On Wed, 23 Jan 2019, Edwin Zimmerman wrote:
> On Wed, 23 Jan 2019, Jani Nikula wrote:
>> On Wed, 23 Jan 2019, Greg KH wrote:
>> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>> >> Variables declared in a switch statement before any case statements
>> >> cannot be initialized, so move all instances out of the switches.
>> >> After this, future always-initialized stack variables will work
>> >> and not throw warnings like this:
>> >>
>> >> fs/fcntl.c: In function ‘send_sigio_to_task’:
>> >> fs/fcntl.c:738:13: warning: statement will never be executed
>> >> [-Wswitch-unreachable]
>> >>siginfo_t si;
>> >> ^~
>> >
>> > That's a pain, so this means we can't have any new variables in { }
>> > scope except for at the top of a function?
>> >
>> > That's going to be a hard thing to keep from happening over time, as
>> > this is valid C :(
>>
>> Not all valid C is meant to be used! ;)
>
> Very true. The other thing to keep in mind is the burden of enforcing
> a prohibition on a valid C construct like this. It seems to me that
> patch reviewers and maintainers have enough to do without forcing them
> to watch for variable declarations in switch statements. Automating
> this prohibition, should it be accepted, seems like a good idea to me.
Considering that the treewide diffstat to fix this is:
18 files changed, 45 insertions(+), 46 deletions(-)
and using the gcc plugin in question will trigger the switch-unreachable
warning, I think we're good. There'll probably be the occasional
declarations that pass through, and will get fixed afterwards.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2)
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption (rev2)
URL : https://patchwork.freedesktop.org/series/55638/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5470 -> Patchwork_12017
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55638/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_12017 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: PASS -> FAIL [fdo#103167]
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u3}:FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-hsw-4770:{SKIP} [fdo#109271] -> PASS +3
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Participating hosts (45 -> 41)
--
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5470 -> Patchwork_12017
CI_DRM_5470: bfac8844379563353df6f77b0cde827ed74653eb @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4785: 70749c70926f12043d3408b160606e1e6238ed3a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12017: 81300ac710397ca473f7cebe94a2100e454340c8 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
81300ac71039 drm/i915/execlists: Suppress redundant preemption
49059512f804 drm/i915/execlists: Suppress preempting self
8de30aea3cc3 drm/i915/execlists: Mark up priority boost on preemption
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12017/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 28/34] drm/i915: Replace global breadcrumbs with per-context interrupt tracking
On 23/01/2019 10:01, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-23 09:21:45)
On 21/01/2019 22:21, Chris Wilson wrote:
-static void error_record_engine_waiters(struct intel_engine_cs *engine,
- struct drm_i915_error_engine *ee)
-{
- struct intel_breadcrumbs *b = &engine->breadcrumbs;
- struct drm_i915_error_waiter *waiter;
- struct rb_node *rb;
- int count;
-
- ee->num_waiters = 0;
- ee->waiters = NULL;
-
- if (RB_EMPTY_ROOT(&b->waiters))
- return;
-
- if (!spin_trylock_irq(&b->rb_lock)) {
- ee->waiters = ERR_PTR(-EDEADLK);
- return;
- }
-
- count = 0;
- for (rb = rb_first(&b->waiters); rb != NULL; rb = rb_next(rb))
- count++;
- spin_unlock_irq(&b->rb_lock);
-
- waiter = NULL;
- if (count)
- waiter = kmalloc_array(count,
-sizeof(struct drm_i915_error_waiter),
-GFP_ATOMIC);
- if (!waiter)
- return;
-
- if (!spin_trylock_irq(&b->rb_lock)) {
- kfree(waiter);
- ee->waiters = ERR_PTR(-EDEADLK);
- return;
- }
-
- ee->waiters = waiter;
- for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
- struct intel_wait *w = rb_entry(rb, typeof(*w), node);
-
- strcpy(waiter->comm, w->tsk->comm);
- waiter->pid = w->tsk->pid;
- waiter->seqno = w->seqno;
- waiter++;
-
- if (++ee->num_waiters == count)
- break;
- }
- spin_unlock_irq(&b->rb_lock);
-}
Capturing context waiters is not interesting for error state?
Not really, we don't have a direct link to the process. We could dig it
out by identifying our special wait_cb inside the fence->signal_list,
but I couldn't be bothered. Who's waiting at the time of the error has
never been that interesting for error debugging, just provides an
overview of the system state.
Who issued the hanging command is much more of interest for the hunting
posse than their victim.
However, storing fence->flag (i.e. the DMA_FENCE_FLAG_SIGNAL_ENABLE_BIT
+ DMA_FENCE_FLAG_SIGNALED_BIT) seems like it would come in handy.
-static bool __i915_spin_request(const struct i915_request *rq,
- u32 seqno, int state, unsigned long timeout_us)
+static bool __i915_spin_request(const struct i915_request * const rq,
+ int state, unsigned long timeout_us)
{
- struct intel_engine_cs *engine = rq->engine;
- unsigned int irq, cpu;
-
- GEM_BUG_ON(!seqno);
+ unsigned int cpu;
/*
* Only wait for the request if we know it is likely to complete.
@@ -1050,7 +1046,7 @@ static bool __i915_spin_request(const struct i915_request
*rq,
* it is a fair assumption that it will not complete within our
* relatively short timeout.
*/
- if (!intel_engine_has_started(engine, seqno))
+ if (!i915_request_started(rq))
Might be more wasteful the more preemption is going on. Probably not the
most important thing to try a fix straight away, but something to put
down on some to do list.
Actually... That would be cheap to fix here as we do a test_bit(ACTIVE).
Hmm, I wonder if that makes sense for all callers.
Maybe i915_request_is_running(rq) as a followup.
Above comment is also outdated now (engine order).
I left a comment! Silly me.
+enum {
+ I915_FENCE_FLAG_ACTIVE = DMA_FENCE_FLAG_USER_BITS,
+ I915_FENCE_FLAG_SIGNAL,
Describe in comments what these mean please.
Mean, you expect them to have meaning outside of their use? :)
No, just that the use can be glanced from here instead of derived from
following the code. :p
+bool intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
+{
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
How can you afford to have this per engine? I guess I might figure out
later in the patch/series.
Hmm, it's always been per engine... What cost are you considering?
I was getting ahead of myself, well the patch series, by thinking how
you can afford to store list of waiters per engine, while with the
virtual engine we won't know. Unless there will be a list on the virtual
engine and some sort of a super-list about on which engines to run the
breadcrumbs irq handler for every physical engine interrupt.
+ struct intel_context *ce, *cn;
+ struct i915_request *rq, *rn;
+ LIST_HEAD(signal);
+
+ spin_lock(&b->irq_lock);
+
+ b->irq_fired = true;
+ if (b->irq_armed && list_empty(&b->signalers))
+ __intel_breadcrumbs_disarm_irq(b);
+
+ list_for_each_entry_safe(ce, cn, &b->signalers, signal_link) {
+ GEM_BUG_ON(list_empty(&ce->signals));
+
+ list_for_each_entry_safe(rq, rn, &ce->signals, signal_link) {
+ if (!__request_completed(rq))
+
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Mark up priority boost on preemption
== Series Details ==
Series: drm/i915/execlists: Mark up priority boost on preemption
URL : https://patchwork.freedesktop.org/series/55641/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5470_full -> Patchwork_12016_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12016_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-c-legacy-gamma:
- shard-apl: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-glk: PASS -> FAIL [fdo#102887] / [fdo#105363]
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@pm_rpm@system-suspend-modeset:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
Possible fixes
* igt@gem_softpin@noreloc-s3:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS +2
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: FAIL [fdo#104873] -> PASS
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS +2
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5470 -> Patchwork_12016
CI_DRM_5470: bfac8844379563353df6f77b0cde827ed74653eb @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4785: 70749c70926f12043d3408b160606e1e6238ed3a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12016: a7bd4c8911e69e3ef9b0c0ab279d3ddf07c7a089 @
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_12016/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915/tv: Fix >1024 modes on gen3
On Wed, Jan 23, 2019 at 03:49:02PM +0200, Imre Deak wrote:
> On Mon, Nov 12, 2018 at 06:59:59PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On gen3 we must disable the TV encoder vertical filter for >1024
> > pixel wide sources. Once that's done all we can is try to center
> > the image on the screen. Naturally the TV mode vertical resolution
> > must be equal or larger than the user mode vertical resolution
> > or else we'd have to cut off part of the user mode.
> >
> > And while we may not be able to respect the user's choice of
> > top and bottom borders exactly (or we'd have to reject he mode
> > most likely), we can try to maintain the relative sizes of the
> > top and bottom border with respect to each orher.
> >
> > Additionally we must configure the pipe as interlaced if the
> > TV mode is interlaced.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_tv.c | 100 +---
> > 1 file changed, 92 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_tv.c
> > b/drivers/gpu/drm/i915/intel_tv.c
> > index 75126fce655d..7099d837e31a 100644
> > --- a/drivers/gpu/drm/i915/intel_tv.c
> > +++ b/drivers/gpu/drm/i915/intel_tv.c
> > @@ -861,6 +861,44 @@ static const struct tv_mode tv_modes[] = {
> > },
> > };
> >
> > +struct intel_tv_connector_state {
> > + struct drm_connector_state base;
> > +
> > + /*
> > +* May need to override the user margins for
> > +* gen3 >1024 wide source vertical centering.
> > +*/
> > + struct {
> > + u16 top, bottom;
> > + } margins;
> > +
> > + bool bypass_vfilter;
> > +};
> > +
> > +#define to_intel_tv_connector_state(x) container_of(x, struct
> > intel_tv_connector_state, base)
> > +
> > +/**
> > + * intel_digital_connector_duplicate_state - duplicate connector state
> ^intel_tv_connector_duplicate_state
> > + * @connector: digital connector
> ^tv connector?
> > + *
> > + * Allocates and returns a copy of the connector state (both common and
> > + * digital connector specific) for the specified connector.
> > + *
> > + * Returns: The newly allocated connector state, or NULL on failure.
> > + */
> > +struct drm_connector_state *
> > +intel_tv_connector_duplicate_state(struct drm_connector *connector)
> > +{
> > + struct intel_tv_connector_state *state;
> > +
> > + state = kmemdup(connector->state, sizeof(*state), GFP_KERNEL);
> > + if (!state)
> > + return NULL;
> > +
> > + __drm_atomic_helper_connector_duplicate_state(connector, &state->base);
> > + return &state->base;
> > +}
>
> You didn't add the corresponding checks for the new
> intel_tv_connector_state fields to intel_tv_atomic_check(). I suppose
> that's ok since something resulting in a change in those will force a
> modeset anyway:
The new fields are not visible to the user so nothing external
will change them. intel_tv_compute_config() (which is executed
after .atomic_check()) will just recompute them based on other
user visible state.
>
> Reviewed-by: Imre Deak
>
> > +
> > static struct intel_tv *enc_to_tv(struct intel_encoder *encoder)
> > {
> > return container_of(encoder, struct intel_tv, base);
> > @@ -1129,6 +1167,9 @@ intel_tv_compute_config(struct intel_encoder *encoder,
> > struct intel_crtc_state *pipe_config,
> > struct drm_connector_state *conn_state)
> > {
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > + struct intel_tv_connector_state *tv_conn_state =
> > + to_intel_tv_connector_state(conn_state);
> > const struct tv_mode *tv_mode = intel_tv_mode_find(conn_state);
> > struct drm_display_mode *adjusted_mode =
> > &pipe_config->base.adjusted_mode;
> > @@ -1149,6 +1190,43 @@ intel_tv_compute_config(struct intel_encoder
> > *encoder,
> > pipe_config->port_clock = tv_mode->clock;
> >
> > intel_tv_mode_to_mode(adjusted_mode, tv_mode);
> > + drm_mode_set_crtcinfo(adjusted_mode, 0);
> > +
> > + if (IS_GEN3(dev_priv) && hdisplay > 1024) {
> > + int extra, top, bottom;
> > +
> > + extra = adjusted_mode->crtc_vdisplay - vdisplay;
> > +
> > + if (extra < 0) {
> > + DRM_DEBUG_KMS("No vertical scaling for >1024 pixel wide
> > modes\n");
> > + return false;
> > + }
> > +
> > + /* Need to turn off the vertical filter and center the image */
> > +
> > + /* Attempt to maintain the relative sizes of the margins */
> > + top = conn_state->tv.margins.top;
> > + bottom = conn_state->tv.margins.bottom;
> > +
> > + if (top + bottom)
> > + top = extra * top / (top + bottom);
> > + else
> > + top = extra / 2;
> > + bottom = extra - top;
> > +
> > + tv_conn_state->margins.top = top;
> > + tv_conn_state->margins.bottom = bottom;
Re: [Intel-gfx] [PATCH 2/3] drm/i915/execlists: Suppress preempting self
On 23/01/2019 14:22, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-23 14:08:56)
On 23/01/2019 12:36, Chris Wilson wrote:
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes a tasklet_schedule triggering the same evaluation to
preempt the active context with itself.
To avoid the extra complications, after deciding that we have
potentially queued a request with higher priority than the currently
executing request, inspect the head of the queue to see if it is indeed
higher priority from another context.
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the current
context")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 20 ++--
drivers/gpu/drm/i915/intel_lrc.c | 67 ---
2 files changed, 76 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 340faea6c08a..fb5d953430e5 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -239,6 +239,18 @@ sched_lock_engine(struct i915_sched_node *node, struct
intel_engine_cs *locked)
return engine;
}
+static bool inflight(const struct i915_request *rq,
+ const struct intel_engine_cs *engine)
+{
+ const struct i915_request *active;
+
+ if (!rq->global_seqno)
+ return false;
+
+ active = port_request(engine->execlists.port);
+ return active->hw_context == rq->hw_context;
+}
+
static void __i915_schedule(struct i915_request *rq,
const struct i915_sched_attr *attr)
{
@@ -328,6 +340,7 @@ static void __i915_schedule(struct i915_request *rq,
INIT_LIST_HEAD(&dep->dfs_link);
engine = sched_lock_engine(node, engine);
+ lockdep_assert_held(&engine->timeline.lock);
/* Recheck after acquiring the engine->timeline.lock */
if (prio <= node->attr.priority || node_signaled(node))
@@ -356,17 +369,16 @@ static void __i915_schedule(struct i915_request *rq,
if (prio <= engine->execlists.queue_priority)
continue;
+ engine->execlists.queue_priority = prio;
+
/*
* If we are already the currently executing context, don't
* bother evaluating if we should preempt ourselves.
*/
- if (node_to_request(node)->global_seqno &&
-
i915_seqno_passed(port_request(engine->execlists.port)->global_seqno,
- node_to_request(node)->global_seqno))
+ if (inflight(node_to_request(node), engine))
continue;
/* Defer (tasklet) submission until after all of our updates. */
- engine->execlists.queue_priority = prio;
tasklet_hi_schedule(&engine->execlists.tasklet);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8aa8a4862543..d9d744f6ab2c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -182,12 +182,64 @@ static inline int rq_prio(const struct i915_request *rq)
}
static inline bool need_preempt(const struct intel_engine_cs *engine,
- const struct i915_request *last,
- int prio)
+ const struct i915_request *rq,
+ int q_prio)
{
- return (intel_engine_has_preemption(engine) &&
- __execlists_need_preempt(prio, rq_prio(last)) &&
- !i915_request_completed(last));
+ const struct intel_context *ctx = rq->hw_context;
+ const int last_prio = rq_prio(rq);
+ struct rb_node *rb;
+ int idx;
+
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
+ if (i915_request_completed(rq))
+ return false;
+
+ if (!__execlists_need_preempt(q_prio, last_prio))
+ return false;
+
+ /*
+ * The queue_priority is a mere hint that we may need to preempt.
+ * If that hint is stale or we may be trying to preempt ourselves,
+ * ignore the request.
+ */
+
+ list_for_each_entry_continue(rq, &engine->timeline.requests, link) {
+ GEM_BUG_ON(rq->hw_context == ctx);
Why would there be no more requests belonging to the same context on the
engine timeline after the first one? Did you mean "if (rq->hw_context ==
ctx) continue;" ?
We enter the function with rq == execlist->port, i.e. the last request
submitted to ELSP[0]. In this loop, we iterate from the start of ELSP[1]
and all the request here belo
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
On Wed, Jan 23, 2019 at 05:02:38PM +0200, Joonas Lahtinen wrote: > We have many reports where just having intel_iommu=on (and using the > system normally, without any virtualization stuff going on) will cause > unexplained GPU hangs. For those users, simply switching to > intel_iommu=igfx_off solves the problems, and the debug often ends > there. If you can reproduce problems on your side, then you can try to enable CONFIG_INTEL_IOMMU_BROKEN_GFX_WA to force the GFX devices into the identity mapping. We can also add a boot-parameter and workarounds if it turns out that this is sufficient to make the GFX devices work with IOMMU enabled. Regards, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Intel-wired-lan] [PATCH 1/3] treewide: Lift switch variables out of switches
On Wed, 2019-01-23 at 03:03 -0800, Kees Cook wrote: > Variables declared in a switch statement before any case statements > cannot be initialized, so move all instances out of the switches. > After this, future always-initialized stack variables will work > and not throw warnings like this: > > fs/fcntl.c: In function ‘send_sigio_to_task’: > fs/fcntl.c:738:13: warning: statement will never be executed [- > Wswitch-unreachable] >siginfo_t si; > ^~ > > Signed-off-by: Kees Cook Acked-by: Jeff Kirsher For the e1000 changes. > --- > arch/x86/xen/enlighten_pv.c | 7 --- > drivers/char/pcmcia/cm4000_cs.c | 2 +- > drivers/char/ppdev.c | 20 - > -- > drivers/gpu/drm/drm_edid.c| 4 ++-- > drivers/gpu/drm/i915/intel_display.c | 2 +- > drivers/gpu/drm/i915/intel_pm.c | 4 ++-- > drivers/net/ethernet/intel/e1000/e1000_main.c | 3 ++- > drivers/tty/n_tty.c | 3 +-- > drivers/usb/gadget/udc/net2280.c | 5 ++--- > fs/fcntl.c| 3 ++- > mm/shmem.c| 5 +++-- > net/core/skbuff.c | 4 ++-- > net/ipv6/ip6_gre.c| 4 ++-- > net/ipv6/ip6_tunnel.c | 4 ++-- > net/openvswitch/flow_netlink.c| 7 +++ > security/tomoyo/common.c | 3 ++- > security/tomoyo/condition.c | 7 --- > security/tomoyo/util.c| 4 ++-- > 18 files changed, 45 insertions(+), 46 deletions(-) signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches
On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > Variables declared in a switch statement before any case statements
> > cannot be initialized, so move all instances out of the switches.
> > After this, future always-initialized stack variables will work
> > and not throw warnings like this:
> >
> > fs/fcntl.c: In function ‘send_sigio_to_task’:
> > fs/fcntl.c:738:13: warning: statement will never be executed
> > [-Wswitch-unreachable]
> >siginfo_t si;
> > ^~
>
> That's a pain, so this means we can't have any new variables in { }
> scope except for at the top of a function?
AFAICS this only applies to switch statements (because they jump to a
case and don't execute stuff at the start of the block), not blocks
after if/while/... .
> That's going to be a hard thing to keep from happening over time, as
> this is valid C :(
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches
On Wed, 23 Jan 2019 at 13:09, Jann Horn wrote:
>
> On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > > Variables declared in a switch statement before any case statements
> > > cannot be initialized, so move all instances out of the switches.
> > > After this, future always-initialized stack variables will work
> > > and not throw warnings like this:
> > >
> > > fs/fcntl.c: In function ‘send_sigio_to_task’:
> > > fs/fcntl.c:738:13: warning: statement will never be executed
> > > [-Wswitch-unreachable]
> > >siginfo_t si;
> > > ^~
> >
> > That's a pain, so this means we can't have any new variables in { }
> > scope except for at the top of a function?
>
> AFAICS this only applies to switch statements (because they jump to a
> case and don't execute stuff at the start of the block), not blocks
> after if/while/... .
>
I guess that means it may apply to other cases where you do a 'goto'
into the middle of a for() loop, for instance (at the first
iteration), which is also a valid pattern.
Is there any way to tag these assignments so the diagnostic disregards them?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches
> On Jan 23, 2019, at 5:09 AM, Jann Horn wrote: > > AFAICS this only applies to switch statements (because they jump to a > case and don't execute stuff at the start of the block), not blocks > after if/while/... . It bothers me that we are going out of our way to deprecate valid C constructs in favor of placing the declarations elsewhere. As current compiler warnings would catch any reference before initialization usage anyway, it seems like we are letting a compiler warning rather than the language standard dictate syntax. Certainly if we want to make it a best practice coding style issue we can, and then an appropriate note explaining why should be added to Documentation/process/coding-style.rst. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches
On Wed, 23 Jan 2019, Jani Nikula wrote:
> On Wed, 23 Jan 2019, Greg KH wrote:
> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> >> Variables declared in a switch statement before any case statements
> >> cannot be initialized, so move all instances out of the switches.
> >> After this, future always-initialized stack variables will work
> >> and not throw warnings like this:
> >>
> >> fs/fcntl.c: In function ‘send_sigio_to_task’:
> >> fs/fcntl.c:738:13: warning: statement will never be executed
> >> [-Wswitch-unreachable]
> >>siginfo_t si;
> >> ^~
> >
> > That's a pain, so this means we can't have any new variables in { }
> > scope except for at the top of a function?
> >
> > That's going to be a hard thing to keep from happening over time, as
> > this is valid C :(
>
> Not all valid C is meant to be used! ;)
Very true. The other thing to keep in mind is the burden of enforcing a
prohibition on a valid C construct like this.
It seems to me that patch reviewers and maintainers have enough to do without
forcing them to watch for variable
declarations in switch statements. Automating this prohibition, should it be
accepted, seems like a good idea to me.
-Edwin Zimmerman
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
On Tue, Jan 22, 2019 at 01:12:07PM -0800, Manasi Navare wrote:
> On Gen 11 platform, to enable resolutions like 5K@120 where
> the pixel clock is greater than pipe pixel rate, we need to split it across
> 2 pipes and enable it using DSC and big joiner. In order to support this
> dual pipe single port mode, we need to link two crtcs involved in this
> ganged mode.
>
> This patch is a RFC patch that links two crtcs using linked_crtc pointer
> in intel_crtc_state and slave to indicate if the crtc is a master or slave.
> Here the HW necessitates the first CRTC to be the master CRTC through which
> the final output will be driven and the next consecutive CRTC should be
> slave crtc.
>
> This is currently not tested, but I wanted to get some inputs on this
> approach.
> The idea is to follow the same approach used in Ganged plane mode for NV12
> planes.
This doesn't actually do much so not quite sure what I'm supposed to
say.
The more I've thought about the two pipe one port case the more I'm
thinking we'll need to do something like:
struct drm_foo_uapi_state {
/* all the uapi visible state for the obj */
};
struct drm_foo_state {
struct drm_foo_uapi_state uapi;
/*
* derived state, including duplicates of the pieces
* of the uapi state we need to massage when stealing
* planes/crtcs for internal uses.
*/
};
And then change all the uapi facing code to play with the uapi stuff
only, and find out where we need to do the uapi->derived copy for
planes/crtcs actually enabled by userspace.
Embedding it like that means all the state iterators etc. will keep
working, and we don't have to change all the driver code playing
around with the state. Ie. changes would be limited to mostly the
uapi facing code.
We didn't have to do this for the nv12 thing because we got lucky
and the difference between the two planes turned out to be minimal.
But in the two pipe case we have massage much more state.
>
> Suggested-by: Maarten Lankhorst ,
> Matt Roper
> Cc: Ville Syrjälä
> Cc: Matt Roper
> Cc: Maarten Lankhorst
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_display.c | 63
> drivers/gpu/drm/i915/intel_drv.h | 6 +++
> 2 files changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2fa9f4aec08e..9910dad7371b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10900,6 +10900,63 @@ static bool check_single_encoder_cloning(struct
> drm_atomic_state *state,
> return true;
> }
>
> +static bool icl_dual_pipe_mode(struct drm_i915_private *dev_priv,
> +struct drm_crtc_state *crtc_state)
> +{
> + if (crtc_state->mode.clock <= 2 * dev_priv->max_cdclk_freq)
> + return false;
> +
> + return true;
> +}
> +
> +static int icl_set_linked_crtcs(struct drm_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->dev);
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + struct intel_crtc_state *linked_state = NULL;
> + struct intel_crtc *slave_crtc = NULL;
> + int i;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + struct intel_crtc_state *pipe_config =
> + to_intel_crtc_state(crtc_state);
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> +
> + if (crtc_state->active)
> + continue;
> +
> + if (!icl_dual_pipe_mode(dev_priv, crtc_state))
> + continue;
> +
> + if (!pipe_config->linked_crtc) {
> + slave_crtc = intel_get_crtc_for_pipe(dev_priv,
> + intel_crtc->pipe +
> 1);
> + if (!slave_crtc)
> + return PTR_ERR(slave_crtc);
> +
> + linked_state = intel_atomic_get_crtc_state(state,
> slave_crtc);
> + if (IS_ERR(linked_state))
> + return PTR_ERR(linked_state);
> +
> + pipe_config->linked_crtc = slave_crtc;
> + pipe_config->slave = false;
> + linked_state->linked_crtc = intel_crtc;
> + linked_state->slave = true;
> + // Update the intel_state->active_crtcs if needed
> +
> + DRM_DEBUG_KMS("Using [CRTC:%d:%s] as master and
> [CRTC:%d:%s] as slave\n",
> + intel_crtc->base.base.id,
> intel_crtc->base.name,
> + slave_crtc->base.base.id,
> slave_crtc->base.name);
> +
> + break;
> + }
> + }
> +
> + return 0;
> +
> +}
> +
> static int icl_add_linked_planes(struct intel_atomic_state *state)
> {
> struct intel_plane
Re: [Intel-gfx] [PATCH] drm: Split out drm_probe_helper.h
Hi Daniel. On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. How are the plans to get this patchset merged? There were dependencies on onging drmP.h removal in i915 IIRC? I guess my "Minimize drmP.h dependencies" patch-set also have a role in this. This does not hold up any work of mine, mainly wanted to make sure this was not lost between all the other patches. Sam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/execlists: Suppress preempting self
Quoting Tvrtko Ursulin (2019-01-23 16:40:44)
>
> On 23/01/2019 14:22, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-23 14:08:56)
> >>
> >> On 23/01/2019 12:36, Chris Wilson wrote:
> >>> In order to avoid preempting ourselves, we currently refuse to schedule
> >>> the tasklet if we reschedule an inflight context. However, this glosses
> >>> over a few issues such as what happens after a CS completion event and
> >>> we then preempt the newly executing context with itself, or if something
> >>> else causes a tasklet_schedule triggering the same evaluation to
> >>> preempt the active context with itself.
> >>>
> >>> To avoid the extra complications, after deciding that we have
> >>> potentially queued a request with higher priority than the currently
> >>> executing request, inspect the head of the queue to see if it is indeed
> >>> higher priority from another context.
> >>>
> >>> References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on
> >>> the current context")
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Tvrtko Ursulin
> >>> ---
> >>>drivers/gpu/drm/i915/i915_scheduler.c | 20 ++--
> >>>drivers/gpu/drm/i915/intel_lrc.c | 67 ---
> >>>2 files changed, 76 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> >>> b/drivers/gpu/drm/i915/i915_scheduler.c
> >>> index 340faea6c08a..fb5d953430e5 100644
> >>> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> >>> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> >>> @@ -239,6 +239,18 @@ sched_lock_engine(struct i915_sched_node *node,
> >>> struct intel_engine_cs *locked)
> >>>return engine;
> >>>}
> >>>
> >>> +static bool inflight(const struct i915_request *rq,
> >>> + const struct intel_engine_cs *engine)
> >>> +{
> >>> + const struct i915_request *active;
> >>> +
> >>> + if (!rq->global_seqno)
> >>> + return false;
> >>> +
> >>> + active = port_request(engine->execlists.port);
> >>> + return active->hw_context == rq->hw_context;
> >>> +}
> >>> +
> >>>static void __i915_schedule(struct i915_request *rq,
> >>>const struct i915_sched_attr *attr)
> >>>{
> >>> @@ -328,6 +340,7 @@ static void __i915_schedule(struct i915_request *rq,
> >>>INIT_LIST_HEAD(&dep->dfs_link);
> >>>
> >>>engine = sched_lock_engine(node, engine);
> >>> + lockdep_assert_held(&engine->timeline.lock);
> >>>
> >>>/* Recheck after acquiring the engine->timeline.lock */
> >>>if (prio <= node->attr.priority || node_signaled(node))
> >>> @@ -356,17 +369,16 @@ static void __i915_schedule(struct i915_request *rq,
> >>>if (prio <= engine->execlists.queue_priority)
> >>>continue;
> >>>
> >>> + engine->execlists.queue_priority = prio;
> >>> +
> >>>/*
> >>> * If we are already the currently executing context, don't
> >>> * bother evaluating if we should preempt ourselves.
> >>> */
> >>> - if (node_to_request(node)->global_seqno &&
> >>> -
> >>> i915_seqno_passed(port_request(engine->execlists.port)->global_seqno,
> >>> - node_to_request(node)->global_seqno))
> >>> + if (inflight(node_to_request(node), engine))
> >>>continue;
> >>>
> >>>/* Defer (tasklet) submission until after all of our
> >>> updates. */
> >>> - engine->execlists.queue_priority = prio;
> >>>tasklet_hi_schedule(&engine->execlists.tasklet);
> >>>}
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >>> b/drivers/gpu/drm/i915/intel_lrc.c
> >>> index 8aa8a4862543..d9d744f6ab2c 100644
> >>> --- a/drivers/gpu/drm/i915/intel_lrc.c
> >>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> >>> @@ -182,12 +182,64 @@ static inline int rq_prio(const struct i915_request
> >>> *rq)
> >>>}
> >>>
> >>>static inline bool need_preempt(const struct intel_engine_cs *engine,
> >>> - const struct i915_request *last,
> >>> - int prio)
> >>> + const struct i915_request *rq,
> >>> + int q_prio)
> >>>{
> >>> - return (intel_engine_has_preemption(engine) &&
> >>> - __execlists_need_preempt(prio, rq_prio(last)) &&
> >>> - !i915_request_completed(last));
> >>> + const struct intel_context *ctx = rq->hw_context;
> >>> + const int last_prio = rq_prio(rq);
> >>> + struct rb_node *rb;
> >>> + int idx;
> >>> +
> >>> + if (!intel_engine_has_preemption(engine))
> >>> + return false;
> >>> +
> >>> + if (i915_request_completed(rq))
> >>> + return false;
> >>> +
> >>> + if (!__execlists_need_preempt(q_prio, last_prio
Re: [Intel-gfx] [RFC] drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
On Tue, Jan 22, 2019 at 01:12:07PM -0800, Manasi Navare wrote:
> On Gen 11 platform, to enable resolutions like 5K@120 where
> the pixel clock is greater than pipe pixel rate, we need to split it across
> 2 pipes and enable it using DSC and big joiner. In order to support this
> dual pipe single port mode, we need to link two crtcs involved in this
> ganged mode.
>
> This patch is a RFC patch that links two crtcs using linked_crtc pointer
> in intel_crtc_state and slave to indicate if the crtc is a master or slave.
> Here the HW necessitates the first CRTC to be the master CRTC through which
> the final output will be driven and the next consecutive CRTC should be
> slave crtc.
>
> This is currently not tested, but I wanted to get some inputs on this
> approach.
> The idea is to follow the same approach used in Ganged plane mode for NV12
> planes.
>
> Suggested-by: Maarten Lankhorst ,
> Matt Roper
> Cc: Ville Syrjälä
> Cc: Matt Roper
> Cc: Maarten Lankhorst
> Signed-off-by: Manasi Navare
Looks like the right general approach of using slave/master. I agree
with Ville and Maarten's feedback as well.
The other thing we're going to need to worry about is dealing with all
the planes on the two crtc's. Suppose we have a userspace-visible state
of:
Pipe A: off
Pipe B: 5000x2000@120 (using round numbers to make example simpler)
Plane 0: RGB32: pos (0,0), width=5000, height=2000
Plane 1: RGB32: pos (100,100), width=100, height=100
Plane 2: RGB32: pos (4800,1800), width=100, height=100
Plane 3: RGB32: pos (0,0), width=3000, height=2000
Plane 4: NV12: pos (2000,0), width=1000, height=2000
Plane 5: off
Plane 6: off
Pipe C: off
this means that we need to grab extra planes on the other CRTC and
adjust their size, position, and/or surface offsets accordingly. So the
internal driver state that we actually program into the hardware needs
to be something like:
Pipe A: off
Pipe B: 2500x1000 (master)
Plane 0: pos (0,0), width=2500, height=2000
Plane 1: pos (100,100), width=100, height=100
Plane 2: off
Plane 3: pos (0, 0), width=2500, height=2000
Plane 4{UV}: pos (2000, 0), width=500, height=2000
Plane 5{Y}: pos (2000, 0), width=500, height=2000
Plane 6: off
Pipe C: 2500x1000 (slave)
Plane 0: pos (0,0), offset=(2500,0), width=2500, height=2000
Plane 1: off
Plane 2: pos (2300,1800), width=100, height=100
Plane 3: pos (0, 0), offset=(2500, 0), width=500, height=2000
Plane 4{UV}: pos (0, 0), offset=(500,0), width=500, height=2000
Plane 5{Y}: pos (0, 0), offset=(500,0), width=500, height=2000
Plane 6: off
So I think Ville is right; we're going to need to really copy a lot of
the userspace-facing state data into our own internal state structures
so that we can do the various adjustments on it. As you can see above
there are cases (2pi1po + nv12) where a single userspace plane request
translates into us programming four different sets of plane register
values.
Matt
> ---
> drivers/gpu/drm/i915/intel_display.c | 63
> drivers/gpu/drm/i915/intel_drv.h | 6 +++
> 2 files changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2fa9f4aec08e..9910dad7371b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10900,6 +10900,63 @@ static bool check_single_encoder_cloning(struct
> drm_atomic_state *state,
> return true;
> }
>
> +static bool icl_dual_pipe_mode(struct drm_i915_private *dev_priv,
> +struct drm_crtc_state *crtc_state)
> +{
> + if (crtc_state->mode.clock <= 2 * dev_priv->max_cdclk_freq)
> + return false;
> +
> + return true;
> +}
> +
> +static int icl_set_linked_crtcs(struct drm_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->dev);
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + struct intel_crtc_state *linked_state = NULL;
> + struct intel_crtc *slave_crtc = NULL;
> + int i;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + struct intel_crtc_state *pipe_config =
> + to_intel_crtc_state(crtc_state);
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> +
> + if (crtc_state->active)
> + continue;
> +
> + if (!icl_dual_pipe_mode(dev_priv, crtc_state))
> + continue;
> +
> + if (!pipe_config->linked_crtc) {
> + slave_crtc = intel_get_crtc_for_pipe(dev_priv,
> + intel_crtc->pipe +
> 1);
> + if (!slave_crtc)
> + return PTR_ERR(slave_crtc);
> +
> + linked_state = intel
[Intel-gfx] [PATCH v2] drm/i915/execlists: Suppress preempting self
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes a tasklet_schedule triggering the same evaluation to
preempt the active context with itself.
To avoid the extra complications, after deciding that we have
potentially queued a request with higher priority than the currently
executing request, inspect the head of the queue to see if it is indeed
higher priority from another context.
v2: We can simplify a bunch of tests based on the knowledge that PI will
ensure that earlier requests along the same context will have the highest
priority.
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the
current context")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 20 --
drivers/gpu/drm/i915/intel_lrc.c | 91 ---
2 files changed, 100 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 340faea6c08a..fb5d953430e5 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -239,6 +239,18 @@ sched_lock_engine(struct i915_sched_node *node, struct
intel_engine_cs *locked)
return engine;
}
+static bool inflight(const struct i915_request *rq,
+const struct intel_engine_cs *engine)
+{
+ const struct i915_request *active;
+
+ if (!rq->global_seqno)
+ return false;
+
+ active = port_request(engine->execlists.port);
+ return active->hw_context == rq->hw_context;
+}
+
static void __i915_schedule(struct i915_request *rq,
const struct i915_sched_attr *attr)
{
@@ -328,6 +340,7 @@ static void __i915_schedule(struct i915_request *rq,
INIT_LIST_HEAD(&dep->dfs_link);
engine = sched_lock_engine(node, engine);
+ lockdep_assert_held(&engine->timeline.lock);
/* Recheck after acquiring the engine->timeline.lock */
if (prio <= node->attr.priority || node_signaled(node))
@@ -356,17 +369,16 @@ static void __i915_schedule(struct i915_request *rq,
if (prio <= engine->execlists.queue_priority)
continue;
+ engine->execlists.queue_priority = prio;
+
/*
* If we are already the currently executing context, don't
* bother evaluating if we should preempt ourselves.
*/
- if (node_to_request(node)->global_seqno &&
-
i915_seqno_passed(port_request(engine->execlists.port)->global_seqno,
- node_to_request(node)->global_seqno))
+ if (inflight(node_to_request(node), engine))
continue;
/* Defer (tasklet) submission until after all of our updates. */
- engine->execlists.queue_priority = prio;
tasklet_hi_schedule(&engine->execlists.tasklet);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8aa8a4862543..11d7fa810d9a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -181,13 +181,89 @@ static inline int rq_prio(const struct i915_request *rq)
return rq->sched.attr.priority;
}
+static int queue_priority(const struct intel_engine_execlists *execlists)
+{
+ struct i915_priolist *p;
+ struct rb_node *rb;
+
+ rb = rb_first_cached(&execlists->queue);
+ if (!rb)
+ return INT_MIN;
+
+ /*
+* As the priolist[] are inverted, with the highest priority in [0],
+* we have to flip the index value to become priority.
+*/
+ p = to_priolist(rb);
+ return ((p->priority + 1) << I915_USER_PRIORITY_SHIFT) - ffs(p->used);
+}
+
static inline bool need_preempt(const struct intel_engine_cs *engine,
- const struct i915_request *last,
- int prio)
+ const struct i915_request *rq,
+ int q_prio)
{
- return (intel_engine_has_preemption(engine) &&
- __execlists_need_preempt(prio, rq_prio(last)) &&
- !i915_request_completed(last));
+ const struct intel_context *ctx = rq->hw_context;
+ const int last_prio = rq_prio(rq);
+
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
+ if (i915_request_completed(rq))
+ return false;
+
+ /*
+* Check if the current queue_priority merits a preemption attempt.
+*
+* However, the queue_priority is a mere hint that we may need to
+
[Intel-gfx] [PATCH v2 2/2] drm/i915/execlists: Suppress redundant preemption
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We can avoid this if we take the boost into account when
checking if the preemption request is valid.
v2: After preemption the active request will be after the preemptee if
they end up with equal priority.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 39
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b61235304734..e11b31eab7d2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -163,6 +163,8 @@
#define WA_TAIL_DWORDS 2
#define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
+#define ACTIVE_PRIORITY (I915_PRIORITY_NEWCLIENT)
+
static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
struct intel_engine_cs *engine,
struct intel_context *ce);
@@ -181,6 +183,34 @@ static inline int rq_prio(const struct i915_request *rq)
return rq->sched.attr.priority;
}
+static inline int active_prio(const struct i915_request *rq)
+{
+ int prio = rq_prio(rq);
+
+ /*
+* On unwinding the active request, we give it a priority bump
+* equivalent to a freshly submitted request. This protects it from
+* being gazumped again, but it would be preferable if we didn't
+* let it be gazumped in the first place!
+*
+* See __unwind_incomplete_requests()
+*/
+ if ((prio & ACTIVE_PRIORITY) != ACTIVE_PRIORITY &&
+ i915_request_started(rq)) {
+ /*
+* After preemption, we insert the active request at the
+* end of the new priority level. This means that we will be
+* _lower_ priority than the preemptee all things equal (and
+* so the preemption is valid), so adjust our comparison
+* accordingly.
+*/
+ prio |= ACTIVE_PRIORITY;
+ prio--;
+ }
+
+ return prio;
+}
+
static int queue_prio(const struct intel_engine_execlists *execlists)
{
struct i915_priolist *p;
@@ -203,7 +233,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
int q_prio)
{
const struct intel_context *ctx = rq->hw_context;
- const int last_prio = rq_prio(rq);
+ int last_prio;
if (!intel_engine_has_preemption(engine))
return false;
@@ -218,6 +248,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
* preempt. If that hint is stale or we may be trying to preempt
* ourselves, ignore the request.
*/
+ last_prio = active_prio(rq);
if (!__execlists_need_preempt(q_prio, last_prio))
return false;
@@ -344,7 +375,7 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
{
struct i915_request *rq, *rn, *active = NULL;
struct list_head *uninitialized_var(pl);
- int prio = I915_PRIORITY_INVALID | I915_PRIORITY_NEWCLIENT;
+ int prio = I915_PRIORITY_INVALID | ACTIVE_PRIORITY;
lockdep_assert_held(&engine->timeline.lock);
@@ -376,8 +407,8 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
* stream, so give it the equivalent small priority bump to prevent
* it being gazumped a second time by another peer.
*/
- if (!(prio & I915_PRIORITY_NEWCLIENT)) {
- prio |= I915_PRIORITY_NEWCLIENT;
+ if ((prio & ACTIVE_PRIORITY) != ACTIVE_PRIORITY) {
+ prio |= ACTIVE_PRIORITY;
active->sched.attr.priority = prio;
list_move_tail(&active->sched.link,
i915_sched_lookup_priolist(engine, prio));
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/execlists: Suppress preempting self
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes a tasklet_schedule triggering the same evaluation to
preempt the active context with itself.
To avoid the extra complications, after deciding that we have
potentially queued a request with higher priority than the currently
executing request, inspect the head of the queue to see if it is indeed
higher priority from another context.
v2: We can simplify a bunch of tests based on the knowledge that PI will
ensure that earlier requests along the same context will have the highest
priority.
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the
current context")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 20 --
drivers/gpu/drm/i915/intel_lrc.c | 91 ---
2 files changed, 100 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 340faea6c08a..fb5d953430e5 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -239,6 +239,18 @@ sched_lock_engine(struct i915_sched_node *node, struct
intel_engine_cs *locked)
return engine;
}
+static bool inflight(const struct i915_request *rq,
+const struct intel_engine_cs *engine)
+{
+ const struct i915_request *active;
+
+ if (!rq->global_seqno)
+ return false;
+
+ active = port_request(engine->execlists.port);
+ return active->hw_context == rq->hw_context;
+}
+
static void __i915_schedule(struct i915_request *rq,
const struct i915_sched_attr *attr)
{
@@ -328,6 +340,7 @@ static void __i915_schedule(struct i915_request *rq,
INIT_LIST_HEAD(&dep->dfs_link);
engine = sched_lock_engine(node, engine);
+ lockdep_assert_held(&engine->timeline.lock);
/* Recheck after acquiring the engine->timeline.lock */
if (prio <= node->attr.priority || node_signaled(node))
@@ -356,17 +369,16 @@ static void __i915_schedule(struct i915_request *rq,
if (prio <= engine->execlists.queue_priority)
continue;
+ engine->execlists.queue_priority = prio;
+
/*
* If we are already the currently executing context, don't
* bother evaluating if we should preempt ourselves.
*/
- if (node_to_request(node)->global_seqno &&
-
i915_seqno_passed(port_request(engine->execlists.port)->global_seqno,
- node_to_request(node)->global_seqno))
+ if (inflight(node_to_request(node), engine))
continue;
/* Defer (tasklet) submission until after all of our updates. */
- engine->execlists.queue_priority = prio;
tasklet_hi_schedule(&engine->execlists.tasklet);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8aa8a4862543..b61235304734 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -181,13 +181,89 @@ static inline int rq_prio(const struct i915_request *rq)
return rq->sched.attr.priority;
}
+static int queue_prio(const struct intel_engine_execlists *execlists)
+{
+ struct i915_priolist *p;
+ struct rb_node *rb;
+
+ rb = rb_first_cached(&execlists->queue);
+ if (!rb)
+ return INT_MIN;
+
+ /*
+* As the priolist[] are inverted, with the highest priority in [0],
+* we have to flip the index value to become priority.
+*/
+ p = to_priolist(rb);
+ return ((p->priority + 1) << I915_USER_PRIORITY_SHIFT) - ffs(p->used);
+}
+
static inline bool need_preempt(const struct intel_engine_cs *engine,
- const struct i915_request *last,
- int prio)
+ const struct i915_request *rq,
+ int q_prio)
{
- return (intel_engine_has_preemption(engine) &&
- __execlists_need_preempt(prio, rq_prio(last)) &&
- !i915_request_completed(last));
+ const struct intel_context *ctx = rq->hw_context;
+ const int last_prio = rq_prio(rq);
+
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
+ if (i915_request_completed(rq))
+ return false;
+
+ /*
+* Check if the current queue_priority merits a preemption attempt.
+*
+* However, the queue_priority is a mere hint that we may need to
+
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev3)
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev3) URL : https://patchwork.freedesktop.org/series/55638/ State : failure == Summary == Applying: drm/i915/execlists: Mark up priority boost on preemption Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/intel_lrc.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: drm/i915/execlists: Suppress preempting self Applying: drm/i915/execlists: Suppress redundant preemption Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/intel_lrc.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_lrc.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0003 drm/i915/execlists: Suppress redundant preemption When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/execlists: Suppress preempting self
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/execlists: Suppress preempting
self
URL : https://patchwork.freedesktop.org/series/55648/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b7170f749928 drm/i915/execlists: Suppress preempting self
-:22: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#22:
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the
current context")
-:22: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit a2bf92e8cc16
("drm/i915/execlists: Avoid kicking priority on the current context")'
#22:
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the
current context")
-:167: WARNING:TYPO_SPELLING: 'premption' may be misspelled - perhaps
'preemption'?
#167: FILE: drivers/gpu/drm/i915/intel_lrc.c:260:
+* Even with premption, there are times when we think it is better not
total: 1 errors, 2 warnings, 0 checks, 156 lines checked
5a4d8c8df0ab drm/i915/execlists: Suppress redundant preemption
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915/execlists: Suppress preempting self
== Series Details == Series: series starting with [v2,1/2] drm/i915/execlists: Suppress preempting self URL : https://patchwork.freedesktop.org/series/55648/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Suppress preempting self -drivers/gpu/drm/i915/intel_ringbuffer.h:602:23: warning: expression using sizeof(void) Commit: drm/i915/execlists: Suppress redundant preemption Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/5] icl: Misc PLL patches
CC'ing people who have commits related to this series. Could you take a look on it? thanks Lucas De Marchi On Thu, Jan 17, 2019 at 12:21:08PM -0800, Lucas De Marchi wrote: Some PLL reworks on ICL. Patches are more or less independent of each other, but touch the same part of the code. Lucas De Marchi (5): drm/i915/icl: use tc_port in MG_PLL macros drm/i915: always return something drm/i915/icl: remove dpll from clk_sel drm/i915/icl: keep track of unused pll while looping drm/i915: allow shared plls to be non-consecutive drivers/gpu/drm/i915/i915_reg.h | 52 +- drivers/gpu/drm/i915/intel_ddi.c | 20 ++-- drivers/gpu/drm/i915/intel_display.c | 3 +- drivers/gpu/drm/i915/intel_dpll_mgr.c | 137 -- drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +- 5 files changed, 105 insertions(+), 109 deletions(-) -- 2.20.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: always return something
On Wed, Jan 23, 2019 at 04:19:30PM +0200, Joonas Lahtinen wrote:
The subject of this patch could really be bit more specific "... on DDI clock
selection".
Fixed. I'll wait for reviews on other patches to re-spin this series as
it's already conflicting.
thanks
Lucas De Marchi
Regards, Joonas
Quoting Lucas De Marchi (2019-01-17 22:21:10)
Even if we don't have the correct clock and get a warning, we should not
skip the return.
Fixes: 1fa11ee2d9d0 ("drm/i915/icl: start adding the TBT pll")
Cc: Paulo Zanoni
Cc: # v4.19+
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 8dbf6c9e22fb..4dc03e8c6c10 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1021,7 +1021,7 @@ static uint32_t icl_pll_to_ddi_pll_sel(struct
intel_encoder *encoder,
return DDI_CLK_SEL_TBT_810;
default:
MISSING_CASE(clock);
- break;
+ return DDI_CLK_SEL_NONE;
}
case DPLL_ID_ICL_MGPLL1:
case DPLL_ID_ICL_MGPLL2:
--
2.20.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/execlists: Suppress preempting self
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/execlists: Suppress preempting
self
URL : https://patchwork.freedesktop.org/series/55648/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5471 -> Patchwork_12019
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55648/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12019 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: PASS -> FAIL [fdo#103167]
* igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: PASS -> FAIL [fdo#108800]
Possible fixes
* igt@kms_busy@basic-flip-c:
- fi-kbl-7500u: {SKIP} [fdo#109271] / [fdo#109278] -> PASS +2
* igt@kms_chamelium@dp-hpd-fast:
- fi-kbl-7500u: DMESG-WARN [fdo#102505] / [fdo#103558] / [fdo#105602]
-> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (46 -> 41)
--
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5471 -> Patchwork_12019
CI_DRM_5471: 198addb18e12d2469bc41d57f9ed63e1072a7f82 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4786: 85cf76182087c09604bcae2bbee9e58b33bcb4f2 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12019: 5a4d8c8df0abe349b2351fdd3820246e660d8dd9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5a4d8c8df0ab drm/i915/execlists: Suppress redundant preemption
b7170f749928 drm/i915/execlists: Suppress preempting self
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12019/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2)
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption (rev2)
URL : https://patchwork.freedesktop.org/series/55638/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5470_full -> Patchwork_12017_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12017_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145]
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: PASS -> FAIL [fdo#103232] +5
* igt@kms_cursor_crc@cursor-128x42-random:
- shard-glk: PASS -> FAIL [fdo#103232] +4
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_flip@flip-vs-panning:
- shard-snb: PASS -> INCOMPLETE [fdo#105411]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-indfb-pgflip-blt:
- shard-snb: NOTRUN -> INCOMPLETE [fdo#105411] / [fdo#107469]
* igt@kms_plane@pixel-format-pipe-b-planes-source-clamping:
- shard-glk: PASS -> FAIL [fdo#108948]
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166] +2
* igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
Possible fixes
* igt@gem_softpin@noreloc-s3:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-glk: FAIL [fdo#103232] -> PASS +2
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS +2
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: FAIL [fdo#104873] -> PASS
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-glk: FAIL [fdo#108145] -> PASS +1
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS +2
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-apl: DMESG-FAIL [fdo#108950] -> PASS
* igt@kms_setmode@basic:
- shard-hsw: 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#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106510]: https://bugs.freedesktop.org/show_bug.cgi?id=106510
[fdo#107469]: https://bugs.freedesktop.org/show_bug.cgi?id=107469
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948
[fdo#108950]: https://bugs.freedesktop.org/show_bug.cgi?id=108950
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5470 -> Patchwork_12017
CI_DRM_5470: bfac8844379563353df6f77b0cde827ed74653eb @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4785: 70749c70926f12043d3408b160606e1e6238ed3a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12017: 81300ac710397ca473f7cebe94a2100e454340c8 @
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_12017/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
On Wed, Jan 23, 2019 at 07:21:57AM +, Kahola, Mika wrote:
> On Tue, 2019-01-22 at 21:09 +0200, Ville Syrjälä wrote:
> > On Tue, Jan 22, 2019 at 08:09:40PM +0200, Jani Nikula wrote:
> > > On Tue, 22 Jan 2019, Ville Syrjälä
> > > wrote:
> > > > On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kahola wrote:
> > > > > Avoid divide by zero warning on static analysis.
> > > > >
> > > > > Signed-off-by: Mika Kahola
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_pm.c | 6 --
> > > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > index 8b63afa3a221..6a8e8b3f44c2 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > @@ -3912,8 +3912,10 @@
> > > > > skl_ddb_get_pipe_allocation_limits(struct drm_i915_private
> > > > > *dev_priv,
> > > > > pipe_width = hdisplay;
> > > > > }
> > > > >
> > > > > - alloc->start = ddb_size * width_before_pipe /
> > > > > total_width;
> > > > > - alloc->end = ddb_size * (width_before_pipe +
> > > > > pipe_width) / total_width;
> > > > > + alloc->start = total_width == 0 ?
> > > > > + 0 : ddb_size * width_before_pipe / total_width;
> > > > > + alloc->end = total_width == 0 ?
> > > > > + 0 : ddb_size * (width_before_pipe + pipe_width)
> > > > > / total_width;
> > > >
> > > > Can't happen.
> I'd say it's very unlikely to happen but in theory possible. If we
> don't have any crtc_state enabled we end up having total_width = 0. In
> this case it probably won't matter what numbers we end up with alloc-
> >start and alloc->end.
The caller bails out early in that case:
if (!cstate->base.active) {
alloc->start = alloc->end = 0;
return 0;
}
>
> Anyway, this was something that caught my eye while looking into crc
> mismatch errors and static checker results.
>
> Like Jani said, warn is sufficient with this case.
>
> Cheers,
> Mika
>
> > >
> > > Yeah, it's about stfu the checker...
> >
> > Feels like the tip of an iceberg. How many more uglies are we going
> > to
> > have to add?
> >
> > >
> > > >
> > > > > }
> > > > >
> > > > > static unsigned int skl_cursor_allocation(int num_active)
> > > > > --
> > > > > 2.17.1
> > > > >
> > > > > ___
> > > > > Intel-gfx mailing list
> > > > > Intel-gfx@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > > --
> > > Jani Nikula, Intel Open Source Graphics Center
> >
> >
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 2/7] drm/i915: Simplify MOCS table definition
On 2019-01-22 06:12, Lucas De Marchi wrote:
Make the defines for LE and L3 caching options to contain the shifts and
remove the zeros from the tables as shifting zeros always result in
zero.
Starting from Ice Lake the MOCS table is defined in the spec and
contains all entries. So to simplify checking the table with the values
set in code, the value is now part of the macro name. This allows to
still give the most used option and sensible name, but also to easily
cross check the table from the spec for gen >= 11.
By removing the zeros we avoid maintaining a huge table since the one
from spec contains many more entries. The new table for Ice Lake will
be added by other patches, this only reformats the table.
While at it also fix the indentation.
Signed-off-by: Lucas De Marchi
That is much cleaner.
Reviewed-by: Tomasz Lis
-Tomasz
---
drivers/gpu/drm/i915/intel_mocs.c | 80 +++
1 file changed, 29 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 0d6b94a239d6..4ea80bb7dcc8 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -36,8 +36,8 @@ struct drm_i915_mocs_table {
};
/* Defines for the tables (XXX_MOCS_0 - XXX_MOCS_63) */
-#define LE_CACHEABILITY(value) ((value) << 0)
-#define LE_TGT_CACHE(value)((value) << 2)
+#define _LE_CACHEABILITY(value)((value) << 0)
+#define _LE_TGT_CACHE(value) ((value) << 2)
#define LE_LRUM(value)((value) << 4)
#define LE_AOM(value) ((value) << 6)
#define LE_RSC(value) ((value) << 7)
@@ -48,28 +48,28 @@ struct drm_i915_mocs_table {
/* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word */
#define L3_ESC(value) ((value) << 0)
#define L3_SCC(value) ((value) << 1)
-#define L3_CACHEABILITY(value) ((value) << 4)
+#define _L3_CACHEABILITY(value)((value) << 4)
/* Helper defines */
#define GEN9_NUM_MOCS_ENTRIES 62 /* 62 out of 64 - 63 & 64 are reserved. */
/* (e)LLC caching options */
-#define LE_PAGETABLE 0
-#define LE_UC 1
-#define LE_WT 2
-#define LE_WB 3
-
-/* L3 caching options */
-#define L3_DIRECT 0
-#define L3_UC 1
-#define L3_RESERVED2
-#define L3_WB 3
+#define LE_0_PAGETABLE _LE_CACHEABILITY(0)
+#define LE_1_UC_LE_CACHEABILITY(1)
+#define LE_2_WT_LE_CACHEABILITY(2)
+#define LE_3_WB_LE_CACHEABILITY(3)
/* Target cache */
-#define LE_TC_PAGETABLE0
-#define LE_TC_LLC 1
-#define LE_TC_LLC_ELLC 2
-#define LE_TC_LLC_ELLC_ALT 3
+#define LE_TC_0_PAGETABLE _LE_TGT_CACHE(0)
+#define LE_TC_1_LLC_LE_TGT_CACHE(1)
+#define LE_TC_2_LLC_ELLC _LE_TGT_CACHE(2)
+#define LE_TC_3_LLC_ELLC_ALT _LE_TGT_CACHE(3)
+
+/* L3 caching options */
+#define L3_0_DIRECT_L3_CACHEABILITY(0)
+#define L3_1_UC_L3_CACHEABILITY(1)
+#define L3_2_RESERVED _L3_CACHEABILITY(2)
+#define L3_3_WB_L3_CACHEABILITY(3)
/*
* MOCS tables
@@ -96,31 +96,21 @@ struct drm_i915_mocs_table {
static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
[I915_MOCS_UNCACHED] = {
/* 0x0009 */
- .control_value = LE_CACHEABILITY(LE_UC) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
-
+ .control_value = LE_1_UC | LE_TC_2_LLC_ELLC,
/* 0x0010 */
- .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+ .l3cc_value =L3_1_UC,
},
[I915_MOCS_PTE] = {
/* 0x0038 */
- .control_value = LE_CACHEABILITY(LE_PAGETABLE) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
+ .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3),
/* 0x0030 */
- .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+ .l3cc_value =L3_3_WB,
},
[I915_MOCS_CACHED] = {
/* 0x003b */
- .control_value = LE_CACHEABILITY(LE_WB) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
+ .control_value = LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
/* 0x0030 */
- .l3cc_value = L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+ .l3cc_value = L3_3_WB,
},
};
@@ -128,33 +118,21 @@ static const struct drm_i915_mocs_entry skylake_
Re: [Intel-gfx] [PATCH v8 1/7] drm/i915: initialize unused MOCS entries to PTE
On 2019-01-22 06:12, Lucas De Marchi wrote:
Instead of initializing them to uncached, let's set them to PTE for
kernel tracking. While at it do some minor adjustments to comments and
coding style.
Signed-off-by: Lucas De Marchi
Reviewed-by: Tomasz Lis
One comment (with no expectations for change) below.
---
drivers/gpu/drm/i915/intel_mocs.c | 56 +--
1 file changed, 23 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index e976c5ce5479..0d6b94a239d6 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -85,10 +85,7 @@ struct drm_i915_mocs_table {
*
* Entries not part of the following tables are undefined as far as
* userspace is concerned and shouldn't be relied upon. For the time
- * being they will be implicitly initialized to the strictest caching
- * configuration (uncached) to guarantee forwards compatibility with
- * userspace programs written against more recent kernels providing
- * additional MOCS entries.
+ * being they will be initialized to PTE.
*
* NOTE: These tables MUST start with being uncached and the length
* MUST be less than 63 as the last two registers are reserved
@@ -249,16 +246,13 @@ void intel_mocs_init_engine(struct intel_engine_cs
*engine)
table.table[index].control_value);
/*
-* Ok, now set the unused entries to uncached. These entries
-* are officially undefined and no contract for the contents
-* and settings is given for these entries.
-*
-* Entry 0 in the table is uncached - so we are just writing
-* that value to all the used entries.
+* Now set the unused entries to PTE. These entries are officially
+* undefined and no contract for the contents and settings is given
+* for these entries.
*/
for (; index < GEN9_NUM_MOCS_ENTRIES; index++)
I915_WRITE(mocs_register(engine->id, index),
- table.table[0].control_value);
+ table.table[I915_MOCS_PTE].control_value);
}
/**
@@ -293,16 +287,13 @@ static int emit_mocs_control_table(struct i915_request
*rq,
}
/*
-* Ok, now set the unused entries to uncached. These entries
-* are officially undefined and no contract for the contents
-* and settings is given for these entries.
-*
-* Entry 0 in the table is uncached - so we are just writing
-* that value to all the used entries.
+* Now set the unused entries to PTE. These entries are officially
+* undefined and no contract for the contents and settings is given
+* for these entries.
*/
for (; index < GEN9_NUM_MOCS_ENTRIES; index++) {
*cs++ = i915_mmio_reg_offset(mocs_register(engine, index));
- *cs++ = table->table[0].control_value;
+ *cs++ = table->table[I915_MOCS_PTE].control_value;
Entries from enum i915_mocs_table_index are not guaranteed to mean the
same thing in future gens;
but for the time, that will work. And later it might still work, we
don't know.
-Tomasz
}
*cs++ = MI_NOOP;
@@ -345,7 +336,7 @@ static int emit_mocs_l3cc_table(struct i915_request *rq,
*cs++ = MI_LOAD_REGISTER_IMM(GEN9_NUM_MOCS_ENTRIES / 2);
- for (i = 0; i < table->size/2; i++) {
+ for (i = 0; i < table->size / 2; i++) {
*cs++ = i915_mmio_reg_offset(GEN9_LNCFCMOCS(i));
*cs++ = l3cc_combine(table, 2 * i, 2 * i + 1);
}
@@ -353,18 +344,18 @@ static int emit_mocs_l3cc_table(struct i915_request *rq,
if (table->size & 0x01) {
/* Odd table size - 1 left over */
*cs++ = i915_mmio_reg_offset(GEN9_LNCFCMOCS(i));
- *cs++ = l3cc_combine(table, 2 * i, 0);
+ *cs++ = l3cc_combine(table, 2 * i, I915_MOCS_PTE);
i++;
}
/*
-* Now set the rest of the table to uncached - use entry 0 as
-* this will be uncached. Leave the last pair uninitialised as
-* they are reserved by the hardware.
+* Now set the unused entries to PTE. These entries are officially
+* undefined and no contract for the contents and settings is given
+* for these entries.
*/
for (; i < GEN9_NUM_MOCS_ENTRIES / 2; i++) {
*cs++ = i915_mmio_reg_offset(GEN9_LNCFCMOCS(i));
- *cs++ = l3cc_combine(table, 0, 0);
+ *cs++ = l3cc_combine(table, I915_MOCS_PTE, I915_MOCS_PTE);
}
*cs++ = MI_NOOP;
@@ -395,22 +386,21 @@ void intel_mocs_init_l3cc_table(struct drm_i915_private
*dev_priv)
if (!get_mocs_settings(dev_priv, &table))
return;
- for (i = 0; i < table.size/2; i++)
- I915_WRITE(GEN9_LNCFCMOCS(i), l3cc_combine(&table, 2*i, 2*i+1));
+
Re: [Intel-gfx] [PATCH v8 3/7] drm/i915/skl: Rework MOCS tables to keep common part in a define
On 2019-01-22 06:12, Lucas De Marchi wrote:
From: Tomasz Lis
The MOCS tables are going to be very similar across platforms.
To reduce the amount of copied code, this patch rips the common part and
puts it into a definition valid for all gen9 platforms.
v2: Made defines for or-ing flags. Renamed macros from MOCS_TABLE
to MOCS_ENTRIES. (Joonas)
v3 (Lucas):
- Fix indentation
- Rebase on rework done by additional patch
- Remove define for or-ing flags as it made the table more complex by
requiring zeroed values to be passed
- Do not embed comma in the macro, so to treat that just as another
item and please source code formatting tools
Signed-off-by: Tomasz Lis
Suggested-by: Lucas De Marchi
Signed-off-by: Lucas De Marchi
Acked-by: Tomasz Lis
-Tomasz
---
drivers/gpu/drm/i915/intel_mocs.c | 57 ++-
1 file changed, 25 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 4ea80bb7dcc8..c7a2a8d81d90 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -93,46 +93,39 @@ struct drm_i915_mocs_table {
* may only be updated incrementally by adding entries at the
* end.
*/
+
+#define GEN9_MOCS_ENTRIES \
+ [I915_MOCS_UNCACHED] = { \
+ /* 0x0009 */ \
+ .control_value = LE_1_UC | LE_TC_2_LLC_ELLC, \
+ /* 0x0010 */ \
+ .l3cc_value = L3_1_UC, \
+ }, \
+ [I915_MOCS_PTE] = { \
+ /* 0x0038 */ \
+ .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC |
LE_LRUM(3), \
+ /* 0x0030 */ \
+ .l3cc_value = L3_3_WB, \
+ }
+
static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
- [I915_MOCS_UNCACHED] = {
- /* 0x0009 */
- .control_value = LE_1_UC | LE_TC_2_LLC_ELLC,
- /* 0x0010 */
- .l3cc_value =L3_1_UC,
- },
- [I915_MOCS_PTE] = {
- /* 0x0038 */
- .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3),
- /* 0x0030 */
- .l3cc_value =L3_3_WB,
- },
+ GEN9_MOCS_ENTRIES,
[I915_MOCS_CACHED] = {
- /* 0x003b */
- .control_value = LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
- /* 0x0030 */
- .l3cc_value = L3_3_WB,
+ /* 0x003b */
+ .control_value = LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
+ /* 0x0030 */
+ .l3cc_value = L3_3_WB,
},
};
/* NOTE: the LE_TGT_CACHE is not used on Broxton */
static const struct drm_i915_mocs_entry broxton_mocs_table[] = {
- [I915_MOCS_UNCACHED] = {
- /* 0x0009 */
- .control_value = LE_1_UC | LE_TC_2_LLC_ELLC,
- /* 0x0010 */
- .l3cc_value = L3_1_UC,
- },
- [I915_MOCS_PTE] = {
- /* 0x0038 */
- .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3),
- /* 0x0030 */
- .l3cc_value = L3_3_WB,
- },
+ GEN9_MOCS_ENTRIES,
[I915_MOCS_CACHED] = {
- /* 0x0039 */
- .control_value = LE_1_UC | LE_TC_2_LLC_ELLC | LE_LRUM(3),
- /* 0x0030 */
- .l3cc_value = L3_3_WB,
+ /* 0x0039 */
+ .control_value = LE_1_UC | LE_TC_2_LLC_ELLC | LE_LRUM(3),
+ /* 0x0030 */
+ .l3cc_value = L3_3_WB,
},
};
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/7] drm/i915: rename has_edp_a() to ilk_has_edp_a()
On Tue, Jan 22, 2019 at 10:23:05AM +0200, Jani Nikula wrote:
> Clarify that the name is specific to ILK+ PCH platforms.
>
> v2: prefix the name with ilk rather than pch (Ville)
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8e89f04ddd9c..9895ea566f99 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14231,7 +14231,7 @@ static int intel_encoder_clones(struct intel_encoder
> *encoder)
> return index_mask;
> }
>
> -static bool has_edp_a(struct drm_i915_private *dev_priv)
> +static bool ilk_has_edp_a(struct drm_i915_private *dev_priv)
> {
> if (!IS_MOBILE(dev_priv))
> return false;
> @@ -14388,7 +14388,7 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
>
> dpd_is_edp = intel_dp_is_port_edp(dev_priv, PORT_D);
>
> - if (has_edp_a(dev_priv))
> + if (ilk_has_edp_a(dev_priv))
> intel_dp_init(dev_priv, DP_A, PORT_A);
>
> if (I915_READ(PCH_HDMIB) & SDVO_DETECTED) {
> --
> 2.20.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/lvds: simplify gen 2 lvds presence
On Tue, Jan 22, 2019 at 10:23:06AM +0200, Jani Nikula wrote:
> Gen 2 mobile and not I830 is, in fact, I85X. Simplify.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9895ea566f99..ed3780f24638 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14508,7 +14508,7 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> if (SUPPORTS_TV(dev_priv))
> intel_tv_init(dev_priv);
> } else if (IS_GEN(dev_priv, 2)) {
> - if (IS_MOBILE(dev_priv) && !IS_I830(dev_priv))
> + if (IS_I85X(dev_priv))
> intel_lvds_init(dev_priv);
>
> if (dev_priv->vbt.int_crt_support)
> --
> 2.20.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 7/7] drm/i915/crt: simplify CRT VBT check on pre-VLV/DDI
On Tue, Jan 22, 2019 at 10:23:07AM +0200, Jani Nikula wrote:
> The VBT int_crt_support can't be trusted on earlier platforms, and is
> always set to true in intel_bios.c for pre-DDI and pre-VLV platforms. We
> can simplify the output setup by unconditionally calling
> intel_crt_init() for these platforms.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 15 ---
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ed3780f24638..d328599240cb 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14382,9 +14382,7 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
>* incorrect sharing of the PPS.
>*/
> intel_lvds_init(dev_priv);
> -
> - if (dev_priv->vbt.int_crt_support)
> - intel_crt_init(dev_priv);
> + intel_crt_init(dev_priv);
>
> dpd_is_edp = intel_dp_is_port_edp(dev_priv, PORT_D);
>
> @@ -14461,17 +14459,14 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> vlv_dsi_init(dev_priv);
> } else if (IS_PINEVIEW(dev_priv)) {
> intel_lvds_init(dev_priv);
> -
> - if (dev_priv->vbt.int_crt_support)
> - intel_crt_init(dev_priv);
> + intel_crt_init(dev_priv);
> } else if (IS_GEN_RANGE(dev_priv, 3, 4)) {
> bool found = false;
>
> if (IS_MOBILE(dev_priv))
> intel_lvds_init(dev_priv);
>
> - if (dev_priv->vbt.int_crt_support)
> - intel_crt_init(dev_priv);
> + intel_crt_init(dev_priv);
>
> if (I915_READ(GEN3_SDVOB) & SDVO_DETECTED) {
> DRM_DEBUG_KMS("probing SDVOB\n");
> @@ -14511,9 +14506,7 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> if (IS_I85X(dev_priv))
> intel_lvds_init(dev_priv);
>
> - if (dev_priv->vbt.int_crt_support)
> - intel_crt_init(dev_priv);
> -
> + intel_crt_init(dev_priv);
> intel_dvo_init(dev_priv);
> }
>
> --
> 2.20.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: do a posting read after irq install
On 01/23/2019 03:40 AM, Mika Kuoppala wrote: Daniele Ceraolo Spurio writes: On 1/22/2019 6:32 PM, Daniele Ceraolo Spurio wrote: When reading GEN11_GT_INTR_DWx closely after enabling the interrupts in gen11_irq_postinstall, the returned value is garbage. This can To clarify, this only happens (or at least I've only seen it) during runtime_resume. How did you notice? The gen11 guc patches add WARN_ON_ONCE(gen11_reset_one_iir(dev_priv, 0, GEN11_GUC)); in the resume path and we saw the warning fire off in testing. A bit of extra logging showed that the whole register was in an invalid state after interrupts were re-enabled, not just the GuC bit. pm_rpm@basic-pci-d3-state hits this consistently. Daniele Daniele cause other parts of the setup code (e.g. gen11_reset_one_iir) to think that there are interrupts to be cleared when there are none. The garbage value is only seen on the first read done after the enable, so this looks like a posting issue. Adding a posting read after enabling the interrupts does indeed fix the problem. Note that the posting read has been purposely added outside of gen11_master_intr_enable since the issue has only been observed when the full interrupt setup is performed. Scary enough that maybe it would have been warranted inside it. But well we know where to escalate if it shows up elsewhere. Acked-by: Mika Kuoppala Cc: Mika Kuoppala Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_irq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 5fd5080c4ccb..7056ae2d1e0e 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -4089,6 +4089,7 @@ static int gen11_irq_postinstall(struct drm_device *dev) I915_WRITE(GEN11_DISPLAY_INT_CTL, GEN11_DISPLAY_IRQ_ENABLE); gen11_master_intr_enable(dev_priv->regs); + POSTING_READ(GEN11_GFX_MSTR_IRQ); return 0; } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 1/7] drm/i915: initialize unused MOCS entries to PTE
On Wed, Jan 23, 2019 at 07:33:35PM +0100, Tomasz Lis wrote:
On 2019-01-22 06:12, Lucas De Marchi wrote:
Instead of initializing them to uncached, let's set them to PTE for
kernel tracking. While at it do some minor adjustments to comments and
coding style.
Signed-off-by: Lucas De Marchi
Reviewed-by: Tomasz Lis
thanks
One comment (with no expectations for change) below.
+ *cs++ = table->table[I915_MOCS_PTE].control_value;
Entries from enum i915_mocs_table_index are not guaranteed to mean the
same thing in future gens;
but for the time, that will work. And later it might still work, we
don't know.
I thought about this, but these values are part of the kernel API
(the same thing could be said for the first entry, btw).
If/when they don't make sense anymore we would need to remap them to
entry that makes sense.
Lucas De Marchi
-Tomasz
}
*cs++ = MI_NOOP;
@@ -345,7 +336,7 @@ static int emit_mocs_l3cc_table(struct i915_request *rq,
*cs++ = MI_LOAD_REGISTER_IMM(GEN9_NUM_MOCS_ENTRIES / 2);
- for (i = 0; i < table->size/2; i++) {
+ for (i = 0; i < table->size / 2; i++) {
*cs++ = i915_mmio_reg_offset(GEN9_LNCFCMOCS(i));
*cs++ = l3cc_combine(table, 2 * i, 2 * i + 1);
}
@@ -353,18 +344,18 @@ static int emit_mocs_l3cc_table(struct i915_request *rq,
if (table->size & 0x01) {
/* Odd table size - 1 left over */
*cs++ = i915_mmio_reg_offset(GEN9_LNCFCMOCS(i));
- *cs++ = l3cc_combine(table, 2 * i, 0);
+ *cs++ = l3cc_combine(table, 2 * i, I915_MOCS_PTE);
i++;
}
/*
-* Now set the rest of the table to uncached - use entry 0 as
-* this will be uncached. Leave the last pair uninitialised as
-* they are reserved by the hardware.
+* Now set the unused entries to PTE. These entries are officially
+* undefined and no contract for the contents and settings is given
+* for these entries.
*/
for (; i < GEN9_NUM_MOCS_ENTRIES / 2; i++) {
*cs++ = i915_mmio_reg_offset(GEN9_LNCFCMOCS(i));
- *cs++ = l3cc_combine(table, 0, 0);
+ *cs++ = l3cc_combine(table, I915_MOCS_PTE, I915_MOCS_PTE);
}
*cs++ = MI_NOOP;
@@ -395,22 +386,21 @@ void intel_mocs_init_l3cc_table(struct drm_i915_private
*dev_priv)
if (!get_mocs_settings(dev_priv, &table))
return;
- for (i = 0; i < table.size/2; i++)
- I915_WRITE(GEN9_LNCFCMOCS(i), l3cc_combine(&table, 2*i, 2*i+1));
+ for (i = 0; i < table.size / 2; i++)
+ I915_WRITE(GEN9_LNCFCMOCS(i),
+ l3cc_combine(&table, 2 * i, 2 * i + 1));
/* Odd table size - 1 left over */
if (table.size & 0x01) {
- I915_WRITE(GEN9_LNCFCMOCS(i), l3cc_combine(&table, 2*i, 0));
+ I915_WRITE(GEN9_LNCFCMOCS(i),
+ l3cc_combine(&table, 2 * i, I915_MOCS_PTE));
i++;
}
- /*
-* Now set the rest of the table to uncached - use entry 0 as
-* this will be uncached. Leave the last pair as initialised as
-* they are reserved by the hardware.
-*/
+ /* Now set the rest of the table to PTE */
for (; i < (GEN9_NUM_MOCS_ENTRIES / 2); i++)
- I915_WRITE(GEN9_LNCFCMOCS(i), l3cc_combine(&table, 0, 0));
+ I915_WRITE(GEN9_LNCFCMOCS(i),
+ l3cc_combine(&table, I915_MOCS_PTE, I915_MOCS_PTE));
}
/**
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 4/7] drm/i915: use a macro to define MOCS entries
On 2019-01-22 06:12, Lucas De Marchi wrote:
Let's use a macro to make tables smaller and at the same time allow us
to add fields that apply to all entries in future.
For the sake of readability, I'm calling an exception on 80 chars limit.
Lines are aligned for easy comparison of the entry values.
Signed-off-by: Lucas De Marchi
Reviewed-by: Tomasz Lis
---
drivers/gpu/drm/i915/intel_mocs.c | 39 +++
1 file changed, 14 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index c7a2a8d81d90..faae2eefc5cc 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -71,6 +71,12 @@ struct drm_i915_mocs_table {
#define L3_2_RESERVED _L3_CACHEABILITY(2)
#define L3_3_WB _L3_CACHEABILITY(3)
+#define MOCS_ENTRY(__idx, __control_value, __l3cc_value) \
+ [__idx] = { \
+ .control_value = __control_value, \
+ .l3cc_value = __l3cc_value, \
+ }
+
/*
* MOCS tables
*
@@ -93,40 +99,23 @@ struct drm_i915_mocs_table {
* may only be updated incrementally by adding entries at the
* end.
*/
-
The idea behind this EOL was that the comment above relates to several
statements below, not just the first one.
But I'm not really sure what our commenting rules are in this case - a
comment which bundles several definitions.
-Tomasz
#define GEN9_MOCS_ENTRIES \
- [I915_MOCS_UNCACHED] = { \
- /* 0x0009 */ \
- .control_value = LE_1_UC | LE_TC_2_LLC_ELLC, \
- /* 0x0010 */ \
- .l3cc_value = L3_1_UC, \
- }, \
- [I915_MOCS_PTE] = { \
- /* 0x0038 */ \
- .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC |
LE_LRUM(3), \
- /* 0x0030 */ \
- .l3cc_value = L3_3_WB, \
- }
+ MOCS_ENTRY(I915_MOCS_UNCACHED, LE_1_UC | LE_TC_2_LLC_ELLC, \
+ L3_1_UC), \
+ MOCS_ENTRY(I915_MOCS_PTE, LE_0_PAGETABLE | LE_TC_2_LLC_ELLC |
LE_LRUM(3), \
+ L3_3_WB) \
static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
GEN9_MOCS_ENTRIES,
- [I915_MOCS_CACHED] = {
- /* 0x003b */
- .control_value = LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
- /* 0x0030 */
- .l3cc_value = L3_3_WB,
- },
+ MOCS_ENTRY(I915_MOCS_CACHED,LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
+ L3_3_WB)
};
/* NOTE: the LE_TGT_CACHE is not used on Broxton */
static const struct drm_i915_mocs_entry broxton_mocs_table[] = {
GEN9_MOCS_ENTRIES,
- [I915_MOCS_CACHED] = {
- /* 0x0039 */
- .control_value = LE_1_UC | LE_TC_2_LLC_ELLC | LE_LRUM(3),
- /* 0x0030 */
- .l3cc_value = L3_3_WB,
- },
+ MOCS_ENTRY(I915_MOCS_CACHED,LE_1_UC | LE_TC_2_LLC_ELLC | LE_LRUM(3),
+ L3_3_WB)
};
/**
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 5/7] drm/i915: keep track of used entries in MOCS table
On 2019-01-22 06:12, Lucas De Marchi wrote:
Instead of considering we have defined entries for any index in the
table, let's keep track of the ones we explicitly defined. This will
allow Gen 11 to have it's new table defined in which we have holes of
undefined entries.
Repeated comments about the meaning of undefined entries were removed
since they are overly verbose and copy-pasted in several functions: now
the definition is in the top only.
Signed-off-by: Lucas De Marchi
Reviewed-by: Tomasz Lis
-Tomasz
---
drivers/gpu/drm/i915/intel_mocs.c | 88 ---
1 file changed, 57 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index faae2eefc5cc..af2ae2f396ae 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -28,6 +28,7 @@
struct drm_i915_mocs_entry {
u32 control_value;
u16 l3cc_value;
+ u16 used;
};
struct drm_i915_mocs_table {
@@ -75,6 +76,7 @@ struct drm_i915_mocs_table {
[__idx] = { \
.control_value = __control_value, \
.l3cc_value = __l3cc_value, \
+ .used = 1, \
}
/*
@@ -195,24 +197,26 @@ 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;
+ u32 unused_value;
if (!get_mocs_settings(dev_priv, &table))
return;
GEM_BUG_ON(table.size > GEN9_NUM_MOCS_ENTRIES);
- for (index = 0; index < table.size; index++)
- I915_WRITE(mocs_register(engine->id, index),
- table.table[index].control_value);
+ /* Set unused values to PTE */
+ unused_value = table.table[I915_MOCS_PTE].control_value;
- /*
-* Now set the unused entries to PTE. These entries are officially
-* undefined and no contract for the contents and settings is given
-* for these entries.
-*/
+ for (index = 0; index < table.size; index++) {
+ u32 value = table.table[index].used ?
+ table.table[index].control_value : unused_value;
+
+ I915_WRITE(mocs_register(engine->id, index), value);
+ }
+
+ /* All remaining entries are also unused */
for (; index < GEN9_NUM_MOCS_ENTRIES; index++)
- I915_WRITE(mocs_register(engine->id, index),
- table.table[I915_MOCS_PTE].control_value);
+ I915_WRITE(mocs_register(engine->id, index), unused_value);
}
/**
@@ -230,11 +234,15 @@ static int emit_mocs_control_table(struct i915_request
*rq,
{
enum intel_engine_id engine = rq->engine->id;
unsigned int index;
+ u32 unused_value;
u32 *cs;
if (WARN_ON(table->size > GEN9_NUM_MOCS_ENTRIES))
return -ENODEV;
+ /* Set unused values to PTE */
+ unused_value = table->table[I915_MOCS_PTE].control_value;
+
cs = intel_ring_begin(rq, 2 + 2 * GEN9_NUM_MOCS_ENTRIES);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -242,18 +250,17 @@ static int emit_mocs_control_table(struct i915_request
*rq,
*cs++ = MI_LOAD_REGISTER_IMM(GEN9_NUM_MOCS_ENTRIES);
for (index = 0; index < table->size; index++) {
+ u32 value = table->table[index].used ?
+ table->table[index].control_value : unused_value;
+
*cs++ = i915_mmio_reg_offset(mocs_register(engine, index));
- *cs++ = table->table[index].control_value;
+ *cs++ = value;
}
- /*
-* Now set the unused entries to PTE. These entries are officially
-* undefined and no contract for the contents and settings is given
-* for these entries.
-*/
+ /* All remaining entries are also unused */
for (; index < GEN9_NUM_MOCS_ENTRIES; index++) {
*cs++ = i915_mmio_reg_offset(mocs_register(engine, index));
- *cs++ = table->table[I915_MOCS_PTE].control_value;
+ *cs++ = unused_value;
}
*cs++ = MI_NOOP;
@@ -284,12 +291,15 @@ static inline u32 l3cc_combine(const struct
drm_i915_mocs_table *table,
static int emit_mocs_l3cc_table(struct i915_request *rq,
const struct drm_i915_mocs_table *table)
{
- unsigned int i;
+ unsigned int i, unused_index;
u32 *cs;
if (WARN_ON(table->size > GEN9_NUM_MOCS_ENTRIES))
return -ENODEV;
+ /* Set unused values to PTE */
+ unused_index = I915_MOCS_PTE;
+
cs = intel_ring_begin(rq, 2 + GEN9_NUM_MOCS_ENTRIES);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -297,25 +307,29 @@ static int emit_mocs_l3cc_table(struct i915_request *rq,
*cs++ = MI_LOAD_REGISTER_IMM(GEN9_NUM_MOCS_ENTRIES / 2);
for (i = 0; i < table->
[Intel-gfx] [PATCH] drm/i915/icl: Delay hotplug sequence for TC ports
Some unpowered USB type-c dongles requires some time to power on
before being able to process aux channel transactions.
It was not a problem for older platforms because there was a hardware
bridge between DDI/DP ports and type-c controller adding a implicit
delay that hid this issue but ICL have type-c controllers integrated
to the SOC, causing sinks to not be detected.
So here it test if DP type-c port is responsive before proceed with
hotplug sequence, it try 5 times with a 150ms of delay between tries
before giving up.
If unpowered TBT dongles shows up in the market this approach should
be extended to TBT ports too.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 4 +
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_hotplug.c | 108 +++
4 files changed, 115 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 03db011caa8e..3fd8c3fa6515 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2639,6 +2639,7 @@ enum hpd_pin intel_hpd_pin_default(struct
drm_i915_private *dev_priv,
enum port port);
bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
+void intel_hotplug_tc_wa_work(struct work_struct *work);
/* i915_irq.c */
static inline void i915_queue_hangcheck(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index b0bb8dfc2ed5..2c149843cacf 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -4258,6 +4258,10 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
goto err;
intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
+
+ if (IS_ICELAKE(dev_priv) && intel_port_is_tc(dev_priv, port))
+ INIT_DELAYED_WORK(&intel_dig_port->tc_wa_work,
+ intel_hotplug_tc_wa_work);
}
/* In theory we don't need the encoder->type check, but leave it just in
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 33b733d37706..fbb6f78ce733 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1242,6 +1242,8 @@ struct intel_digital_port {
enum intel_display_power_domain ddi_io_power_domain;
bool tc_legacy_port:1;
enum tc_port_type tc_type;
+ struct delayed_work tc_wa_work;
+ u8 tc_wa_count;
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index e027d2b4abe5..9838b60e8f63 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -342,6 +342,74 @@ static void i915_digport_work_func(struct work_struct
*work)
}
}
+#define TC_WA_DELAY_MSEC 150
+#define TC_WA_TRIES 5
+
+/*
+ * Test if type-c dongle is responsive return true if so otherwise schedule a
+ * work to try again and return false.
+ */
+static bool intel_hotplug_tc_wa_test(struct intel_digital_port *dig_port)
+{
+ struct intel_dp *intel_dp = &dig_port->dp;
+ u8 buffer;
+
+ dig_port->tc_wa_count++;
+
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_DPCD_REV, &buffer, 1) != 1)
+ goto not_responsive;
+
+ if (!drm_probe_ddc(&intel_dp->aux.ddc))
+ goto not_responsive;
+
+ return true;
+
+not_responsive:
+ if (dig_port->tc_wa_count < TC_WA_TRIES) {
+ const unsigned long delay = msecs_to_jiffies(TC_WA_DELAY_MSEC);
+
+ schedule_delayed_work(&dig_port->tc_wa_work, delay);
+ } else {
+ DRM_DEBUG_KMS("TC port not responsive, giving up\n");
+ }
+
+ return false;
+}
+
+void intel_hotplug_tc_wa_work(struct work_struct *work)
+{
+ struct delayed_work *delayed_work = to_delayed_work(work);
+ struct intel_digital_port *dig_port = container_of(delayed_work,
+ struct
intel_digital_port,
+ tc_wa_work);
+ struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+ struct intel_encoder *intel_encoder = &dig_port->base;
+ struct intel_dp *intel_dp = &dig_port->dp;
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_device *dev = &dev_priv->drm;
+ intel_wakeref_t wakeref;
+ bool ret;
+
+ wakeref = intel_runtime_pm_get(dev_priv);
+
+ if (!intel_digital_port_connected(intel_encoder) ||
+ dig_port->tc_type != TC_PORT_TYPEC
Re: [Intel-gfx] [PATCH v8 4/7] drm/i915: use a macro to define MOCS entries
On Tue, Jan 22, 2019 at 09:37:02PM +, Chris Wilson wrote: Quoting Lucas De Marchi (2019-01-22 21:33:25) On Tue, Jan 22, 2019 at 6:32 AM Chris Wilson wrote: > > Quoting Lucas De Marchi (2019-01-22 05:12:24) > > Let's use a macro to make tables smaller and at the same time allow us > > to add fields that apply to all entries in future. > > > > For the sake of readability, I'm calling an exception on 80 chars limit. > > Lines are aligned for easy comparison of the entry values. > > > + MOCS_ENTRY(I915_MOCS_UNCACHED, LE_1_UC | LE_TC_2_LLC_ELLC, \ > > + L3_1_UC), \ > > MOCS_ENTRY(I915_MOCS_UNCACHED, > LE_1_UC | LE_TC_2_LLC_ELLC, L3_1_UC), \ My intention was to split the lines for each *value*, so it's easy to see what control_value vs l3cc_value is set to (too difficult to spot mistakes on adding a comma rather than a |). But I'm not strongly against your version, so I'll switch to that. Have another new line :) Because you are right as I confused that \ for a |. MOCS_ENTRY(I915_MOCS_UNCACHED, \ LE_1_UC | LE_TC_2_LLC_ELLC, \ L3_1_UC), \ ok. The Ice Lake table is huge (see last patch) and this will mandate 3 lines per entry, but at least it will be clear. Lucas De Marchi -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
