Re: [Intel-gfx] [PATCH] RFC: i915: Drop relocation support on Gen12+
Quoting Dave Airlie (2020-05-07 21:27:27) > On Fri, 8 May 2020 at 01:44, Chris Wilson wrote: > > > > Quoting Jason Ekstrand (2020-05-07 16:36:00) > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if > > > it's running on a version of i915 that supports at least softpin which > > > all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is > > > only supported by iris which never uses relocations. The older i965 > > > driver in Mesa does use relocations but it only supports Intel hardware > > > through Gen11 and has been deprecated for all hardware Gen9+. The entire > > > relocation UAPI and related infrastructure, therefore, doesn't have any > > > open-source userspace consumer starting with Gen12. > > > > > > Rejecting relocations starting with Gen12 has the benefit that we don't > > > have to bother supporting it on platforms with local memory. Given how > > > much CPU touching of memory is required for relocations, not having to > > > do so on platforms where not all memory is directly CPU-accessible > > > carries significant advantages. > > > > You are not supplying them, the kernel is not checking them [as they > > don't exist], so there is no material benefit. The only question is > > maintainability. > > > > How confident are you that you will never use them and rewrite the > > media-driver? The code exists, will be tested, and can just as easily > > expire with the rest of execbuffer2. > > From an upstream POV I say hell yes, if the hw isn't generally available yet, > and the media-driver/intel-compute-runtime people are warned in advance, > > I'm all in on ripping it out for new GENs. There have been discussions with our media driver team about eliminating any relocations, but today they are still being used. They have started partially using soft-pinning, which is a great first step to that direction. The compute driver does not rely on relocations, they use soft-pinning everywhere and explicitly manage the address space. Be assured that I'm also in favor of eliminating relocations (just like execbuffer2, userptr and couple other things), just that we still need to have a functional stack before they can be dropped for new hardware. Like Chris mentioned, enough optimization have been put in the code so that there is zero impact from the relocations to the exclusively soft-pinning drivers. So the sole benefit would be being able to drop the relocations code in the future when the Gen11 hardware has gone exctinct and that is a worthy goal, too. But for now the feature is still needed for Gen12, so forcefully disabling it is untimely. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes drm-intel-fixes-2020-05-07: - Fixes on execlist to avoid GPU hang situation (Chris) - Fixes couple deadlocks (Chris) - Timeslice preemption fixes (Chris) - Fix Display Port interrupt handling on Tiger Lake (Imre) - Reduce debug noise around Frame Buffer Compression (Peter) - Fix logic around IPC W/a for Coffee Lake and Kaby Lake (Sultan) - Avoid dereferencing a dead context (Chris) Thanks, Rodrigo. The following changes since commit 8598eb781cf68fd6cb67c479f1479ae58bd54fb9: drm/i915: Use proper fault mask in interrupt postinstall too (2020-04-28 16:38:03 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-05-07 for you to fetch changes up to 1bc6a60143a4f9264cc6e09ceb9919f4e813a872: drm/i915/execlists: Track inflight CCID (2020-05-06 15:37:59 -0700) - Fixes on execlist to avoid GPU hang situation (Chris) - Fixes couple deadlocks (Chris) - Timeslice preemption fixes (Chris) - Fix Display Port interrupt handling on Tiger Lake (Imre) - Reduce debug noise around Frame Buffer Compression (Peter) - Fix logic around IPC W/a for Coffee Lake and Kaby Lake (Sultan) - Avoid dereferencing a dead context (Chris) Chris Wilson (7): drm/i915: Avoid dereferencing a dead context drm/i915/gt: Make timeslicing an explicit engine property drm/i915: Check current i915_vma.pin_count status first on unbind drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore drm/i915/gem: Remove object_is_locked assertion from unpin_from_display_plane drm/i915/execlists: Avoid reusing the same logical CCID drm/i915/execlists: Track inflight CCID Imre Deak (1): drm/i915/tgl+: Fix interrupt handling for DP AUX transactions Peter Jones (1): Make the "Reducing compressed framebufer size" message be DRM_INFO_ONCE() Sultan Alsawaf (1): drm/i915: Don't enable WaIncreaseLatencyIPCEnabled when IPC is disabled drivers/gpu/drm/i915/display/intel_fbc.c | 3 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 7 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 8 +- drivers/gpu/drm/i915/gt/intel_engine.h| 9 -- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 ++ drivers/gpu/drm/i915/gt/intel_engine_types.h | 35 +-- drivers/gpu/drm/i915/gt/intel_gt_irq.c| 15 ++- drivers/gpu/drm/i915/gt/intel_lrc.c | 117 ++ drivers/gpu/drm/i915/gt/selftest_lrc.c| 34 --- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +- drivers/gpu/drm/i915/gvt/scheduler.c | 4 +- drivers/gpu/drm/i915/i915_gpu_error.c | 12 ++- drivers/gpu/drm/i915/i915_irq.c | 16 +-- drivers/gpu/drm/i915/i915_perf.c | 6 +- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/i915_vma.c | 25 ++--- drivers/gpu/drm/i915/intel_pm.c | 2 +- drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- 18 files changed, 180 insertions(+), 124 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build failure after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from include/asm-generic/bug.h:19,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/seq_file.h:7,
from include/drm/drm_print.h:31,
from drivers/gpu/drm/i915/gt/intel_engine_cs.c:25:
drivers/gpu/drm/i915/gt/intel_engine_cs.c: In function
'intel_engine_print_registers':
drivers/gpu/drm/i915/gt/intel_engine_cs.c:1428:31: error: 'struct
intel_context' has no member named 'lrc_desc'
1428 | upper_32_bits(rq->context->lrc_desc));
| ^~
drivers/gpu/drm/i915/gt/intel_engine_cs.c:1440:31: error: 'struct
intel_context' has no member named 'lrc_desc'
1440 | upper_32_bits(rq->context->lrc_desc));
| ^~
In file included from include/linux/interrupt.h:6,
from drivers/gpu/drm/i915/gt/intel_lrc.c:134:
drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'active_context':
drivers/gpu/drm/i915/gt/intel_lrc.c:2850:32: error: 'struct intel_context' has
no member named 'lrc_desc'
2850 | if (upper_32_bits(rq->context->lrc_desc) == ccid) {
|^~
drivers/gpu/drm/i915/gt/intel_lrc.c:2859:32: error: 'struct intel_context' has
no member named 'lrc_desc'
2859 | if (upper_32_bits(rq->context->lrc_desc) == ccid) {
|^~
Caused by commit
53b2622e7746 ("drm/i915/execlists: Avoid reusing the same logical CCID")
from the drm-intel-fixes tree interacting with commits
606727842d8b ("drm/i915/gt: Include the execlists CCID of each port in the
engine dump")
4c977837ba29 ("drm/i915/execlists: Peek at the next submission for error
interrupts")
from the drm tree.
I have added teh following merge fix patch.
From: Stephen Rothwell
Date: Fri, 8 May 2020 14:21:40 +1000
Subject: [PATCH] drm/i915/execlists: fix up for "Avoid reusing the same logical
CCID"
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index b1f8527f02c8..7c3cb5aedfdf 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1425,7 +1425,7 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
len = scnprintf(hdr, sizeof(hdr),
"\t\tActive[%d]: ccid:%08x, ",
(int)(port - execlists->active),
- upper_32_bits(rq->context->lrc_desc));
+ rq->context->lrc.ccid);
len += print_ring(hdr + len, sizeof(hdr) - len, rq);
scnprintf(hdr + len, sizeof(hdr) - len, "rq: ");
print_request(m, rq, hdr);
@@ -1437,7 +1437,7 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
len = scnprintf(hdr, sizeof(hdr),
"\t\tPending[%d]: ccid:%08x, ",
(int)(port - execlists->pending),
- upper_32_bits(rq->context->lrc_desc));
+ rq->context->lrc.ccid);
len += print_ring(hdr + len, sizeof(hdr) - len, rq);
scnprintf(hdr + len, sizeof(hdr) - len, "rq: ");
print_request(m, rq, hdr);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 233f815c3c86..456d286c17dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2847,7 +2847,7 @@ active_context(struct intel_engine_cs *engine, u32 ccid)
*/
for (port = el->active; (rq = *port); port++) {
- if (upper_32_bits(rq->context->lrc_desc) == ccid) {
+ if (rq->context->lrc.ccid == ccid) {
ENGINE_TRACE(engine,
"ccid found at active:%zd\n",
port - el->active);
@@ -2856,7 +2856,7 @@ active_context(struct intel_engine_cs *engine, u32 ccid)
}
for (port = el->pending; (rq = *port); port++) {
- if (upper_32_bits(rq->context->lrc_desc) == ccid) {
+ if (rq->context->lrc.ccid == ccid) {
ENGINE_TRACE(engine,
"ccid found at pending:%zd\n",
port - el->pending);
--
2.26.2
--
Cheers,
Stephen Rothwell
pgptOucd_2E8Z.pgp
Description: OpenPGP digital signature
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/gem/i915_gem_domain.c
between commit:
47bf7b7a7151 ("drm/i915/gem: Remove object_is_locked assertion from
unpin_from_display_plane")
from the drm-intel-fixes tree and commit:
9da0ea09639f ("drm/i915/gem: Drop cached obj->bind_count")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 4f96c8788a2e,af43e82f45c7..
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@@ -368,7 -368,8 +368,7 @@@ static void i915_gem_object_bump_inacti
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct i915_vma *vma;
- if (!atomic_read(>bind_count))
- GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
+ if (list_empty(>vma.list))
return;
mutex_lock(>ggtt.vm.mutex);
pgp27p62Ao_BG.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v11 14/14] drm/i915/psr: Use new DP VSC SDP compute routine on PSR
Hi Gwan-gyeong,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
next-20200507]
[cannot apply to tegra-drm/drm/tegra/for-next linus/master v5.7-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Gwan-gyeong-Mun/In-order-to-readout-DP-SDPs-refactors-the-handling-of-DP-SDPs/20200508-034404
base: git://anongit.freedesktop.org/drm-intel for-linux-next
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
New smatch warnings:
drivers/gpu/drm/i915/display/intel_psr.c:727 intel_psr_compute_config() warn:
inconsistent indenting
Old smatch warnings:
drivers/gpu/drm/i915/display/intel_psr.c:1564 intel_psr_short_pulse() error:
uninitialized symbol 'error_status'.
drivers/gpu/drm/i915/display/intel_psr.c:1569 intel_psr_short_pulse() error:
uninitialized symbol 'error_status'.
vim +727 drivers/gpu/drm/i915/display/intel_psr.c
711
712 void intel_psr_compute_config(struct intel_dp *intel_dp,
713struct intel_crtc_state *crtc_state)
714 {
715 struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
716 struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
717 const struct drm_display_mode *adjusted_mode =
718 _state->hw.adjusted_mode;
719 int psr_setup_time;
720
721 if (!CAN_PSR(dev_priv))
722 return;
723
724 if (intel_dp != dev_priv->psr.dp)
725 return;
726
> 727 if (!psr_global_enabled(dev_priv))
728 return;
729 /*
730 * HSW spec explicitly says PSR is tied to port A.
731 * BDW+ platforms have a instance of PSR registers per
transcoder but
732 * for now it only supports one instance of PSR, so lets keep it
733 * hardcoded to PORT_A
734 */
735 if (dig_port->base.port != PORT_A) {
736 drm_dbg_kms(_priv->drm,
737 "PSR condition failed: Port not
supported\n");
738 return;
739 }
740
741 if (dev_priv->psr.sink_not_reliable) {
742 drm_dbg_kms(_priv->drm,
743 "PSR sink implementation is not
reliable\n");
744 return;
745 }
746
747 if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
748 drm_dbg_kms(_priv->drm,
749 "PSR condition failed: Interlaced mode
enabled\n");
750 return;
751 }
752
753 psr_setup_time = drm_dp_psr_setup_time(intel_dp->psr_dpcd);
754 if (psr_setup_time < 0) {
755 drm_dbg_kms(_priv->drm,
756 "PSR condition failed: Invalid PSR setup
time (0x%02x)\n",
757 intel_dp->psr_dpcd[1]);
758 return;
759 }
760
761 if (intel_usecs_to_scanlines(adjusted_mode, psr_setup_time) >
762 adjusted_mode->crtc_vtotal - adjusted_mode->crtc_vdisplay -
1) {
763 drm_dbg_kms(_priv->drm,
764 "PSR condition failed: PSR setup time (%d
us) too long\n",
765 psr_setup_time);
766 return;
767 }
768
769 crtc_state->has_psr = true;
770 crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp,
crtc_state);
771 crtc_state->infoframes.enable |=
intel_hdmi_infoframe_enable(DP_SDP_VSC);
772 }
773
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/mst: filter out the display mode exceed sink's capability
On Thu, 2020-04-30 at 02:37 +, Lee, Shawn C wrote:
> On Sat, 2020-04-25, Lyude Paul wrote:
> > Hi! Sorry this took me a little while to get back to, I had a couple of
> > MST regressions that I had to look into
> >
> > On Sat, 2020-04-18 at 05:24 +0800, Lee Shawn C wrote:
> > > So far, max dot clock rate for MST mode rely on physcial bandwidth
> > > limitation. It would caused compatibility issue if source display
> > > resolution exceed MST hub output ability.
> > >
> > > For example, source DUT had DP 1.2 output capability.
> > > And MST docking just support HDMI 1.4 spec. When a HDMI 2.0 monitor
> > > connected. Source would retrieve EDID from external and get max
> > > resolution 4k@60fps. DP 1.2 can support 4K@60fps because it did not
> > > surpass DP physical bandwidth limitation.
> > > Do modeset to 4k@60fps, source output display data but MST docking
> > > can't output HDMI properly due to this resolution already over HDMI
> > > 1.4 spec.
> > >
> > > Refer to commit ("drm/dp_mst: Use full_pbn instead of
> > > available_pbn for bandwidth checks").
> > > Source driver should refer to full_pbn to evaluate sink output
> > > capability. And filter out the resolution surpass sink output
> > > limitation.
> > >
> > > Cc: Manasi Navare
> > > Cc: Jani Nikula
> > > Cc: Ville Syrjala
> > > Cc: Cooper Chiou
> > > Cc: Lyude Paul
> > > Signed-off-by: Lee Shawn C
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 24
> > > -
> > > 1 file changed, 23 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > index 61605eb8c2af..68697f463dab 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > @@ -609,6 +609,26 @@ static int intel_dp_mst_get_modes(struct
> > > drm_connector
> > > *connector)
> > > return intel_dp_mst_get_ddc_modes(connector);
> > > }
> > >
> > > +static bool
> > > +intel_dp_mst_mode_clock_exceed_pbn_bandwidth(struct drm_connector
> > > *connector, int clock, int bpp)
> > > +{
> > > + struct intel_connector *intel_connector =
> > > to_intel_connector(connector);
> > > + struct intel_dp *intel_dp = intel_connector->mst_port;
> > > + struct drm_dp_mst_topology_mgr *mgr = _dp->mst_mgr;
> > > + struct drm_dp_mst_port *port = (to_intel_connector(connector))->port;
> > > + bool ret = false;
> > > +
> > > + if (!mgr)
> > > + return ret;
> > > +
> > > + mutex_lock(>lock);
> >
> > This isn't the right lock for this - mgr->lock protects the topology
> > layout (e.g. drm_dp_mst_port.mstb, drm_dp_mst_port.next, and
> > drm_dp_mst_branch.ports). port->full_pbn is protected under
> > _dp_mst_topology_mgr.base.lock (not drm_dp_mst_topology_mgr.lock), so
> > you need to first add a version of .mode_valid() to struct
> > drm_connector_helper_funcs that accepts a drm_modeset_acquire_ctx so you
> > can use that to safely grab _dp_mst_topology_mgr.base.lock.
> >
>
> Thanks for comments! I will correct the lock to protect port->full_pbn.
>
> > > + if (port->full_pbn)
> >
> > Also - there's no reason to check if (port->full_pbn) here, so long as
> > you're holding the right locks this should always be populated by the time
> > we create the drm_connector for the MST port (if it's not, that's a bug
> > that needs to be fixed).
> >
>
> Just want to make sure full_pbn value is greater than zero. As you mention
> in another patch, it's hard to predict sink report full or available PBN
> properly.
Sorry this took me a little while to respond to, crunch time came up at work…
Anyway-have you seen issues with full_pbn reporting on hubs? I've seen plenty
of problems with available_pbn reporting, but the reason we switched over to
full_pbn in the first place is because that seemed to be the one hubs reported
reliably. We actually make the assumption full_pbn is always > 0 if
something's connected in some places in the MST helpers, so if we've got cases
of full_pbn lying as well on some hubs we might want to fix that.
>
> > > + ret = (drm_dp_calc_pbn_mode(clock, bpp, false) > port-
> > > > full_pbn);
> >
> > Finally - I'd say we should probably have a separate patch to add a helper
> > for calculating the PBN and checking it against port->full_pbn. Maybe
> > something that looks like this:
> >
> > int drm_dp_mst_mode_valid(struct drm_dp_mst_port *port, struct
> > drm_modeset_acquire_ctx *ctx, int clock, int bpp) {
> > int ret = MODE_VALID;
> > /* TODO: DSC support */
> >
> > /* ...try grabbing locks here...*/
> > if (drm_dp_calc_pbn_mode(clock, bpp, false) > port->full_pbn)
> > ret = MODE_CLOCK_HIGH;
> >
> > return ret;
> > }
> >
> > That way we might be able to add some checks for DSC capable connectors
> > later once I've migrated most of the DSC code from amdgpu into the MST
> > helpers
>
> This sounds good. DRM driver provide a public
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gen12: Invalidate aux table entries forcibly
On Wed, May 06, 2020 at 04:32:02PM +0100, Chris Wilson wrote: > Quoting Mika Kuoppala (2020-05-06 16:20:22) > > Chris Wilson writes: > > > > > Quoting Mika Kuoppala (2020-05-06 15:47:34) > > >> Aux table invalidation can fail on update. So > > >> next access may cause memory access to be into stale entry. > > >> > > >> Proposed workaround is to invalidate entries between > > >> all batchbuffers. > > > > > > This sounds like it should have a sunset clause. Do we anticipate being > > > able to drop this w/a in future? > > > > Rafael kindly pointed out that Mesa already does this: > > https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gallium/drivers/iris/iris_state.c#L5131 > > So I would say we can drop this patch. > > Is the false hit self-contained? Is it caused by PTE update of the > address or by a 3D state change i.e. is it a potential isolation issue? > -Chris There's no 3D state for the aux table. What we do in Iris is: - allocate buffers and cpu map them - write the multiple levels of the table (main buffers -> CCS buffers) and keep track of when it changes - whenever it changes, we emit LRI to 0x4208 to invalidate the cache. Anv does something similar except it writes to the table from the GPU. I tried removing the heuristics and invalidating the table on the beginning of every batch, but it doesn't help. We can probably get preempted mid-batch and then another context with a different aux table and the wrong cache is probably causing the hang. The kernel invalidating it seems to fix the problem. > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gen12: Add aux table invalidate for all engines
On 5/7/20 7:20 AM, Mika Kuoppala wrote:
All engines, exception being blitter as it does not
care about the form, can access compressed surfaces.
So we need to add forced aux table invalidates
for those engines.
v2: virtual instance masking (Chris)
v3: bug on if not found (Chris)
References: d248b371f747 ("drm/i915/gen12: Invalidate aux table entries
forcibly")
References bspec#43904, hsdes#1809175790
Cc: Chris Wilson
Cc: Chuansheng Liu
Cc: Rafael Antognolli
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 86 +++--
drivers/gpu/drm/i915/i915_reg.h | 6 ++
2 files changed, 87 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index bbdb0e2a4571..e12916e2799b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4539,11 +4539,36 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
+static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
+{
+ static const i915_reg_t vd[] = {
+ GEN12_VD0_AUX_NV,
+ GEN12_VD1_AUX_NV,
+ GEN12_VD2_AUX_NV,
+ GEN12_VD3_AUX_NV,
+ };
+
+ static const i915_reg_t ve[] = {
+ GEN12_VE0_AUX_NV,
+ GEN12_VE1_AUX_NV,
+ };
+
+ if (engine->class == VIDEO_DECODE_CLASS)
+ return vd[engine->instance];
+
+ if (engine->class == VIDEO_ENHANCEMENT_CLASS)
+ return ve[engine->instance];
+
+ GEM_BUG_ON("unknown aux_inv_reg\n");
+
+ return INVALID_MMIO_REG;
+}
+
static u32 *
-gen12_emit_aux_table_inv(struct i915_request *rq, u32 *cs)
+gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
{
*cs++ = MI_LOAD_REGISTER_IMM(1);
- *cs++ = i915_mmio_reg_offset(GEN12_GFX_CCS_AUX_NV);
+ *cs++ = i915_mmio_reg_offset(inv_reg);
*cs++ = AUX_INV;
*cs++ = MI_NOOP;
@@ -4612,7 +4637,7 @@ static int gen12_emit_flush_render(struct i915_request *request,
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
/* hsdes: 1809175790 */
- cs = gen12_emit_aux_table_inv(request, cs);
+ cs = gen12_emit_aux_table_inv(GEN12_GFX_CCS_AUX_NV, cs);
*cs++ = preparser_disable(false);
intel_ring_advance(request, cs);
@@ -4621,6 +4646,56 @@ static int gen12_emit_flush_render(struct i915_request
*request,
return 0;
}
+static int gen12_emit_flush(struct i915_request *request, u32 mode)
+{
+ intel_engine_mask_t aux_inv = 0;
+ u32 cmd, *cs;
+
+ if (mode & EMIT_INVALIDATE)
+ aux_inv = request->engine->mask & ~BIT(BCS0);
+
+ cs = intel_ring_begin(request,
+ 4 + (aux_inv ? 2 * hweight8(aux_inv) + 2 : 0));
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ cmd = MI_FLUSH_DW + 1;
+
+ /* We always require a command barrier so that subsequent
+* commands, such as breadcrumb interrupts, are strictly ordered
+* wrt the contents of the write cache being flushed to memory
+* (and thus being coherent from the CPU).
+*/
+ cmd |= MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW;
+
+ if (mode & EMIT_INVALIDATE) {
+ cmd |= MI_INVALIDATE_TLB;
+ if (request->engine->class == VIDEO_DECODE_CLASS)
+ cmd |= MI_INVALIDATE_BSD;
+ }
+
+ *cs++ = cmd;
+ *cs++ = LRC_PPHWSP_SCRATCH_ADDR;
+ *cs++ = 0; /* upper addr */
+ *cs++ = 0; /* value */
+
+ if (aux_inv) { /* hsdes: 1809175790 */
+ struct intel_engine_cs *engine;
+ unsigned int tmp;
+
+ *cs++ = MI_LOAD_REGISTER_IMM(hweight8(aux_inv));
+ for_each_engine_masked(engine, request->engine->gt,
+ aux_inv, tmp) {
+ *cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
+ *cs++ = AUX_INV;
Why do we loop through all engines? AFAICS the WA just says to
invalidate the current one. If it is because we don't know what we're
running on, can't we just use the automatic mmio remap on the CS? That
was added on purpose for per-engine registers that are not relative to
the mmio base (see bspec 45606)
Daniele
+ }
+ *cs++ = MI_NOOP;
+ }
+ intel_ring_advance(request, cs);
+
+ return 0;
+}
+
/*
* Reserve space for 2 NOOPs at the end of each request to be
* used as a workaround for not being allowed to do lite
@@ -4854,9 +4929,10 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
engine->emit_flush = gen8_emit_flush;
engine->emit_init_breadcrumb = gen8_emit_init_breadcrumb;
engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb;
- if (INTEL_GEN(engine->i915)
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2] drm/i915: Mark concurrent submissions with a weak-dependency (rev3)
== Series Details == Series: series starting with [v2] drm/i915: Mark concurrent submissions with a weak-dependency (rev3) URL : https://patchwork.freedesktop.org/series/77045/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8444_full -> Patchwork_17606_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17606_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17606_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17606_full: ### IGT changes ### Possible regressions * igt@perf@oa-exponents: - shard-apl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-apl6/igt@p...@oa-exponents.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/shard-apl6/igt@p...@oa-exponents.html New tests - New tests have been introduced between CI_DRM_8444_full and Patchwork_17606_full: ### New IGT tests (12) ### * igt@gem_exec_fence@submit3@bcs0: - Statuses : 6 pass(s) - Exec time: [0.00, 0.03] s * igt@gem_exec_fence@submit3@vcs0: - Statuses : 6 pass(s) - Exec time: [0.00, 0.03] s * igt@gem_exec_fence@submit3@vcs1: - Statuses : 2 pass(s) - Exec time: [0.01] s * igt@gem_exec_fence@submit3@vecs0: - Statuses : 6 pass(s) - Exec time: [0.00, 0.03] s * igt@gem_exec_fence@submit67@bcs0: - Statuses : 2 pass(s) - Exec time: [0.54, 0.72] s * igt@gem_exec_fence@submit67@vcs0: - Statuses : 2 pass(s) - Exec time: [0.56, 0.68] s * igt@gem_exec_fence@submit67@vcs1: - Statuses : 2 pass(s) - Exec time: [0.57, 0.70] s * igt@gem_exec_fence@submit67@vecs0: - Statuses : 2 pass(s) - Exec time: [0.56, 0.70] s * igt@gem_exec_fence@submit@bcs0: - Statuses : 6 pass(s) - Exec time: [0.00, 0.06] s * igt@gem_exec_fence@submit@vcs0: - Statuses : 6 pass(s) - Exec time: [0.00, 0.05] s * igt@gem_exec_fence@submit@vcs1: - Statuses : 2 pass(s) - Exec time: [0.01] s * igt@gem_exec_fence@submit@vecs0: - Statuses : 6 pass(s) - Exec time: [0.01, 0.06] s Known issues Here are the changes found in Patchwork_17606_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled: - shard-apl: [PASS][3] -> [FAIL][4] ([i915#52] / [i915#54] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-apl2/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/shard-apl8/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#49]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-glk1/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/shard-glk2/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-kbl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/shard-kbl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#108145] / [i915#265]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/shard-iclb3/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_setmode@basic: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#31]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-apl7/igt@kms_setm...@basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/shard-apl7/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-apl:
[Intel-gfx] ✓ Fi.CI.IGT: success for SAGV support for Gen12+ (rev36)
== Series Details == Series: SAGV support for Gen12+ (rev36) URL : https://patchwork.freedesktop.org/series/75129/ State : success == Summary == CI Bug Log - changes from CI_DRM_8444_full -> Patchwork_17603_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17603_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@kms: - shard-glk: [PASS][1] -> [TIMEOUT][2] ([i915#1383]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-glk2/igt@gem_...@kms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/shard-glk9/igt@gem_...@kms.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-apl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@pipe-c-torture-move: - shard-iclb: [PASS][5] -> [DMESG-WARN][6] ([i915#128]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-iclb8/igt@kms_cursor_leg...@pipe-c-torture-move.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/shard-iclb5/igt@kms_cursor_leg...@pipe-c-torture-move.html * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#49]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-glk1/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/shard-glk7/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#69]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-skl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/shard-skl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#173]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-iclb2/igt@kms_psr@no_drrs.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/shard-iclb1/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_psr@suspend: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([i915#198]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-skl4/igt@kms_...@suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/shard-skl6/igt@kms_...@suspend.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([i915#31]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-apl7/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/shard-apl4/igt@kms_setm...@basic.html Possible fixes * igt@gem_workarounds@suspend-resume-context: - shard-apl: [DMESG-WARN][23] ([i915#180]) -> [PASS][24] +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-apl8/igt@gem_workarou...@suspend-resume-context.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/shard-apl1/igt@gem_workarou...@suspend-resume-context.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [FAIL][25] ([i915#72]) -> [PASS][26] +1 similar issue [25]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mst: Wait for ACT sent before enabling the pipe
== Series Details ==
Series: drm/i915/mst: Wait for ACT sent before enabling the pipe
URL : https://patchwork.freedesktop.org/series/77040/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8444_full -> Patchwork_17602_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17602_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][1] -> [FAIL][2] ([i915#454])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-iclb8/igt@i915_pm...@dc6-psr.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/shard-iclb3/igt@i915_pm...@dc6-psr.html
* igt@i915_suspend@sysfs-reader:
- shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-apl8/igt@i915_susp...@sysfs-reader.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/shard-apl6/igt@i915_susp...@sysfs-reader.html
* igt@kms_color@pipe-a-ctm-green-to-red:
- shard-skl: [PASS][5] -> [FAIL][6] ([i915#129])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-skl5/igt@kms_co...@pipe-a-ctm-green-to-red.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/shard-skl8/igt@kms_co...@pipe-a-ctm-green-to-red.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +5 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html
* igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled:
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#52] / [i915#54] /
[i915#95])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-apl2/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/shard-apl2/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#49])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-glk1/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/shard-glk6/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265])
+1 similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-skl10/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
* igt@kms_psr@psr2_sprite_mmap_gtt:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/shard-iclb6/igt@kms_psr@psr2_sprite_mmap_gtt.html
Possible fixes
* igt@gem_workarounds@suspend-resume-context:
- shard-apl: [DMESG-WARN][17] ([i915#180]) -> [PASS][18] +4
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-apl8/igt@gem_workarou...@suspend-resume-context.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/shard-apl3/igt@gem_workarou...@suspend-resume-context.html
* igt@kms_cursor_legacy@pipe-c-torture-bo:
- shard-hsw: [DMESG-WARN][19] ([i915#128]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-hsw5/igt@kms_cursor_leg...@pipe-c-torture-bo.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/shard-hsw4/igt@kms_cursor_leg...@pipe-c-torture-bo.html
* igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled:
- shard-kbl: [FAIL][21] ([i915#177] / [i915#52] / [i915#54] /
[i915#93] / [i915#95]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-kbl7/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/shard-kbl2/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html
* {igt@kms_flip@flip-vs-rmfb-interruptible@c-vga1}:
- shard-hsw: [INCOMPLETE][23] ([i915#61]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-hsw4/igt@kms_flip@flip-vs-rmfb-interrupti...@c-vga1.html
[24]:
Re: [Intel-gfx] [PATCH] RFC: i915: Drop relocation support on Gen12+
On Fri, 8 May 2020 at 01:44, Chris Wilson wrote: > > Quoting Jason Ekstrand (2020-05-07 16:36:00) > > The Vulkan driver in Mesa for Intel hardware never uses relocations if > > it's running on a version of i915 that supports at least softpin which > > all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is > > only supported by iris which never uses relocations. The older i965 > > driver in Mesa does use relocations but it only supports Intel hardware > > through Gen11 and has been deprecated for all hardware Gen9+. The entire > > relocation UAPI and related infrastructure, therefore, doesn't have any > > open-source userspace consumer starting with Gen12. > > > > Rejecting relocations starting with Gen12 has the benefit that we don't > > have to bother supporting it on platforms with local memory. Given how > > much CPU touching of memory is required for relocations, not having to > > do so on platforms where not all memory is directly CPU-accessible > > carries significant advantages. > > You are not supplying them, the kernel is not checking them [as they > don't exist], so there is no material benefit. The only question is > maintainability. > > How confident are you that you will never use them and rewrite the > media-driver? The code exists, will be tested, and can just as easily > expire with the rest of execbuffer2. >From an upstream POV I say hell yes, if the hw isn't generally available yet, and the media-driver/intel-compute-runtime people are warned in advance, I'm all in on ripping it out for new GENs. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gen12: Add aux table invalidate for all engines (rev2)
== Series Details ==
Series: drm/i915/gen12: Add aux table invalidate for all engines (rev2)
URL : https://patchwork.freedesktop.org/series/77038/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8444_full -> Patchwork_17601_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17601_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17601_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17601_full:
### IGT changes ###
Possible regressions
* igt@gem_ctx_persistence@engines-queued@vcs1:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-tglb6/igt@gem_ctx_persistence@engines-que...@vcs1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/shard-tglb2/igt@gem_ctx_persistence@engines-que...@vcs1.html
* igt@gem_exec_balancer@bonded-slice:
- shard-kbl: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-kbl7/igt@gem_exec_balan...@bonded-slice.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/shard-kbl1/igt@gem_exec_balan...@bonded-slice.html
* igt@runner@aborted:
- shard-kbl: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/shard-kbl1/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_flip@dpms-vs-vblank-race@c-hdmi-a1}:
- shard-glk: [PASS][6] -> [FAIL][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-glk8/igt@kms_flip@dpms-vs-vblank-r...@c-hdmi-a1.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/shard-glk5/igt@kms_flip@dpms-vs-vblank-r...@c-hdmi-a1.html
Known issues
Here are the changes found in Patchwork_17601_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_workarounds@suspend-resume-fd:
- shard-kbl: [PASS][8] -> [DMESG-WARN][9] ([i915#180]) +1 similar
issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-kbl3/igt@gem_workarou...@suspend-resume-fd.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/shard-kbl4/igt@gem_workarou...@suspend-resume-fd.html
* igt@kms_color@pipe-a-ctm-green-to-red:
- shard-skl: [PASS][10] -> [FAIL][11] ([i915#129])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-skl5/igt@kms_co...@pipe-a-ctm-green-to-red.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/shard-skl7/igt@kms_co...@pipe-a-ctm-green-to-red.html
* igt@kms_cursor_legacy@all-pipes-torture-bo:
- shard-tglb: [PASS][12] -> [DMESG-WARN][13] ([i915#128])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-tglb7/igt@kms_cursor_leg...@all-pipes-torture-bo.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/shard-tglb8/igt@kms_cursor_leg...@all-pipes-torture-bo.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: [PASS][14] -> [FAIL][15] ([i915#49])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-glk1/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/shard-glk6/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][16] -> [FAIL][17] ([i915#1188])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-skl5/igt@kms_...@bpc-switch-suspend.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/shard-skl7/igt@kms_...@bpc-switch-suspend.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][18] -> [FAIL][19] ([fdo#108145] / [i915#265])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_sprite_mmap_gtt:
- shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) +4 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/shard-iclb6/igt@kms_psr@psr2_sprite_mmap_gtt.html
* igt@kms_setmode@basic:
- shard-apl:
Re: [Intel-gfx] [PATCH v2 14/22] drm/i915/rkl: provide port/phy mapping for vbt
On Thu, May 07, 2020 at 03:04:30PM +0300, Ville Syrjälä wrote:
> On Mon, May 04, 2020 at 03:52:19PM -0700, Matt Roper wrote:
> > From: Lucas De Marchi
> >
> > RKL uses the DDI A, DDI B, DDI USBC1, DDI USBC2 from the DE point of
> > view, so all DDI/pipe/transcoder register use these indexes to refer to
> > them. Combo phy and IO functions follow another namespace that we keep
> > as "enum phy". The VBT in theory would use the DE point of view, but
> > that does not happen in practice.
> >
> > Provide a table to convert the child devices to the "correct" port
> > numbering we use. Now this is the output we get while reading the VBT:
> >
> > DDIA:
> > [drm:intel_bios_port_aux_ch [i915]] using AUX A for port A (VBT)
> > [drm:intel_dp_init_connector [i915]] Adding DP connector on
> > [ENCODER:275:DDI A]
> > [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on
> > [ENCODER:275:DDI A]
> > [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x1 for port A (VBT)
> >
> > DDIB:
> > [drm:intel_bios_port_aux_ch [i915]] using AUX B for port B (platform
> > default)
> > [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on
> > [ENCODER:291:DDI B]
> > [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x2 for port B (VBT)
> >
> > DDI USBC1:
> > [drm:intel_bios_port_aux_ch [i915]] using AUX D for port D (VBT)
> > [drm:intel_dp_init_connector [i915]] Adding DP connector on
> > [ENCODER:295:DDI D]
> > [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on
> > [ENCODER:295:DDI D]
> > [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x3 for port D (VBT)
> >
> > DDI USBC2:
> > [drm:intel_bios_port_aux_ch [i915]] using AUX E for port E (VBT)
> > [drm:intel_dp_init_connector [i915]] Adding DP connector on
> > [ENCODER:306:DDI E]
> > [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on
> > [ENCODER:306:DDI E]
> > [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x9 for port E (VBT)
> >
> > Cc: Clinton Taylor
> > Cc: Aditya Swarup
> > Signed-off-by: Lucas De Marchi
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/display/intel_bios.c | 72 ---
> > 1 file changed, 51 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 839124647202..4f1a72a90b8f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -1619,30 +1619,18 @@ static u8 map_ddc_pin(struct drm_i915_private
> > *dev_priv, u8 vbt_pin)
> > return 0;
> > }
> >
> > -static enum port dvo_port_to_port(u8 dvo_port)
> > +static enum port __dvo_port_to_port(int n_ports, int n_dvo,
> > + const int port_mapping[][3], u8 dvo_port)
> > {
> > - /*
> > -* Each DDI port can have more than one value on the "DVO Port" field,
> > -* so look for all the possible values for each port.
> > -*/
> > - static const int dvo_ports[][3] = {
> > - [PORT_A] = { DVO_PORT_HDMIA, DVO_PORT_DPA, -1},
> > - [PORT_B] = { DVO_PORT_HDMIB, DVO_PORT_DPB, -1},
> > - [PORT_C] = { DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
> > - [PORT_D] = { DVO_PORT_HDMID, DVO_PORT_DPD, -1},
> > - [PORT_E] = { DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
> > - [PORT_F] = { DVO_PORT_HDMIF, DVO_PORT_DPF, -1},
> > - [PORT_G] = { DVO_PORT_HDMIG, DVO_PORT_DPG, -1},
> > - };
> > enum port port;
> > int i;
> >
> > - for (port = PORT_A; port < ARRAY_SIZE(dvo_ports); port++) {
> > - for (i = 0; i < ARRAY_SIZE(dvo_ports[port]); i++) {
> > - if (dvo_ports[port][i] == -1)
> > + for (port = PORT_A; port < n_ports; port++) {
> > + for (i = 0; i < n_dvo; i++) {
> > + if (port_mapping[port][i] == -1)
> > break;
> >
> > - if (dvo_port == dvo_ports[port][i])
> > + if (dvo_port == port_mapping[port][i])
> > return port;
> > }
> > }
> > @@ -1650,6 +1638,48 @@ static enum port dvo_port_to_port(u8 dvo_port)
> > return PORT_NONE;
> > }
> >
> > +static enum port dvo_port_to_port(struct drm_i915_private *dev_priv,
> > + u8 dvo_port)
> > +{
> > + /*
> > +* Each DDI port can have more than one value on the "DVO Port" field,
> > +* so look for all the possible values for each port.
> > +*/
> > + static const int port_mapping[][3] = {
> > + [PORT_A] = { DVO_PORT_HDMIA, DVO_PORT_DPA, -1 },
> > + [PORT_B] = { DVO_PORT_HDMIB, DVO_PORT_DPB, -1 },
> > + [PORT_C] = { DVO_PORT_HDMIC, DVO_PORT_DPC, -1 },
> > + [PORT_D] = { DVO_PORT_HDMID, DVO_PORT_DPD, -1 },
> > + [PORT_E] = { DVO_PORT_CRT, DVO_PORT_HDMIE, -1 },
> > + [PORT_F] = { DVO_PORT_HDMIF, DVO_PORT_DPF, -1 },
> > + [PORT_G] = {
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Mark concurrent submissions with a weak-dependency
Quoting Tvrtko Ursulin (2020-05-07 18:55:17)
>
> On 07/05/2020 16:34, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-05-07 16:23:59)
> >> On 07/05/2020 16:00, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2020-05-07 15:53:08)
> On 07/05/2020 09:21, Chris Wilson wrote:
> > We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
> > correctly perform priority inheritance from the parallel branches to the
> > common trunk. However, for the purpose of timeslicing and reset
> > handling, the dependency is weak -- as we the pair of requests are
> > allowed to run in parallel and not in strict succession. So for example
> > we do need to suspend one if the other hangs.
> >
> > The real significance though is that this allows us to rearrange
> > groups of WAIT_FOR_SUBMIT linked requests along the single engine, and
> > so can resolve user level inter-batch scheduling dependencies from user
> > semaphores.
> >
> > Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags
> > across submit fences")
> > Testcase: igt/gem_exec_fence/submit
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: # v5.6+
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
> > drivers/gpu/drm/i915/i915_request.c | 8 ++--
> > drivers/gpu/drm/i915/i915_scheduler.c | 6 +++---
> > drivers/gpu/drm/i915/i915_scheduler.h | 3 ++-
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
> > 5 files changed, 21 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index dc3f2ee7136d..10109f661bcb 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request
> > *rq, struct list_head * const pl)
> > struct i915_request *w =
> > container_of(p->waiter, typeof(*w),
> > sched);
> >
> > + if (p->flags & I915_DEPENDENCY_WEAK)
> > + continue;
> > +
>
> I did not quite get it - submit fence dependency would mean different
> engines, so the below check (w->engine != rq->engine) would effectively
> have the same effect. What am I missing?
> >>>
> >>> That submit fences can be between different contexts on the same engine.
> >>> The example (from mesa) is where we have two interdependent clients
> >>> which are using their own userlevel scheduling inside each batch, i.e.
> >>> waiting on semaphores.
> >>
> >> But if submit fence was used that means the waiter should never be
> >> submitted ahead of the signaler. And with this change it could get ahead
> >> in the priolist, no?
> >
> > You do recall the starting point for this series was future fences :)
> >
> > The test case for this is:
> >
> > execbuf.flags = engine | I915_EXEC_FENCE_OUT;
> > execbuf.batch_start_offset = 0;
> > gem_execbuf_wr(i915, );
> >
> > execbuf.rsvd1 = gem_context_clone_with_engines(i915, 0);
> > execbuf.rsvd2 >>= 32;
> > execbuf.flags = e->flags;
> > execbuf.flags |= I915_EXEC_FENCE_SUBMIT | I915_EXEC_FENCE_OUT;
> > execbuf.batch_start_offset = offset;
> > gem_execbuf_wr(i915, );
> > gem_context_destroy(i915, execbuf.rsvd1);
> >
> > gem_sync(i915, obj.handle);
> >
> > /* no hangs! */
> > out = execbuf.rsvd2;
> > igt_assert_eq(sync_fence_status(out), 1);
> > close(out);
> >
> > out = execbuf.rsvd2 >> 32;
> > igt_assert_eq(sync_fence_status(out), 1);
> > close(out);
> >
> > Where the batches are a couple of semaphore waits, which is the essence
> > of a bonded request but being run on a single engine.
> >
> > Unless we treat the submit fence as a weak dependency here, we can't
> > timeslice between the two.
>
> Yes it is fine, once the initial submit was controlled by a fence it is
> okay to re-order.
Right. That we can't submit the second batch before the master, even if
the master is blocked is covered in gem_exec_fence/parallel. Hmm, but
that only covers submit fences on other engines (simply because it wants
to check the submit fences complete before the master, and didn't assume
timeslicing). So there's room for another test here, where we have both
requests on the same engine, and block the master.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Remove wait priority boosting
On 07/05/2020 16:23, Chris Wilson wrote:
Upon waiting a request (when asked), we gave that request a small
priority boost, not enough for it to cause preemption, but enough for it
to be scheduled next before all equals. We also used that bit to give
new clients a small priority boost, similar to FQ_CODEL, such that we
favoured short interactive tasks ahead of long running streams.
However, this is causing lots of complications with timeslicing where we
both want to honour the boost and yet ignore it. Those complications
cause unexpected user behaviour (tasks not being timesliced and run
concurrently as epxected), and the easiest way to resolve that is to
remove the boost. Hopefully, we can find a compromise again if we need
to, but in theory timeslicing itself and future more advanced schedulers
should give us the interactivity boost we seek.
Testcase: igt/gem_exec_schedule/lateslice
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 9 -
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/i915_priolist_types.h| 7 ++-
drivers/gpu/drm/i915/i915_request.c | 3 ---
drivers/gpu/drm/i915/i915_scheduler.c | 12 +---
6 files changed, 5 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 966523a8503f..d54a4933cc05 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2597,15 +2597,6 @@ static void eb_request_add(struct i915_execbuffer *eb)
*/
if (!(rq->sched.flags & I915_SCHED_HAS_SEMAPHORE_CHAIN))
attr.priority |= I915_PRIORITY_NOSEMAPHORE;
-
- /*
-* Boost priorities to new clients (new request flows).
-*
-* Allow interactive/synchronous clients to jump ahead of
-* the bulk clients. (FQ_CODEL)
-*/
- if (list_empty(>sched.signalers_list))
- attr.priority |= I915_PRIORITY_WAIT;
} else {
/* Serialise with context_close via the add_to_timeline */
i915_request_set_error_once(rq, -ENOENT);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 860ef97895c8..c3924c3d8351 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -438,9 +438,7 @@ static int effective_prio(const struct i915_request *rq)
if (__i915_request_has_started(rq))
prio |= I915_PRIORITY_NOSEMAPHORE;
- /* Restrict mere WAIT boosts from triggering preemption */
- BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
- return prio | __NO_PREEMPTION;
+ return prio;
}
static int queue_prio(const struct intel_engine_execlists *execlists)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index aa6d56e25a10..94eb63f309ce 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -258,7 +258,7 @@ static void guc_submit(struct intel_engine_cs *engine,
static inline int rq_prio(const struct i915_request *rq)
{
- return rq->sched.attr.priority | __NO_PREEMPTION;
+ return rq->sched.attr.priority;
}
static struct i915_request *schedule_in(struct i915_request *rq, int idx)
diff --git a/drivers/gpu/drm/i915/i915_priolist_types.h
b/drivers/gpu/drm/i915/i915_priolist_types.h
index 732aad148881..e18723d8df86 100644
--- a/drivers/gpu/drm/i915/i915_priolist_types.h
+++ b/drivers/gpu/drm/i915/i915_priolist_types.h
@@ -24,14 +24,13 @@ enum {
I915_PRIORITY_DISPLAY,
};
-#define I915_USER_PRIORITY_SHIFT 2
+#define I915_USER_PRIORITY_SHIFT 1
#define I915_USER_PRIORITY(x) ((x) << I915_USER_PRIORITY_SHIFT)
#define I915_PRIORITY_COUNT BIT(I915_USER_PRIORITY_SHIFT)
#define I915_PRIORITY_MASK (I915_PRIORITY_COUNT - 1)
-#define I915_PRIORITY_WAIT ((u8)BIT(0))
-#define I915_PRIORITY_NOSEMAPHORE ((u8)BIT(1))
+#define I915_PRIORITY_NOSEMAPHORE ((u8)BIT(0))
/* Smallest priority value that cannot be bumped. */
#define I915_PRIORITY_INVALID (INT_MIN | (u8)I915_PRIORITY_MASK)
@@ -47,8 +46,6 @@ enum {
#define I915_PRIORITY_UNPREEMPTABLE INT_MAX
#define I915_PRIORITY_BARRIER INT_MAX
-#define __NO_PREEMPTION (I915_PRIORITY_WAIT)
-
struct i915_priolist {
struct list_head requests[I915_PRIORITY_COUNT];
struct rb_node node;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 3c38d61c90f8..589739bfee25 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Mark concurrent submissions with a weak-dependency
On 07/05/2020 16:23, Chris Wilson wrote:
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in parallel and not in strict succession. So for example
we do need to suspend one if the other hangs.
The real significance though is that this allows us to rearrange
groups of WAIT_FOR_SUBMIT linked requests along the single engine, and
so can resolve user level inter-batch scheduling dependencies from user
semaphores.
Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across submit
fences")
Testcase: igt/gem_exec_fence/submit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.6+
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
drivers/gpu/drm/i915/i915_request.c | 8 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 6 +++---
drivers/gpu/drm/i915/i915_scheduler.h | 3 ++-
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
5 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index bbdb0e2a4571..860ef97895c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq, struct
list_head * const pl)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
@@ -2726,6 +2729,9 @@ static void __execlists_hold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
@@ -2850,6 +2856,9 @@ static void __execlists_unhold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Propagate any change in error status */
if (rq->fence.error)
i915_request_set_error_once(w, rq->fence.error);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 4d18f808fda2..3c38d61c90f8 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1040,7 +1040,9 @@ i915_request_await_request(struct i915_request *to,
struct i915_request *from)
}
if (to->engine->schedule) {
- ret = i915_sched_node_add_dependency(>sched, >sched);
+ ret = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_EXTERNAL);
if (ret < 0)
return ret;
}
@@ -1202,7 +1204,9 @@ __i915_request_await_execution(struct i915_request *to,
/* Couple the dependency tree for PI on this exposed to->fence */
if (to->engine->schedule) {
- err = i915_sched_node_add_dependency(>sched, >sched);
+ err = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_WEAK);
if (err < 0)
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 37cfcf5b321b..6e2d4190099f 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -462,7 +462,8 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
}
int i915_sched_node_add_dependency(struct i915_sched_node *node,
- struct i915_sched_node *signal)
+ struct i915_sched_node *signal,
+ unsigned long flags)
{
struct i915_dependency *dep;
@@ -473,8 +474,7 @@ int i915_sched_node_add_dependency(struct i915_sched_node *node,
local_bh_disable();
if (!__i915_sched_node_add_dependency(node, signal, dep,
- I915_DEPENDENCY_EXTERNAL |
-
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Mark concurrent submissions with a weak-dependency
On 07/05/2020 16:34, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-07 16:23:59)
On 07/05/2020 16:00, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-07 15:53:08)
On 07/05/2020 09:21, Chris Wilson wrote:
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in parallel and not in strict succession. So for example
we do need to suspend one if the other hangs.
The real significance though is that this allows us to rearrange
groups of WAIT_FOR_SUBMIT linked requests along the single engine, and
so can resolve user level inter-batch scheduling dependencies from user
semaphores.
Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across submit
fences")
Testcase: igt/gem_exec_fence/submit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.6+
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
drivers/gpu/drm/i915/i915_request.c | 8 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 6 +++---
drivers/gpu/drm/i915/i915_scheduler.h | 3 ++-
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
5 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index dc3f2ee7136d..10109f661bcb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq, struct
list_head * const pl)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
I did not quite get it - submit fence dependency would mean different
engines, so the below check (w->engine != rq->engine) would effectively
have the same effect. What am I missing?
That submit fences can be between different contexts on the same engine.
The example (from mesa) is where we have two interdependent clients
which are using their own userlevel scheduling inside each batch, i.e.
waiting on semaphores.
But if submit fence was used that means the waiter should never be
submitted ahead of the signaler. And with this change it could get ahead
in the priolist, no?
You do recall the starting point for this series was future fences :)
The test case for this is:
execbuf.flags = engine | I915_EXEC_FENCE_OUT;
execbuf.batch_start_offset = 0;
gem_execbuf_wr(i915, );
execbuf.rsvd1 = gem_context_clone_with_engines(i915, 0);
execbuf.rsvd2 >>= 32;
execbuf.flags = e->flags;
execbuf.flags |= I915_EXEC_FENCE_SUBMIT | I915_EXEC_FENCE_OUT;
execbuf.batch_start_offset = offset;
gem_execbuf_wr(i915, );
gem_context_destroy(i915, execbuf.rsvd1);
gem_sync(i915, obj.handle);
/* no hangs! */
out = execbuf.rsvd2;
igt_assert_eq(sync_fence_status(out), 1);
close(out);
out = execbuf.rsvd2 >> 32;
igt_assert_eq(sync_fence_status(out), 1);
close(out);
Where the batches are a couple of semaphore waits, which is the essence
of a bonded request but being run on a single engine.
Unless we treat the submit fence as a weak dependency here, we can't
timeslice between the two.
Yes it is fine, once the initial submit was controlled by a fence it is
okay to re-order.
Regards,
Tvrtko
The other observation is that we may not have to suspend the request if
the other hangs as the linkage is implicit. If the request does continue
to wait on the hung request, we can only hope it too hangs. I should
make that a second patch, since it is a distinct change.
___
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] drm/i915: Mark concurrent submissions with a weak-dependency (rev3)
== Series Details == Series: series starting with [v2] drm/i915: Mark concurrent submissions with a weak-dependency (rev3) URL : https://patchwork.freedesktop.org/series/77045/ State : success == Summary == CI Bug Log - changes from CI_DRM_8444 -> Patchwork_17606 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/index.html Known issues Here are the changes found in Patchwork_17606 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_pm_rpm@basic-rte: - fi-hsw-4770:[SKIP][1] ([fdo#109271]) -> [PASS][2] +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-hsw-4770/igt@i915_pm_...@basic-rte.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/fi-hsw-4770/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rpm@module-reload: - fi-skl-6700k2: [INCOMPLETE][3] ([i915#151]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-skl-6700k2/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/fi-skl-6700k2/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@reset: - fi-bwr-2160:[INCOMPLETE][5] ([i915#489]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-bwr-2160/igt@i915_selftest@l...@reset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/fi-bwr-2160/igt@i915_selftest@l...@reset.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][7] ([fdo#109271]) -> [FAIL][8] ([i915#62]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151 [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (49 -> 43) -- Additional (1): fi-kbl-7560u Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-byt-clapper Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8444 -> Patchwork_17606 CI-20190529: 20190529 CI_DRM_8444: 39544482386ac801dc4140df00a7e7e5bbea4d8a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5638: 50868ab3c532a86aa147fb555b69a1078c572b13 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17606: 51e347e643d7b35e05340cc9c7adbb9852a6a1ae @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 51e347e643d7 drm/i915: Remove wait priority boosting e2db934f1637 drm/i915: Treat weak-dependencies as bidirectional when applying priorities 301b1676201d drm/i915: Mark concurrent submissions with a weak-dependency == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17606/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for In order to readout DP SDPs, refactors the handling of DP SDPs (rev13)
== Series Details ==
Series: In order to readout DP SDPs, refactors the handling of DP SDPs (rev13)
URL : https://patchwork.freedesktop.org/series/72853/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8444_full -> Patchwork_17600_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17600_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_flip@2x-modeset-vs-vblank-race@bc-hdmi-a1-hdmi-a2}:
- shard-glk: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-glk5/igt@kms_flip@2x-modeset-vs-vblank-r...@bc-hdmi-a1-hdmi-a2.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/shard-glk8/igt@kms_flip@2x-modeset-vs-vblank-r...@bc-hdmi-a1-hdmi-a2.html
New tests
-
New tests have been introduced between CI_DRM_8444_full and
Patchwork_17600_full:
### New Piglit tests (1) ###
* spec@arb_texture_multisample@texelfetch@2-gs-isampler2dmsarray:
- Statuses : 1 fail(s)
- Exec time: [0.12] s
Known issues
Here are the changes found in Patchwork_17600_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_softpin@noreloc-s3:
- shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-apl2/igt@gem_soft...@noreloc-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/shard-apl1/igt@gem_soft...@noreloc-s3.html
* igt@kms_color@pipe-a-ctm-green-to-red:
- shard-skl: [PASS][5] -> [FAIL][6] ([i915#129])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-skl5/igt@kms_co...@pipe-a-ctm-green-to-red.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/shard-skl6/igt@kms_co...@pipe-a-ctm-green-to-red.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +2 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#49])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-glk1/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/shard-glk9/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu.html
* igt@kms_psr@psr2_sprite_mmap_gtt:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) +4 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/shard-iclb7/igt@kms_psr@psr2_sprite_mmap_gtt.html
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#69])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-skl3/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/shard-skl4/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
Possible fixes
* igt@gem_exec_params@invalid-bsd-ring:
- shard-iclb: [SKIP][15] ([fdo#109276]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-iclb8/igt@gem_exec_par...@invalid-bsd-ring.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/shard-iclb1/igt@gem_exec_par...@invalid-bsd-ring.html
* igt@gem_workarounds@suspend-resume-context:
- shard-apl: [DMESG-WARN][17] ([i915#180]) -> [PASS][18] +4
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-apl8/igt@gem_workarou...@suspend-resume-context.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/shard-apl3/igt@gem_workarou...@suspend-resume-context.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: [FAIL][19] ([i915#72]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/shard-glk1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [FAIL][21] ([i915#1188]) -> [PASS][22]
[21]:
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Remove wait priority boosting
Quoting Chris Wilson (2020-05-07 16:23:38) > Upon waiting a request (when asked), we gave that request a small > priority boost, not enough for it to cause preemption, but enough for it > to be scheduled next before all equals. We also used that bit to give > new clients a small priority boost, similar to FQ_CODEL, such that we > favoured short interactive tasks ahead of long running streams. > > However, this is causing lots of complications with timeslicing where we > both want to honour the boost and yet ignore it. Those complications > cause unexpected user behaviour (tasks not being timesliced and run > concurrently as epxected), and the easiest way to resolve that is to > remove the boost. Hopefully, we can find a compromise again if we need > to, but in theory timeslicing itself and future more advanced schedulers > should give us the interactivity boost we seek. Fwiw, initial results show that it would be possible to remove the NOSEMA handling as well now. Previously gem_wsim -r busy would be hurt due to the inopportune semaphores and slow timeslicing. Touch wood, that pain seems to be gone. But that will take a few days to get solid numbers. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2] drm/i915: Mark concurrent submissions with a weak-dependency (rev2)
== Series Details == Series: series starting with [v2] drm/i915: Mark concurrent submissions with a weak-dependency (rev2) URL : https://patchwork.freedesktop.org/series/77045/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8444 -> Patchwork_17605 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17605 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17605, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17605/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17605: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-skl-6600u: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-skl-6600u/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17605/fi-skl-6600u/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_17605 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_pm_rpm@basic-rte: - fi-hsw-4770:[SKIP][3] ([fdo#109271]) -> [PASS][4] +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-hsw-4770/igt@i915_pm_...@basic-rte.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17605/fi-hsw-4770/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rpm@module-reload: - fi-skl-6700k2: [INCOMPLETE][5] ([i915#151]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-skl-6700k2/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17605/fi-skl-6700k2/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@reset: - fi-bwr-2160:[INCOMPLETE][7] ([i915#489]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-bwr-2160/igt@i915_selftest@l...@reset.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17605/fi-bwr-2160/igt@i915_selftest@l...@reset.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151 [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 Participating hosts (49 -> 43) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8444 -> Patchwork_17605 CI-20190529: 20190529 CI_DRM_8444: 39544482386ac801dc4140df00a7e7e5bbea4d8a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5638: 50868ab3c532a86aa147fb555b69a1078c572b13 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17605: ca5fbec309c108c6fdc707672f0a40df591c5abf @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ca5fbec309c1 drm/i915: Remove wait priority boosting e583d2f085e1 drm/i915: Treat weak-dependencies as bidirectional when applying priorities 480b9b16aad7 drm/i915: Mark concurrent submissions with a weak-dependency == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17605/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for SAGV support for Gen12+ (rev36)
== Series Details == Series: SAGV support for Gen12+ (rev36) URL : https://patchwork.freedesktop.org/series/75129/ State : success == Summary == CI Bug Log - changes from CI_DRM_8444 -> Patchwork_17603 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/index.html Known issues Here are the changes found in Patchwork_17603 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_pm_rpm@basic-rte: - fi-hsw-4770:[SKIP][1] ([fdo#109271]) -> [PASS][2] +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-hsw-4770/igt@i915_pm_...@basic-rte.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/fi-hsw-4770/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rpm@module-reload: - fi-skl-6700k2: [INCOMPLETE][3] ([i915#151]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-skl-6700k2/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/fi-skl-6700k2/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@reset: - fi-bwr-2160:[INCOMPLETE][5] ([i915#489]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-bwr-2160/igt@i915_selftest@l...@reset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/fi-bwr-2160/igt@i915_selftest@l...@reset.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151 [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 Participating hosts (49 -> 43) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8444 -> Patchwork_17603 CI-20190529: 20190529 CI_DRM_8444: 39544482386ac801dc4140df00a7e7e5bbea4d8a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5638: 50868ab3c532a86aa147fb555b69a1078c572b13 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17603: 7b0099b8e0d14efdb0b26fe1e7748e0361c00fa0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7b0099b8e0d1 drm/i915: Enable SAGV support for Gen12 3d9400f258c5 drm/i915: Restrict qgv points which don't have enough bandwidth. 1807e09ca9e6 drm/i915: Add TGL+ SAGV support f4268af8a090 drm/i915: Make active_pipes check skl specific 37b1bc532f92 drm/i915: Extract skl SAGV checking 74acb8869d96 drm/i915: Introduce skl_plane_wm_level accessor. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17603/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for RFC: i915: Drop relocation support on Gen12+
== Series Details == Series: RFC: i915: Drop relocation support on Gen12+ URL : https://patchwork.freedesktop.org/series/77048/ State : failure == Summary == Applying: RFC: i915: Drop relocation support on Gen12+ Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 RFC: i915: Drop relocation support on Gen12+ When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gen12: Add aux table invalidate for all engines
Quoting Mika Kuoppala (2020-05-07 15:20:45)
> All engines, exception being blitter as it does not
> care about the form, can access compressed surfaces.
>
> So we need to add forced aux table invalidates
> for those engines.
>
> v2: virtual instance masking (Chris)
> v3: bug on if not found (Chris)
>
> References: d248b371f747 ("drm/i915/gen12: Invalidate aux table entries
> forcibly")
> References bspec#43904, hsdes#1809175790
> Cc: Chris Wilson
> Cc: Chuansheng Liu
> Cc: Rafael Antognolli
> Signed-off-by: Mika Kuoppala
The code handles the more complicated vengs without exploding, so looks
good. But I still think is a w/a and only deserves an ack as something
that empirically works [although we have a lack of evidence situation
here :],
Acked-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for SAGV support for Gen12+ (rev36)
== Series Details ==
Series: SAGV support for Gen12+ (rev36)
URL : https://patchwork.freedesktop.org/series/75129/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
74acb8869d96 drm/i915: Introduce skl_plane_wm_level accessor.
37b1bc532f92 drm/i915: Extract skl SAGV checking
f4268af8a090 drm/i915: Make active_pipes check skl specific
-:63: WARNING:LONG_LINE: line over 100 characters
#63: FILE: drivers/gpu/drm/i915/intel_pm.c:3902:
+ if (intel_can_enable_sagv(dev_priv, new_bw_state) !=
intel_can_enable_sagv(dev_priv, old_bw_state)) {
total: 0 errors, 1 warnings, 0 checks, 55 lines checked
1807e09ca9e6 drm/i915: Add TGL+ SAGV support
3d9400f258c5 drm/i915: Restrict qgv points which don't have enough bandwidth.
7b0099b8e0d1 drm/i915: Enable SAGV support for Gen12
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
Hi! Here is this week drm-misc-fixes PR Maxime drm-misc-fixes-2020-05-07: A few minor fixes for an ordering issue in virtio, an (old) gcc warning in sun4i, a probe issue in ingenic-drm and a regression in the HDCP support. The following changes since commit 6f49c2515e2258f08f2b905c9772dbf729610415: dma-buf: fix documentation build warnings (2020-04-30 19:47:39 +0530) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-05-07 for you to fetch changes up to 5fe89a6acd668cbd1817fcdef5caa9fee568c2e8: drm: Fix HDCP failures when SRM fw is missing (2020-05-05 14:01:53 -0400) A few minor fixes for an ordering issue in virtio, an (old) gcc warning in sun4i, a probe issue in ingenic-drm and a regression in the HDCP support. Arnd Bergmann (1): sun6i: dsi: fix gcc-4.8 Gurchetan Singh (1): drm/virtio: create context before RESOURCE_CREATE_2D in 3D mode H. Nikolaus Schaller (1): drm: ingenic-drm: add MODULE_DEVICE_TABLE Sean Paul (1): drm: Fix HDCP failures when SRM fw is missing drivers/gpu/drm/drm_hdcp.c | 8 +++- drivers/gpu/drm/ingenic/ingenic-drm.c | 1 + drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_gem.c | 3 +++ drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +-- 6 files changed, 14 insertions(+), 4 deletions(-) signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: i915: Drop relocation support on Gen12+
On Thu, May 7, 2020 at 10:44 AM Chris Wilson wrote: > > Quoting Jason Ekstrand (2020-05-07 16:36:00) > > The Vulkan driver in Mesa for Intel hardware never uses relocations if > > it's running on a version of i915 that supports at least softpin which > > all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is > > only supported by iris which never uses relocations. The older i965 > > driver in Mesa does use relocations but it only supports Intel hardware > > through Gen11 and has been deprecated for all hardware Gen9+. The entire > > relocation UAPI and related infrastructure, therefore, doesn't have any > > open-source userspace consumer starting with Gen12. > > > > Rejecting relocations starting with Gen12 has the benefit that we don't > > have to bother supporting it on platforms with local memory. Given how > > much CPU touching of memory is required for relocations, not having to > > do so on platforms where not all memory is directly CPU-accessible > > carries significant advantages. > > You are not supplying them, the kernel is not checking them [as they > don't exist], so there is no material benefit. The only question is > maintainability. > > How confident are you that you will never use them Confident enough to send this patch. Especially in a Vulkan world where it's very hard to tell which bits of memory are actually in-use on the GPU, stalling to relocate is performance death. With a 48-bit GTT, there's no need to have the kernel involved in address space assignment so relocations don't really serve much purpose. We did potentially have one use for them with VK_KHR_performance_query but we're going out of our way to avoid them there. If we desperately need relocations, we can do them from userspace. > and rewrite the media-driver? I'm pretty sure they're working on getting rid of them. I'm checking on that right now. > The code exists, will be tested, and can just as easily > expire with the rest of execbuffer2. Sure. The question, again, is maintenance. If we're spending piles of time trying to figure out how to keep relocations going in a local memory world, that's likely a waste. Relocations can sit and rot on Gen11 and below until we finally make execbuffer3 a reality and then they can rot in the deprecated execbuffer2 ioct. There is a bit of a question here about what to do with IGT. I suspect it uses relocations for a lot of stuff and the fallout there could be significant. (I explicitly made this patch so it won't actually build because I don't hate our CI people.) --Jason ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Mark concurrent submissions with a weak-dependency
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in parallel and not in strict succession.
The real significance though is that this allows us to rearrange
groups of WAIT_FOR_SUBMIT linked requests along the single engine, and
so can resolve user level inter-batch scheduling dependencies from user
semaphores.
Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across
submit fences")
Testcase: igt/gem_exec_fence/submit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.6+
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++
drivers/gpu/drm/i915/i915_request.c | 8 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 6 +++---
drivers/gpu/drm/i915/i915_scheduler.h | 3 ++-
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
5 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index bbdb0e2a4571..dd0fd4c4cf32 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq, struct
list_head * const pl)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 4d18f808fda2..3c38d61c90f8 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1040,7 +1040,9 @@ i915_request_await_request(struct i915_request *to,
struct i915_request *from)
}
if (to->engine->schedule) {
- ret = i915_sched_node_add_dependency(>sched, >sched);
+ ret = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_EXTERNAL);
if (ret < 0)
return ret;
}
@@ -1202,7 +1204,9 @@ __i915_request_await_execution(struct i915_request *to,
/* Couple the dependency tree for PI on this exposed to->fence */
if (to->engine->schedule) {
- err = i915_sched_node_add_dependency(>sched, >sched);
+ err = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_WEAK);
if (err < 0)
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 37cfcf5b321b..6e2d4190099f 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -462,7 +462,8 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
}
int i915_sched_node_add_dependency(struct i915_sched_node *node,
- struct i915_sched_node *signal)
+ struct i915_sched_node *signal,
+ unsigned long flags)
{
struct i915_dependency *dep;
@@ -473,8 +474,7 @@ int i915_sched_node_add_dependency(struct i915_sched_node
*node,
local_bh_disable();
if (!__i915_sched_node_add_dependency(node, signal, dep,
- I915_DEPENDENCY_EXTERNAL |
- I915_DEPENDENCY_ALLOC))
+ flags | I915_DEPENDENCY_ALLOC))
i915_dependency_free(dep);
local_bh_enable(); /* kick submission tasklet */
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
b/drivers/gpu/drm/i915/i915_scheduler.h
index d1dc4efef77b..6f0bf00fc569 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -34,7 +34,8 @@ bool __i915_sched_node_add_dependency(struct i915_sched_node
*node,
unsigned long flags);
int i915_sched_node_add_dependency(struct i915_sched_node *node,
- struct i915_sched_node *signal);
+ struct i915_sched_node *signal,
+ unsigned long flags);
void i915_sched_node_fini(struct i915_sched_node *node);
diff --git a/drivers/gpu/drm/i915/i915_scheduler_types.h
b/drivers/gpu/drm/i915/i915_scheduler_types.h
index d18e70550054..7186875088a0 100644
---
Re: [Intel-gfx] [PATCH] RFC: i915: Drop relocation support on Gen12+
Quoting Jason Ekstrand (2020-05-07 16:36:00) > The Vulkan driver in Mesa for Intel hardware never uses relocations if > it's running on a version of i915 that supports at least softpin which > all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is > only supported by iris which never uses relocations. The older i965 > driver in Mesa does use relocations but it only supports Intel hardware > through Gen11 and has been deprecated for all hardware Gen9+. The entire > relocation UAPI and related infrastructure, therefore, doesn't have any > open-source userspace consumer starting with Gen12. > > Rejecting relocations starting with Gen12 has the benefit that we don't > have to bother supporting it on platforms with local memory. Given how > much CPU touching of memory is required for relocations, not having to > do so on platforms where not all memory is directly CPU-accessible > carries significant advantages. You are not supplying them, the kernel is not checking them [as they don't exist], so there is no material benefit. The only question is maintainability. How confident are you that you will never use them and rewrite the media-driver? The code exists, will be tested, and can just as easily expire with the rest of execbuffer2. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] RFC: i915: Drop relocation support on Gen12+
The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is
only supported by iris which never uses relocations. The older i965
driver in Mesa does use relocations but it only supports Intel hardware
through Gen11 and has been deprecated for all hardware Gen9+. The entire
relocation UAPI and related infrastructure, therefore, doesn't have any
open-source userspace consumer starting with Gen12.
Rejecting relocations starting with Gen12 has the benefit that we don't
have to bother supporting it on platforms with local memory. Given how
much CPU touching of memory is required for relocations, not having to
do so on platforms where not all memory is directly CPU-accessible
carries significant advantages.
Signed-off-by: Jason Ekstrand
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 4f9c1f5a4dedb..e10c93aff945d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1533,7 +1533,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct
i915_vma *vma)
return err;
}
-static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+static int check_relocations(const struct i915_execbuffer *eb,
+const struct drm_i915_gem_exec_object2 *entry)
{
const char __user *addr, *end;
unsigned long size;
@@ -1543,6 +1544,9 @@ static int check_relocations(const struct
drm_i915_gem_exec_object2 *entry)
if (size == 0)
return 0;
+ if (size && eb->reloc_cache.gen >= 12)
+ return -EINVAL;
+
if (size > N_RELOC(ULONG_MAX))
return -EINVAL;
@@ -1576,7 +1580,7 @@ static int eb_copy_relocations(const struct
i915_execbuffer *eb)
if (nreloc == 0)
continue;
- err = check_relocations(>exec[i]);
+ err = check_relocations(eb, >exec[i]);
if (err)
goto err;
--
2.26.2
___
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/mst: Wait for ACT sent before enabling the pipe
== Series Details == Series: drm/i915/mst: Wait for ACT sent before enabling the pipe URL : https://patchwork.freedesktop.org/series/77040/ State : success == Summary == CI Bug Log - changes from CI_DRM_8444 -> Patchwork_17602 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/index.html Known issues Here are the changes found in Patchwork_17602 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_pm_rpm@basic-rte: - fi-hsw-4770:[SKIP][1] ([fdo#109271]) -> [PASS][2] +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-hsw-4770/igt@i915_pm_...@basic-rte.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/fi-hsw-4770/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rpm@module-reload: - fi-skl-6700k2: [INCOMPLETE][3] ([i915#151]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-skl-6700k2/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/fi-skl-6700k2/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@reset: - fi-bwr-2160:[INCOMPLETE][5] ([i915#489]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-bwr-2160/igt@i915_selftest@l...@reset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/fi-bwr-2160/igt@i915_selftest@l...@reset.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151 [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 Participating hosts (49 -> 43) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8444 -> Patchwork_17602 CI-20190529: 20190529 CI_DRM_8444: 39544482386ac801dc4140df00a7e7e5bbea4d8a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5638: 50868ab3c532a86aa147fb555b69a1078c572b13 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17602: 953c411c67db0f481d8549261a836e2ef5bb1183 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 953c411c67db drm/i915/mst: Wait for ACT sent before enabling the pipe == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17602/index.html ___ 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: Mark concurrent submissions with a weak-dependency
Quoting Tvrtko Ursulin (2020-05-07 16:23:59)
>
>
> On 07/05/2020 16:00, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-05-07 15:53:08)
> >> On 07/05/2020 09:21, Chris Wilson wrote:
> >>> We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
> >>> correctly perform priority inheritance from the parallel branches to the
> >>> common trunk. However, for the purpose of timeslicing and reset
> >>> handling, the dependency is weak -- as we the pair of requests are
> >>> allowed to run in parallel and not in strict succession. So for example
> >>> we do need to suspend one if the other hangs.
> >>>
> >>> The real significance though is that this allows us to rearrange
> >>> groups of WAIT_FOR_SUBMIT linked requests along the single engine, and
> >>> so can resolve user level inter-batch scheduling dependencies from user
> >>> semaphores.
> >>>
> >>> Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags
> >>> across submit fences")
> >>> Testcase: igt/gem_exec_fence/submit
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Tvrtko Ursulin
> >>> Cc: # v5.6+
> >>> ---
> >>>drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
> >>>drivers/gpu/drm/i915/i915_request.c | 8 ++--
> >>>drivers/gpu/drm/i915/i915_scheduler.c | 6 +++---
> >>>drivers/gpu/drm/i915/i915_scheduler.h | 3 ++-
> >>>drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
> >>>5 files changed, 21 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> index dc3f2ee7136d..10109f661bcb 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> @@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq,
> >>> struct list_head * const pl)
> >>>struct i915_request *w =
> >>>container_of(p->waiter, typeof(*w), sched);
> >>>
> >>> + if (p->flags & I915_DEPENDENCY_WEAK)
> >>> + continue;
> >>> +
> >>
> >> I did not quite get it - submit fence dependency would mean different
> >> engines, so the below check (w->engine != rq->engine) would effectively
> >> have the same effect. What am I missing?
> >
> > That submit fences can be between different contexts on the same engine.
> > The example (from mesa) is where we have two interdependent clients
> > which are using their own userlevel scheduling inside each batch, i.e.
> > waiting on semaphores.
>
> But if submit fence was used that means the waiter should never be
> submitted ahead of the signaler. And with this change it could get ahead
> in the priolist, no?
You do recall the starting point for this series was future fences :)
The test case for this is:
execbuf.flags = engine | I915_EXEC_FENCE_OUT;
execbuf.batch_start_offset = 0;
gem_execbuf_wr(i915, );
execbuf.rsvd1 = gem_context_clone_with_engines(i915, 0);
execbuf.rsvd2 >>= 32;
execbuf.flags = e->flags;
execbuf.flags |= I915_EXEC_FENCE_SUBMIT | I915_EXEC_FENCE_OUT;
execbuf.batch_start_offset = offset;
gem_execbuf_wr(i915, );
gem_context_destroy(i915, execbuf.rsvd1);
gem_sync(i915, obj.handle);
/* no hangs! */
out = execbuf.rsvd2;
igt_assert_eq(sync_fence_status(out), 1);
close(out);
out = execbuf.rsvd2 >> 32;
igt_assert_eq(sync_fence_status(out), 1);
close(out);
Where the batches are a couple of semaphore waits, which is the essence
of a bonded request but being run on a single engine.
Unless we treat the submit fence as a weak dependency here, we can't
timeslice between the two.
The other observation is that we may not have to suspend the request if
the other hangs as the linkage is implicit. If the request does continue
to wait on the hung request, we can only hope it too hangs. I should
make that a second patch, since it is a distinct change.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Mark concurrent submissions with a weak-dependency
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in parallel and not in strict succession. So for example
we do need to suspend one if the other hangs.
The real significance though is that this allows us to rearrange
groups of WAIT_FOR_SUBMIT linked requests along the single engine, and
so can resolve user level inter-batch scheduling dependencies from user
semaphores.
Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across
submit fences")
Testcase: igt/gem_exec_fence/submit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.6+
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
drivers/gpu/drm/i915/i915_request.c | 8 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 6 +++---
drivers/gpu/drm/i915/i915_scheduler.h | 3 ++-
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
5 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index bbdb0e2a4571..860ef97895c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq, struct
list_head * const pl)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
@@ -2726,6 +2729,9 @@ static void __execlists_hold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
@@ -2850,6 +2856,9 @@ static void __execlists_unhold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Propagate any change in error status */
if (rq->fence.error)
i915_request_set_error_once(w, rq->fence.error);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 4d18f808fda2..3c38d61c90f8 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1040,7 +1040,9 @@ i915_request_await_request(struct i915_request *to,
struct i915_request *from)
}
if (to->engine->schedule) {
- ret = i915_sched_node_add_dependency(>sched, >sched);
+ ret = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_EXTERNAL);
if (ret < 0)
return ret;
}
@@ -1202,7 +1204,9 @@ __i915_request_await_execution(struct i915_request *to,
/* Couple the dependency tree for PI on this exposed to->fence */
if (to->engine->schedule) {
- err = i915_sched_node_add_dependency(>sched, >sched);
+ err = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_WEAK);
if (err < 0)
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 37cfcf5b321b..6e2d4190099f 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -462,7 +462,8 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
}
int i915_sched_node_add_dependency(struct i915_sched_node *node,
- struct i915_sched_node *signal)
+ struct i915_sched_node *signal,
+ unsigned long flags)
{
struct i915_dependency *dep;
@@ -473,8 +474,7 @@ int i915_sched_node_add_dependency(struct i915_sched_node
*node,
local_bh_disable();
if (!__i915_sched_node_add_dependency(node, signal, dep,
- I915_DEPENDENCY_EXTERNAL |
-
[Intel-gfx] [PATCH 3/3] drm/i915: Remove wait priority boosting
Upon waiting a request (when asked), we gave that request a small
priority boost, not enough for it to cause preemption, but enough for it
to be scheduled next before all equals. We also used that bit to give
new clients a small priority boost, similar to FQ_CODEL, such that we
favoured short interactive tasks ahead of long running streams.
However, this is causing lots of complications with timeslicing where we
both want to honour the boost and yet ignore it. Those complications
cause unexpected user behaviour (tasks not being timesliced and run
concurrently as epxected), and the easiest way to resolve that is to
remove the boost. Hopefully, we can find a compromise again if we need
to, but in theory timeslicing itself and future more advanced schedulers
should give us the interactivity boost we seek.
Testcase: igt/gem_exec_schedule/lateslice
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 9 -
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/i915_priolist_types.h| 7 ++-
drivers/gpu/drm/i915/i915_request.c | 3 ---
drivers/gpu/drm/i915/i915_scheduler.c | 12 +---
6 files changed, 5 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 966523a8503f..d54a4933cc05 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2597,15 +2597,6 @@ static void eb_request_add(struct i915_execbuffer *eb)
*/
if (!(rq->sched.flags & I915_SCHED_HAS_SEMAPHORE_CHAIN))
attr.priority |= I915_PRIORITY_NOSEMAPHORE;
-
- /*
-* Boost priorities to new clients (new request flows).
-*
-* Allow interactive/synchronous clients to jump ahead of
-* the bulk clients. (FQ_CODEL)
-*/
- if (list_empty(>sched.signalers_list))
- attr.priority |= I915_PRIORITY_WAIT;
} else {
/* Serialise with context_close via the add_to_timeline */
i915_request_set_error_once(rq, -ENOENT);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 860ef97895c8..c3924c3d8351 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -438,9 +438,7 @@ static int effective_prio(const struct i915_request *rq)
if (__i915_request_has_started(rq))
prio |= I915_PRIORITY_NOSEMAPHORE;
- /* Restrict mere WAIT boosts from triggering preemption */
- BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
- return prio | __NO_PREEMPTION;
+ return prio;
}
static int queue_prio(const struct intel_engine_execlists *execlists)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index aa6d56e25a10..94eb63f309ce 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -258,7 +258,7 @@ static void guc_submit(struct intel_engine_cs *engine,
static inline int rq_prio(const struct i915_request *rq)
{
- return rq->sched.attr.priority | __NO_PREEMPTION;
+ return rq->sched.attr.priority;
}
static struct i915_request *schedule_in(struct i915_request *rq, int idx)
diff --git a/drivers/gpu/drm/i915/i915_priolist_types.h
b/drivers/gpu/drm/i915/i915_priolist_types.h
index 732aad148881..e18723d8df86 100644
--- a/drivers/gpu/drm/i915/i915_priolist_types.h
+++ b/drivers/gpu/drm/i915/i915_priolist_types.h
@@ -24,14 +24,13 @@ enum {
I915_PRIORITY_DISPLAY,
};
-#define I915_USER_PRIORITY_SHIFT 2
+#define I915_USER_PRIORITY_SHIFT 1
#define I915_USER_PRIORITY(x) ((x) << I915_USER_PRIORITY_SHIFT)
#define I915_PRIORITY_COUNT BIT(I915_USER_PRIORITY_SHIFT)
#define I915_PRIORITY_MASK (I915_PRIORITY_COUNT - 1)
-#define I915_PRIORITY_WAIT ((u8)BIT(0))
-#define I915_PRIORITY_NOSEMAPHORE ((u8)BIT(1))
+#define I915_PRIORITY_NOSEMAPHORE ((u8)BIT(0))
/* Smallest priority value that cannot be bumped. */
#define I915_PRIORITY_INVALID (INT_MIN | (u8)I915_PRIORITY_MASK)
@@ -47,8 +46,6 @@ enum {
#define I915_PRIORITY_UNPREEMPTABLE INT_MAX
#define I915_PRIORITY_BARRIER INT_MAX
-#define __NO_PREEMPTION (I915_PRIORITY_WAIT)
-
struct i915_priolist {
struct list_head requests[I915_PRIORITY_COUNT];
struct rb_node node;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 3c38d61c90f8..589739bfee25 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1464,8 +1464,6 @@ void i915_request_add(struct i915_request *rq)
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Mark concurrent submissions with a weak-dependency
On 07/05/2020 16:00, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-07 15:53:08)
On 07/05/2020 09:21, Chris Wilson wrote:
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in parallel and not in strict succession. So for example
we do need to suspend one if the other hangs.
The real significance though is that this allows us to rearrange
groups of WAIT_FOR_SUBMIT linked requests along the single engine, and
so can resolve user level inter-batch scheduling dependencies from user
semaphores.
Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across submit
fences")
Testcase: igt/gem_exec_fence/submit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.6+
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
drivers/gpu/drm/i915/i915_request.c | 8 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 6 +++---
drivers/gpu/drm/i915/i915_scheduler.h | 3 ++-
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
5 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index dc3f2ee7136d..10109f661bcb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq, struct
list_head * const pl)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
I did not quite get it - submit fence dependency would mean different
engines, so the below check (w->engine != rq->engine) would effectively
have the same effect. What am I missing?
That submit fences can be between different contexts on the same engine.
The example (from mesa) is where we have two interdependent clients
which are using their own userlevel scheduling inside each batch, i.e.
waiting on semaphores.
But if submit fence was used that means the waiter should never be
submitted ahead of the signaler. And with this change it could get ahead
in the priolist, no?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Treat weak-dependencies as bidirectional when applying priorities
Clients may use a submit-fence as bidirectional bond between two or more
co-operating requests, and so if we bump the priority of one, we wish to
bump the priority of the set.
Testcase: igt/gem_exec_fence/submitN
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 6e2d4190099f..1c33973dbd20 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -291,6 +291,19 @@ static void __i915_schedule(struct i915_sched_node *node,
if (prio > READ_ONCE(p->signaler->attr.priority))
list_move_tail(>dfs_link, );
}
+
+ /*
+* A weak dependency is used for submit-fence, which while
+* not strongly coupled, we do need to treat as a coordinated
+* set of co-operating requests that need to be run
+* concurrently. So if one request of that set receives a
+* priority boost, they all receive a priority boost.
+*/
+ list_for_each_entry(p, >waiters_list, wait_link) {
+ if (p->flags & I915_DEPENDENCY_WEAK &&
+ prio > READ_ONCE(p->waiter->attr.priority))
+ list_move_tail(>dfs_link, );
+ }
}
/*
--
2.20.1
___
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/gem: Treat submit-fence as weak dependency for new clients
Quoting Tvrtko Ursulin (2020-05-07 16:10:37)
>
> On 07/05/2020 16:05, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-05-07 15:59:56)
> >>
> >> On 07/05/2020 09:21, Chris Wilson wrote:
> >>> The submit-fence adds a weak dependency to the requests, and for the
> >>> purpose of our FQ_CODEL hinting we do not want to treat as a
> >>> restriction. This is primarily because clients may treat submit-fences
> >>> as a bidirectional bonding between a pair of co-ordinating requests.
> >>>
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Tvrtko Ursulin
> >>> ---
> >>>drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 13 -
> >>>1 file changed, 12 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> index 966523a8503f..e8bf0cf02fd7 100644
> >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> @@ -2565,6 +2565,17 @@ static void retire_requests(struct intel_timeline
> >>> *tl, struct i915_request *end)
> >>>break;
> >>>}
> >>>
> >>> +static bool new_client(struct i915_request *rq)
> >>> +{
> >>> + struct i915_dependency *p;
> >>> +
> >>> + list_for_each_entry(p, >sched.signalers_list, signal_link)
> >>> + if (!(p->flags & I915_DEPENDENCY_WEAK))
> >>> + return false;
> >>> +
> >>> + return true;
> >>> +}
> >>> +
> >>>static void eb_request_add(struct i915_execbuffer *eb)
> >>>{
> >>>struct i915_request *rq = eb->request;
> >>> @@ -2604,7 +2615,7 @@ static void eb_request_add(struct i915_execbuffer
> >>> *eb)
> >>> * Allow interactive/synchronous clients to jump ahead of
> >>> * the bulk clients. (FQ_CODEL)
> >>> */
> >>> - if (list_empty(>sched.signalers_list))
> >>> + if (new_client(rq))
> >>>attr.priority |= I915_PRIORITY_WAIT;
> >>>} else {
> >>>/* Serialise with context_close via the add_to_timeline */
> >>>
> >>
> >> Did absence of this have any functional effect? I hope not, but anyway:
> >
> > Bah, I have a new test case where this WAIT bumping is still upsetting us.
> >
> > I don't think I have any choice but to rip it out if we have timeslicing
> > enabled.
> >
> > Would you prefer a complete remission of I915_PRIORITY_WAIT or keep it
> > under if (!intel_engine_has_timeslicing(rq->engine)) ?
>
> Doesn't feel worthwhile to keep it for just BDW right?
No. There's ivb waiting in the rings (as I haven't figured out
preemption for it yet), but similarly just doesn't feel worth the
complications. :(
-Chris
___
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/gem: Treat submit-fence as weak dependency for new clients
On 07/05/2020 16:05, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-07 15:59:56)
On 07/05/2020 09:21, Chris Wilson wrote:
The submit-fence adds a weak dependency to the requests, and for the
purpose of our FQ_CODEL hinting we do not want to treat as a
restriction. This is primarily because clients may treat submit-fences
as a bidirectional bonding between a pair of co-ordinating requests.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 966523a8503f..e8bf0cf02fd7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2565,6 +2565,17 @@ static void retire_requests(struct intel_timeline *tl,
struct i915_request *end)
break;
}
+static bool new_client(struct i915_request *rq)
+{
+ struct i915_dependency *p;
+
+ list_for_each_entry(p, >sched.signalers_list, signal_link)
+ if (!(p->flags & I915_DEPENDENCY_WEAK))
+ return false;
+
+ return true;
+}
+
static void eb_request_add(struct i915_execbuffer *eb)
{
struct i915_request *rq = eb->request;
@@ -2604,7 +2615,7 @@ static void eb_request_add(struct i915_execbuffer *eb)
* Allow interactive/synchronous clients to jump ahead of
* the bulk clients. (FQ_CODEL)
*/
- if (list_empty(>sched.signalers_list))
+ if (new_client(rq))
attr.priority |= I915_PRIORITY_WAIT;
} else {
/* Serialise with context_close via the add_to_timeline */
Did absence of this have any functional effect? I hope not, but anyway:
Bah, I have a new test case where this WAIT bumping is still upsetting us.
I don't think I have any choice but to rip it out if we have timeslicing
enabled.
Would you prefer a complete remission of I915_PRIORITY_WAIT or keep it
under if (!intel_engine_has_timeslicing(rq->engine)) ?
Doesn't feel worthwhile to keep it for just BDW right?
Regards,
Tvrtko
___
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/gen12: Add aux table invalidate for all engines (rev2)
== Series Details == Series: drm/i915/gen12: Add aux table invalidate for all engines (rev2) URL : https://patchwork.freedesktop.org/series/77038/ State : success == Summary == CI Bug Log - changes from CI_DRM_8444 -> Patchwork_17601 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/index.html Known issues Here are the changes found in Patchwork_17601 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_pm_rpm@basic-rte: - fi-hsw-4770:[SKIP][1] ([fdo#109271]) -> [PASS][2] +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-hsw-4770/igt@i915_pm_...@basic-rte.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/fi-hsw-4770/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rpm@module-reload: - fi-skl-6700k2: [INCOMPLETE][3] ([i915#151]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-skl-6700k2/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/fi-skl-6700k2/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@reset: - fi-bwr-2160:[INCOMPLETE][5] ([i915#489]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-bwr-2160/igt@i915_selftest@l...@reset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/fi-bwr-2160/igt@i915_selftest@l...@reset.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151 [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 Participating hosts (49 -> 42) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-n2820 fi-byt-clapper Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8444 -> Patchwork_17601 CI-20190529: 20190529 CI_DRM_8444: 39544482386ac801dc4140df00a7e7e5bbea4d8a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5638: 50868ab3c532a86aa147fb555b69a1078c572b13 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17601: e20a34365bd65217187425abcc1fbba0528a8003 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e20a34365bd6 drm/i915/gen12: Add aux table invalidate for all engines == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17601/index.html ___ 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/gem: Treat submit-fence as weak dependency for new clients
Quoting Tvrtko Ursulin (2020-05-07 15:59:56)
>
> On 07/05/2020 09:21, Chris Wilson wrote:
> > The submit-fence adds a weak dependency to the requests, and for the
> > purpose of our FQ_CODEL hinting we do not want to treat as a
> > restriction. This is primarily because clients may treat submit-fences
> > as a bidirectional bonding between a pair of co-ordinating requests.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 13 -
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 966523a8503f..e8bf0cf02fd7 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -2565,6 +2565,17 @@ static void retire_requests(struct intel_timeline
> > *tl, struct i915_request *end)
> > break;
> > }
> >
> > +static bool new_client(struct i915_request *rq)
> > +{
> > + struct i915_dependency *p;
> > +
> > + list_for_each_entry(p, >sched.signalers_list, signal_link)
> > + if (!(p->flags & I915_DEPENDENCY_WEAK))
> > + return false;
> > +
> > + return true;
> > +}
> > +
> > static void eb_request_add(struct i915_execbuffer *eb)
> > {
> > struct i915_request *rq = eb->request;
> > @@ -2604,7 +2615,7 @@ static void eb_request_add(struct i915_execbuffer *eb)
> >* Allow interactive/synchronous clients to jump ahead of
> >* the bulk clients. (FQ_CODEL)
> >*/
> > - if (list_empty(>sched.signalers_list))
> > + if (new_client(rq))
> > attr.priority |= I915_PRIORITY_WAIT;
> > } else {
> > /* Serialise with context_close via the add_to_timeline */
> >
>
> Did absence of this have any functional effect? I hope not, but anyway:
Bah, I have a new test case where this WAIT bumping is still upsetting us.
I don't think I have any choice but to rip it out if we have timeslicing
enabled.
Would you prefer a complete remission of I915_PRIORITY_WAIT or keep it
under if (!intel_engine_has_timeslicing(rq->engine)) ?
-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: Mark concurrent submissions with a weak-dependency
Quoting Tvrtko Ursulin (2020-05-07 15:53:08)
>
> On 07/05/2020 09:21, Chris Wilson wrote:
> > We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
> > correctly perform priority inheritance from the parallel branches to the
> > common trunk. However, for the purpose of timeslicing and reset
> > handling, the dependency is weak -- as we the pair of requests are
> > allowed to run in parallel and not in strict succession. So for example
> > we do need to suspend one if the other hangs.
> >
> > The real significance though is that this allows us to rearrange
> > groups of WAIT_FOR_SUBMIT linked requests along the single engine, and
> > so can resolve user level inter-batch scheduling dependencies from user
> > semaphores.
> >
> > Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags
> > across submit fences")
> > Testcase: igt/gem_exec_fence/submit
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: # v5.6+
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
> > drivers/gpu/drm/i915/i915_request.c | 8 ++--
> > drivers/gpu/drm/i915/i915_scheduler.c | 6 +++---
> > drivers/gpu/drm/i915/i915_scheduler.h | 3 ++-
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
> > 5 files changed, 21 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index dc3f2ee7136d..10109f661bcb 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq,
> > struct list_head * const pl)
> > struct i915_request *w =
> > container_of(p->waiter, typeof(*w), sched);
> >
> > + if (p->flags & I915_DEPENDENCY_WEAK)
> > + continue;
> > +
>
> I did not quite get it - submit fence dependency would mean different
> engines, so the below check (w->engine != rq->engine) would effectively
> have the same effect. What am I missing?
That submit fences can be between different contexts on the same engine.
The example (from mesa) is where we have two interdependent clients
which are using their own userlevel scheduling inside each batch, i.e.
waiting on semaphores.
-Chris
___
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/gem: Treat submit-fence as weak dependency for new clients
On 07/05/2020 09:21, Chris Wilson wrote:
The submit-fence adds a weak dependency to the requests, and for the
purpose of our FQ_CODEL hinting we do not want to treat as a
restriction. This is primarily because clients may treat submit-fences
as a bidirectional bonding between a pair of co-ordinating requests.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 966523a8503f..e8bf0cf02fd7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2565,6 +2565,17 @@ static void retire_requests(struct intel_timeline *tl,
struct i915_request *end)
break;
}
+static bool new_client(struct i915_request *rq)
+{
+ struct i915_dependency *p;
+
+ list_for_each_entry(p, >sched.signalers_list, signal_link)
+ if (!(p->flags & I915_DEPENDENCY_WEAK))
+ return false;
+
+ return true;
+}
+
static void eb_request_add(struct i915_execbuffer *eb)
{
struct i915_request *rq = eb->request;
@@ -2604,7 +2615,7 @@ static void eb_request_add(struct i915_execbuffer *eb)
* Allow interactive/synchronous clients to jump ahead of
* the bulk clients. (FQ_CODEL)
*/
- if (list_empty(>sched.signalers_list))
+ if (new_client(rq))
attr.priority |= I915_PRIORITY_WAIT;
} else {
/* Serialise with context_close via the add_to_timeline */
Did absence of this have any functional effect? I hope not, but anyway:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
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: Treat weak-dependencies as bidirectional when applying priorities
On 07/05/2020 09:21, Chris Wilson wrote:
Clients may use a submit-fence as bidirectional bond between two or more
co-operating requests, and so if we bump the priority of one, we wish to
bump the priority of the set.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 6e2d4190099f..7194fbfcaa49 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -291,6 +291,12 @@ static void __i915_schedule(struct i915_sched_node *node,
if (prio > READ_ONCE(p->signaler->attr.priority))
list_move_tail(>dfs_link, );
}
+
+ list_for_each_entry(p, >waiters_list, wait_link) {
+ if (p->flags & I915_DEPENDENCY_WEAK &&
+ prio > READ_ONCE(p->waiter->attr.priority))
+ list_move_tail(>dfs_link, );
+ }
}
/*
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
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: Mark concurrent submissions with a weak-dependency
On 07/05/2020 09:21, Chris Wilson wrote:
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in parallel and not in strict succession. So for example
we do need to suspend one if the other hangs.
The real significance though is that this allows us to rearrange
groups of WAIT_FOR_SUBMIT linked requests along the single engine, and
so can resolve user level inter-batch scheduling dependencies from user
semaphores.
Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across submit
fences")
Testcase: igt/gem_exec_fence/submit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.6+
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
drivers/gpu/drm/i915/i915_request.c | 8 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 6 +++---
drivers/gpu/drm/i915/i915_scheduler.h | 3 ++-
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
5 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index dc3f2ee7136d..10109f661bcb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq, struct
list_head * const pl)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
I did not quite get it - submit fence dependency would mean different
engines, so the below check (w->engine != rq->engine) would effectively
have the same effect. What am I missing?
Regards,
Tvrtko
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
@@ -2726,6 +2729,9 @@ static void __execlists_hold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
@@ -2850,6 +2856,9 @@ static void __execlists_unhold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Propagate any change in error status */
if (rq->fence.error)
i915_request_set_error_once(w, rq->fence.error);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 4d18f808fda2..3c38d61c90f8 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1040,7 +1040,9 @@ i915_request_await_request(struct i915_request *to,
struct i915_request *from)
}
if (to->engine->schedule) {
- ret = i915_sched_node_add_dependency(>sched, >sched);
+ ret = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_EXTERNAL);
if (ret < 0)
return ret;
}
@@ -1202,7 +1204,9 @@ __i915_request_await_execution(struct i915_request *to,
/* Couple the dependency tree for PI on this exposed to->fence */
if (to->engine->schedule) {
- err = i915_sched_node_add_dependency(>sched, >sched);
+ err = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_WEAK);
if (err < 0)
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 37cfcf5b321b..6e2d4190099f 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -462,7 +462,8 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
}
int i915_sched_node_add_dependency(struct i915_sched_node *node,
- struct i915_sched_node *signal)
+ struct i915_sched_node *signal,
+ unsigned long flags)
{
struct i915_dependency *dep;
@@ -473,8 +474,7 @@ int i915_sched_node_add_dependency(struct i915_sched_node *node,
[Intel-gfx] ✓ Fi.CI.BAT: success for In order to readout DP SDPs, refactors the handling of DP SDPs (rev13)
== Series Details == Series: In order to readout DP SDPs, refactors the handling of DP SDPs (rev13) URL : https://patchwork.freedesktop.org/series/72853/ State : success == Summary == CI Bug Log - changes from CI_DRM_8444 -> Patchwork_17600 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/index.html Known issues Here are the changes found in Patchwork_17600 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_pm: - fi-cfl-8700k: [PASS][1] -> [INCOMPLETE][2] ([i915#1794]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-cfl-8700k/igt@i915_selftest@live@gt_pm.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/fi-cfl-8700k/igt@i915_selftest@live@gt_pm.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-skl-6700k2: [INCOMPLETE][3] ([i915#151]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-skl-6700k2/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/fi-skl-6700k2/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@reset: - fi-bwr-2160:[INCOMPLETE][5] ([i915#489]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8444/fi-bwr-2160/igt@i915_selftest@l...@reset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/fi-bwr-2160/igt@i915_selftest@l...@reset.html [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151 [i915#1794]: https://gitlab.freedesktop.org/drm/intel/issues/1794 [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 Participating hosts (49 -> 42) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-hsw-4770 fi-byt-clapper Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8444 -> Patchwork_17600 CI-20190529: 20190529 CI_DRM_8444: 39544482386ac801dc4140df00a7e7e5bbea4d8a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5638: 50868ab3c532a86aa147fb555b69a1078c572b13 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17600: 21e992a96510a4b297170c1aee390b96286704e9 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 21e992a96510 drm/i915/psr: Use new DP VSC SDP compute routine on PSR 74c2a914a012 drm/i915/dp: Add compute routine for DP PSR VSC SDP 5cf81085a0c1 drm/i915: Stop sending DP SDPs on ddi disable 0251102af3b9 drm/i915: Program DP SDPs on pipe updates a71792fd1d5a drm/i915: Fix enabled infoframe states of lspcon 84bf9208397c drm/i915: Add state readout for DP VSC SDP e1c3006e8068 drm/i915: Add state readout for DP HDR Metadata Infoframe SDP 0c6956c780de drm/i915: Program DP SDPs with computed configs ffb06944568a drm/i915: Include DP VSC SDP in the crtc state dump 20cdec4dde7d drm/i915: Include DP HDR Metadata Infoframe SDP in the crtc state dump ee8f99248537 drm/i915: Include HDMI DRM infoframe in the crtc state dump e32e44f11938 drm: Add logging function for DP VSC SDP 2ad5c4085132 drm/i915/dp: Read out DP SDPs 96f3abd228ee video/hdmi: Add Unpack only function for DRM infoframe == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17600/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v28 1/6] drm/i915: Introduce skl_plane_wm_level accessor.
For future Gen12 SAGV implementation we need to
seemlessly alter wm levels calculated, depending
on whether we are allowed to enable SAGV or not.
So this accessor will give additional flexibility
to do that.
Currently this accessor is still simply working
as "pass-through" function. This will be changed
in next coming patches from this series.
v2: - plane_id -> plane->id(Ville Syrjälä)
- Moved wm_level var to have more local scope
(Ville Syrjälä)
- Renamed yuv to color_plane(Ville Syrjälä) in
skl_plane_wm_level
v3: - plane->id -> plane_id(this time for real, Ville Syrjälä)
- Changed colorplane id type from boolean to int as index
(Ville Syrjälä)
- Moved crtc_state param so that it is first now
(Ville Syrjälä)
- Moved wm_level declaration to tigher scope in
skl_write_plane_wm(Ville Syrjälä)
v4: - Started to use enum values for color plane
- Do sizeof for a type what we are memset'ing
- Zero out wm_uv as well(Ville Syrjälä)
v5: - Fixed rebase conflict caused by COLOR_PLANE_*
enum removal
v6: - Do not use skl_plane_wm_level accessor in skl_allocate_pipe_ddb
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 416cb1a1e7cb..8a86298962dc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4632,6 +4632,18 @@ icl_get_total_relative_data_rate(struct intel_crtc_state
*crtc_state,
return total_data_rate;
}
+static const struct skl_wm_level *
+skl_plane_wm_level(const struct intel_crtc_state *crtc_state,
+ enum plane_id plane_id,
+ int level,
+ int color_plane)
+{
+ const struct skl_plane_wm *wm =
+ _state->wm.skl.optimal.planes[plane_id];
+
+ return color_plane == 0 ? >wm[level] : >uv_wm[level];
+}
+
static int
skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
{
@@ -5439,8 +5451,13 @@ void skl_write_plane_wm(struct intel_plane *plane,
_state->wm.skl.plane_ddb_uv[plane_id];
for (level = 0; level <= max_level; level++) {
+ const struct skl_wm_level *wm_level;
+ int color_plane = 0;
+
+ wm_level = skl_plane_wm_level(crtc_state, plane_id, level,
color_plane);
+
skl_write_wm_level(dev_priv, PLANE_WM(pipe, plane_id, level),
- >wm[level]);
+ wm_level);
}
skl_write_wm_level(dev_priv, PLANE_WM_TRANS(pipe, plane_id),
>trans_wm);
@@ -5473,8 +5490,13 @@ void skl_write_cursor_wm(struct intel_plane *plane,
_state->wm.skl.plane_ddb_y[plane_id];
for (level = 0; level <= max_level; level++) {
+ const struct skl_wm_level *wm_level;
+ int color_plane = 0;
+
+ wm_level = skl_plane_wm_level(crtc_state, plane_id, level,
color_plane);
+
skl_write_wm_level(dev_priv, CUR_WM(pipe, level),
- >wm[level]);
+ wm_level);
}
skl_write_wm_level(dev_priv, CUR_WM_TRANS(pipe), >trans_wm);
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v28 0/6] SAGV support for Gen12+
For Gen11+ platforms BSpec suggests disabling specific QGV points separately, depending on bandwidth limitations and current display configuration. Thus it required adding a new PCode request for disabling QGV points and some refactoring of already existing SAGV code. Also had to refactor intel_can_enable_sagv function, as current seems to be outdated and using skl specific workarounds, also not following BSpec for Gen11+. v25: Rebased patch series as part was merged already v26: Had to resend the whole series as one more mid patch was added v27: Patches 2,3,7 were pushed, have to resend the series to prevent build failure. v28: PCode patch was merged, one patch was added, sent new series. Stanislav Lisovskiy (6): drm/i915: Introduce skl_plane_wm_level accessor. drm/i915: Extract skl SAGV checking drm/i915: Make active_pipes check skl specific drm/i915: Add TGL+ SAGV support drm/i915: Restrict qgv points which don't have enough bandwidth. drm/i915: Enable SAGV support for Gen12 drivers/gpu/drm/i915/display/intel_bw.c | 139 --- drivers/gpu/drm/i915/display/intel_bw.h | 9 + drivers/gpu/drm/i915/display/intel_display.c | 8 +- .../drm/i915/display/intel_display_types.h| 5 + drivers/gpu/drm/i915/intel_pm.c | 222 -- drivers/gpu/drm/i915/intel_pm.h | 5 +- 6 files changed, 334 insertions(+), 54 deletions(-) -- 2.24.1.485.gad05a3d8e5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v28 4/6] drm/i915: Add TGL+ SAGV support
Starting from TGL we need to have a separate wm0
values for SAGV and non-SAGV which affects
how calculations are done.
v2: Remove long lines
v3: Removed COLOR_PLANE enum references
v4, v5, v6: Fixed rebase conflict
v7: - Removed skl_plane_wm_level accessor from skl_allocate_pipe_ddb(Ville)
- Removed sagv_uv_wm0(Ville)
- can_sagv->use_sagv_wm(Ville)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_display.c | 8 +-
.../drm/i915/display/intel_display_types.h| 2 +
drivers/gpu/drm/i915/intel_pm.c | 118 +-
3 files changed, 121 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index fd6d63b03489..be5741cb7595 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13961,7 +13961,9 @@ static void verify_wm_state(struct intel_crtc *crtc,
/* Watermarks */
for (level = 0; level <= max_level; level++) {
if (skl_wm_level_equals(_plane_wm->wm[level],
- _plane_wm->wm[level]))
+ _plane_wm->wm[level]) ||
+ (level == 0 &&
skl_wm_level_equals(_plane_wm->wm[level],
+
_plane_wm->sagv_wm0)))
continue;
drm_err(_priv->drm,
@@ -14016,7 +14018,9 @@ static void verify_wm_state(struct intel_crtc *crtc,
/* Watermarks */
for (level = 0; level <= max_level; level++) {
if (skl_wm_level_equals(_plane_wm->wm[level],
- _plane_wm->wm[level]))
+ _plane_wm->wm[level]) ||
+ (level == 0 &&
skl_wm_level_equals(_plane_wm->wm[level],
+
_plane_wm->sagv_wm0)))
continue;
drm_err(_priv->drm,
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9488449e4b94..8cede29c9562 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -688,11 +688,13 @@ struct skl_plane_wm {
struct skl_wm_level wm[8];
struct skl_wm_level uv_wm[8];
struct skl_wm_level trans_wm;
+ struct skl_wm_level sagv_wm0;
bool is_planar;
};
struct skl_pipe_wm {
struct skl_plane_wm planes[I915_MAX_PLANES];
+ bool use_sagv_wm;
};
enum vlv_wm_level {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index db188efee21e..934a686342ad 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3863,25 +3863,35 @@ bool intel_can_enable_sagv(struct drm_i915_private
*dev_priv,
return bw_state->pipe_sagv_reject == 0;
}
+static bool
+tgl_crtc_can_enable_sagv(const struct intel_crtc_state *crtc_state);
+
static int intel_compute_sagv_mask(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
int ret;
struct intel_crtc *crtc;
- const struct intel_crtc_state *new_crtc_state;
+ struct intel_crtc_state *new_crtc_state;
struct intel_bw_state *new_bw_state = NULL;
const struct intel_bw_state *old_bw_state = NULL;
int i;
for_each_new_intel_crtc_in_state(state, crtc,
new_crtc_state, i) {
+ bool can_sagv;
+
new_bw_state = intel_atomic_get_bw_state(state);
if (IS_ERR(new_bw_state))
return PTR_ERR(new_bw_state);
old_bw_state = intel_atomic_get_old_bw_state(state);
- if (skl_crtc_can_enable_sagv(new_crtc_state))
+ if (INTEL_GEN(dev_priv) >= 12)
+ can_sagv = tgl_crtc_can_enable_sagv(new_crtc_state);
+ else
+ can_sagv = skl_crtc_can_enable_sagv(new_crtc_state);
+
+ if (can_sagv)
new_bw_state->pipe_sagv_reject &= ~BIT(crtc->pipe);
else
new_bw_state->pipe_sagv_reject |= BIT(crtc->pipe);
@@ -3899,6 +3909,24 @@ static int intel_compute_sagv_mask(struct
intel_atomic_state *state)
return ret;
}
+ for_each_new_intel_crtc_in_state(state, crtc,
+new_crtc_state, i) {
+ struct skl_pipe_wm *pipe_wm = _crtc_state->wm.skl.optimal;
+
+ /*
+* Due to drm limitation at commit state, when
+* changes are written the whole atomic state
[Intel-gfx] [PATCH v28 6/6] drm/i915: Enable SAGV support for Gen12
Flip the switch and enable SAGV support
for Gen12 also.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 66775d4fb1ae..ef2ec390b99b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3638,10 +3638,6 @@ static bool skl_needs_memory_bw_wa(struct
drm_i915_private *dev_priv)
static bool
intel_has_sagv(struct drm_i915_private *dev_priv)
{
- /* HACK! */
- if (IS_GEN(dev_priv, 12))
- return false;
-
return (IS_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10) &&
dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED;
}
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v28 5/6] drm/i915: Restrict qgv points which don't have enough bandwidth.
According to BSpec 53998, we should try to restrict qgv points, which can't provide enough bandwidth for desired display configuration. Currently we are just comparing against all of those and take minimum(worst case). v2: Fixed wrong PCode reply mask, removed hardcoded values. v3: Forbid simultaneous legacy SAGV PCode requests and restricting qgv points. Put the actual restriction to commit function, added serialization(thanks to Ville) to prevent commit being applied out of order in case of nonblocking and/or nomodeset commits. v4: - Minor code refactoring, fixed few typos(thanks to James Ausmus) - Change the naming of qgv point masking/unmasking functions(James Ausmus). - Simplify the masking/unmasking operation itself, as we don't need to mask only single point per request(James Ausmus) - Reject and stick to highest bandwidth point if SAGV can't be enabled(BSpec) v5: - Add new mailbox reply codes, which seems to happen during boot time for TGL and indicate that QGV setting is not yet available. v6: - Increase number of supported QGV points to be in sync with BSpec. v7: - Rebased and resolved conflict to fix build failure. - Fix NUM_QGV_POINTS to 8 and moved that to header file(James Ausmus) v8: - Don't report an error if we can't restrict qgv points, as SAGV can be disabled by BIOS, which is completely legal. So don't make CI panic. Instead if we detect that there is only 1 QGV point accessible just analyze if we can fit the required bandwidth requirements, but no need in restricting. v9: - Fix wrong QGV transition if we have 0 planes and no SAGV simultaneously. v10: - Fix CDCLK corruption, because of global state getting serialized without modeset, which caused copying of non-calculated cdclk to be copied to dev_priv(thanks to Ville for the hint). v11: - Remove unneeded headers and spaces(Matthew Roper) - Remove unneeded intel_qgv_info qi struct from bw check and zero out the needed one(Matthew Roper) - Changed QGV error message to have more clear meaning(Matthew Roper) - Use state->modeset_set instead of any_ms(Matthew Roper) - Moved NUM_SAGV_POINTS from i915_reg.h to i915_drv.h where it's used - Keep using crtc_state->hw.active instead of .enable(Matthew Roper) - Moved unrelated changes to other patch(using latency as parameter for plane wm calculation, moved to SAGV refactoring patch) v12: - Fix rebase conflict with own temporary SAGV/QGV fix. - Remove unnecessary mask being zero check when unmasking qgv points as this is completely legal(Matt Roper) - Check if we are setting the same mask as already being set in hardware to prevent error from PCode. - Fix error message when restricting/unrestricting qgv points to "mask/unmask" which sounds more accurate(Matt Roper) - Move sagv status setting to icl_get_bw_info from atomic check as this should be calculated only once.(Matt Roper) - Edited comments for the case when we can't enable SAGV and use only 1 QGV point with highest bandwidth to be more understandable.(Matt Roper) v13: - Moved max_data_rate in bw check to closer scope(Ville Syrjälä) - Changed comment for zero new_mask in qgv points masking function to better reflect reality(Ville Syrjälä) - Simplified bit mask operation in qgv points masking function (Ville Syrjälä) - Moved intel_qgv_points_mask closer to gen11 SAGV disabling, however this still can't be under modeset condition(Ville Syrjälä) - Packed qgv_points_mask as u8 and moved closer to pipe_sagv_mask (Ville Syrjälä) - Extracted PCode changes to separate patch.(Ville Syrjälä) - Now treat num_planes 0 same as 1 to avoid confusion and returning max_bw as 0, which would prevent choosing QGV point having max bandwidth in case if SAGV is not allowed, as per BSpec(Ville Syrjälä) - Do the actual qgv_points_mask swap in the same place as all other global state parts like cdclk are swapped. In the next patch, this all will be moved to bw state as global state, once new global state patch series from Ville lands v14: - Now using global state to serialize access to qgv points - Added global state locking back, otherwise we seem to read bw state in a wrong way. v15: - Added TODO comment for near atomic global state locking in bw code. v16: - Fixed intel_atomic_bw_* functions to be intel_bw_* as discussed with Jani Nikula. - Take bw_state_changed flag into use. v17: - Moved qgv point related manipulations next to SAGV code, as those are semantically related(Ville Syrjälä) - Renamed those into intel_sagv_(pre)|(post)_plane_update (Ville Syrjälä) v18: - Move sagv related calls from commit tail into intel_sagv_(pre)|(post)_plane_update(Ville
[Intel-gfx] [PATCH v28 3/6] drm/i915: Make active_pipes check skl specific
Seems that only skl needs to have SAGV turned off
for multipipe scenarios, so lets do it this way.
If anything blows up - we can always revert this patch.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 15 +--
drivers/gpu/drm/i915/intel_pm.h | 3 ++-
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3dc1ad66beb3..db188efee21e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3777,7 +3777,7 @@ void intel_sagv_pre_plane_update(struct
intel_atomic_state *state)
if (!new_bw_state)
return;
- if (!intel_can_enable_sagv(new_bw_state))
+ if (!intel_can_enable_sagv(dev_priv, new_bw_state))
intel_disable_sagv(dev_priv);
}
@@ -3800,7 +3800,7 @@ void intel_sagv_post_plane_update(struct
intel_atomic_state *state)
if (!new_bw_state)
return;
- if (intel_can_enable_sagv(new_bw_state))
+ if (intel_can_enable_sagv(dev_priv, new_bw_state))
intel_enable_sagv(dev_priv);
}
@@ -3853,16 +3853,19 @@ static bool skl_crtc_can_enable_sagv(const struct
intel_crtc_state *crtc_state)
return true;
}
-bool intel_can_enable_sagv(const struct intel_bw_state *bw_state)
+bool intel_can_enable_sagv(struct drm_i915_private *dev_priv,
+ const struct intel_bw_state *bw_state)
{
- if (bw_state->active_pipes && !is_power_of_2(bw_state->active_pipes))
- return false;
+ if (INTEL_GEN(dev_priv) < 11)
+ if (bw_state->active_pipes &&
!is_power_of_2(bw_state->active_pipes))
+ return false;
return bw_state->pipe_sagv_reject == 0;
}
static int intel_compute_sagv_mask(struct intel_atomic_state *state)
{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
int ret;
struct intel_crtc *crtc;
const struct intel_crtc_state *new_crtc_state;
@@ -3896,7 +3899,7 @@ static int intel_compute_sagv_mask(struct
intel_atomic_state *state)
return ret;
}
- if (intel_can_enable_sagv(new_bw_state) !=
intel_can_enable_sagv(old_bw_state)) {
+ if (intel_can_enable_sagv(dev_priv, new_bw_state) !=
intel_can_enable_sagv(dev_priv, old_bw_state)) {
ret = intel_atomic_serialize_global_state(_bw_state->base);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_pm.h b/drivers/gpu/drm/i915/intel_pm.h
index fd1dc422e6c5..614ac7f8d4cc 100644
--- a/drivers/gpu/drm/i915/intel_pm.h
+++ b/drivers/gpu/drm/i915/intel_pm.h
@@ -42,7 +42,8 @@ void skl_pipe_wm_get_hw_state(struct intel_crtc *crtc,
struct skl_pipe_wm *out);
void g4x_wm_sanitize(struct drm_i915_private *dev_priv);
void vlv_wm_sanitize(struct drm_i915_private *dev_priv);
-bool intel_can_enable_sagv(const struct intel_bw_state *bw_state);
+bool intel_can_enable_sagv(struct drm_i915_private *dev_priv,
+ const struct intel_bw_state *bw_state);
int intel_enable_sagv(struct drm_i915_private *dev_priv);
int intel_disable_sagv(struct drm_i915_private *dev_priv);
void intel_sagv_pre_plane_update(struct intel_atomic_state *state);
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v28 2/6] drm/i915: Extract skl SAGV checking
Introduce platform dependent SAGV checking in
combination with bandwidth state pipe SAGV mask.
This is preparation to adding TGL support, which
requires different way of SAGV checking.
v2, v3, v4, v5, v6: Fix rebase conflict
v7: - Nuke icl specific function, use skl
for icl as well, gen specific active_pipes
check to be added in the next patch(Ville)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8a86298962dc..3dc1ad66beb3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3804,7 +3804,7 @@ void intel_sagv_post_plane_update(struct
intel_atomic_state *state)
intel_enable_sagv(dev_priv);
}
-static bool intel_crtc_can_enable_sagv(const struct intel_crtc_state
*crtc_state)
+static bool skl_crtc_can_enable_sagv(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -3865,7 +3865,7 @@ static int intel_compute_sagv_mask(struct
intel_atomic_state *state)
{
int ret;
struct intel_crtc *crtc;
- struct intel_crtc_state *new_crtc_state;
+ const struct intel_crtc_state *new_crtc_state;
struct intel_bw_state *new_bw_state = NULL;
const struct intel_bw_state *old_bw_state = NULL;
int i;
@@ -3878,7 +3878,7 @@ static int intel_compute_sagv_mask(struct
intel_atomic_state *state)
old_bw_state = intel_atomic_get_old_bw_state(state);
- if (intel_crtc_can_enable_sagv(new_crtc_state))
+ if (skl_crtc_can_enable_sagv(new_crtc_state))
new_bw_state->pipe_sagv_reject &= ~BIT(crtc->pipe);
else
new_bw_state->pipe_sagv_reject |= BIT(crtc->pipe);
@@ -3889,6 +3889,7 @@ static int intel_compute_sagv_mask(struct
intel_atomic_state *state)
new_bw_state->active_pipes =
intel_calc_active_pipes(state, old_bw_state->active_pipes);
+
if (new_bw_state->active_pipes != old_bw_state->active_pipes) {
ret = intel_atomic_lock_global_state(_bw_state->base);
if (ret)
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gen12: Add aux table invalidate for all engines (rev2)
== Series Details ==
Series: drm/i915/gen12: Add aux table invalidate for all engines (rev2)
URL : https://patchwork.freedesktop.org/series/77038/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e20a34365bd6 drm/i915/gen12: Add aux table invalidate for all engines
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#15:
References: d248b371f747 ("drm/i915/gen12: Invalidate aux table entries
forcibly")
-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit d248b371f747 ("drm/i915/gen12:
Invalidate aux table entries forcibly")'
#15:
References: d248b371f747 ("drm/i915/gen12: Invalidate aux table entries
forcibly")
-:50: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to using
'aux_inv_reg', this function's name, in a string
#50: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:4562:
+ GEM_BUG_ON("unknown aux_inv_reg\n");
total: 1 errors, 2 warnings, 0 checks, 126 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [kbuild] Re: [PATCH v12 3/4] drm/i915/perf: prepare driver to receive multiple ctx handles
Hi Lionel,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Lionel-Landwerlin/drm-i915-perf-Add-support-for-multi-context-perf-queries/20200505-060720
base: git://anongit.freedesktop.org/drm-intel for-linux-next
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
Reported-by: Dan Carpenter
New smatch warnings:
drivers/gpu/drm/i915/i915_perf.c:1457 i915_oa_stream_destroy() error:
uninitialized symbol 'err'.
Old smatch warnings:
drivers/gpu/drm/i915/i915_perf.c:1383 oa_get_render_ctx_ids() error: double
unlocked 'ctx->engines_mutex' (orig line 1351)
drivers/gpu/drm/i915/i915_perf.c:3044 i915_oa_stream_init() error:
uninitialized symbol 'timeline'.
drivers/gpu/drm/i915/i915_perf.c:3664 i915_perf_open_ioctl_locked() error:
uninitialized symbol 'ret'.
#
https://github.com/0day-ci/linux/commit/dc9d77b54dfbfd0de4e30e59d29d5216b80a51b2
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout dc9d77b54dfbfd0de4e30e59d29d5216b80a51b2
vim +/err +1457 drivers/gpu/drm/i915/i915_perf.c
307ca63ef54097 Lionel Landwerlin 2020-05-04 1441
d79651522e89c4 Robert Bragg 2016-11-07 1442 static void
i915_oa_stream_destroy(struct i915_perf_stream *stream)
d79651522e89c4 Robert Bragg 2016-11-07 1443 {
8f8b1171e1a514 Chris Wilson 2019-10-07 1444 struct i915_perf *perf
= stream->perf;
307ca63ef54097 Lionel Landwerlin 2020-05-04 1445 int err;
^^^
d79651522e89c4 Robert Bragg 2016-11-07 1446
8f8b1171e1a514 Chris Wilson 2019-10-07 1447 BUG_ON(stream !=
perf->exclusive_stream);
d79651522e89c4 Robert Bragg 2016-11-07 1448
19f81df2859eb1 Robert Bragg 2017-06-13 1449 /*
f89823c212246d Lionel Landwerlin 2017-08-03 1450* Unset
exclusive_stream first, it will be checked while disabling
f89823c212246d Lionel Landwerlin 2017-08-03 1451* the metric set on
gen8+.
a5af081d012e8b Chris Wilson 2020-02-27 1452*
a5af081d012e8b Chris Wilson 2020-02-27 1453* See
i915_oa_init_reg_state() and lrc_configure_all_contexts()
19f81df2859eb1 Robert Bragg 2017-06-13 1454*/
a5af081d012e8b Chris Wilson 2020-02-27 1455
WRITE_ONCE(perf->exclusive_stream, NULL);
dc9d77b54dfbfd Lionel Landwerlin 2020-05-04 1456
dc9d77b54dfbfd Lionel Landwerlin 2020-05-04 @1457 if (!err) {
^
Uninitialized
307ca63ef54097 Lionel Landwerlin 2020-05-04 1458 err =
i915_perf_stream_sync(stream, false /* enable */);
307ca63ef54097 Lionel Landwerlin 2020-05-04 1459 if (err) {
307ca63ef54097 Lionel Landwerlin 2020-05-04 1460
drm_err(>i915->drm,
307ca63ef54097 Lionel Landwerlin 2020-05-04 1461
"Error while disabling OA stream\n");
307ca63ef54097 Lionel Landwerlin 2020-05-04 1462 }
dc9d77b54dfbfd Lionel Landwerlin 2020-05-04 1463 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
kbuild mailing list -- kbu...@lists.01.org
To unsubscribe send an email to kbuild-le...@lists.01.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/mst: Wait for ACT sent before enabling the pipe
From: Ville Syrjälä The correct sequence according to bspec is to wait for the ACT sent status before we turn on the pipe. Make it so. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp_mst.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c index 4d2384650383..d18b406f2a7d 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c @@ -510,10 +510,6 @@ static void intel_mst_enable_dp(struct intel_atomic_state *state, intel_ddi_enable_transcoder_func(encoder, pipe_config); - intel_enable_pipe(pipe_config); - - intel_crtc_vblank_on(pipe_config); - drm_dbg_kms(_priv->drm, "active links %d\n", intel_dp->active_mst_links); @@ -524,6 +520,11 @@ static void intel_mst_enable_dp(struct intel_atomic_state *state, drm_dp_check_act_status(_dp->mst_mgr); drm_dp_update_payload_part2(_dp->mst_mgr); + + intel_enable_pipe(pipe_config); + + intel_crtc_vblank_on(pipe_config); + if (pipe_config->has_audio) intel_audio_codec_enable(encoder, pipe_config, conn_state); } -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gen12: Add aux table invalidate for all engines
All engines, exception being blitter as it does not
care about the form, can access compressed surfaces.
So we need to add forced aux table invalidates
for those engines.
v2: virtual instance masking (Chris)
v3: bug on if not found (Chris)
References: d248b371f747 ("drm/i915/gen12: Invalidate aux table entries
forcibly")
References bspec#43904, hsdes#1809175790
Cc: Chris Wilson
Cc: Chuansheng Liu
Cc: Rafael Antognolli
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 86 +++--
drivers/gpu/drm/i915/i915_reg.h | 6 ++
2 files changed, 87 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index bbdb0e2a4571..e12916e2799b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4539,11 +4539,36 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
+static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
+{
+ static const i915_reg_t vd[] = {
+ GEN12_VD0_AUX_NV,
+ GEN12_VD1_AUX_NV,
+ GEN12_VD2_AUX_NV,
+ GEN12_VD3_AUX_NV,
+ };
+
+ static const i915_reg_t ve[] = {
+ GEN12_VE0_AUX_NV,
+ GEN12_VE1_AUX_NV,
+ };
+
+ if (engine->class == VIDEO_DECODE_CLASS)
+ return vd[engine->instance];
+
+ if (engine->class == VIDEO_ENHANCEMENT_CLASS)
+ return ve[engine->instance];
+
+ GEM_BUG_ON("unknown aux_inv_reg\n");
+
+ return INVALID_MMIO_REG;
+}
+
static u32 *
-gen12_emit_aux_table_inv(struct i915_request *rq, u32 *cs)
+gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
{
*cs++ = MI_LOAD_REGISTER_IMM(1);
- *cs++ = i915_mmio_reg_offset(GEN12_GFX_CCS_AUX_NV);
+ *cs++ = i915_mmio_reg_offset(inv_reg);
*cs++ = AUX_INV;
*cs++ = MI_NOOP;
@@ -4612,7 +4637,7 @@ static int gen12_emit_flush_render(struct i915_request
*request,
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
/* hsdes: 1809175790 */
- cs = gen12_emit_aux_table_inv(request, cs);
+ cs = gen12_emit_aux_table_inv(GEN12_GFX_CCS_AUX_NV, cs);
*cs++ = preparser_disable(false);
intel_ring_advance(request, cs);
@@ -4621,6 +4646,56 @@ static int gen12_emit_flush_render(struct i915_request
*request,
return 0;
}
+static int gen12_emit_flush(struct i915_request *request, u32 mode)
+{
+ intel_engine_mask_t aux_inv = 0;
+ u32 cmd, *cs;
+
+ if (mode & EMIT_INVALIDATE)
+ aux_inv = request->engine->mask & ~BIT(BCS0);
+
+ cs = intel_ring_begin(request,
+ 4 + (aux_inv ? 2 * hweight8(aux_inv) + 2 : 0));
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ cmd = MI_FLUSH_DW + 1;
+
+ /* We always require a command barrier so that subsequent
+* commands, such as breadcrumb interrupts, are strictly ordered
+* wrt the contents of the write cache being flushed to memory
+* (and thus being coherent from the CPU).
+*/
+ cmd |= MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW;
+
+ if (mode & EMIT_INVALIDATE) {
+ cmd |= MI_INVALIDATE_TLB;
+ if (request->engine->class == VIDEO_DECODE_CLASS)
+ cmd |= MI_INVALIDATE_BSD;
+ }
+
+ *cs++ = cmd;
+ *cs++ = LRC_PPHWSP_SCRATCH_ADDR;
+ *cs++ = 0; /* upper addr */
+ *cs++ = 0; /* value */
+
+ if (aux_inv) { /* hsdes: 1809175790 */
+ struct intel_engine_cs *engine;
+ unsigned int tmp;
+
+ *cs++ = MI_LOAD_REGISTER_IMM(hweight8(aux_inv));
+ for_each_engine_masked(engine, request->engine->gt,
+ aux_inv, tmp) {
+ *cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
+ *cs++ = AUX_INV;
+ }
+ *cs++ = MI_NOOP;
+ }
+ intel_ring_advance(request, cs);
+
+ return 0;
+}
+
/*
* Reserve space for 2 NOOPs at the end of each request to be
* used as a workaround for not being allowed to do lite
@@ -4854,9 +4929,10 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
engine->emit_flush = gen8_emit_flush;
engine->emit_init_breadcrumb = gen8_emit_init_breadcrumb;
engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb;
- if (INTEL_GEN(engine->i915) >= 12)
+ if (INTEL_GEN(engine->i915) >= 12) {
engine->emit_fini_breadcrumb = gen12_emit_fini_breadcrumb;
-
+ engine->emit_flush = gen12_emit_flush;
+ }
engine->set_default_submission = intel_execlists_set_default_submission;
if (INTEL_GEN(engine->i915) < 11) {
diff --git
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for In order to readout DP SDPs, refactors the handling of DP SDPs (rev13)
== Series Details ==
Series: In order to readout DP SDPs, refactors the handling of DP SDPs (rev13)
URL : https://patchwork.freedesktop.org/series/72853/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
96f3abd228ee video/hdmi: Add Unpack only function for DRM infoframe
2ad5c4085132 drm/i915/dp: Read out DP SDPs
e32e44f11938 drm: Add logging function for DP VSC SDP
ee8f99248537 drm/i915: Include HDMI DRM infoframe in the crtc state dump
20cdec4dde7d drm/i915: Include DP HDR Metadata Infoframe SDP in the crtc state
dump
ffb06944568a drm/i915: Include DP VSC SDP in the crtc state dump
0c6956c780de drm/i915: Program DP SDPs with computed configs
e1c3006e8068 drm/i915: Add state readout for DP HDR Metadata Infoframe SDP
84bf9208397c drm/i915: Add state readout for DP VSC SDP
-:83: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible
side-effects?
#83: FILE: drivers/gpu/drm/i915/display/intel_display.c:13750:
+#define PIPE_CONF_CHECK_DP_VSC_SDP(name) do { \
+ if (!current_config->has_psr && !pipe_config->has_psr && \
+ !intel_compare_dp_vsc_sdp(_config->infoframes.name, \
+ _config->infoframes.name)) { \
+ pipe_config_dp_vsc_sdp_mismatch(dev_priv, fastset,
__stringify(name), \
+
_config->infoframes.name, \
+ _config->infoframes.name);
\
+ ret = false; \
+ } \
+} while (0)
total: 0 errors, 0 warnings, 1 checks, 75 lines checked
a71792fd1d5a drm/i915: Fix enabled infoframe states of lspcon
0251102af3b9 drm/i915: Program DP SDPs on pipe updates
5cf81085a0c1 drm/i915: Stop sending DP SDPs on ddi disable
74c2a914a012 drm/i915/dp: Add compute routine for DP PSR VSC SDP
21e992a96510 drm/i915/psr: Use new DP VSC SDP compute routine on PSR
-:107: WARNING:TABSTOP: Statements should start on a tabstop
#107: FILE: drivers/gpu/drm/i915/display/intel_psr.c:727:
+if (!psr_global_enabled(dev_priv))
total: 0 errors, 1 warnings, 0 checks, 168 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Hotplug cleanups (rev7)
== Series Details == Series: drm/i915: Hotplug cleanups (rev7) URL : https://patchwork.freedesktop.org/series/72348/ State : success == Summary == CI Bug Log - changes from CI_DRM_8442_full -> Patchwork_17599_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17599_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/shard-apl7/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/shard-apl6/igt@gem_...@in-flight-suspend.html * igt@kms_big_fb@linear-32bpp-rotate-0: - shard-kbl: [PASS][3] -> [FAIL][4] ([i915#1119] / [i915#93] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/shard-kbl2/igt@kms_big...@linear-32bpp-rotate-0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/shard-kbl3/igt@kms_big...@linear-32bpp-rotate-0.html * igt@kms_color@pipe-a-ctm-green-to-red: - shard-skl: [PASS][5] -> [FAIL][6] ([i915#129]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/shard-skl5/igt@kms_co...@pipe-a-ctm-green-to-red.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/shard-skl8/igt@kms_co...@pipe-a-ctm-green-to-red.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +7 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size: - shard-skl: [PASS][9] -> [FAIL][10] ([IGT#5]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/shard-skl8/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/shard-skl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109349]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/shard-iclb4/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#52] / [i915#54] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/shard-apl1/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/shard-apl6/igt@kms_draw_...@draw-method-xrgb-pwrite-untiled.html * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#49]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/shard-glk4/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/shard-glk1/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1188]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/shard-skl5/igt@kms_...@bpc-switch-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/shard-skl9/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_cursor_blt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/shard-iclb4/igt@kms_psr@psr2_cursor_blt.html * igt@kms_setmode@basic: - shard-hsw: [PASS][23] -> [FAIL][24] ([i915#31]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/shard-hsw1/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/shard-hsw4/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-skl: [PASS][25] ->
Re: [Intel-gfx] [PATCH 12/15] drm/i915: Replace the hardcoded I915_FENCE_TIMEOUT
Quoting Ruhl, Michael J (2020-05-07 14:53:00) > > > >-Original Message- > >From: Intel-gfx On Behalf Of Chris > >Wilson > >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c > >b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c > >index 3a146aa2593b..d3a86a4d5c04 100644 > >--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c > >+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c > >@@ -288,8 +288,7 @@ int i915_gem_schedule_fill_pages_blt(struct > >drm_i915_gem_object *obj, > > > > i915_gem_object_lock(obj); > > err = i915_sw_fence_await_reservation(>wait, > >-obj->base.resv, NULL, > >-true, I915_FENCE_TIMEOUT, > >+obj->base.resv, NULL, true, 0, > > Did you miss this one, or is the '0' on purpose? It should be 0, as it should be only handling internal fences which may take as long as required and should not be timed out. Still this is a placeholder function and should not be taken too seriously. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/15] drm/i915: Replace the hardcoded I915_FENCE_TIMEOUT
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Wednesday, May 6, 2020 4:59 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Chris Wilson
>Subject: [Intel-gfx] [PATCH 12/15] drm/i915: Replace the hardcoded
>I915_FENCE_TIMEOUT
>
>Expose the hardcoded timeout for unsignaled foreign fences as a Kconfig
>option, primarily to allow brave systems to disable the timeout and
>solely rely on correct signaling.
>
>Signed-off-by: Chris Wilson
>Cc: Joonas Lahtinen
>---
> drivers/gpu/drm/i915/Kconfig.profile | 12
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_display.c | 5 +++--
> drivers/gpu/drm/i915/gem/i915_gem_clflush.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 3 +--
> drivers/gpu/drm/i915/gem/i915_gem_fence.c | 4 ++--
> drivers/gpu/drm/i915/i915_config.c | 15 +++
> drivers/gpu/drm/i915/i915_drv.h| 10 +-
> drivers/gpu/drm/i915/i915_request.c| 9 ++---
> 9 files changed, 50 insertions(+), 11 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_config.c
>
>diff --git a/drivers/gpu/drm/i915/Kconfig.profile
>b/drivers/gpu/drm/i915/Kconfig.profile
>index 0bfd276c19fe..3925be65d314 100644
>--- a/drivers/gpu/drm/i915/Kconfig.profile
>+++ b/drivers/gpu/drm/i915/Kconfig.profile
>@@ -1,3 +1,15 @@
>+config DRM_I915_FENCE_TIMEOUT
>+ int "Timeout for unsignaled foreign fences"
>+ default 1 # milliseconds
>+ help
>+When listening to a foreign fence, we install a supplementary timer
>+to ensure that we are always signaled and our userspace is able to
>+make forward progress. This value specifies the timeout used for an
>+unsignaled foreign fence.
>+
>+May be 0 to disable the timeout, and rely on the foreign fence being
>+eventually signaled.
>+
> config DRM_I915_USERFAULT_AUTOSUSPEND
> int "Runtime autosuspend delay for userspace GGTT mmaps (ms)"
> default 250 # milliseconds
>diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>index 5359c736c789..b0da6ea6e3f1 100644
>--- a/drivers/gpu/drm/i915/Makefile
>+++ b/drivers/gpu/drm/i915/Makefile
>@@ -35,6 +35,7 @@ subdir-ccflags-y += -I$(srctree)/$(src)
>
> # core driver code
> i915-y += i915_drv.o \
>+i915_config.o \
> i915_irq.o \
> i915_getparam.o \
> i915_params.o \
>diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>b/drivers/gpu/drm/i915/display/intel_display.c
>index fd6d63b03489..432b4eeaf9f6 100644
>--- a/drivers/gpu/drm/i915/display/intel_display.c
>+++ b/drivers/gpu/drm/i915/display/intel_display.c
>@@ -15814,7 +15814,7 @@ intel_prepare_plane_fb(struct drm_plane
>*_plane,
> if (new_plane_state->uapi.fence) { /* explicit fencing */
> ret = i915_sw_fence_await_dma_fence(
>>commit_ready,
> new_plane_state-
>>uapi.fence,
>- I915_FENCE_TIMEOUT,
>+
>i915_fence_timeout(dev_priv),
> GFP_KERNEL);
> if (ret < 0)
> return ret;
>@@ -15841,7 +15841,8 @@ intel_prepare_plane_fb(struct drm_plane
>*_plane,
>
> ret = i915_sw_fence_await_reservation(
>>commit_ready,
> obj->base.resv, NULL,
>-false,
>I915_FENCE_TIMEOUT,
>+false,
>+
>i915_fence_timeout(dev_priv),
> GFP_KERNEL);
> if (ret < 0)
> goto unpin_fb;
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
>b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
>index 34be4c0ee7c5..bc0223716906 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
>@@ -108,7 +108,7 @@ bool i915_gem_clflush_object(struct
>drm_i915_gem_object *obj,
> if (clflush) {
> i915_sw_fence_await_reservation(>base.chain,
> obj->base.resv, NULL, true,
>- I915_FENCE_TIMEOUT,
>+
> i915_fence_timeout(to_i915(obj->base.dev)),
> I915_FENCE_GFP);
> dma_resv_add_excl_fence(obj->base.resv,
>>base.dma);
> dma_fence_work_commit(>base);
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>index 3a146aa2593b..d3a86a4d5c04 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>@@ -288,8 +288,7 @@ int i915_gem_schedule_fill_pages_blt(struct
>drm_i915_gem_object *obj,
>
> i915_gem_object_lock(obj);
> err =
Re: [Intel-gfx] [PATCH] drm/i915/gen12: Add aux table invalidate for all engines
Quoting Mika Kuoppala (2020-05-07 14:41:22)
> All engines, exception being blitter as it does not
> care about the form, can access compressed surfaces.
>
> So we need to add forced aux table invalidates
> for those engines.
>
> v2: virtual instance masking (Chris)
>
> References: d248b371f747 ("drm/i915/gen12: Invalidate aux table entries
> forcibly")
> References bspec#43904, hsdes#1809175790
> Cc: Chris Wilson
> Cc: Chuansheng Liu
> Cc: Rafael Antognolli
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 84 +++--
> drivers/gpu/drm/i915/i915_reg.h | 6 +++
> 2 files changed, 85 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index bbdb0e2a4571..2fffedc99806 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -4539,11 +4539,34 @@ static u32 preparser_disable(bool state)
> return MI_ARB_CHECK | 1 << 8 | state;
> }
>
> +static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
> +{
> + static const i915_reg_t vd[] = {
> + GEN12_VD0_AUX_NV,
> + GEN12_VD1_AUX_NV,
> + GEN12_VD2_AUX_NV,
> + GEN12_VD3_AUX_NV,
> + };
> +
> + static const i915_reg_t ve[] = {
> + GEN12_VE0_AUX_NV,
> + GEN12_VE1_AUX_NV,
> + };
> +
> + if (engine->class == VIDEO_DECODE_CLASS)
> + return vd[engine->instance];
> +
> + if (engine->class == VIDEO_ENHANCEMENT_CLASS)
> + return ve[engine->instance];
> +
GEM_BUG_ON("unknown aux_inv_reg");
> + return INVALID_MMIO_REG;
> +}
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gen12: Add aux table invalidate for all engines
All engines, exception being blitter as it does not
care about the form, can access compressed surfaces.
So we need to add forced aux table invalidates
for those engines.
v2: virtual instance masking (Chris)
References: d248b371f747 ("drm/i915/gen12: Invalidate aux table entries
forcibly")
References bspec#43904, hsdes#1809175790
Cc: Chris Wilson
Cc: Chuansheng Liu
Cc: Rafael Antognolli
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 84 +++--
drivers/gpu/drm/i915/i915_reg.h | 6 +++
2 files changed, 85 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index bbdb0e2a4571..2fffedc99806 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4539,11 +4539,34 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
+static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
+{
+ static const i915_reg_t vd[] = {
+ GEN12_VD0_AUX_NV,
+ GEN12_VD1_AUX_NV,
+ GEN12_VD2_AUX_NV,
+ GEN12_VD3_AUX_NV,
+ };
+
+ static const i915_reg_t ve[] = {
+ GEN12_VE0_AUX_NV,
+ GEN12_VE1_AUX_NV,
+ };
+
+ if (engine->class == VIDEO_DECODE_CLASS)
+ return vd[engine->instance];
+
+ if (engine->class == VIDEO_ENHANCEMENT_CLASS)
+ return ve[engine->instance];
+
+ return INVALID_MMIO_REG;
+}
+
static u32 *
-gen12_emit_aux_table_inv(struct i915_request *rq, u32 *cs)
+gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
{
*cs++ = MI_LOAD_REGISTER_IMM(1);
- *cs++ = i915_mmio_reg_offset(GEN12_GFX_CCS_AUX_NV);
+ *cs++ = i915_mmio_reg_offset(inv_reg);
*cs++ = AUX_INV;
*cs++ = MI_NOOP;
@@ -4612,7 +4635,7 @@ static int gen12_emit_flush_render(struct i915_request
*request,
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
/* hsdes: 1809175790 */
- cs = gen12_emit_aux_table_inv(request, cs);
+ cs = gen12_emit_aux_table_inv(GEN12_GFX_CCS_AUX_NV, cs);
*cs++ = preparser_disable(false);
intel_ring_advance(request, cs);
@@ -4621,6 +4644,56 @@ static int gen12_emit_flush_render(struct i915_request
*request,
return 0;
}
+static int gen12_emit_flush(struct i915_request *request, u32 mode)
+{
+ intel_engine_mask_t aux_inv = 0;
+ u32 cmd, *cs;
+
+ if (mode & EMIT_INVALIDATE)
+ aux_inv = request->engine->mask & ~BIT(BCS0);
+
+ cs = intel_ring_begin(request,
+ 4 + (aux_inv ? 2 * hweight8(aux_inv) + 2 : 0));
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ cmd = MI_FLUSH_DW + 1;
+
+ /* We always require a command barrier so that subsequent
+* commands, such as breadcrumb interrupts, are strictly ordered
+* wrt the contents of the write cache being flushed to memory
+* (and thus being coherent from the CPU).
+*/
+ cmd |= MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW;
+
+ if (mode & EMIT_INVALIDATE) {
+ cmd |= MI_INVALIDATE_TLB;
+ if (request->engine->class == VIDEO_DECODE_CLASS)
+ cmd |= MI_INVALIDATE_BSD;
+ }
+
+ *cs++ = cmd;
+ *cs++ = LRC_PPHWSP_SCRATCH_ADDR;
+ *cs++ = 0; /* upper addr */
+ *cs++ = 0; /* value */
+
+ if (aux_inv) { /* hsdes: 1809175790 */
+ struct intel_engine_cs *engine;
+ unsigned int tmp;
+
+ *cs++ = MI_LOAD_REGISTER_IMM(hweight8(aux_inv));
+ for_each_engine_masked(engine, request->engine->gt,
+ aux_inv, tmp) {
+ *cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
+ *cs++ = AUX_INV;
+ }
+ *cs++ = MI_NOOP;
+ }
+ intel_ring_advance(request, cs);
+
+ return 0;
+}
+
/*
* Reserve space for 2 NOOPs at the end of each request to be
* used as a workaround for not being allowed to do lite
@@ -4854,9 +4927,10 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
engine->emit_flush = gen8_emit_flush;
engine->emit_init_breadcrumb = gen8_emit_init_breadcrumb;
engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb;
- if (INTEL_GEN(engine->i915) >= 12)
+ if (INTEL_GEN(engine->i915) >= 12) {
engine->emit_fini_breadcrumb = gen12_emit_fini_breadcrumb;
-
+ engine->emit_flush = gen12_emit_flush;
+ }
engine->set_default_submission = intel_execlists_set_default_submission;
if (INTEL_GEN(engine->i915) < 11) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dc5952200a07..6c076a24eb82 100644
[Intel-gfx] [PATCH v11 13/14] drm/i915/dp: Add compute routine for DP PSR VSC SDP
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it adds a compute routine for PSR VSC SDP.
As PSR routine can not use infoframes.vsc of crtc state, it also adds new
writing of DP SDPs (Secondary Data Packet) for PSR.
PSR routine has its own scenario and timings of writing a VSC SDP.
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
v10: 1) Fix packing of VSC SDP where Pixel Encoding/Colorimetry Format is
not supported.
2) Change a checking of PSR state.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 66 -
drivers/gpu/drm/i915/display/intel_dp.h | 8 +++
2 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3325a60bd297..67edbe06bd6e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2487,8 +2487,8 @@ static void intel_dp_compute_vsc_sdp(struct intel_dp
*intel_dp,
{
struct drm_dp_vsc_sdp *vsc = _state->infoframes.vsc;
- /* When PSR is enabled, VSC SDP is handled by PSR routine */
- if (intel_psr_enabled(intel_dp))
+ /* When a crtc state has PSR, VSC SDP will be handled by PSR routine */
+ if (crtc_state->has_psr)
return;
if (!intel_dp_needs_vsc_sdp(crtc_state, conn_state))
@@ -2500,6 +2500,42 @@ static void intel_dp_compute_vsc_sdp(struct intel_dp
*intel_dp,
_state->infoframes.vsc);
}
+void intel_dp_compute_psr_vsc_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state,
+ struct drm_dp_vsc_sdp *vsc)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+ vsc->sdp_type = DP_SDP_VSC;
+
+ if (dev_priv->psr.psr2_enabled) {
+ if (dev_priv->psr.colorimetry_support &&
+ intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
+ /* [PSR2, +Colorimetry] */
+ intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
+vsc);
+ } else {
+ /*
+* [PSR2, -Colorimetry]
+* Prepare VSC Header for SU as per eDP 1.4 spec, Table
6-11
+* 3D stereo + PSR/PSR2 + Y-coordinate.
+*/
+ vsc->revision = 0x4;
+ vsc->length = 0xe;
+ }
+ } else {
+ /*
+* [PSR1]
+* Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
+* VSC SDP supporting 3D stereo + PSR (applies to eDP v1.3 or
+* higher).
+*/
+ vsc->revision = 0x2;
+ vsc->length = 0x8;
+ }
+}
+
static void
intel_dp_compute_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state,
@@ -4791,6 +4827,13 @@ static ssize_t intel_dp_vsc_sdp_pack(const struct
drm_dp_vsc_sdp *vsc,
sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
+ /*
+* Only revision 0x5 supports Pixel Encoding/Colorimetry Format as
+* per DP 1.4a spec.
+*/
+ if (vsc->revision != 0x5)
+ goto out;
+
/* VSC SDP Payload for DB16 through DB18 */
/* Pixel Encoding and Colorimetry Formats */
sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
@@ -4823,6 +4866,7 @@ static ssize_t intel_dp_vsc_sdp_pack(const struct
drm_dp_vsc_sdp *vsc,
/* Content Type */
sdp->db[18] = vsc->content_type & 0x7;
+out:
return length;
}
@@ -4935,6 +4979,24 @@ static void intel_write_dp_sdp(struct intel_encoder
*encoder,
intel_dig_port->write_infoframe(encoder, crtc_state, type, , len);
}
+void intel_write_dp_vsc_sdp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ struct drm_dp_vsc_sdp *vsc)
+{
+ struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct dp_sdp sdp = {};
+ ssize_t len;
+
+ len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
+
+ if (drm_WARN_ON(_priv->drm, len < 0))
+ return;
+
+ intel_dig_port->write_infoframe(encoder, crtc_state, DP_SDP_VSC,
+ , len);
+}
+
void intel_dp_set_infoframes(struct intel_encoder *encoder,
[Intel-gfx] [PATCH v11 01/14] video/hdmi: Add Unpack only function for DRM infoframe
It adds an unpack only function for DRM infoframe for dynamic range and
mastering infoframe readout.
It unpacks the information data block contained in the binary buffer into
a structured frame of the HDMI Dynamic Range and Mastering (DRM)
information frame.
In contrast to hdmi_drm_infoframe_unpack() function, it does not verify
a checksum.
It can be used for unpacking a DP HDR Metadata Infoframe SDP case.
DP HDR Metadata Infoframe SDP uses the same Dynamic Range and Mastering
(DRM) information (CTA-861-G spec.) such as HDMI DRM infoframe.
But DP SDP header and payload structure are different from HDMI DRM
Infoframe. Therefore unpacking DRM infoframe for DP requires skipping of
a verifying checksum.
v9: Add clear comments to hdmi_drm_infoframe_unpack_only() and
hdmi_drm_infoframe_unpack() (Laurent Pinchart)
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
Cc: Laurent Pinchart
Cc: Ville Syrjala
---
drivers/video/hdmi.c | 65 +++-
include/linux/hdmi.h | 2 ++
2 files changed, 48 insertions(+), 19 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 856a8c4e84a2..e70792b3e367 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1768,20 +1768,21 @@ hdmi_vendor_any_infoframe_unpack(union
hdmi_vendor_any_infoframe *frame,
}
/**
- * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM infoframe
+ * hdmi_drm_infoframe_unpack_only() - unpack binary buffer of CTA-861-G DRM
+ *infoframe DataBytes to a HDMI DRM
+ *infoframe
* @frame: HDMI DRM infoframe
* @buffer: source buffer
* @size: size of buffer
*
- * Unpacks the information contained in binary @buffer into a structured
- * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
- * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
- * specification.
+ * Unpacks CTA-861-G DRM infoframe DataBytes contained in the binary @buffer
+ * into a structured @frame of the HDMI Dynamic Range and Mastering (DRM)
+ * infoframe.
*
* Returns 0 on success or a negative error code on failure.
*/
-static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
-const void *buffer, size_t size)
+int hdmi_drm_infoframe_unpack_only(struct hdmi_drm_infoframe *frame,
+ const void *buffer, size_t size)
{
const u8 *ptr = buffer;
const u8 *temp;
@@ -1790,23 +1791,13 @@ static int hdmi_drm_infoframe_unpack(struct
hdmi_drm_infoframe *frame,
int ret;
int i;
- if (size < HDMI_INFOFRAME_SIZE(DRM))
- return -EINVAL;
-
- if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
- ptr[1] != 1 ||
- ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
- return -EINVAL;
-
- if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
+ if (size < HDMI_DRM_INFOFRAME_SIZE)
return -EINVAL;
ret = hdmi_drm_infoframe_init(frame);
if (ret)
return ret;
- ptr += HDMI_INFOFRAME_HEADER_SIZE;
-
frame->eotf = ptr[0] & 0x7;
frame->metadata_type = ptr[1] & 0x7;
@@ -1814,7 +1805,7 @@ static int hdmi_drm_infoframe_unpack(struct
hdmi_drm_infoframe *frame,
for (i = 0; i < 3; i++) {
x_lsb = *temp++;
x_msb = *temp++;
- frame->display_primaries[i].x = (x_msb << 8) | x_lsb;
+ frame->display_primaries[i].x = (x_msb << 8) | x_lsb;
y_lsb = *temp++;
y_msb = *temp++;
frame->display_primaries[i].y = (y_msb << 8) | y_lsb;
@@ -1830,6 +1821,42 @@ static int hdmi_drm_infoframe_unpack(struct
hdmi_drm_infoframe *frame,
return 0;
}
+EXPORT_SYMBOL(hdmi_drm_infoframe_unpack_only);
+
+/**
+ * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM infoframe
+ * @frame: HDMI DRM infoframe
+ * @buffer: source buffer
+ * @size: size of buffer
+ *
+ * Unpacks the CTA-861-G DRM infoframe contained in the binary @buffer into
+ * a structured @frame of the HDMI Dynamic Range and Mastering (DRM)
+ * infoframe. It also verifies the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
+const void *buffer, size_t size)
+{
+ const u8 *ptr = buffer;
+ int ret;
+
+ if (size < HDMI_INFOFRAME_SIZE(DRM))
+ return -EINVAL;
+
+ if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
+ ptr[1] != 1 ||
+ ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
+ return -EINVAL;
+
+ if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
+ return -EINVAL;
+
+ ret =
[Intel-gfx] [PATCH v11 11/14] drm/i915: Program DP SDPs on pipe updates
Call intel_dp_set_infoframes() function on pipe updates to make sure that we send VSC SDP and HDR Metadata Infoframe SDP (when applicable) on fastsets. Signed-off-by: Gwan-gyeong Mun Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_ddi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index dc232cef867f..e0862b899f1b 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3864,6 +3864,7 @@ static void intel_ddi_update_pipe_dp(struct intel_atomic_state *state, intel_ddi_set_dp_msa(crtc_state, conn_state); intel_psr_update(intel_dp, crtc_state); + intel_dp_set_infoframes(encoder, true, crtc_state, conn_state); intel_edp_drrs_enable(intel_dp, crtc_state); intel_panel_update_backlight(state, encoder, crtc_state, conn_state); -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11 02/14] drm/i915/dp: Read out DP SDPs
It adds code to read the DP SDPs from the video DIP and unpack them into
the crtc state.
It adds routines that read out DP VSC SDP and DP HDR Metadata Infoframe SDP
In order to unpack DP VSC SDP, it adds intel_dp_vsc_sdp_unpack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and
[Table 2-117: VSC SDP Payload for DB16 through DB18]
In order to unpack DP HDR Metadata Infoframe SDP, it adds
intel_dp_hdr_metadata_infoframe_sdp_unpack(). And it follows DP 1.4a spec.
([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and
[Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31])
and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame].
A naming rule and style of intel_read_dp_sdp() function references
intel_read_infoframe() function of intel_hdmi.c
v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
v5: Addressed review comments from Uma
- Polish commit message and comments
- Combine the if checks of sdp.HB2 and sdp.HB3
- Add 6bpc to unpacking of VSC SDP
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 187
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
2 files changed, 190 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6952b0295096..691f96519d07 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4971,6 +4971,193 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
intel_write_dp_sdp(encoder, crtc_state,
HDMI_PACKET_TYPE_GAMUT_METADATA);
}
+static int intel_dp_vsc_sdp_unpack(struct drm_dp_vsc_sdp *vsc,
+ const void *buffer, size_t size)
+{
+ const struct dp_sdp *sdp = buffer;
+
+ if (size < sizeof(struct dp_sdp))
+ return -EINVAL;
+
+ memset(vsc, 0, size);
+
+ if (sdp->sdp_header.HB0 != 0)
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB1 != DP_SDP_VSC)
+ return -EINVAL;
+
+ vsc->sdp_type = sdp->sdp_header.HB1;
+ vsc->revision = sdp->sdp_header.HB2;
+ vsc->length = sdp->sdp_header.HB3;
+
+ if ((sdp->sdp_header.HB2 == 0x2 && sdp->sdp_header.HB3 == 0x8) ||
+ (sdp->sdp_header.HB2 == 0x4 && sdp->sdp_header.HB3 == 0xe)) {
+ /*
+* - HB2 = 0x2, HB3 = 0x8
+* VSC SDP supporting 3D stereo + PSR
+* - HB2 = 0x4, HB3 = 0xe
+* VSC SDP supporting 3D stereo + PSR2 with Y-coordinate of
+* first scan line of the SU region (applies to eDP v1.4b
+* and higher).
+*/
+ return 0;
+ } else if (sdp->sdp_header.HB2 == 0x5 && sdp->sdp_header.HB3 == 0x13) {
+ /*
+* - HB2 = 0x5, HB3 = 0x13
+* VSC SDP supporting 3D stereo + PSR2 + Pixel
Encoding/Colorimetry
+* Format.
+*/
+ vsc->pixelformat = (sdp->db[16] >> 4) & 0xf;
+ vsc->colorimetry = sdp->db[16] & 0xf;
+ vsc->dynamic_range = (sdp->db[17] >> 7) & 0x1;
+
+ switch (sdp->db[17] & 0x7) {
+ case 0x0:
+ vsc->bpc = 6;
+ break;
+ case 0x1:
+ vsc->bpc = 8;
+ break;
+ case 0x2:
+ vsc->bpc = 10;
+ break;
+ case 0x3:
+ vsc->bpc = 12;
+ break;
+ case 0x4:
+ vsc->bpc = 16;
+ break;
+ default:
+ MISSING_CASE(sdp->db[17] & 0x7);
+ return -EINVAL;
+ }
+
+ vsc->content_type = sdp->db[18] & 0x7;
+ } else {
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int
+intel_dp_hdr_metadata_infoframe_sdp_unpack(struct hdmi_drm_infoframe
*drm_infoframe,
+ const void *buffer, size_t size)
+{
+ int ret;
+
+ const struct dp_sdp *sdp = buffer;
+
+ if (size < sizeof(struct dp_sdp))
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB0 != 0)
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB1 != HDMI_INFOFRAME_TYPE_DRM)
+ return -EINVAL;
+
+ /*
+* Least Significant Eight Bits of (Data Byte Count – 1)
+* 1Dh (i.e., Data Byte Count = 30 bytes).
+*/
+ if (sdp->sdp_header.HB2 != 0x1D)
+ return -EINVAL;
+
+ /* Most Significant Two Bits of (Data Byte Count – 1), Clear to 00b. */
+ if ((sdp->sdp_header.HB3 & 0x3) != 0)
+ return -EINVAL;
+
+ /* INFOFRAME SDP Version Number
[Intel-gfx] [PATCH v11 09/14] drm/i915: Add state readout for DP VSC SDP
Added state readout for DP VSC SDP and enabled state validation
for DP VSC SDP.
v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
v10: Skip checking of VSC SDP when a crtc config has psr.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 44
2 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 109c60710310..dc232cef867f 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4307,6 +4307,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
bdw_get_trans_port_sync_config(pipe_config);
intel_read_dp_sdp(encoder, pipe_config,
HDMI_PACKET_TYPE_GAMUT_METADATA);
+ intel_read_dp_sdp(encoder, pipe_config, DP_SDP_VSC);
}
static enum intel_output_type
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index d1c722dde77a..a7a1729a99bb 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13489,6 +13489,13 @@ intel_compare_infoframe(const union hdmi_infoframe *a,
return memcmp(a, b, sizeof(*a)) == 0;
}
+static bool
+intel_compare_dp_vsc_sdp(const struct drm_dp_vsc_sdp *a,
+const struct drm_dp_vsc_sdp *b)
+{
+ return memcmp(a, b, sizeof(*a)) == 0;
+}
+
static void
pipe_config_infoframe_mismatch(struct drm_i915_private *dev_priv,
bool fastset, const char *name,
@@ -13514,6 +13521,31 @@ pipe_config_infoframe_mismatch(struct drm_i915_private
*dev_priv,
}
}
+static void
+pipe_config_dp_vsc_sdp_mismatch(struct drm_i915_private *dev_priv,
+ bool fastset, const char *name,
+ const struct drm_dp_vsc_sdp *a,
+ const struct drm_dp_vsc_sdp *b)
+{
+ if (fastset) {
+ if (!drm_debug_enabled(DRM_UT_KMS))
+ return;
+
+ drm_dbg_kms(_priv->drm,
+ "fastset mismatch in %s dp sdp\n", name);
+ drm_dbg_kms(_priv->drm, "expected:\n");
+ drm_dp_vsc_sdp_log(KERN_DEBUG, dev_priv->drm.dev, a);
+ drm_dbg_kms(_priv->drm, "found:\n");
+ drm_dp_vsc_sdp_log(KERN_DEBUG, dev_priv->drm.dev, b);
+ } else {
+ drm_err(_priv->drm, "mismatch in %s dp sdp\n", name);
+ drm_err(_priv->drm, "expected:\n");
+ drm_dp_vsc_sdp_log(KERN_ERR, dev_priv->drm.dev, a);
+ drm_err(_priv->drm, "found:\n");
+ drm_dp_vsc_sdp_log(KERN_ERR, dev_priv->drm.dev, b);
+ }
+}
+
static void __printf(4, 5)
pipe_config_mismatch(bool fastset, const struct intel_crtc *crtc,
const char *name, const char *format, ...)
@@ -13715,6 +13747,17 @@ intel_pipe_config_compare(const struct
intel_crtc_state *current_config,
} \
} while (0)
+#define PIPE_CONF_CHECK_DP_VSC_SDP(name) do { \
+ if (!current_config->has_psr && !pipe_config->has_psr && \
+ !intel_compare_dp_vsc_sdp(_config->infoframes.name, \
+ _config->infoframes.name)) { \
+ pipe_config_dp_vsc_sdp_mismatch(dev_priv, fastset,
__stringify(name), \
+
_config->infoframes.name, \
+ _config->infoframes.name);
\
+ ret = false; \
+ } \
+} while (0)
+
#define PIPE_CONF_CHECK_COLOR_LUT(name1, name2, bit_precision) do { \
if (current_config->name1 != pipe_config->name1) { \
pipe_config_mismatch(fastset, crtc, __stringify(name1), \
@@ -13892,6 +13935,7 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_INFOFRAME(spd);
PIPE_CONF_CHECK_INFOFRAME(hdmi);
PIPE_CONF_CHECK_INFOFRAME(drm);
+ PIPE_CONF_CHECK_DP_VSC_SDP(vsc);
PIPE_CONF_CHECK_X(sync_mode_slaves_mask);
PIPE_CONF_CHECK_I(master_transcoder);
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11 14/14] drm/i915/psr: Use new DP VSC SDP compute routine on PSR
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it uses a new psr vsc sdp compute routine.
Because PSR routine has its own scenario and timings of writing a VSC SDP,
the current PSR routine needs to have its own drm_dp_vsc_sdp structure
member variable on struct i915_psr.
In order to calculate colorimetry information, intel_psr_update()
function and intel_psr_enable() function extend a drm_connector_state
argument.
There are no changes to PSR mechanism.
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Rebased
v8: Rebased
v10: When a PSR is enabled, it needs to add DP_SDP_VSC to
infoframes.enable.
It is needed for comparing between HW and pipe_state of VSC_SDP.
V11: If PSR is disabled by flag, it don't enable psr on pipe compute.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
drivers/gpu/drm/i915/display/intel_psr.c | 58
drivers/gpu/drm/i915/display/intel_psr.h | 6 ++-
drivers/gpu/drm/i915/i915_drv.h | 1 +
4 files changed, 26 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index d88431ebb34e..b4d20b33b9fd 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3682,7 +3682,7 @@ static void intel_enable_ddi_dp(struct intel_atomic_state
*state,
intel_dp_stop_link_train(intel_dp);
intel_edp_backlight_on(crtc_state, conn_state);
- intel_psr_enable(intel_dp, crtc_state);
+ intel_psr_enable(intel_dp, crtc_state, conn_state);
intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
@@ -3865,7 +3865,7 @@ static void intel_ddi_update_pipe_dp(struct
intel_atomic_state *state,
intel_ddi_set_dp_msa(crtc_state, conn_state);
- intel_psr_update(intel_dp, crtc_state);
+ intel_psr_update(intel_dp, crtc_state, conn_state);
intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index a0569fdfeb16..dcb2dcde0078 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -30,6 +30,7 @@
#include "intel_display_types.h"
#include "intel_psr.h"
#include "intel_sprite.h"
+#include "intel_hdmi.h"
/**
* DOC: Panel Self Refresh (PSR/SRD)
@@ -357,39 +358,6 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
}
}
-static void intel_psr_setup_vsc(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state)
-{
- struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- struct dp_sdp psr_vsc;
-
- if (dev_priv->psr.psr2_enabled) {
- /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
- memset(_vsc, 0, sizeof(psr_vsc));
- psr_vsc.sdp_header.HB0 = 0;
- psr_vsc.sdp_header.HB1 = 0x7;
- if (dev_priv->psr.colorimetry_support) {
- psr_vsc.sdp_header.HB2 = 0x5;
- psr_vsc.sdp_header.HB3 = 0x13;
- } else {
- psr_vsc.sdp_header.HB2 = 0x4;
- psr_vsc.sdp_header.HB3 = 0xe;
- }
- } else {
- /* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
- memset(_vsc, 0, sizeof(psr_vsc));
- psr_vsc.sdp_header.HB0 = 0;
- psr_vsc.sdp_header.HB1 = 0x7;
- psr_vsc.sdp_header.HB2 = 0x2;
- psr_vsc.sdp_header.HB3 = 0x8;
- }
-
- intel_dig_port->write_infoframe(_dig_port->base,
- crtc_state,
- DP_SDP_VSC, _vsc, sizeof(psr_vsc));
-}
-
static void hsw_psr_setup_aux(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -756,6 +724,8 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
if (intel_dp != dev_priv->psr.dp)
return;
+if (!psr_global_enabled(dev_priv))
+ return;
/*
* HSW spec explicitly says PSR is tied to port A.
* BDW+ platforms have a instance of PSR registers per transcoder but
@@ -798,6 +768,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
crtc_state->has_psr = true;
crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
+ crtc_state->infoframes.enable |=
intel_hdmi_infoframe_enable(DP_SDP_VSC);
}
static void intel_psr_activate(struct intel_dp *intel_dp)
@@ -880,9 +851,12 @@ static void intel_psr_enable_source(struct
[Intel-gfx] [PATCH v11 00/14] In order to readout DP SDPs, refactors the handling of DP SDPs
In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes. It adds new compute routines for DP HDR Metadata Infoframe SDP and DP VSC SDP. And new writing routines of DP SDPs (Secondary Data Packet) that uses computed configs. New reading routines of DP SDPs are added for readout. It adds a logging function for DP VSC SDP. When receiving video it is very useful to be able to log DP VSC SDP. This greatly simplifies debugging. In order to use a common VSC SDP Colorimetry calculating code on PSR, it uses a new psr vsc sdp compute routine. v2: Minor style fix v3: - Add a new drm data structure for DP VSC SDP - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp - Move logging functions to drm core [Jani N] And use drm core's DP VSC SDP logging function - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. v4: - Use struct drm_device logging macros - Rebased v5: - Use intel_de_*() functions for register access - Add warning where a bpc is 6 and a pixel format is RGB. - Addressed review comments from Uma Add kernel docs for added data structures Rename enum dp_colorspace to dp_pixelformat Polish commit message and comments Combine the if checks of sdp.HB2 and sdp.HB3 Add 6bpc to packining and unpacking of VSC SDP v6: Fix enabled infoframe states of lspcon v7: Fix the wrong check of combination bpc 6 and RGB pixelformat v8: Rebased v9: Add clear comments to hdmi_drm_infoframe_unpack_only() and hdmi_drm_infoframe_unpack() (Laurent Pinchart) v10: - Fix packing of VSC SDP where Pixel Encoding/Colorimetry Format is not supported - When a PSR is enabled, it needs to add DP_SDP_VSC to infoframes.enable. - Change a checking of PSR state. - Skip checking of VSC SDP when a crtc config has psr. - Rebased V11: If PSR is disabled by flag, it don't enable psr on pipe compute Gwan-gyeong Mun (14): video/hdmi: Add Unpack only function for DRM infoframe drm/i915/dp: Read out DP SDPs drm: Add logging function for DP VSC SDP drm/i915: Include HDMI DRM infoframe in the crtc state dump drm/i915: Include DP HDR Metadata Infoframe SDP in the crtc state dump drm/i915: Include DP VSC SDP in the crtc state dump drm/i915: Program DP SDPs with computed configs drm/i915: Add state readout for DP HDR Metadata Infoframe SDP drm/i915: Add state readout for DP VSC SDP drm/i915: Fix enabled infoframe states of lspcon drm/i915: Program DP SDPs on pipe updates drm/i915: Stop sending DP SDPs on ddi disable drm/i915/dp: Add compute routine for DP PSR VSC SDP drm/i915/psr: Use new DP VSC SDP compute routine on PSR drivers/gpu/drm/drm_dp_helper.c | 174 drivers/gpu/drm/i915/display/intel_ddi.c | 19 +- drivers/gpu/drm/i915/display/intel_display.c | 63 +++ drivers/gpu/drm/i915/display/intel_dp.c | 406 ++- drivers/gpu/drm/i915/display/intel_dp.h | 15 +- drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 58 +-- drivers/gpu/drm/i915/display/intel_psr.h | 6 +- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/video/hdmi.c | 65 ++- include/drm/drm_dp_helper.h | 3 + include/linux/hdmi.h | 2 + 12 files changed, 551 insertions(+), 263 deletions(-) -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11 04/14] drm/i915: Include HDMI DRM infoframe in the crtc state dump
Dump out the HDMI Dynamic Range and Mastering (DRM) infoframe in the normal crtc state dump. Signed-off-by: Gwan-gyeong Mun Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index fd6d63b03489..93f8ae9471e7 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -13023,6 +13023,9 @@ static void intel_dump_pipe_config(const struct intel_crtc_state *pipe_config, if (pipe_config->infoframes.enable & intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_VENDOR)) intel_dump_infoframe(dev_priv, _config->infoframes.hdmi); + if (pipe_config->infoframes.enable & + intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM)) + intel_dump_infoframe(dev_priv, _config->infoframes.drm); drm_dbg_kms(_priv->drm, "requested mode:\n"); drm_mode_debug_printmodeline(_config->hw.mode); -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11 03/14] drm: Add logging function for DP VSC SDP
When receiving video it is very useful to be able to log DP VSC SDP.
This greatly simplifies debugging.
v2: Minor style fix
v3: Move logging functions to drm core [Jani N]
v5: Rebased
v10: Rebased
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 174
include/drm/drm_dp_helper.h | 3 +
2 files changed, 177 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 612a59ec8116..43e57632b00a 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1629,3 +1629,177 @@ int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
return 0;
}
EXPORT_SYMBOL(drm_dp_set_phy_test_pattern);
+
+static const char *dp_pixelformat_get_name(enum dp_pixelformat pixelformat)
+{
+ if (pixelformat < 0 || pixelformat > DP_PIXELFORMAT_RESERVED)
+ return "Invalid";
+
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "RGB";
+ case DP_PIXELFORMAT_YUV444:
+ return "YUV444";
+ case DP_PIXELFORMAT_YUV422:
+ return "YUV422";
+ case DP_PIXELFORMAT_YUV420:
+ return "YUV420";
+ case DP_PIXELFORMAT_Y_ONLY:
+ return "Y_ONLY";
+ case DP_PIXELFORMAT_RAW:
+ return "RAW";
+ default:
+ return "Reserved";
+ }
+}
+
+static const char *dp_colorimetry_get_name(enum dp_pixelformat pixelformat,
+ enum dp_colorimetry colorimetry)
+{
+ if (pixelformat < 0 || pixelformat > DP_PIXELFORMAT_RESERVED)
+ return "Invalid";
+
+ switch (colorimetry) {
+ case DP_COLORIMETRY_DEFAULT:
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "sRGB";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ return "BT.601";
+ case DP_PIXELFORMAT_Y_ONLY:
+ return "DICOM PS3.14";
+ case DP_PIXELFORMAT_RAW:
+ return "Custom Color Profile";
+ default:
+ return "Reserved";
+ }
+ case DP_COLORIMETRY_RGB_WIDE_FIXED: /* and DP_COLORIMETRY_BT709_YCC */
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "Wide Fixed";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ return "BT.709";
+ default:
+ return "Reserved";
+ }
+ case DP_COLORIMETRY_RGB_WIDE_FLOAT: /* and DP_COLORIMETRY_XVYCC_601 */
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "Wide Float";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ return "xvYCC 601";
+ default:
+ return "Reserved";
+ }
+ case DP_COLORIMETRY_OPRGB: /* and DP_COLORIMETRY_XVYCC_709 */
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "OpRGB";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ return "xvYCC 709";
+ default:
+ return "Reserved";
+ }
+ case DP_COLORIMETRY_DCI_P3_RGB: /* and DP_COLORIMETRY_SYCC_601 */
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "DCI-P3";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ return "sYCC 601";
+ default:
+ return "Reserved";
+ }
+ case DP_COLORIMETRY_RGB_CUSTOM: /* and DP_COLORIMETRY_OPYCC_601 */
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "Custom Profile";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ return "OpYCC 601";
+ default:
+ return "Reserved";
+ }
+ case DP_COLORIMETRY_BT2020_RGB: /* and DP_COLORIMETRY_BT2020_CYCC */
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "BT.2020 RGB";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+
[Intel-gfx] [PATCH v11 06/14] drm/i915: Include DP VSC SDP in the crtc state dump
Dump out the DP VSC SDP in the normal crtc state dump
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
Use drm core's DP VSC SDP logging function
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 172574a60ddd..d1c722dde77a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12866,6 +12866,16 @@ intel_dump_infoframe(struct drm_i915_private *dev_priv,
hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, frame);
}
+static void
+intel_dump_dp_vsc_sdp(struct drm_i915_private *dev_priv,
+ const struct drm_dp_vsc_sdp *vsc)
+{
+ if (!drm_debug_enabled(DRM_UT_KMS))
+ return;
+
+ drm_dp_vsc_sdp_log(KERN_DEBUG, dev_priv->drm.dev, vsc);
+}
+
#define OUTPUT_TYPE(x) [INTEL_OUTPUT_ ## x] = #x
static const char * const output_type_str[] = {
@@ -13029,6 +13039,9 @@ static void intel_dump_pipe_config(const struct
intel_crtc_state *pipe_config,
if (pipe_config->infoframes.enable &
intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA))
intel_dump_infoframe(dev_priv, _config->infoframes.drm);
+ if (pipe_config->infoframes.enable &
+ intel_hdmi_infoframe_enable(DP_SDP_VSC))
+ intel_dump_dp_vsc_sdp(dev_priv, _config->infoframes.vsc);
drm_dbg_kms(_priv->drm, "requested mode:\n");
drm_mode_debug_printmodeline(_config->hw.mode);
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11 08/14] drm/i915: Add state readout for DP HDR Metadata Infoframe SDP
Added state readout for DP HDR Metadata Infoframe SDP. v9: Rebased v10: Rebased Signed-off-by: Gwan-gyeong Mun Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_ddi.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 4cfb749dea0c..109c60710310 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -4234,6 +4234,9 @@ void intel_ddi_get_config(struct intel_encoder *encoder, pipe_config->fec_enable); } + pipe_config->infoframes.enable |= + intel_hdmi_infoframes_enabled(encoder, pipe_config); + break; case TRANS_DDI_MODE_SELECT_DP_MST: pipe_config->output_types |= BIT(INTEL_OUTPUT_DP_MST); @@ -4245,6 +4248,9 @@ void intel_ddi_get_config(struct intel_encoder *encoder, REG_FIELD_GET(TRANS_DDI_MST_TRANSPORT_SELECT_MASK, temp); intel_dp_get_m_n(intel_crtc, pipe_config); + + pipe_config->infoframes.enable |= + intel_hdmi_infoframes_enabled(encoder, pipe_config); break; default: break; @@ -4299,6 +4305,8 @@ void intel_ddi_get_config(struct intel_encoder *encoder, if (INTEL_GEN(dev_priv) >= 8) bdw_get_trans_port_sync_config(pipe_config); + + intel_read_dp_sdp(encoder, pipe_config, HDMI_PACKET_TYPE_GAMUT_METADATA); } static enum intel_output_type -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11 10/14] drm/i915: Fix enabled infoframe states of lspcon
Compared to implementation of DP and HDMI's encoder->infoframes_enabled,
the lspcon's implementation returns its active state. (we expect enabled
infoframe states of HW.) It leads to pipe state mismatch error
when ddi_get_config is called.
Because the current implementation of lspcon is not ready to support
readout infoframes, we need to return 0 here.
In order to support readout to lspcon, we need to implement read_infoframe
and infoframes_enabled. And set_infoframes also have to set an appropriate
bit on crtc_state->infoframes.enable
Cc: Ville Syrjälä
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index d807c5648c87..6ff7b226f0a1 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -522,7 +522,7 @@ u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config)
{
/* FIXME actually read this from the hw */
- return enc_to_intel_lspcon(encoder)->active;
+ return 0;
}
void lspcon_resume(struct intel_lspcon *lspcon)
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11 07/14] drm/i915: Program DP SDPs with computed configs
In order to use computed config for DP SDPs (DP VSC SDP and DP HDR Metadata
Infoframe SDP), it replaces intel_dp_vsc_enable() function and
intel_dp_hdr_metadata_enable() function to intel_dp_set_infoframes()
function.
And it removes unused functions.
Before:
intel_dp_vsc_enable() and intel_dp_hdr_metadata_enable() compute sdp
configs and program sdp registers on enable callback of encoder.
After:
It separates computing of sdp configs and programming of sdp register.
The compute config callback of encoder calls computing sdp configs.
The enable callback of encoder calls programming sdp register.
v3: Rebased
v5: Polish commit message [Uma]
v10: Rebased
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
drivers/gpu/drm/i915/display/intel_dp.c | 229 ---
drivers/gpu/drm/i915/display/intel_dp.h | 6 -
3 files changed, 1 insertion(+), 237 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5601673c3f30..4cfb749dea0c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3681,8 +3681,7 @@ static void intel_enable_ddi_dp(struct intel_atomic_state
*state,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
- intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
- intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
+ intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 691f96519d07..3325a60bd297 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5158,235 +5158,6 @@ void intel_read_dp_sdp(struct intel_encoder *encoder,
}
}
-static void
-intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
-{
- struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- struct dp_sdp vsc_sdp = {};
-
- /* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119 */
- vsc_sdp.sdp_header.HB0 = 0;
- vsc_sdp.sdp_header.HB1 = 0x7;
-
- /*
-* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
-* Colorimetry Format indication.
-*/
- vsc_sdp.sdp_header.HB2 = 0x5;
-
- /*
-* VSC SDP supporting 3D stereo, + PSR2, + Pixel Encoding/
-* Colorimetry Format indication (HB2 = 05h).
-*/
- vsc_sdp.sdp_header.HB3 = 0x13;
-
- /* DP 1.4a spec, Table 2-120 */
- switch (crtc_state->output_format) {
- case INTEL_OUTPUT_FORMAT_YCBCR444:
- vsc_sdp.db[16] = 0x1 << 4; /* YCbCr 444 : DB16[7:4] = 1h */
- break;
- case INTEL_OUTPUT_FORMAT_YCBCR420:
- vsc_sdp.db[16] = 0x3 << 4; /* YCbCr 420 : DB16[7:4] = 3h */
- break;
- case INTEL_OUTPUT_FORMAT_RGB:
- default:
- /* RGB: DB16[7:4] = 0h */
- break;
- }
-
- switch (conn_state->colorspace) {
- case DRM_MODE_COLORIMETRY_BT709_YCC:
- vsc_sdp.db[16] |= 0x1;
- break;
- case DRM_MODE_COLORIMETRY_XVYCC_601:
- vsc_sdp.db[16] |= 0x2;
- break;
- case DRM_MODE_COLORIMETRY_XVYCC_709:
- vsc_sdp.db[16] |= 0x3;
- break;
- case DRM_MODE_COLORIMETRY_SYCC_601:
- vsc_sdp.db[16] |= 0x4;
- break;
- case DRM_MODE_COLORIMETRY_OPYCC_601:
- vsc_sdp.db[16] |= 0x5;
- break;
- case DRM_MODE_COLORIMETRY_BT2020_CYCC:
- case DRM_MODE_COLORIMETRY_BT2020_RGB:
- vsc_sdp.db[16] |= 0x6;
- break;
- case DRM_MODE_COLORIMETRY_BT2020_YCC:
- vsc_sdp.db[16] |= 0x7;
- break;
- case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
- case DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
- vsc_sdp.db[16] |= 0x4; /* DCI-P3 (SMPTE RP 431-2) */
- break;
- default:
- /* sRGB (IEC 61966-2-1) / ITU-R BT.601: DB16[0:3] = 0h */
-
- /* RGB->YCBCR color conversion uses the BT.709 color space. */
- if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
- vsc_sdp.db[16] |= 0x1; /* 0x1, ITU-R BT.709 */
- break;
- }
-
- /*
-* For pixel encoding formats YCbCr444, YCbCr422, YCbCr420, and Y Only,
-* the following Component Bit Depth values are defined:
-* 001b = 8bpc.
-* 010b = 10bpc.
-* 011b = 12bpc.
-* 100b = 16bpc.
-*/
- switch
[Intel-gfx] [PATCH v11 05/14] drm/i915: Include DP HDR Metadata Infoframe SDP in the crtc state dump
Dump out the DP HDR Metadata Infoframe SDP in the normal crtc state dump. HDMI Dynamic Range and Mastering (DRM) infoframe and DP HDR Metadata Infoframe SDP use the same member variable in infoframes of crtc state. Signed-off-by: Gwan-gyeong Mun Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 93f8ae9471e7..172574a60ddd 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -13026,6 +13026,9 @@ static void intel_dump_pipe_config(const struct intel_crtc_state *pipe_config, if (pipe_config->infoframes.enable & intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM)) intel_dump_infoframe(dev_priv, _config->infoframes.drm); + if (pipe_config->infoframes.enable & + intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA)) + intel_dump_infoframe(dev_priv, _config->infoframes.drm); drm_dbg_kms(_priv->drm, "requested mode:\n"); drm_mode_debug_printmodeline(_config->hw.mode); -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11 12/14] drm/i915: Stop sending DP SDPs on ddi disable
Call intel_dp_set_infoframes(false) function on intel_ddi_post_disable_dp() to make sure not to send VSC SDP and HDR Metadata Infoframe SDP. v5: Polish commit message [Uma] Signed-off-by: Gwan-gyeong Mun Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index e0862b899f1b..d88431ebb34e 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3472,6 +3472,8 @@ static void intel_ddi_post_disable_dp(struct intel_atomic_state *state, INTEL_OUTPUT_DP_MST); enum phy phy = intel_port_to_phy(dev_priv, encoder->port); + intel_dp_set_infoframes(encoder, false, old_crtc_state, old_conn_state); + /* * Power down sink before disabling the port, otherwise we end * up getting interrupts from the sink on detecting link loss. -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: Stash hpd status bits under dev_priv
On Thu, May 07, 2020 at 02:48:08PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of constnantly having to figure out which hpd status bit
> array to use let's store them under dev_priv.
>
> Should perhaps take this further and stash even more stuff to
> make the hpd handling more abstract yet.
>
> v2: Remeber cnp (Imre)
> Add MISSING_CASE() for unknown PCHs (Imre)
>
> Cc: Imre Deak
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_irq.c | 203 ++--
> 2 files changed, 116 insertions(+), 89 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6af69555733e..155f3fa3286c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -148,6 +148,8 @@ enum hpd_pin {
> struct i915_hotplug {
> struct delayed_work hotplug_work;
>
> + const u32 *hpd, *pch_hpd;
> +
> struct {
> unsigned long last_jiffies;
> int count;
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index ea4c87784a27..4dc601dffc08 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -124,7 +124,6 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
> [HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS,
> };
>
> -/* BXT hpd list */
> static const u32 hpd_bxt[HPD_NUM_PINS] = {
> [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
> [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
> @@ -168,6 +167,49 @@ static const u32 hpd_tgp[HPD_NUM_PINS] = {
> [HPD_PORT_I] = SDE_TC_HOTPLUG_ICP(PORT_TC6),
> };
>
> +static void intel_hpd_init_pins(struct drm_i915_private *dev_priv)
> +{
> + struct i915_hotplug *hpd = _priv->hotplug;
> +
> + if (HAS_GMCH(dev_priv)) {
> + if (IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
> + IS_CHERRYVIEW(dev_priv))
> + hpd->hpd = hpd_status_g4x;
> + else
> + hpd->hpd = hpd_status_i915;
> + return;
> + }
> +
> + if (INTEL_GEN(dev_priv) >= 12)
> + hpd->hpd = hpd_gen12;
> + else if (INTEL_GEN(dev_priv) >= 11)
> + hpd->hpd = hpd_gen11;
> + else if (IS_GEN9_LP(dev_priv))
> + hpd->hpd = hpd_bxt;
> + else if (INTEL_GEN(dev_priv) >= 8)
> + hpd->hpd = hpd_bdw;
> + else if (INTEL_GEN(dev_priv) >= 7)
> + hpd->hpd = hpd_ivb;
> + else
> + hpd->hpd = hpd_ilk;
> +
> + if (!HAS_PCH_SPLIT(dev_priv) || HAS_PCH_NOP(dev_priv))
> + return;
> +
> + if (HAS_PCH_TGP(dev_priv) || HAS_PCH_JSP(dev_priv))
> + hpd->pch_hpd = hpd_tgp;
> + else if (HAS_PCH_ICP(dev_priv) || HAS_PCH_MCC(dev_priv))
> + hpd->pch_hpd = hpd_icp;
> + else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_SPT(dev_priv))
> + hpd->pch_hpd = hpd_spt;
> + else if (HAS_PCH_LPT(dev_priv) || HAS_PCH_CPT(dev_priv))
> + hpd->pch_hpd = hpd_cpt;
> + else if (HAS_PCH_IBX(dev_priv))
> + hpd->pch_hpd = hpd_ibx;
> + else
> + MISSING_CASE(INTEL_PCH_TYPE(dev_priv));
> +}
> +
> static void
> intel_handle_vblank(struct drm_i915_private *dev_priv, enum pipe pipe)
> {
> @@ -1504,33 +1546,27 @@ static void i9xx_hpd_irq_handler(struct
> drm_i915_private *dev_priv,
>u32 hotplug_status)
> {
> u32 pin_mask = 0, long_mask = 0;
> + u32 hotplug_trigger;
>
> - if (IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
> - IS_CHERRYVIEW(dev_priv)) {
> - u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
> -
> - if (hotplug_trigger) {
> - intel_get_hpd_pins(dev_priv, _mask, _mask,
> -hotplug_trigger, hotplug_trigger,
> -hpd_status_g4x,
> -i9xx_port_hotplug_long_detect);
> + if (IS_G4X(dev_priv) ||
> + IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
> + else
> + hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
>
> - intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
> - }
> + if (hotplug_trigger) {
> + intel_get_hpd_pins(dev_priv, _mask, _mask,
> +hotplug_trigger, hotplug_trigger,
> +dev_priv->hotplug.hpd,
> +i9xx_port_hotplug_long_detect);
>
> - if (hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
> - dp_aux_irq_handler(dev_priv);
> - } else {
> - u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
> -
> - if (hotplug_trigger) {
> -
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Mark concurrent submissions with a weak-dependency (rev2)
== Series Details == Series: series starting with [1/3] drm/i915: Mark concurrent submissions with a weak-dependency (rev2) URL : https://patchwork.freedesktop.org/series/77024/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8441_full -> Patchwork_17598_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17598_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17598_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17598_full: ### IGT changes ### Possible regressions * igt@kms_flip_event_leak: - shard-kbl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-kbl2/igt@kms_flip_event_leak.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/shard-kbl3/igt@kms_flip_event_leak.html New tests - New tests have been introduced between CI_DRM_8441_full and Patchwork_17598_full: ### New IGT tests (4) ### * igt@gem_exec_fence@submit@bcs0: - Statuses : 6 pass(s) - Exec time: [0.01, 0.05] s * igt@gem_exec_fence@submit@vcs0: - Statuses : 6 pass(s) - Exec time: [0.01, 0.05] s * igt@gem_exec_fence@submit@vcs1: - Statuses : 3 pass(s) - Exec time: [0.01] s * igt@gem_exec_fence@submit@vecs0: - Statuses : 6 pass(s) - Exec time: [0.01, 0.05] s Known issues Here are the changes found in Patchwork_17598_full that come from known issues: ### IGT changes ### Issues hit * igt@gen9_exec_parse@allowed-all: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] / [i915#716]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-kbl1/igt@gen9_exec_pa...@allowed-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/shard-kbl2/igt@gen9_exec_pa...@allowed-all.html * igt@i915_suspend@forcewake: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-kbl3/igt@i915_susp...@forcewake.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/shard-kbl1/igt@i915_susp...@forcewake.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#1188]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-skl2/igt@kms_...@bpc-switch-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/shard-skl8/igt@kms_...@bpc-switch-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#69]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-skl6/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/shard-skl8/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/shard-iclb1/igt@kms_psr@psr2_primary_mmap_cpu.html * igt@kms_setmode@basic: - shard-kbl: [PASS][17] -> [FAIL][18] ([i915#31]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-kbl6/igt@kms_setm...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/shard-kbl7/igt@kms_setm...@basic.html Possible fixes * igt@gem_eio@in-flight-suspend: - shard-skl: [INCOMPLETE][19] ([i915#69]) -> [PASS][20] +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-skl9/igt@gem_...@in-flight-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/shard-skl2/igt@gem_...@in-flight-suspend.html *
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Hotplug cleanups (rev7)
== Series Details ==
Series: drm/i915: Hotplug cleanups (rev7)
URL : https://patchwork.freedesktop.org/series/72348/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8442 -> Patchwork_17599
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/index.html
Known issues
Here are the changes found in Patchwork_17599 that come from known issues:
### IGT changes ###
Possible fixes
* {igt@kms_flip@basic-flip-vs-wf_vblank@b-dvi-d1}:
- fi-bwr-2160:[FAIL][1] ([i915#34]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8442/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vbl...@b-dvi-d1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vbl...@b-dvi-d1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#34]: https://gitlab.freedesktop.org/drm/intel/issues/34
Participating hosts (50 -> 44)
--
Additional (1): fi-kbl-7560u
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8442 -> Patchwork_17599
CI-20190529: 20190529
CI_DRM_8442: 05cbc9bc4cf15e838086241abfc734022c7adc2e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5638: 50868ab3c532a86aa147fb555b69a1078c572b13 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17599: 84534bb4dc5ed21993fb88de48afa2f8239e6ac1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
84534bb4dc5e drm/i915: Use stashed away hpd isr bits in
intel_digital_port_connected()
2b7a794ec44a drm/i915: Stash hpd status bits under dev_priv
b7c529044516 drm/i915: Turn intel_digital_port_connected() in a vfunc
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17599/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/22] drm/i915/rkl: Update memory bandwidth parameters
On Mon, May 04, 2020 at 03:52:11PM -0700, Matt Roper wrote:
> The RKL platform has different memory characteristics from past
> platforms. Update the values used by our memory bandwidth calculations
> accordingly.
>
> Bspec: 53998
> Cc: James Ausmus
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 6e7cc3a4f1aa..d435cc6019e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -176,6 +176,12 @@ static const struct intel_sa_info tgl_sa_info = {
> .displayrtids = 256,
> };
>
> +static const struct intel_sa_info rkl_sa_info = {
> + .deburst = 16,
> + .deprogbwlimit = 20, /* GB/s */
> + .displayrtids = 128,
> +};
Numbers appear to match the spec.
Reviewed-by: Ville Syrjälä
> +
> static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct
> intel_sa_info *sa)
> {
> struct intel_qgv_info qi = {};
> @@ -271,7 +277,9 @@ void intel_bw_init_hw(struct drm_i915_private *dev_priv)
> if (!HAS_DISPLAY(dev_priv))
> return;
>
> - if (IS_GEN(dev_priv, 12))
> + if (IS_ROCKETLAKE(dev_priv))
> + icl_get_bw_info(dev_priv, _sa_info);
> + else if (IS_GEN(dev_priv, 12))
> icl_get_bw_info(dev_priv, _sa_info);
> else if (IS_GEN(dev_priv, 11))
> icl_get_bw_info(dev_priv, _sa_info);
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/22] drm/i915/rkl: Limit number of universal planes to 5
On Mon, May 04, 2020 at 03:52:12PM -0700, Matt Roper wrote:
> RKL only has five universal planes, plus a cursor. Since the
> bottom-most universal plane is considered the primary plane, set the
> number of sprites available on this platform to 4.
>
> In general, the plane capabilities of the remaining planes stay the same
> as TGL. However the NV12 Y-plane support moves down to the new top two
> planes and now only the bottom three planes can be used for NV12 UV.
>
> Bspec: 49181
> Bspec: 49251
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 6 +-
> drivers/gpu/drm/i915/display/intel_sprite.c | 17 -
> drivers/gpu/drm/i915/display/intel_sprite.h | 11 ++-
> drivers/gpu/drm/i915/i915_irq.c | 4 +++-
> drivers/gpu/drm/i915/i915_reg.h | 5 +
> drivers/gpu/drm/i915/intel_device_info.c | 5 -
> 6 files changed, 35 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index fd6d63b03489..7d7a5b66f2cb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -12500,7 +12500,7 @@ static int icl_check_nv12_planes(struct
> intel_crtc_state *crtc_state)
> continue;
>
> for_each_intel_plane_on_crtc(_priv->drm, crtc, linked) {
> - if (!icl_is_nv12_y_plane(linked->id))
> + if (!icl_is_nv12_y_plane(dev_priv, linked->id))
> continue;
>
> if (crtc_state->active_planes & BIT(linked->id))
> @@ -12546,6 +12546,10 @@ static int icl_check_nv12_planes(struct
> intel_crtc_state *crtc_state)
> plane_state->cus_ctl |= PLANE_CUS_PLANE_7;
> else if (linked->id == PLANE_SPRITE4)
> plane_state->cus_ctl |= PLANE_CUS_PLANE_6;
> + else if (linked->id == PLANE_SPRITE3)
> + plane_state->cus_ctl |= PLANE_CUS_PLANE_5_RKL;
> + else if (linked->id == PLANE_SPRITE2)
> + plane_state->cus_ctl |= PLANE_CUS_PLANE_4_RKL;
> else
> MISSING_CASE(linked->id);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index ec7055f7..571c36f929bd 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -333,6 +333,21 @@ int intel_plane_check_src_coordinates(struct
> intel_plane_state *plane_state)
> return 0;
> }
>
> +static u8 icl_nv12_y_plane_mask(struct drm_i915_private *i915)
> +{
> + if (IS_ROCKETLAKE(i915))
> + return BIT(PLANE_SPRITE2) | BIT(PLANE_SPRITE3);
> + else
I'd probably move the gen11+ check here too.
Starting to wonder if we shouldn't just stuff a few plane
masks into the device info (and replace all num_sprites
stuff with those).
Anyways, looks reasonable:
Reviewed-by: Ville Syrjälä
Also wondering what happened to some of the stuff I did to these
functions... Oh right, it was all part of some colorkey stuff
which by now needs to rebased.
> + return BIT(PLANE_SPRITE4) | BIT(PLANE_SPRITE5);
> +}
> +
> +bool icl_is_nv12_y_plane(struct drm_i915_private *dev_priv,
> + enum plane_id plane_id)
> +{
> + return INTEL_GEN(dev_priv) >= 11 &&
> + icl_nv12_y_plane_mask(dev_priv) & BIT(plane_id);
> +}
> +
> bool icl_is_hdr_plane(struct drm_i915_private *dev_priv, enum plane_id
> plane_id)
> {
> return INTEL_GEN(dev_priv) >= 11 &&
> @@ -3003,7 +3018,7 @@ static const u32 *icl_get_plane_formats(struct
> drm_i915_private *dev_priv,
> if (icl_is_hdr_plane(dev_priv, plane_id)) {
> *num_formats = ARRAY_SIZE(icl_hdr_plane_formats);
> return icl_hdr_plane_formats;
> - } else if (icl_is_nv12_y_plane(plane_id)) {
> + } else if (icl_is_nv12_y_plane(dev_priv, plane_id)) {
> *num_formats = ARRAY_SIZE(icl_sdr_y_plane_formats);
> return icl_sdr_y_plane_formats;
> } else {
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.h
> b/drivers/gpu/drm/i915/display/intel_sprite.h
> index 5eeaa92420d1..cd2104ba1ca1 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.h
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.h
> @@ -32,21 +32,14 @@ struct intel_plane *
> skl_universal_plane_create(struct drm_i915_private *dev_priv,
> enum pipe pipe, enum plane_id plane_id);
>
> -static inline bool icl_is_nv12_y_plane(enum plane_id id)
> -{
> - /* Don't need to do a gen check, these planes are only available on
> gen11 */
> - if (id == PLANE_SPRITE4 || id == PLANE_SPRITE5)
> - return true;
Re: [Intel-gfx] [PATCH v2 14/22] drm/i915/rkl: provide port/phy mapping for vbt
On Mon, May 04, 2020 at 03:52:19PM -0700, Matt Roper wrote:
> From: Lucas De Marchi
>
> RKL uses the DDI A, DDI B, DDI USBC1, DDI USBC2 from the DE point of
> view, so all DDI/pipe/transcoder register use these indexes to refer to
> them. Combo phy and IO functions follow another namespace that we keep
> as "enum phy". The VBT in theory would use the DE point of view, but
> that does not happen in practice.
>
> Provide a table to convert the child devices to the "correct" port
> numbering we use. Now this is the output we get while reading the VBT:
>
> DDIA:
> [drm:intel_bios_port_aux_ch [i915]] using AUX A for port A (VBT)
> [drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:275:DDI
> A]
> [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on
> [ENCODER:275:DDI A]
> [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x1 for port A (VBT)
>
> DDIB:
> [drm:intel_bios_port_aux_ch [i915]] using AUX B for port B (platform default)
> [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on
> [ENCODER:291:DDI B]
> [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x2 for port B (VBT)
>
> DDI USBC1:
> [drm:intel_bios_port_aux_ch [i915]] using AUX D for port D (VBT)
> [drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:295:DDI
> D]
> [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on
> [ENCODER:295:DDI D]
> [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x3 for port D (VBT)
>
> DDI USBC2:
> [drm:intel_bios_port_aux_ch [i915]] using AUX E for port E (VBT)
> [drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:306:DDI
> E]
> [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on
> [ENCODER:306:DDI E]
> [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x9 for port E (VBT)
>
> Cc: Clinton Taylor
> Cc: Aditya Swarup
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 72 ---
> 1 file changed, 51 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 839124647202..4f1a72a90b8f 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1619,30 +1619,18 @@ static u8 map_ddc_pin(struct drm_i915_private
> *dev_priv, u8 vbt_pin)
> return 0;
> }
>
> -static enum port dvo_port_to_port(u8 dvo_port)
> +static enum port __dvo_port_to_port(int n_ports, int n_dvo,
> + const int port_mapping[][3], u8 dvo_port)
> {
> - /*
> - * Each DDI port can have more than one value on the "DVO Port" field,
> - * so look for all the possible values for each port.
> - */
> - static const int dvo_ports[][3] = {
> - [PORT_A] = { DVO_PORT_HDMIA, DVO_PORT_DPA, -1},
> - [PORT_B] = { DVO_PORT_HDMIB, DVO_PORT_DPB, -1},
> - [PORT_C] = { DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
> - [PORT_D] = { DVO_PORT_HDMID, DVO_PORT_DPD, -1},
> - [PORT_E] = { DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
> - [PORT_F] = { DVO_PORT_HDMIF, DVO_PORT_DPF, -1},
> - [PORT_G] = { DVO_PORT_HDMIG, DVO_PORT_DPG, -1},
> - };
> enum port port;
> int i;
>
> - for (port = PORT_A; port < ARRAY_SIZE(dvo_ports); port++) {
> - for (i = 0; i < ARRAY_SIZE(dvo_ports[port]); i++) {
> - if (dvo_ports[port][i] == -1)
> + for (port = PORT_A; port < n_ports; port++) {
> + for (i = 0; i < n_dvo; i++) {
> + if (port_mapping[port][i] == -1)
> break;
>
> - if (dvo_port == dvo_ports[port][i])
> + if (dvo_port == port_mapping[port][i])
> return port;
> }
> }
> @@ -1650,6 +1638,48 @@ static enum port dvo_port_to_port(u8 dvo_port)
> return PORT_NONE;
> }
>
> +static enum port dvo_port_to_port(struct drm_i915_private *dev_priv,
> + u8 dvo_port)
> +{
> + /*
> + * Each DDI port can have more than one value on the "DVO Port" field,
> + * so look for all the possible values for each port.
> + */
> + static const int port_mapping[][3] = {
> + [PORT_A] = { DVO_PORT_HDMIA, DVO_PORT_DPA, -1 },
> + [PORT_B] = { DVO_PORT_HDMIB, DVO_PORT_DPB, -1 },
> + [PORT_C] = { DVO_PORT_HDMIC, DVO_PORT_DPC, -1 },
> + [PORT_D] = { DVO_PORT_HDMID, DVO_PORT_DPD, -1 },
> + [PORT_E] = { DVO_PORT_CRT, DVO_PORT_HDMIE, -1 },
> + [PORT_F] = { DVO_PORT_HDMIF, DVO_PORT_DPF, -1 },
> + [PORT_G] = { DVO_PORT_HDMIG, DVO_PORT_DPG, -1 },
> + };
> + /*
> + * Bspec lists the ports as A, B, C, D - however internally in our
> + * driver we keep them as PORT_A, PORT_B, PORT_D and PORT_E so the
> +
Re: [Intel-gfx] [PATCH v2 12/22] drm/i915/rkl: Check proper SDEISR bits for TC1 and TC2 outputs
On Mon, May 04, 2020 at 03:52:17PM -0700, Matt Roper wrote:
> When Rocket Lake is paired with a TGP PCH, the last two outputs utilize
> the TC1 and TC2 hpd pins, even though these are combo outputs.
>
> Bspec: 49181
> Cc: Lucas De Marchi
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 6952b0295096..d32bbcd99b8a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6172,8 +6172,12 @@ static bool bxt_digital_port_connected(struct
> intel_encoder *encoder)
> static bool intel_combo_phy_connected(struct drm_i915_private *dev_priv,
> enum phy phy)
> {
> - if (HAS_PCH_MCC(dev_priv) && phy == PHY_C)
> - return intel_de_read(dev_priv, SDEISR) &
> SDE_TC_HOTPLUG_ICP(PORT_TC1);
> + if (IS_ROCKETLAKE(dev_priv) && phy >= PHY_C)
> + return intel_de_read(dev_priv, SDEISR) &
> + SDE_TC_HOTPLUG_ICP(phy - PHY_C);
> + else if (HAS_PCH_MCC(dev_priv) && phy == PHY_C)
> + return intel_de_read(dev_priv, SDEISR) &
> + SDE_TC_HOTPLUG_ICP(PORT_TC1);
Most of this mess is going to disappear as soon as I can land
https://patchwork.freedesktop.org/series/72348/
So assuming the hpd[] thing gets correctly populated we no longer
need any hack like these.
>
> return intel_de_read(dev_priv, SDEISR) & SDE_DDI_HOTPLUG_ICP(phy);
> }
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 17/22] drm/i915/rkl: Don't try to read out DSI transcoders
On Mon, May 04, 2020 at 03:52:22PM -0700, Matt Roper wrote: > From: Aditya Swarup > > RKL doesn't have DSI outputs, so we shouldn't try to read out the DSI > transcoder registers. > > Signed-off-by: Aditya Swarup > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/display/intel_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 2eeafda82188..e63221b8a9a6 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -10901,7 +10901,7 @@ static bool hsw_get_transcoder_state(struct > intel_crtc *crtc, > intel_wakeref_t wf; > u32 tmp; > > - if (INTEL_GEN(dev_priv) >= 11) > + if (!IS_ROCKETLAKE(dev_priv) && INTEL_GEN(dev_priv) >= 11) > panel_transcoder_mask |= > BIT(TRANSCODER_DSI_0) | BIT(TRANSCODER_DSI_1); I suspect we want 1) fix the deivice info transcoder mask (if not already done) 2) use for_each_transcoder_masked() here > > -- > 2.24.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/3] drm/i915: Stash hpd status bits under dev_priv
From: Ville Syrjälä
Instead of constnantly having to figure out which hpd status bit
array to use let's store them under dev_priv.
Should perhaps take this further and stash even more stuff to
make the hpd handling more abstract yet.
v2: Remeber cnp (Imre)
Add MISSING_CASE() for unknown PCHs (Imre)
Cc: Imre Deak
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_irq.c | 203 ++--
2 files changed, 116 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6af69555733e..155f3fa3286c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -148,6 +148,8 @@ enum hpd_pin {
struct i915_hotplug {
struct delayed_work hotplug_work;
+ const u32 *hpd, *pch_hpd;
+
struct {
unsigned long last_jiffies;
int count;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ea4c87784a27..4dc601dffc08 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -124,7 +124,6 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS,
};
-/* BXT hpd list */
static const u32 hpd_bxt[HPD_NUM_PINS] = {
[HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
@@ -168,6 +167,49 @@ static const u32 hpd_tgp[HPD_NUM_PINS] = {
[HPD_PORT_I] = SDE_TC_HOTPLUG_ICP(PORT_TC6),
};
+static void intel_hpd_init_pins(struct drm_i915_private *dev_priv)
+{
+ struct i915_hotplug *hpd = _priv->hotplug;
+
+ if (HAS_GMCH(dev_priv)) {
+ if (IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
+ IS_CHERRYVIEW(dev_priv))
+ hpd->hpd = hpd_status_g4x;
+ else
+ hpd->hpd = hpd_status_i915;
+ return;
+ }
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ hpd->hpd = hpd_gen12;
+ else if (INTEL_GEN(dev_priv) >= 11)
+ hpd->hpd = hpd_gen11;
+ else if (IS_GEN9_LP(dev_priv))
+ hpd->hpd = hpd_bxt;
+ else if (INTEL_GEN(dev_priv) >= 8)
+ hpd->hpd = hpd_bdw;
+ else if (INTEL_GEN(dev_priv) >= 7)
+ hpd->hpd = hpd_ivb;
+ else
+ hpd->hpd = hpd_ilk;
+
+ if (!HAS_PCH_SPLIT(dev_priv) || HAS_PCH_NOP(dev_priv))
+ return;
+
+ if (HAS_PCH_TGP(dev_priv) || HAS_PCH_JSP(dev_priv))
+ hpd->pch_hpd = hpd_tgp;
+ else if (HAS_PCH_ICP(dev_priv) || HAS_PCH_MCC(dev_priv))
+ hpd->pch_hpd = hpd_icp;
+ else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_SPT(dev_priv))
+ hpd->pch_hpd = hpd_spt;
+ else if (HAS_PCH_LPT(dev_priv) || HAS_PCH_CPT(dev_priv))
+ hpd->pch_hpd = hpd_cpt;
+ else if (HAS_PCH_IBX(dev_priv))
+ hpd->pch_hpd = hpd_ibx;
+ else
+ MISSING_CASE(INTEL_PCH_TYPE(dev_priv));
+}
+
static void
intel_handle_vblank(struct drm_i915_private *dev_priv, enum pipe pipe)
{
@@ -1504,33 +1546,27 @@ static void i9xx_hpd_irq_handler(struct
drm_i915_private *dev_priv,
u32 hotplug_status)
{
u32 pin_mask = 0, long_mask = 0;
+ u32 hotplug_trigger;
- if (IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
- IS_CHERRYVIEW(dev_priv)) {
- u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
-
- if (hotplug_trigger) {
- intel_get_hpd_pins(dev_priv, _mask, _mask,
- hotplug_trigger, hotplug_trigger,
- hpd_status_g4x,
- i9xx_port_hotplug_long_detect);
+ if (IS_G4X(dev_priv) ||
+ IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+ hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
+ else
+ hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
- intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
- }
+ if (hotplug_trigger) {
+ intel_get_hpd_pins(dev_priv, _mask, _mask,
+ hotplug_trigger, hotplug_trigger,
+ dev_priv->hotplug.hpd,
+ i9xx_port_hotplug_long_detect);
- if (hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
- dp_aux_irq_handler(dev_priv);
- } else {
- u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
-
- if (hotplug_trigger) {
- intel_get_hpd_pins(dev_priv, _mask, _mask,
- hotplug_trigger, hotplug_trigger,
- hpd_status_i915,
-
Re: [Intel-gfx] [PATCH v2 12/22] drm/i915/rkl: Check proper SDEISR bits for TC1 and TC2 outputs
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Tuesday, May 5, 2020 4:22 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas
> Subject: [Intel-gfx] [PATCH v2 12/22] drm/i915/rkl: Check proper SDEISR bits
> for
> TC1 and TC2 outputs
>
> When Rocket Lake is paired with a TGP PCH, the last two outputs utilize the
> TC1 and TC2 hpd pins, even though these are combo outputs.
>
> Bspec: 49181
> Cc: Lucas De Marchi
> Signed-off-by: Matt Roper
Looks good.
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 6952b0295096..d32bbcd99b8a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6172,8 +6172,12 @@ static bool bxt_digital_port_connected(struct
> intel_encoder *encoder) static bool intel_combo_phy_connected(struct
> drm_i915_private *dev_priv,
> enum phy phy)
> {
> - if (HAS_PCH_MCC(dev_priv) && phy == PHY_C)
> - return intel_de_read(dev_priv, SDEISR) &
> SDE_TC_HOTPLUG_ICP(PORT_TC1);
> + if (IS_ROCKETLAKE(dev_priv) && phy >= PHY_C)
> + return intel_de_read(dev_priv, SDEISR) &
> + SDE_TC_HOTPLUG_ICP(phy - PHY_C);
> + else if (HAS_PCH_MCC(dev_priv) && phy == PHY_C)
> + return intel_de_read(dev_priv, SDEISR) &
> + SDE_TC_HOTPLUG_ICP(PORT_TC1);
>
> return intel_de_read(dev_priv, SDEISR) &
> SDE_DDI_HOTPLUG_ICP(phy); }
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 10/22] drm/i915/rkl: RKL only uses PHY_MISC for PHY's A and B
> -Original Message-
> From: Roper, Matthew D
> Sent: Wednesday, May 6, 2020 10:20 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 10/22] drm/i915/rkl: RKL only uses PHY_MISC
> for PHY's A and B
>
> On Wed, May 06, 2020 at 06:49:06AM -0700, Srivatsa, Anusha wrote:
> >
> >
> > > -Original Message- From: Intel-gfx
> > > On Behalf Of Matt Roper
> > > Sent: Tuesday, May 5, 2020 4:22 AM To:
> > > intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [PATCH v2
> > > 10/22] drm/i915/rkl: RKL only uses PHY_MISC for PHY's A and B
> > >
> > > Since the number of platforms with this restriction are growing,
> > > let's separate out the platform logic into a has_phy_misc()
> > > function.
> > >
> > > Bspec: 50107 Signed-off-by: Matt Roper
> > > --- .../gpu/drm/i915/display/intel_combo_phy.c| 30
> > > +++ 1 file changed, 17 insertions(+), 13
> > > deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> > > b/drivers/gpu/drm/i915/display/intel_combo_phy.c index
> > > 9ff05ec12115..43d8784f6fa0 100644 ---
> > > a/drivers/gpu/drm/i915/display/intel_combo_phy.c +++
> > > b/drivers/gpu/drm/i915/display/intel_combo_phy.c @@ -181,11 +181,25
> > > @@ static void cnl_combo_phys_uninit(struct drm_i915_private
> > > *dev_priv) intel_de_write(dev_priv, CHICKEN_MISC_2, val); }
> > >
> > > +static bool has_phy_misc(struct drm_i915_private *i915, enum phy
> > > phy) { + /* + * Some platforms only expect PHY_MISC to be
> > > programmed for PHY-A and + * PHY-B and may not even have
> instances
> > > of the register for the + * other combo PHY's. + */ + if
> > > (IS_ELKHARTLAKE(i915) || +IS_ROCKETLAKE(i915)) + return phy <
> > > PHY_C;
> > According BSpec 50107, there is an instance of this for combo PHY C as
> > well.
> >
> Yeah, there's technically an instance of the register, but the only field in
> it that
> our driver programs has a RKL programming note that says "This register field
> need only be programmed for port A and B."
Ok. Thanks for pointing it out.
Reviewed-by: Anusha Srivatsa
>
> Matt
>
> > Anusha
> > > +
> > > + return true;
> > > +}
> > > +
> > > static bool icl_combo_phy_enabled(struct drm_i915_private *dev_priv,
> > > enum phy phy)
> > > {
> > > /* The PHY C added by EHL has no PHY_MISC register */
> > > - if (IS_ELKHARTLAKE(dev_priv) && phy == PHY_C)
> > > + if (!has_phy_misc(dev_priv, phy))
> > > return intel_de_read(dev_priv, ICL_PORT_COMP_DW0(phy))
> &
> > > COMP_INIT;
> > > else
> > > return !(intel_de_read(dev_priv, ICL_PHY_MISC(phy)) & @@ -
> > > 317,12 +331,7 @@ static void icl_combo_phys_init(struct
> > > drm_i915_private
> > > *dev_priv)
> > > continue;
> > > }
> > >
> > > - /*
> > > - * Although EHL adds a combo PHY C, there's no PHY_MISC
> > > - * register for it and no need to program the
> > > - * DE_IO_COMP_PWR_DOWN setting on PHY C.
> > > - */
> > > - if (IS_ELKHARTLAKE(dev_priv) && phy == PHY_C)
> > > + if (!has_phy_misc(dev_priv, phy))
> > > goto skip_phy_misc;
> > >
> > > /*
> > > @@ -376,12 +385,7 @@ static void icl_combo_phys_uninit(struct
> > > drm_i915_private *dev_priv)
> > >"Combo PHY %c HW state changed
> unexpectedly\n",
> > >phy_name(phy));
> > >
> > > - /*
> > > - * Although EHL adds a combo PHY C, there's no PHY_MISC
> > > - * register for it and no need to program the
> > > - * DE_IO_COMP_PWR_DOWN setting on PHY C.
> > > - */
> > > - if (IS_ELKHARTLAKE(dev_priv) && phy == PHY_C)
> > > + if (!has_phy_misc(dev_priv, phy))
> > > goto skip_phy_misc;
> > >
> > > val = intel_de_read(dev_priv, ICL_PHY_MISC(phy));
> > > --
> > > 2.24.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 01/22] drm/i915/rkl: Add RKL platform info and PCI ids
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Tuesday, May 5, 2020 4:22 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas
> Subject: [Intel-gfx] [PATCH v2 01/22] drm/i915/rkl: Add RKL platform info and
> PCI ids
>
> Introduce the basic platform definition, macros, and PCI IDs.
>
> Bspec: 44501
> Cc: Lucas De Marchi
> Cc: Caz Yokoyama
> Cc: Aditya Swarup
> Signed-off-by: Matt Roper
> Acked-by: Caz Yokoyama
Confirmed the info with the BSpec.
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/i915_drv.h | 8
> drivers/gpu/drm/i915/i915_pci.c | 10 ++
> drivers/gpu/drm/i915/intel_device_info.c | 1 +
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> include/drm/i915_pciids.h| 9 +
> 5 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index 6af69555733e..1ba77283123d
> 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1406,6 +1406,7 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
> #define IS_ICELAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ICELAKE)
> #define IS_ELKHARTLAKE(dev_priv) IS_PLATFORM(dev_priv,
> INTEL_ELKHARTLAKE)
> #define IS_TIGERLAKE(dev_priv) IS_PLATFORM(dev_priv,
> INTEL_TIGERLAKE)
> +#define IS_ROCKETLAKE(dev_priv) IS_PLATFORM(dev_priv,
> INTEL_ROCKETLAKE)
> #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
> (INTEL_DEVID(dev_priv) & 0xFF00) ==
> 0x0C00) #define IS_BDW_ULT(dev_priv) \ @@ -1514,6 +1515,13 @@
> IS_SUBPLATFORM(const struct drm_i915_private *i915, #define
> IS_TGL_REVID(p, since, until) \
> (IS_TIGERLAKE(p) && IS_REVID(p, since, until))
>
> +#define RKL_REVID_A0 0x0
> +#define RKL_REVID_B0 0x1
> +#define RKL_REVID_C0 0x4
> +
> +#define IS_RKL_REVID(p, since, until) \
> + (IS_ROCKETLAKE(p) && IS_REVID(p, since, until))
> +
> #define IS_LP(dev_priv) (INTEL_INFO(dev_priv)->is_lp)
> #define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv))
> #define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 1faf9d6ec0a4..5a470bab2214 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -863,6 +863,15 @@ static const struct intel_device_info tgl_info = {
> BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2), };
>
> +static const struct intel_device_info rkl_info = {
> + GEN12_FEATURES,
> + PLATFORM(INTEL_ROCKETLAKE),
> + .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C),
> + .require_force_probe = 1,
> + .engine_mask =
> + BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0), };
> +
> #define GEN12_DGFX_FEATURES \
> GEN12_FEATURES, \
> .is_dgfx = 1
> @@ -941,6 +950,7 @@ static const struct pci_device_id pciidlist[] = {
> INTEL_ICL_11_IDS(_info),
> INTEL_EHL_IDS(_info),
> INTEL_TGL_12_IDS(_info),
> + INTEL_RKL_IDS(_info),
> {0, 0, 0}
> };
> MODULE_DEVICE_TABLE(pci, pciidlist);
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 91bb7891c70c..9862c1185059 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -61,6 +61,7 @@ static const char * const platform_names[] = {
> PLATFORM_NAME(ICELAKE),
> PLATFORM_NAME(ELKHARTLAKE),
> PLATFORM_NAME(TIGERLAKE),
> + PLATFORM_NAME(ROCKETLAKE),
> };
> #undef PLATFORM_NAME
>
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 69c9257c6c6a..a126984cef7f 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -80,6 +80,7 @@ enum intel_platform {
> INTEL_ELKHARTLAKE,
> /* gen12 */
> INTEL_TIGERLAKE,
> + INTEL_ROCKETLAKE,
> INTEL_MAX_PLATFORMS
> };
>
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index
> 662d8351c87a..bc989de2aac2 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -605,4 +605,13 @@
> INTEL_VGA_DEVICE(0x9AD9, info), \
> INTEL_VGA_DEVICE(0x9AF8, info)
>
> +/* RKL */
> +#define INTEL_RKL_IDS(info) \
> + INTEL_VGA_DEVICE(0x4C80, info), \
> + INTEL_VGA_DEVICE(0x4C8A, info), \
> + INTEL_VGA_DEVICE(0x4C8B, info), \
> + INTEL_VGA_DEVICE(0x4C8C, info), \
> + INTEL_VGA_DEVICE(0x4C90, info), \
> + INTEL_VGA_DEVICE(0x4C9A, info)
> +
> #endif /* _I915_PCIIDS_H */
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Mark concurrent submissions with a weak-dependency (rev2)
== Series Details == Series: series starting with [1/3] drm/i915: Mark concurrent submissions with a weak-dependency (rev2) URL : https://patchwork.freedesktop.org/series/77007/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8441_full -> Patchwork_17597_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17597_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17597_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17597_full: ### IGT changes ### Possible regressions * igt@gem_eio@hibernate: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-iclb7/igt@gem_...@hibernate.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17597/shard-iclb1/igt@gem_...@hibernate.html * igt@perf@oa-exponents: - shard-apl: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-apl1/igt@p...@oa-exponents.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17597/shard-apl3/igt@p...@oa-exponents.html New tests - New tests have been introduced between CI_DRM_8441_full and Patchwork_17597_full: ### New IGT tests (4) ### * igt@gem_exec_fence@submit@bcs0: - Statuses : 6 pass(s) - Exec time: [0.00, 0.07] s * igt@gem_exec_fence@submit@vcs0: - Statuses : 6 pass(s) - Exec time: [0.00, 0.05] s * igt@gem_exec_fence@submit@vcs1: - Statuses : 3 pass(s) - Exec time: [0.00, 0.01] s * igt@gem_exec_fence@submit@vecs0: - Statuses : 6 pass(s) - Exec time: [0.01, 0.06] s Known issues Here are the changes found in Patchwork_17597_full that come from known issues: ### IGT changes ### Issues hit * igt@gen9_exec_parse@allowed-all: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-kbl1/igt@gen9_exec_pa...@allowed-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17597/shard-kbl2/igt@gen9_exec_pa...@allowed-all.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-iclb: [PASS][7] -> [TIMEOUT][8] ([i915#1346]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-iclb7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17597/shard-iclb1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane@plane-panning-top-left-pipe-c-planes: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#1036]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-skl10/igt@kms_pl...@plane-panning-top-left-pipe-c-planes.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17597/shard-skl6/igt@kms_pl...@plane-panning-top-left-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145] / [i915#265]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17597/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17597/shard-iclb6/igt@kms_psr@psr2_primary_mmap_cpu.html * igt@kms_setmode@basic: - shard-kbl: [PASS][15] -> [FAIL][16] ([i915#31]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-kbl6/igt@kms_setm...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17597/shard-kbl7/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-kbl6/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17597/shard-kbl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html * igt@perf@oa-exponents: - shard-glk: [PASS][19] -> [INCOMPLETE][20] ([i915#58] / [k.org#198133]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/shard-glk2/igt@p...@oa-exponents.html [20]:
[Intel-gfx] [drm-tip:drm-tip 3/9] drivers/gpu/drm/i915/gt/intel_engine_cs.c:1428:31: error: 'struct intel_context' has no member named 'lrc_desc'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 6c0ee41a7c3201ef2a89800234803a95f65989be
commit: e81df648fc5bcd0fa702df401e02b7914c76ff71 [3/9] Merge remote-tracking
branch 'drm/drm-next' into drm-tip
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce:
git checkout e81df648fc5bcd0fa702df401e02b7914c76ff71
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
Note: the drm-tip/drm-tip HEAD 6c0ee41a7c3201ef2a89800234803a95f65989be builds
fine.
It only hurts bisectibility.
All error/warnings (new ones prefixed by >>):
In file included from include/asm-generic/bug.h:19:0,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/seq_file.h:7,
from include/drm/drm_print.h:31,
from drivers/gpu/drm/i915/gt/intel_engine_cs.c:25:
drivers/gpu/drm/i915/gt/intel_engine_cs.c: In function
'intel_engine_print_registers':
>> drivers/gpu/drm/i915/gt/intel_engine_cs.c:1428:31: error: 'struct
>> intel_context' has no member named 'lrc_desc'
upper_32_bits(rq->context->lrc_desc));
^
include/linux/kernel.h:183:35: note: in definition of macro 'upper_32_bits'
#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
^
drivers/gpu/drm/i915/gt/intel_engine_cs.c:1440:31: error: 'struct
intel_context' has no member named 'lrc_desc'
upper_32_bits(rq->context->lrc_desc));
^
include/linux/kernel.h:183:35: note: in definition of macro 'upper_32_bits'
#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
^
--
drivers/gpu/drm/i915/gt/intel_lrc.c: In function '__execlists_schedule_in':
>> drivers/gpu/drm/i915/gt/intel_lrc.c:1256:35: error: 'struct
>> intel_engine_execlists' has no member named 'ccid'
ce->lrc.ccid |= engine->execlists.ccid;
^
In file included from include/linux/interrupt.h:6:0,
from drivers/gpu/drm/i915/gt/intel_lrc.c:134:
drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'timeslice_yield':
>> drivers/gpu/drm/i915/gt/intel_lrc.c:1804:34: error: 'struct intel_context'
>> has no member named 'lrc_desc'
return upper_32_bits(rq->context->lrc_desc) == READ_ONCE(el->yield);
^
include/linux/kernel.h:183:35: note: in definition of macro 'upper_32_bits'
#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
^
drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'active_context':
drivers/gpu/drm/i915/gt/intel_lrc.c:2850:32: error: 'struct intel_context'
has no member named 'lrc_desc'
if (upper_32_bits(rq->context->lrc_desc) == ccid) {
^
include/linux/kernel.h:183:35: note: in definition of macro 'upper_32_bits'
#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
^
drivers/gpu/drm/i915/gt/intel_lrc.c:2859:32: error: 'struct intel_context'
has no member named 'lrc_desc'
if (upper_32_bits(rq->context->lrc_desc) == ccid) {
^
include/linux/kernel.h:183:35: note: in definition of macro 'upper_32_bits'
#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
^
drivers/gpu/drm/i915/gt/intel_lrc.c: In function
'intel_execlists_submission_setup':
drivers/gpu/drm/i915/gt/intel_lrc.c:4668:12: error: 'struct
intel_engine_execlists' has no member named 'ccid'
execlists->ccid |= engine->instance << (GEN11_ENGINE_INSTANCE_SHIFT - 32);
^~
drivers/gpu/drm/i915/gt/intel_lrc.c:4669:12: error: 'struct
intel_engine_execlists' has no member named 'ccid'
execlists->ccid |= engine->class << (GEN11_ENGINE_CLASS_SHIFT - 32);
^~
drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'timeslice_yield':
>> drivers/gpu/drm/i915/gt/intel_lrc.c:1805:1: warning: control reaches end of
>> non-void function [-Wreturn-type]
}
^
vim +1428 drivers/gpu/drm/i915/gt/intel_engine_cs.c
2229adc81380c46 drivers/gpu/drm/i915/gt/intel_engine_cs.c Chris Wilson
2019-10-16 1318
eca153603f2f020 drivers/gpu/drm/i915/gt/intel_engine_cs.c Chris Wilson
2019-06-18 1319 static void intel_engine_print_registers(struct
intel_engine_cs *engine,
3ceda3a4a856336 drivers/gpu/drm/i915/intel_engine_cs.cChris Wilson
2018-02-12 1320struct drm_printer *m)
f636edb214a5ffd drivers/gpu/drm/i915/intel_engine_cs.cChris Wilson
2017-10-09 1321 {
f636edb214a5ffd drivers/gpu/drm/i915/intel_engine_cs.cChris Wilson
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Mark concurrent submissions with a weak-dependency (rev2)
== Series Details == Series: series starting with [1/3] drm/i915: Mark concurrent submissions with a weak-dependency (rev2) URL : https://patchwork.freedesktop.org/series/77024/ State : success == Summary == CI Bug Log - changes from CI_DRM_8441 -> Patchwork_17598 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/index.html Known issues Here are the changes found in Patchwork_17598 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@active: - fi-kbl-soraka: [PASS][1] -> [DMESG-FAIL][2] ([i915#666]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8441/fi-kbl-soraka/igt@i915_selftest@l...@active.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/fi-kbl-soraka/igt@i915_selftest@l...@active.html [i915#666]: https://gitlab.freedesktop.org/drm/intel/issues/666 Participating hosts (49 -> 43) -- Additional (1): fi-bdw-gvtdvm Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8441 -> Patchwork_17598 CI-20190529: 20190529 CI_DRM_8441: 6c0ee41a7c3201ef2a89800234803a95f65989be @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5637: fdc33f7e1adc5bb6a1ba88b6233aaf224174d75a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17598: 183fe789671fbe6252b0474dc63a6cca25c998cc @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 183fe789671f drm/i915: Treat weak-dependencies as bidirectional when applying priorities d62dd47b9d3b drm/i915/gem: Treat submit-fence as weak dependency for new clients 4776c2422f73 drm/i915: Mark concurrent submissions with a weak-dependency == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17598/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [bug report] drm/i915: Use the async worker to avoid reclaim tainting the ggtt->mutex
Quoting Dan Carpenter (2020-05-07 10:17:14)
> Hello Chris Wilson,
>
> The patch e3793468b466: "drm/i915: Use the async worker to avoid
> reclaim tainting the ggtt->mutex" from Jan 30, 2020, leads to the
> following static checker warning:
>
> drivers/gpu/drm/i915/i915_vma.c:356 i915_vma_wait_for_bind()
> warn: 's64max' cannot fit into 'bool'
>
> drivers/gpu/drm/i915/i915_vma.c
>345 int i915_vma_wait_for_bind(struct i915_vma *vma)
>346 {
>347 int err = 0;
>348
>349 if (rcu_access_pointer(vma->active.excl.fence)) {
>350 struct dma_fence *fence;
>351
>352 rcu_read_lock();
>353 fence =
> dma_fence_get_rcu_safe(>active.excl.fence);
>354 rcu_read_unlock();
>355 if (fence) {
>356 err = dma_fence_wait(fence,
> MAX_SCHEDULE_TIMEOUT);
>
>
> The dma_fence_wait() takes a bool, not a timeout value.
Fortuitously becomes the same thing, an indefinite interruptible wait.
Accidentally fixed in a queued patch.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [bug report] drm/i915: Use the async worker to avoid reclaim tainting the ggtt->mutex
Hello Chris Wilson,
The patch e3793468b466: "drm/i915: Use the async worker to avoid
reclaim tainting the ggtt->mutex" from Jan 30, 2020, leads to the
following static checker warning:
drivers/gpu/drm/i915/i915_vma.c:356 i915_vma_wait_for_bind()
warn: 's64max' cannot fit into 'bool'
drivers/gpu/drm/i915/i915_vma.c
345 int i915_vma_wait_for_bind(struct i915_vma *vma)
346 {
347 int err = 0;
348
349 if (rcu_access_pointer(vma->active.excl.fence)) {
350 struct dma_fence *fence;
351
352 rcu_read_lock();
353 fence = dma_fence_get_rcu_safe(>active.excl.fence);
354 rcu_read_unlock();
355 if (fence) {
356 err = dma_fence_wait(fence,
MAX_SCHEDULE_TIMEOUT);
The dma_fence_wait() takes a bool, not a timeout value.
357 dma_fence_put(fence);
358 }
359 }
360
361 return err;
362 }
regards,
dan carpenter
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Warn if the FBC is still writing to stolen on removal
Quoting Jani Nikula (2020-05-07 09:49:15)
> On Sun, 03 May 2020, Chris Wilson wrote:
> > If the FBC is still writing into stolen, it will overwrite any future
> > users of that stolen region. Check before release.
> >
> > References: https://gitlab.freedesktop.org/drm/intel/-/issues/1635
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/display/intel_fbc.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index c6afa10e814c..37244ed92ae4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -540,6 +540,9 @@ static void __intel_fbc_cleanup_cfb(struct
> > drm_i915_private *dev_priv)
> > {
> > struct intel_fbc *fbc = _priv->fbc;
> >
> > + if (WARN_ON(intel_fbc_hw_is_active(dev_priv)))
>
> drm_WARN_ON() ;)
I'm hoping that by the time you get around to it, we will have a drm-tip
idle run which will tell us whether or not this is barking up the wrong
tree.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Warn if the FBC is still writing to stolen on removal
On Sun, 03 May 2020, Chris Wilson wrote:
> If the FBC is still writing into stolen, it will overwrite any future
> users of that stolen region. Check before release.
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/1635
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index c6afa10e814c..37244ed92ae4 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -540,6 +540,9 @@ static void __intel_fbc_cleanup_cfb(struct
> drm_i915_private *dev_priv)
> {
> struct intel_fbc *fbc = _priv->fbc;
>
> + if (WARN_ON(intel_fbc_hw_is_active(dev_priv)))
drm_WARN_ON() ;)
> + return;
> +
> if (!drm_mm_node_allocated(>compressed_fb))
> return;
--
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 v3 2/3] drm/i915: Stash hpd status bits under dev_priv
On Thu, May 07, 2020 at 09:53:13AM +0300, Ville Syrjälä wrote:
> On Wed, May 06, 2020 at 07:03:41PM +0300, Imre Deak wrote:
> > On Wed, Mar 11, 2020 at 05:54:21PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Instead of constnantly having to figure out which hpd status bit
> > > array to use let's store them under dev_priv.
> > >
> > > Should perhaps take this further and stash even more stuff to
> > > make the hpd handling more abstract yet.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > > drivers/gpu/drm/i915/i915_irq.c | 198 ++--
> > > 2 files changed, 111 insertions(+), 89 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 19195bde4921..b5afbabf4c3b 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -149,6 +149,8 @@ enum hpd_pin {
> > > struct i915_hotplug {
> > > struct delayed_work hotplug_work;
> > >
> > > + const u32 *hpd, *pch_hpd;
> > > +
> > > struct {
> > > unsigned long last_jiffies;
> > > int count;
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index 9f0653cf0510..b95d952bd47d 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -124,7 +124,6 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
> > > [HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS,
> > > };
> > >
> > > -/* BXT hpd list */
> > > static const u32 hpd_bxt[HPD_NUM_PINS] = {
> > > [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
> > > [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
> > > @@ -168,6 +167,44 @@ static const u32 hpd_tgp[HPD_NUM_PINS] = {
> > > [HPD_PORT_I] = SDE_TC_HOTPLUG_ICP(PORT_TC6),
> > > };
> > >
> > > +static void intel_hpd_init_pins(struct drm_i915_private *dev_priv)
> > > +{
> > > + struct i915_hotplug *hpd = _priv->hotplug;
> > > +
> > > + if (HAS_GMCH(dev_priv)) {
> > > + if (IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
> > > + IS_CHERRYVIEW(dev_priv))
> > > + hpd->hpd = hpd_status_g4x;
> > > + else
> > > + hpd->hpd = hpd_status_i915;
> > > + return;
> > > + }
> > > +
> > > + if (INTEL_GEN(dev_priv) >= 12)
> > > + hpd->hpd = hpd_gen12;
> > > + else if (INTEL_GEN(dev_priv) >= 11)
> > > + hpd->hpd = hpd_gen11;
> > > + else if (IS_GEN9_LP(dev_priv))
> > > + hpd->hpd = hpd_bxt;
> > > + else if (INTEL_GEN(dev_priv) >= 8)
> > > + hpd->hpd = hpd_bdw;
> > > + else if (INTEL_GEN(dev_priv) >= 7)
> > > + hpd->hpd = hpd_ivb;
> > > + else
> > > + hpd->hpd = hpd_ilk;
> > > +
> > > + if (HAS_PCH_TGP(dev_priv) || HAS_PCH_JSP(dev_priv))
> > > + hpd->pch_hpd = hpd_tgp;
> > > + else if (HAS_PCH_ICP(dev_priv) || HAS_PCH_MCC(dev_priv))
> > > + hpd->pch_hpd = hpd_icp;
> > > + else if (HAS_PCH_SPT(dev_priv))
> >
> > What about CNP?
>
> Argh. We have too many of these. Do we even need all of them?
Not sure, but atm it's special cased in a few places (ddc/hpd setup, and
rawclk readout). Here it's just the same as SPT.
> > > + hpd->pch_hpd = hpd_spt;
> > > + else if (HAS_PCH_LPT(dev_priv) || HAS_PCH_CPT(dev_priv))
> > > + hpd->pch_hpd = hpd_cpt;
> > > + else if (HAS_PCH_IBX(dev_priv))
> > > + hpd->pch_hpd = hpd_ibx;
> >
> > Can we add MISSING_CASE for PCH platforms?
>
> else if (HAS_PCH_SPLIT())
> MISSING_CASE(INTEL_PCH_TYPE())
> ?
Yes, with && !PCH_NOP.
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Mark concurrent submissions with a weak-dependency (rev2)
== Series Details == Series: series starting with [1/3] drm/i915: Mark concurrent submissions with a weak-dependency (rev2) URL : https://patchwork.freedesktop.org/series/77007/ State : success == Summary == CI Bug Log - changes from CI_DRM_8441 -> Patchwork_17597 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17597/index.html Changes --- No changes found Participating hosts (49 -> 43) -- Additional (1): fi-kbl-7560u Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8441 -> Patchwork_17597 CI-20190529: 20190529 CI_DRM_8441: 6c0ee41a7c3201ef2a89800234803a95f65989be @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5637: fdc33f7e1adc5bb6a1ba88b6233aaf224174d75a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17597: b9060fd22920f225e0556c7e171f9630ac1056b7 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b9060fd22920 drm/i915: Ignore submit-fences on the same timeline b860188a0dfb drm/i915/gt: Suppress internal I915_PRIORITY_WAIT for timeslicing c4a391901bbf drm/i915: Mark concurrent submissions with a weak-dependency == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17597/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Treat weak-dependencies as bidirectional when applying priorities
Clients may use a submit-fence as bidirectional bond between two or more
co-operating requests, and so if we bump the priority of one, we wish to
bump the priority of the set.
Testcase: igt/gem_exec_fence/submitN
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 6e2d4190099f..1c33973dbd20 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -291,6 +291,19 @@ static void __i915_schedule(struct i915_sched_node *node,
if (prio > READ_ONCE(p->signaler->attr.priority))
list_move_tail(>dfs_link, );
}
+
+ /*
+* A weak dependency is used for submit-fence, which while
+* not strongly coupled, we do need to treat as a coordinated
+* set of co-operating requests that need to be run
+* concurrently. So if one request of that set receives a
+* priority boost, they all receive a priority boost.
+*/
+ list_for_each_entry(p, >waiters_list, wait_link) {
+ if (p->flags & I915_DEPENDENCY_WEAK &&
+ prio > READ_ONCE(p->waiter->attr.priority))
+ list_move_tail(>dfs_link, );
+ }
}
/*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
