[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/23] drm/i915: Cache the error string
== Series Details == Series: series starting with [01/23] drm/i915: Cache the error string URL : https://patchwork.freedesktop.org/series/48362/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4682_full -> Patchwork_9965_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9965_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9965_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_9965_full: === IGT changes === Warnings igt@kms_universal_plane@universal-plane-pipe-a-sanity: shard-snb: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_9965_full that come from known issues: === IGT changes === Issues hit igt@gem_mocs_settings@mocs-rc6-bsd1: shard-snb: NOTRUN -> INCOMPLETE (fdo#105411) igt@gem_softpin@noreloc-s3: shard-snb: PASS -> DMESG-WARN (fdo#102365) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_suspend@shrink: shard-snb: INCOMPLETE (fdo#106886, fdo#105411) -> PASS fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4682 -> Patchwork_9965 CI_DRM_4682: 1d6d9c1a324bb0d68b1901006bb9982438a725d0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4604: 2a5777f8a694f1f8edcf021afb1ef36192c6762d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9965: 147bda82fa16c6c99607c4a734944a5bb69d7beb @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9965/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915/skl+: Decode memory bandwidth and parameters
On Thu, Jul 26, 2018 at 07:44:07PM +0530, Mahesh Kumar wrote:
> This patch adds support to decode system memory bandwidth and other
> parameters for skylake and Gen9+ platforms, which will be used for
> arbitrated display memory bandwidth calculation in GEN9 based
> platforms and WM latency level-0 Work-around calculation on GEN9+.
>
> Changes Since V1:
> - s/memdev_info/dram_info
> - create a struct to hold channel info
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/i915_drv.c | 131
> ++--
> drivers/gpu/drm/i915/i915_drv.h | 7 +++
> drivers/gpu/drm/i915/i915_reg.h | 21 +++
> 3 files changed, 155 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 16629601c9f4..ddf6bf9b500a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1070,6 +1070,118 @@ static void intel_sanitize_options(struct
> drm_i915_private *dev_priv)
> intel_gvt_sanitize_options(dev_priv);
> }
>
> +static int
> +skl_dram_get_channel_info(struct dram_channel_info *ch, u32 val)
> +{
> + u8 l_rank, s_rank;
> + u8 l_size, s_size;
> + u8 l_width, s_width;
> + enum dram_rank rank;
> +
> + if (!val)
> + return -1;
-SOMEERRNO?
> +
> + l_size = (val >> SKL_DRAM_SIZE_L_SHIFT) & SKL_DRAM_SIZE_MASK;
> + s_size = (val >> SKL_DRAM_SIZE_S_SHIFT) & SKL_DRAM_SIZE_MASK;
> + l_width = (val >> SKL_DRAM_WIDTH_L_SHIFT) & SKL_DRAM_WIDTH_MASK;
> + s_width = (val >> SKL_DRAM_WIDTH_S_SHIFT) & SKL_DRAM_WIDTH_MASK;
> + l_rank = (val >> SKL_DRAM_RANK_L_SHIFT) & SKL_DRAM_RANK_MASK;
> + s_rank = (val >> SKL_DRAM_RANK_S_SHIFT) & SKL_DRAM_RANK_MASK;
> +
> + if (l_size == 0 && s_size == 0)
> + return -1;
ditto
> +
> + DRM_DEBUG_KMS("(size:width:rank) L(%dGB:X%d:%s) S(%dGB:X%d:%s)\n",
> + l_size, (1 << l_width) * 8, l_rank ? "dual" : "single",
> + s_size, (1 << s_width) * 8, s_rank ? "dual" : "single");
> +
> + if (l_rank == SKL_DRAM_RANK_DUAL || s_rank == SKL_DRAM_RANK_DUAL)
> + rank = I915_DRAM_RANK_DUAL;
> + else if ((l_size && l_rank == SKL_DRAM_RANK_SINGLE) &&
> + (s_size && s_rank == SKL_DRAM_RANK_SINGLE))
> + rank = I915_DRAM_RANK_DUAL;
> + else
> + rank = I915_DRAM_RANK_SINGLE;
> +
> + ch->l_info.size = l_size;
> + ch->s_info.size = s_size;
> + ch->l_info.width = l_width;
> + ch->s_info.width = s_width;
> + ch->l_info.rank = l_rank;
> + ch->s_info.rank = s_rank;
> + ch->rank = rank;
could we do this directly without intermediates? not clear if we change
in the middle after printing...
> +
> + return 0;
> +}
> +
> +static int
> +skl_dram_get_channels_info(struct drm_i915_private *dev_priv)
> +{
> + struct dram_info *dram_info = _priv->dram_info;
> + struct dram_channel_info ch0, ch1;
> + u32 val;
> + int ret;
> +
> + val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> + ret = skl_dram_get_channel_info(, val);
> + if (ret == 0)
> + dram_info->num_channels++;
> +
> + val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> + ret = skl_dram_get_channel_info(, val);
> + if (ret == 0)
> + dram_info->num_channels++;
> +
> + if (dram_info->num_channels == 0) {
> + DRM_INFO("Number of memory channels is zero\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * If any of the channel is single rank channel, worst case output
> + * will be same as if single rank memory, so consider single rank
> + * memory.
> + */
> + if (ch0.rank == I915_DRAM_RANK_SINGLE ||
> + ch1.rank == I915_DRAM_RANK_SINGLE)
> + dram_info->rank = I915_DRAM_RANK_SINGLE;
> + else
> + dram_info->rank = max(ch0.rank, ch1.rank);
> +
> + if (dram_info->rank == I915_DRAM_RANK_INVALID) {
> + DRM_INFO("couldn't get memory rank information\n");
> + return -EINVAL;
> + }
> + return 0;
> +}
> +
> +static int
> +skl_get_dram_info(struct drm_i915_private *dev_priv)
> +{
> + struct dram_info *dram_info = _priv->dram_info;
> + u32 mem_freq_khz, val;
> + int ret;
> +
> + ret = skl_dram_get_channels_info(dev_priv);
> + if (ret)
> + return ret;
> +
> + val = I915_READ(SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU);
> + mem_freq_khz = DIV_ROUND_UP((val & SKL_REQ_DATA_MASK) *
> + SKL_MEMORY_FREQ_MULTIPLIER_HZ, 1000);
> +
> + dram_info->bandwidth_kbps = dram_info->num_channels *
> + mem_freq_khz * 8;
> +
> + if (dram_info->bandwidth_kbps == 0) {
> + DRM_INFO("Couldn't get system memory bandwidth\n");
> + return -EINVAL;
> + }
> +
> + dram_info->valid = true;
> + return 0;
> +}
> +
> static
Re: [Intel-gfx] [PATCH 1/5] drm/i915/bxt: Decode memory bandwidth and parameters
On Thu, Jul 26, 2018 at 07:44:06PM +0530, Mahesh Kumar wrote:
> This patch adds support to decode system memory bandwidth and other
> parameters for broxton platform, which will be used for arbitrated
> display memory bandwidth calculation in GEN9 based platforms and
> WM latency level-0 Work-around calculation on GEN9+ platforms.
>
> Changes since V1:
> - s/memdev_info/dram_info
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/i915_drv.c | 116
>
> drivers/gpu/drm/i915/i915_drv.h | 11
> drivers/gpu/drm/i915/i915_reg.h | 30 +++
> 3 files changed, 157 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 18a45e7a3d7c..16629601c9f4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1070,6 +1070,116 @@ static void intel_sanitize_options(struct
> drm_i915_private *dev_priv)
> intel_gvt_sanitize_options(dev_priv);
> }
>
> +static int
> +bxt_get_dram_info(struct drm_i915_private *dev_priv)
> +{
> + struct dram_info *dram_info = _priv->dram_info;
> + u32 dram_channels;
> + u32 mem_freq_khz, val;
> + u8 num_active_channels;
> + int i;
> +
> + val = I915_READ(BXT_P_CR_MC_BIOS_REQ_0_0_0);
> + mem_freq_khz = DIV_ROUND_UP((val & BXT_REQ_DATA_MASK) *
> + BXT_MEMORY_FREQ_MULTIPLIER_HZ, 1000);
> +
> + dram_channels = (val >> BXT_DRAM_CHANNEL_ACTIVE_SHIFT) &
> + BXT_DRAM_CHANNEL_ACTIVE_MASK;
> + num_active_channels = hweight32(dram_channels);
> +
> + /* Each active bit represents 4-byte channel */
> + dram_info->bandwidth_kbps = (mem_freq_khz * num_active_channels * 4);
> +
> + if (dram_info->bandwidth_kbps == 0) {
> + DRM_INFO("Couldn't get system memory bandwidth\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * Now read each DUNIT8/9/10/11 to check the rank of each dimms.
> + */
> + for (i = BXT_D_CR_DRP0_DUNIT_START; i <= BXT_D_CR_DRP0_DUNIT_END; i++) {
> + u8 rank, size, width;
> + enum dram_rank ch_rank;
> +
> + val = I915_READ(BXT_D_CR_DRP0_DUNIT(i));
> + if (val == 0x)
why? any spec or any comment here?
> + continue;
> +
> + dram_info->num_channels++;
> + rank = val & BXT_DRAM_RANK_MASK;
> + width = (val >> BXT_DRAM_WIDTH_SHIFT) & BXT_DRAM_WIDTH_MASK;
> + size = (val >> BXT_DRAM_SIZE_SHIFT) & BXT_DRAM_SIZE_MASK;
> + if (rank == BXT_DRAM_RANK_SINGLE)
> + ch_rank = I915_DRAM_RANK_SINGLE;
> + else if (rank == BXT_DRAM_RANK_DUAL)
> + ch_rank = I915_DRAM_RANK_DUAL;
> + else
> + ch_rank = I915_DRAM_RANK_INVALID;
> +
> + if (size == BXT_DRAM_SIZE_4GB)
> + size = 4;
> + else if (size == BXT_DRAM_SIZE_6GB)
> + size = 6;
> + else if (size == BXT_DRAM_SIZE_8GB)
> + size = 8;
> + else if (size == BXT_DRAM_SIZE_12GB)
> + size = 12;
> + else if (size == BXT_DRAM_SIZE_16GB)
> + size = 16;
> + else
> + size = 0;
switch case? or define these BXT_DRAM_SIZE with enums?
> +
> + width = (1 << width) * 8;
> + DRM_DEBUG_KMS("dram size:%dGB width:X%d rank:%s\n", size,
> + width, rank == BXT_DRAM_RANK_SINGLE ? "single" :
> + rank == BXT_DRAM_RANK_DUAL ? "dual" : "unknown");
> +
> + /*
> + * If any of the channel is single rank channel,
> + * worst case output will be same as if single rank
> + * memory, so consider single rank memory.
> + */
> + if (dram_info->rank == I915_DRAM_RANK_INVALID)
> + dram_info->rank = ch_rank;
> + else if (ch_rank == I915_DRAM_RANK_SINGLE)
> + dram_info->rank = I915_DRAM_RANK_SINGLE;
> + }
> +
> + if (dram_info->rank == I915_DRAM_RANK_INVALID) {
> + DRM_INFO("couldn't get memory rank information\n");
> + return -EINVAL;
> + }
> +
> + dram_info->valid = true;
> + return 0;
> +}
> +
> +static void
> +intel_get_dram_info(struct drm_i915_private *dev_priv)
> +{
> + struct dram_info *dram_info = _priv->dram_info;
> + int ret;
> +
> + dram_info->valid = false;
> + dram_info->rank = I915_DRAM_RANK_INVALID;
> + dram_info->bandwidth_kbps = 0;
> + dram_info->num_channels = 0;
> +
> + if (!IS_BROXTON(dev_priv))
> + return;
I think this should be checked earlier and probably with some
macro NEED_EDRAM_INFO(dev_priv)... to prepare for other platforms
> +
> + ret = bxt_get_dram_info(dev_priv);
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/23] drm/i915: Cache the error string
== Series Details ==
Series: series starting with [01/23] drm/i915: Cache the error string
URL : https://patchwork.freedesktop.org/series/48362/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4682 -> Patchwork_9965 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48362/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9965:
=== IGT changes ===
Warnings
{igt@pm_rpm@module-reload}:
fi-cnl-psr: WARN -> FAIL
fi-hsw-4770r: FAIL -> WARN
fi-skl-6700k2: FAIL -> WARN
== Known issues ==
Here are the changes found in Patchwork_9965 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
igt@gem_exec_suspend@basic-s3:
{fi-skl-caroline}: NOTRUN -> INCOMPLETE (fdo#107556, fdo#104108)
Possible fixes
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
{igt@kms_psr@primary_mmap_gtt}:
fi-cnl-psr: DMESG-WARN (fdo#107372) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556
== Participating hosts (51 -> 47) ==
Additional (1): fi-skl-caroline
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4682 -> Patchwork_9965
CI_DRM_4682: 1d6d9c1a324bb0d68b1901006bb9982438a725d0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4604: 2a5777f8a694f1f8edcf021afb1ef36192c6762d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9965: 147bda82fa16c6c99607c4a734944a5bb69d7beb @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
147bda82fa16 drm/i915: Enable runtime-pm debugging by default for CI
39971cb567f5 drm/i915: Mark up Ironlake ips with rpm wakerefs
5803b4691f5e drm/i915: Complain if hsw_get_pipe_config acquires the same power
well twice
7628024c7252 drm/i915/dp: Markup pps lock power well
28d161441228 drm/i915: Track the wakeref used to initialise display power
domains
09683b7d42ed drm/i915: Markup paired operations on display power domains
cc5070256ace drm/i915: Syntatic sugar for using intel_runtime_pm
53d707353038 drm/i915: Markup paired operations on wakerefs
06c35ac73fff drm/i915: Track all held rpm wakerefs
f701f7a446fc drm/i915: Attach the pci match data to the device upon creation
41987cac178b drm/i915/execlists: Use direct submission to restart HW after reset
3e9a52f60a87 drm/i915/execlists: Include reset depth in traces
0471fde14d4f drm/i915/execlists: Reset queue_priority on cancellation
0b779c883955 drm/i915/execlists: Assert the queue is non-empty on unsubmitting
9a5b5d34b0e7 drm/i915: Remove debugfs/i915_ppgtt_info
b80a0049bd90 drm/i915: Report the number of closed vma held by each context in
debugfs
961fcf08085e drm/i915/execlists: Onion unwind for logical_ring_init() failure
e3c5fe224683 drm/i915/execlists: Use coherent writes into the context image
1994f89c4bee drm/i915/execlists: Delay updating ring register state after resume
aa77959dacd7 drm/i915/selftests: Basic stress test for rapid context switching
59a7f61abead drm/i915: Missed interrupt simulation is no more, tell the world
07069ce0121b drm/i915/execlists: Avoid kicking priority on the current context
31a8de99a658 drm/i915: Cache the error string
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9965/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
On Thu, Aug 16, 2018 at 11:51:07PM +0200, Fredrik Schön wrote:
> tor 2018-08-16 klockan 14:43 -0700 skrev Rodrigo Vivi:
> > On Thu, Aug 16, 2018 at 11:35:26PM +0200, fredriksc...@gmail.com
> > wrote:
> > > tor 2018-08-16 klockan 11:23 -0700 skrev Rodrigo Vivi:
> > > > On Thu, Aug 16, 2018 at 10:36:43AM +0200, Fredrik Schön wrote:
> > > > > Shashank,
> > > > >
> > > > > Den tors 16 aug. 2018 kl 10:15 skrev Sharma, Shashank
> > > > > :
> > > > > >
> > > > > > Hey Chris,
> > > > > >
> > > > > >
> > > > > > On 8/16/2018 1:13 PM, Chris Wilson wrote:
> > > > > > > Quoting Sharma, Shashank (2018-08-16 08:33:36)
> > > > > > > > Regards
> > > > > > > >
> > > > > > > > Shashank
> > > > > > > >
> > > > > > > >
> > > > > > > > On 8/16/2018 12:47 PM, Jani Nikula wrote:
> > > > > > > > > On Wed, 15 Aug 2018, Rodrigo Vivi <
> > > > > > > > > rodrigo.v...@intel.com>
> > > > > > > > > wrote:
> > > > > > > > > > On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo
> > > > > > > > > > Vivi
> > > > > > > > > > wrote:
> > > > > > > > > > > On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik
> > > > > > > > > > > Schön
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > First of all we need to fix the commit subject:
> > > > > > > > > > >
> > > > > > > > > > > drm/i915: Increase LSPCON timeout
> > > > > > > > > > >
> > > > > > > > > > > (this can be done when merging, no need to resend)
> > > > > > > > > > >
> > > > > > > > > > > > 100 ms is not enough time for the LSPCON adapter
> > > > > > > > > > > > on
> > > > > > > > > > > > Intel NUC devices to
> > > > > > > > > > > > settle. This causes dropped display modes at
> > > > > > > > > > > > driver
> > > > > > > > > > > > initialisation.
> > > > > > > > > > > >
> > > > > > > > > > > > Increase timeout to 1000 ms.
> > > > > > > > > > > >
> > > > > > > > > > > > Fixes:
> > > > > > > > > > > >
> https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> > > > > > > > > > >
> > > > > > > > > > > Missusage of "Fixes:" tag, please read
> > > > > > > > > > >
> > > > > > > > > > >
> > >
> > >
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
> > > > > > > > > > >
> > > > > > > > > > > But also no need for resending... could be fixed
> > > > > > > > > > > when
> > > > > > > > > > > merging
> > > > > > > > > > >
> > > > > > > > > > > The right one would be:
> > > > > > > > > > >
> > > > > > > > > > > Bugzilla:
> > > > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> > > > > > > > > > > Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for
> > > > > > > > > > > expected LSPCON mode to settle")
> > > > > > > > > > > Cc: Shashank Sharma
> > > > > > > > > > > Cc: Imre Deak
> > > > > > > > > > > Cc: Jani Nikula
> > > > > > > > > > > Cc: # v4.11+
> > > > > > > > > > >
> > > > > > > > > > > Since initial 100 seemed to be empirical and this
> > > > > > > > > > > increase seems to
> > > > > > > > > > > help other cases I'm in favor of this move so
> > > > > > > > > > >
> > > > > > > > > > > Reviewed-by: Rodrigo Vivi
> > > > > > > > > > >
> > > > > > > > > > > However I will wait a bit before merging it
> > > > > > > > > > > so Imre, Shashank, and/or Jani can take a look
> > > > > > > > > > > here...
> > > > > > > > > >
> > > > > > > > > > now, really cc'ing them...
> > > > > > > > >
> > > > > > > > > Shashank? Does this slow down non-LSPCON paths?
> > > > > > > >
> > > > > > > > This will slow down the lspcon probing and resume part,
> > > > > > > > but
> > > > > > > > both of them
> > > > > > > > happen only when LSPCON device is found. So to answer
> > > > > > > > your
> > > > > > > > question,
> > > > > > > > this will not slow down the non-lspcon path, but will
> > > > > > > > slow
> > > > > > > > down the
> > > > > > > > LSPCON connector resume and probe time. but I would
> > > > > > > > recommend, instead
> > > > > > > > of increasing it to 1000 ms in a single shot, we might
> > > > > > > > want
> > > > > > > > to gradually
> > > > > > > > pick this up, on a wake-and-check way.
> > > > > > >
> > > > > > > wait_for() checks every [10us, 1ms] until the condition is
> > > > > > > met,
> > > > > > > or it
> > > > > > > times out. So, so long as we don't enter this path for
> > > > > > > !LPSCON
> > > > > > > where we
> > > > > > > know that it will timeout, the wait_for() will only take as
> > > > > > > long as is
> > > > > > > required for the connector to settle.
> > > > > >
> > > > > > We wont hit !LSPCON timeout case here, as we have already
> > > > > > read
> > > > > > the
> > > > > > dongle signature successfully by now. But I was thinking
> > > > > > that,
> > > > > > if the
> > > > > > spec recommends max wait time as 100ms (which is of course
> > > > > > doesn't seem
> > > > > > enough), if we can't detect i2c-over-aux after first 500ms, I
> > > > > > guess we
> > > > > > wont be able to do that in next 500ms too. So is it really ok
> > > > > > to
> > > > > > wait
> > > > > > this long in the
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
tor 2018-08-16 klockan 14:43 -0700 skrev Rodrigo Vivi:
> On Thu, Aug 16, 2018 at 11:35:26PM +0200, fredriksc...@gmail.com
> wrote:
> > tor 2018-08-16 klockan 11:23 -0700 skrev Rodrigo Vivi:
> > > On Thu, Aug 16, 2018 at 10:36:43AM +0200, Fredrik Schön wrote:
> > > > Shashank,
> > > >
> > > > Den tors 16 aug. 2018 kl 10:15 skrev Sharma, Shashank
> > > > :
> > > > >
> > > > > Hey Chris,
> > > > >
> > > > >
> > > > > On 8/16/2018 1:13 PM, Chris Wilson wrote:
> > > > > > Quoting Sharma, Shashank (2018-08-16 08:33:36)
> > > > > > > Regards
> > > > > > >
> > > > > > > Shashank
> > > > > > >
> > > > > > >
> > > > > > > On 8/16/2018 12:47 PM, Jani Nikula wrote:
> > > > > > > > On Wed, 15 Aug 2018, Rodrigo Vivi <
> > > > > > > > rodrigo.v...@intel.com>
> > > > > > > > wrote:
> > > > > > > > > On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo
> > > > > > > > > Vivi
> > > > > > > > > wrote:
> > > > > > > > > > On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik
> > > > > > > > > > Schön
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > First of all we need to fix the commit subject:
> > > > > > > > > >
> > > > > > > > > > drm/i915: Increase LSPCON timeout
> > > > > > > > > >
> > > > > > > > > > (this can be done when merging, no need to resend)
> > > > > > > > > >
> > > > > > > > > > > 100 ms is not enough time for the LSPCON adapter
> > > > > > > > > > > on
> > > > > > > > > > > Intel NUC devices to
> > > > > > > > > > > settle. This causes dropped display modes at
> > > > > > > > > > > driver
> > > > > > > > > > > initialisation.
> > > > > > > > > > >
> > > > > > > > > > > Increase timeout to 1000 ms.
> > > > > > > > > > >
> > > > > > > > > > > Fixes:
> > > > > > > > > > >
https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> > > > > > > > > >
> > > > > > > > > > Missusage of "Fixes:" tag, please read
> > > > > > > > > >
> > > > > > > > > >
> >
> >
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
> > > > > > > > > >
> > > > > > > > > > But also no need for resending... could be fixed
> > > > > > > > > > when
> > > > > > > > > > merging
> > > > > > > > > >
> > > > > > > > > > The right one would be:
> > > > > > > > > >
> > > > > > > > > > Bugzilla:
> > > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> > > > > > > > > > Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for
> > > > > > > > > > expected LSPCON mode to settle")
> > > > > > > > > > Cc: Shashank Sharma
> > > > > > > > > > Cc: Imre Deak
> > > > > > > > > > Cc: Jani Nikula
> > > > > > > > > > Cc: # v4.11+
> > > > > > > > > >
> > > > > > > > > > Since initial 100 seemed to be empirical and this
> > > > > > > > > > increase seems to
> > > > > > > > > > help other cases I'm in favor of this move so
> > > > > > > > > >
> > > > > > > > > > Reviewed-by: Rodrigo Vivi
> > > > > > > > > >
> > > > > > > > > > However I will wait a bit before merging it
> > > > > > > > > > so Imre, Shashank, and/or Jani can take a look
> > > > > > > > > > here...
> > > > > > > > >
> > > > > > > > > now, really cc'ing them...
> > > > > > > >
> > > > > > > > Shashank? Does this slow down non-LSPCON paths?
> > > > > > >
> > > > > > > This will slow down the lspcon probing and resume part,
> > > > > > > but
> > > > > > > both of them
> > > > > > > happen only when LSPCON device is found. So to answer
> > > > > > > your
> > > > > > > question,
> > > > > > > this will not slow down the non-lspcon path, but will
> > > > > > > slow
> > > > > > > down the
> > > > > > > LSPCON connector resume and probe time. but I would
> > > > > > > recommend, instead
> > > > > > > of increasing it to 1000 ms in a single shot, we might
> > > > > > > want
> > > > > > > to gradually
> > > > > > > pick this up, on a wake-and-check way.
> > > > > >
> > > > > > wait_for() checks every [10us, 1ms] until the condition is
> > > > > > met,
> > > > > > or it
> > > > > > times out. So, so long as we don't enter this path for
> > > > > > !LPSCON
> > > > > > where we
> > > > > > know that it will timeout, the wait_for() will only take as
> > > > > > long as is
> > > > > > required for the connector to settle.
> > > > >
> > > > > We wont hit !LSPCON timeout case here, as we have already
> > > > > read
> > > > > the
> > > > > dongle signature successfully by now. But I was thinking
> > > > > that,
> > > > > if the
> > > > > spec recommends max wait time as 100ms (which is of course
> > > > > doesn't seem
> > > > > enough), if we can't detect i2c-over-aux after first 500ms, I
> > > > > guess we
> > > > > wont be able to do that in next 500ms too. So is it really ok
> > > > > to
> > > > > wait
> > > > > this long in the resume sequence ?
> > > > >
> > > > > I guess Fredrik can provide some inputs here on if there are
> > > > > some
> > > > > experiments behind this number of 1000ms, or this is just a
> > > > > safe
> > > > > bet ?
> > > > > >
> > > >
> > > > My first patch attempt - which is attached to the Redhat and
> > > > FDO
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/23] drm/i915: Cache the error string
== Series Details == Series: series starting with [01/23] drm/i915: Cache the error string URL : https://patchwork.freedesktop.org/series/48362/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Cache the error string +drivers/gpu/drm/i915/i915_gpu_error.c:820:25: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_gpu_error.c:884:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gpu_error.c:884:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_sysfs.c:531:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_sysfs.c:531:23: warning: expression using sizeof(void) Commit: drm/i915/execlists: Avoid kicking priority on the current context Okay! Commit: drm/i915: Missed interrupt simulation is no more, tell the world Okay! Commit: drm/i915/selftests: Basic stress test for rapid context switching +./include/linux/slab.h:631:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/slab.h:631:13: warning: call with no type! Commit: drm/i915/execlists: Delay updating ring register state after resume Okay! Commit: drm/i915/execlists: Use coherent writes into the context image -drivers/gpu/drm/i915/selftests/../i915_drv.h:3685:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3691:16: warning: expression using sizeof(void) Commit: drm/i915/execlists: Onion unwind for logical_ring_init() failure Okay! Commit: drm/i915: Report the number of closed vma held by each context in debugfs Okay! Commit: drm/i915: Remove debugfs/i915_ppgtt_info Okay! Commit: drm/i915/execlists: Assert the queue is non-empty on unsubmitting Okay! Commit: drm/i915/execlists: Reset queue_priority on cancellation Okay! Commit: drm/i915/execlists: Include reset depth in traces Okay! Commit: drm/i915/execlists: Use direct submission to restart HW after reset Okay! Commit: drm/i915: Attach the pci match data to the device upon creation Okay! Commit: drm/i915: Track all held rpm wakerefs + -drivers/gpu/drm/i915/selftests/../i915_drv.h:3691:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3698:16: warning: expression using sizeof(void) +Error in reading or end of file. Commit: drm/i915: Markup paired operations on wakerefs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3698:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3702:16: warning: expression using sizeof(void) Commit: drm/i915: Syntatic sugar for using intel_runtime_pm Okay! Commit: drm/i915: Markup paired operations on display power domains -drivers/gpu/drm/i915/selftests/../i915_drv.h:3702:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3704:16: warning: expression using sizeof(void) Commit: drm/i915: Track the wakeref used to initialise display power domains -drivers/gpu/drm/i915/selftests/../i915_drv.h:3704:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3706:16: warning: expression using sizeof(void) Commit: drm/i915/dp: Markup pps lock power well Okay! Commit: drm/i915: Complain if hsw_get_pipe_config acquires the same power well twice Okay! Commit: drm/i915: Mark up Ironlake ips with rpm wakerefs Okay! Commit: drm/i915: Enable runtime-pm debugging by default for CI - +drivers/gpu/drm/i915/gvt/gtt.c:757:9:expected void [noderef] **slot +drivers/gpu/drm/i915/gvt/gtt.c:757:9:expected void **slot +drivers/gpu/drm/i915/gvt/gtt.c:757:9:expected void **slot +drivers/gpu/drm/i915/gvt/gtt.c:757:9:expected void **slot +drivers/gpu/drm/i915/gvt/gtt.c:757:9:got void [noderef] ** +drivers/gpu/drm/i915/gvt/gtt.c:757:9:got void [noderef] ** +drivers/gpu/drm/i915/gvt/gtt.c:757:9:got void [noderef] ** +drivers/gpu/drm/i915/gvt/gtt.c:757:9:got void **slot +drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gvt/gtt.c:758:45:expected void [noderef] **slot +drivers/gpu/drm/i915/gvt/gtt.c:758:45:got void **slot +drivers/gpu/drm/i915/gvt/gtt.c:758:45: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/gvt/mmio.c:253:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/gvt/mmio.c:254:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gvt/vgpu.c:196:48: warning: expression using sizeof(void)
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
On Thu, Aug 16, 2018 at 11:35:26PM +0200, fredriksc...@gmail.com wrote:
> tor 2018-08-16 klockan 11:23 -0700 skrev Rodrigo Vivi:
> > On Thu, Aug 16, 2018 at 10:36:43AM +0200, Fredrik Schön wrote:
> > > Shashank,
> > >
> > > Den tors 16 aug. 2018 kl 10:15 skrev Sharma, Shashank
> > > :
> > > >
> > > > Hey Chris,
> > > >
> > > >
> > > > On 8/16/2018 1:13 PM, Chris Wilson wrote:
> > > > > Quoting Sharma, Shashank (2018-08-16 08:33:36)
> > > > > > Regards
> > > > > >
> > > > > > Shashank
> > > > > >
> > > > > >
> > > > > > On 8/16/2018 12:47 PM, Jani Nikula wrote:
> > > > > > > On Wed, 15 Aug 2018, Rodrigo Vivi
> > > > > > > wrote:
> > > > > > > > On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi
> > > > > > > > wrote:
> > > > > > > > > On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > First of all we need to fix the commit subject:
> > > > > > > > >
> > > > > > > > > drm/i915: Increase LSPCON timeout
> > > > > > > > >
> > > > > > > > > (this can be done when merging, no need to resend)
> > > > > > > > >
> > > > > > > > > > 100 ms is not enough time for the LSPCON adapter on
> > > > > > > > > > Intel NUC devices to
> > > > > > > > > > settle. This causes dropped display modes at driver
> > > > > > > > > > initialisation.
> > > > > > > > > >
> > > > > > > > > > Increase timeout to 1000 ms.
> > > > > > > > > >
> > > > > > > > > > Fixes:
> > > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> > > > > > > > >
> > > > > > > > > Missusage of "Fixes:" tag, please read
> > > > > > > > >
> > > > > > > > >
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
> > > > > > > > >
> > > > > > > > > But also no need for resending... could be fixed when
> > > > > > > > > merging
> > > > > > > > >
> > > > > > > > > The right one would be:
> > > > > > > > >
> > > > > > > > > Bugzilla:
> > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> > > > > > > > > Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for
> > > > > > > > > expected LSPCON mode to settle")
> > > > > > > > > Cc: Shashank Sharma
> > > > > > > > > Cc: Imre Deak
> > > > > > > > > Cc: Jani Nikula
> > > > > > > > > Cc: # v4.11+
> > > > > > > > >
> > > > > > > > > Since initial 100 seemed to be empirical and this
> > > > > > > > > increase seems to
> > > > > > > > > help other cases I'm in favor of this move so
> > > > > > > > >
> > > > > > > > > Reviewed-by: Rodrigo Vivi
> > > > > > > > >
> > > > > > > > > However I will wait a bit before merging it
> > > > > > > > > so Imre, Shashank, and/or Jani can take a look here...
> > > > > > > >
> > > > > > > > now, really cc'ing them...
> > > > > > >
> > > > > > > Shashank? Does this slow down non-LSPCON paths?
> > > > > >
> > > > > > This will slow down the lspcon probing and resume part, but
> > > > > > both of them
> > > > > > happen only when LSPCON device is found. So to answer your
> > > > > > question,
> > > > > > this will not slow down the non-lspcon path, but will slow
> > > > > > down the
> > > > > > LSPCON connector resume and probe time. but I would
> > > > > > recommend, instead
> > > > > > of increasing it to 1000 ms in a single shot, we might want
> > > > > > to gradually
> > > > > > pick this up, on a wake-and-check way.
> > > > >
> > > > > wait_for() checks every [10us, 1ms] until the condition is met,
> > > > > or it
> > > > > times out. So, so long as we don't enter this path for !LPSCON
> > > > > where we
> > > > > know that it will timeout, the wait_for() will only take as
> > > > > long as is
> > > > > required for the connector to settle.
> > > >
> > > > We wont hit !LSPCON timeout case here, as we have already read
> > > > the
> > > > dongle signature successfully by now. But I was thinking that,
> > > > if the
> > > > spec recommends max wait time as 100ms (which is of course
> > > > doesn't seem
> > > > enough), if we can't detect i2c-over-aux after first 500ms, I
> > > > guess we
> > > > wont be able to do that in next 500ms too. So is it really ok to
> > > > wait
> > > > this long in the resume sequence ?
> > > >
> > > > I guess Fredrik can provide some inputs here on if there are some
> > > > experiments behind this number of 1000ms, or this is just a safe
> > > > bet ?
> > > > >
> > >
> > > My first patch attempt - which is attached to the Redhat and FDO
> > > Bugzilla
> > > bugs - added a retry loop around the original 100 ms timeout. The
> > > retry loop
> > > did trigger, but never more than once in a row in my testing.
> > >
> > > So possibly 200 ms would be a sufficient timeout, but as the
> > > wait_for() loop
> > > terminates early on success I suggested a conservative value of
> > > 1000 ms.
> >
> > Since Shashank mentioned 100us came from some spec, maybe the double
> > is already
> > a conservative value.
> >
> > Since there is the concerns of delaying something when LSPCON fails
> > and we are possibly looping on
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/23] drm/i915: Cache the error string
== Series Details ==
Series: series starting with [01/23] drm/i915: Cache the error string
URL : https://patchwork.freedesktop.org/series/48362/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
31a8de99a658 drm/i915: Cache the error string
07069ce0121b drm/i915/execlists: Avoid kicking priority on the current context
-:49: ERROR:SPACING: space prohibited after that open parenthesis '('
#49: FILE: drivers/gpu/drm/i915/intel_guc_submission.c:767:
+ if ( __guc_dequeue(engine))
total: 1 errors, 0 warnings, 0 checks, 103 lines checked
59a7f61abead drm/i915: Missed interrupt simulation is no more, tell the world
aa77959dacd7 drm/i915/selftests: Basic stress test for rapid context switching
-:120: WARNING:ALLOC_ARRAY_ARGS: kcalloc uses number as first arg, sizeof is
generally wrong
#120: FILE: drivers/gpu/drm/i915/selftests/i915_gem_context.c:127:
+ ctx = kcalloc(sizeof(*ctx), nctx, GFP_KERNEL);
total: 0 errors, 1 warnings, 0 checks, 203 lines checked
1994f89c4bee drm/i915/execlists: Delay updating ring register state after resume
-:68: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV)
#68: FILE: drivers/gpu/drm/i915/intel_lrc.c:2827:
+ ce->lrc_reg_state[CTX_RING_HEAD+1] = 0;
^
-:69: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV)
#69: FILE: drivers/gpu/drm/i915/intel_lrc.c:2828:
+ ce->lrc_reg_state[CTX_RING_TAIL+1] = 0;
^
total: 0 errors, 0 warnings, 2 checks, 52 lines checked
e3c5fe224683 drm/i915/execlists: Use coherent writes into the context image
-:56: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#56: FILE: drivers/gpu/drm/i915/i915_perf.c:1853:
+ regs = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(dev_priv));
total: 0 errors, 0 warnings, 1 checks, 71 lines checked
961fcf08085e drm/i915/execlists: Onion unwind for logical_ring_init() failure
b80a0049bd90 drm/i915: Report the number of closed vma held by each context in
debugfs
-:43: WARNING:LONG_LINE: line over 100 characters
#43: FILE: drivers/gpu/drm/i915/i915_debugfs.c:350:
+ seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
inactive, %llu global, %llu shared, %llu unbound, %llu closed)\n", \
total: 0 errors, 1 warnings, 0 checks, 169 lines checked
9a5b5d34b0e7 drm/i915: Remove debugfs/i915_ppgtt_info
0b779c883955 drm/i915/execlists: Assert the queue is non-empty on unsubmitting
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#9:
<0>[ 531.960431] drv_self-48067 527402570us : intel_gpu_reset:
engine_mask=1, ret=0, retry=0
total: 0 errors, 1 warnings, 0 checks, 7 lines checked
0471fde14d4f drm/i915/execlists: Reset queue_priority on cancellation
3e9a52f60a87 drm/i915/execlists: Include reset depth in traces
41987cac178b drm/i915/execlists: Use direct submission to restart HW after reset
f701f7a446fc drm/i915: Attach the pci match data to the device upon creation
-:83: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON &
recovery code rather than BUG() or BUG_ON()
#83: FILE: drivers/gpu/drm/i915/i915_drv.c:1351:
+ BUG_ON(device_info->gen > sizeof(device_info->gen_mask) *
BITS_PER_BYTE);
total: 0 errors, 1 warnings, 0 checks, 107 lines checked
06c35ac73fff drm/i915: Track all held rpm wakerefs
-:121: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#121: FILE: drivers/gpu/drm/i915/i915_drv.h:1293:
+ spinlock_t debug_lock;
total: 0 errors, 0 warnings, 1 checks, 586 lines checked
53d707353038 drm/i915: Markup paired operations on wakerefs
-:692: WARNING:NEW_TYPEDEFS: do not add new typedefs
#692: FILE: drivers/gpu/drm/i915/i915_drv.h:130:
+typedef depot_stack_handle_t intel_wakeref_t;
total: 0 errors, 1 warnings, 0 checks, 1868 lines checked
cc5070256ace drm/i915: Syntatic sugar for using intel_runtime_pm
-:491: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible
side-effects?
#491: FILE: drivers/gpu/drm/i915/intel_drv.h:2055:
+#define with_intel_runtime_pm(i915, wf) \
+ for (wf = intel_runtime_pm_get(i915); wf; \
+intel_runtime_pm_put(i915, wf), wf = 0)
-:491: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects?
#491: FILE: drivers/gpu/drm/i915/intel_drv.h:2055:
+#define with_intel_runtime_pm(i915, wf) \
+ for (wf = intel_runtime_pm_get(i915); wf; \
+intel_runtime_pm_put(i915, wf), wf = 0)
-:495: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible
side-effects?
#495: FILE: drivers/gpu/drm/i915/intel_drv.h:2059:
+#define with_intel_runtime_pm_if_in_use(i915, wf) \
+ for (wf = intel_runtime_pm_get_if_in_use(i915); wf; \
+intel_runtime_pm_put(i915, wf), wf = 0)
-:495:
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
tor 2018-08-16 klockan 11:23 -0700 skrev Rodrigo Vivi:
> On Thu, Aug 16, 2018 at 10:36:43AM +0200, Fredrik Schön wrote:
> > Shashank,
> >
> > Den tors 16 aug. 2018 kl 10:15 skrev Sharma, Shashank
> > :
> > >
> > > Hey Chris,
> > >
> > >
> > > On 8/16/2018 1:13 PM, Chris Wilson wrote:
> > > > Quoting Sharma, Shashank (2018-08-16 08:33:36)
> > > > > Regards
> > > > >
> > > > > Shashank
> > > > >
> > > > >
> > > > > On 8/16/2018 12:47 PM, Jani Nikula wrote:
> > > > > > On Wed, 15 Aug 2018, Rodrigo Vivi
> > > > > > wrote:
> > > > > > > On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi
> > > > > > > wrote:
> > > > > > > > On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > First of all we need to fix the commit subject:
> > > > > > > >
> > > > > > > > drm/i915: Increase LSPCON timeout
> > > > > > > >
> > > > > > > > (this can be done when merging, no need to resend)
> > > > > > > >
> > > > > > > > > 100 ms is not enough time for the LSPCON adapter on
> > > > > > > > > Intel NUC devices to
> > > > > > > > > settle. This causes dropped display modes at driver
> > > > > > > > > initialisation.
> > > > > > > > >
> > > > > > > > > Increase timeout to 1000 ms.
> > > > > > > > >
> > > > > > > > > Fixes:
> > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> > > > > > > >
> > > > > > > > Missusage of "Fixes:" tag, please read
> > > > > > > >
> > > > > > > >
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
> > > > > > > >
> > > > > > > > But also no need for resending... could be fixed when
> > > > > > > > merging
> > > > > > > >
> > > > > > > > The right one would be:
> > > > > > > >
> > > > > > > > Bugzilla:
> > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> > > > > > > > Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for
> > > > > > > > expected LSPCON mode to settle")
> > > > > > > > Cc: Shashank Sharma
> > > > > > > > Cc: Imre Deak
> > > > > > > > Cc: Jani Nikula
> > > > > > > > Cc: # v4.11+
> > > > > > > >
> > > > > > > > Since initial 100 seemed to be empirical and this
> > > > > > > > increase seems to
> > > > > > > > help other cases I'm in favor of this move so
> > > > > > > >
> > > > > > > > Reviewed-by: Rodrigo Vivi
> > > > > > > >
> > > > > > > > However I will wait a bit before merging it
> > > > > > > > so Imre, Shashank, and/or Jani can take a look here...
> > > > > > >
> > > > > > > now, really cc'ing them...
> > > > > >
> > > > > > Shashank? Does this slow down non-LSPCON paths?
> > > > >
> > > > > This will slow down the lspcon probing and resume part, but
> > > > > both of them
> > > > > happen only when LSPCON device is found. So to answer your
> > > > > question,
> > > > > this will not slow down the non-lspcon path, but will slow
> > > > > down the
> > > > > LSPCON connector resume and probe time. but I would
> > > > > recommend, instead
> > > > > of increasing it to 1000 ms in a single shot, we might want
> > > > > to gradually
> > > > > pick this up, on a wake-and-check way.
> > > >
> > > > wait_for() checks every [10us, 1ms] until the condition is met,
> > > > or it
> > > > times out. So, so long as we don't enter this path for !LPSCON
> > > > where we
> > > > know that it will timeout, the wait_for() will only take as
> > > > long as is
> > > > required for the connector to settle.
> > >
> > > We wont hit !LSPCON timeout case here, as we have already read
> > > the
> > > dongle signature successfully by now. But I was thinking that,
> > > if the
> > > spec recommends max wait time as 100ms (which is of course
> > > doesn't seem
> > > enough), if we can't detect i2c-over-aux after first 500ms, I
> > > guess we
> > > wont be able to do that in next 500ms too. So is it really ok to
> > > wait
> > > this long in the resume sequence ?
> > >
> > > I guess Fredrik can provide some inputs here on if there are some
> > > experiments behind this number of 1000ms, or this is just a safe
> > > bet ?
> > > >
> >
> > My first patch attempt - which is attached to the Redhat and FDO
> > Bugzilla
> > bugs - added a retry loop around the original 100 ms timeout. The
> > retry loop
> > did trigger, but never more than once in a row in my testing.
> >
> > So possibly 200 ms would be a sufficient timeout, but as the
> > wait_for() loop
> > terminates early on success I suggested a conservative value of
> > 1000 ms.
>
> Since Shashank mentioned 100us came from some spec, maybe the double
> is already
> a conservative value.
>
> Since there is the concerns of delaying something when LSPCON fails
> and we are possibly looping on connectors somewhere/somehow I believe
> we need
> to have a balanced approach here.
>
> could you please try the 200 ms approach on your case there for a
> while and
> see how it goes?
>
I ran a few stress tests using Nicholas test case from [1]. I can
quickly reproduce the failure with timeouts 100 ms, 110 ms, 130 ms, 150
[Intel-gfx] [PATCH 04/23] drm/i915/selftests: Basic stress test for rapid context switching
We need to exercise the HW and submission paths for switching contexts
rapidly to check that features such as execlists' wa_tail are adequate.
Plus it's an interesting baseline latency metric.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 185 ++
1 file changed, 185 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 1c92560d35da..d8004bf5a4f0 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -22,6 +22,8 @@
*
*/
+#include
+
#include "../i915_selftest.h"
#include "i915_random.h"
#include "igt_flush_test.h"
@@ -32,6 +34,188 @@
#define DW_PER_PAGE (PAGE_SIZE / sizeof(u32))
+struct live_test {
+ struct drm_i915_private *i915;
+ const char *func;
+ const char *name;
+
+ unsigned int reset_count;
+};
+
+static int begin_live_test(struct live_test *t,
+ struct drm_i915_private *i915,
+ const char *func,
+ const char *name)
+{
+ int err;
+
+ t->i915 = i915;
+ t->func = func;
+ t->name = name;
+
+ err = i915_gem_wait_for_idle(i915,
+I915_WAIT_LOCKED,
+MAX_SCHEDULE_TIMEOUT);
+ if (err) {
+ pr_err("%s(%s): failed to idle before, with err=%d!",
+ func, name, err);
+ return err;
+ }
+
+ i915->gpu_error.missed_irq_rings = 0;
+ t->reset_count = i915_reset_count(>gpu_error);
+
+ return 0;
+}
+
+static int end_live_test(struct live_test *t)
+{
+ struct drm_i915_private *i915 = t->i915;
+
+ i915_retire_requests(i915);
+
+ if (wait_for(intel_engines_are_idle(i915), 10)) {
+ pr_err("%s(%s): GPU not idle\n", t->func, t->name);
+ return -EIO;
+ }
+
+ if (t->reset_count != i915_reset_count(>gpu_error)) {
+ pr_err("%s(%s): GPU was reset %d times!\n",
+ t->func, t->name,
+ i915_reset_count(>gpu_error) - t->reset_count);
+ return -EIO;
+ }
+
+ if (i915->gpu_error.missed_irq_rings) {
+ pr_err("%s(%s): Missed interrupts on engines %lx\n",
+ t->func, t->name, i915->gpu_error.missed_irq_rings);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int live_nop_switch(void *arg)
+{
+ const unsigned int nctx = 1024;
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context **ctx;
+ enum intel_engine_id id;
+ struct drm_file *file;
+ struct live_test t;
+ unsigned long n;
+ int err = -ENODEV;
+
+ /*
+* Create as many contexts as we can feasibly get away with
+* and check we can switch between them rapidly.
+*
+* Serves as very simple stress test for submission and HW switching
+* between contexts.
+*/
+
+ if (!DRIVER_CAPS(i915)->has_logical_contexts)
+ return 0;
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(>drm.struct_mutex);
+
+ ctx = kcalloc(sizeof(*ctx), nctx, GFP_KERNEL);
+ if (!ctx) {
+ err = -ENOMEM;
+ goto out_unlock;
+ }
+
+ for (n = 0; n < nctx; n++) {
+ ctx[n] = i915_gem_create_context(i915, file->driver_priv);
+ if (IS_ERR(ctx[n])) {
+ err = PTR_ERR(ctx[n]);
+ goto out_unlock;
+ }
+ }
+
+ for_each_engine(engine, i915, id) {
+ struct i915_request *request;
+ unsigned long end_time, prime;
+ ktime_t times[2] = {};
+
+ times[0] = ktime_get_raw();
+ for (n = 0; n < nctx; n++) {
+ request = i915_request_alloc(engine, ctx[n]);
+ i915_request_add(request);
+ }
+ i915_request_wait(request,
+ I915_WAIT_LOCKED,
+ MAX_SCHEDULE_TIMEOUT);
+ times[1] = ktime_get_raw();
+
+ pr_info("Populated %d contexts on %s in %lluns\n",
+ nctx, engine->name, ktime_to_ns(times[1] - times[0]));
+
+ err = begin_live_test(, i915, __func__, engine->name);
+ if (err)
+ goto out_unlock;
+
+ end_time = jiffies + i915_selftest.timeout_jiffies;
+ for_each_prime_number_from(prime, 2, 8192) {
+ times[1] = ktime_get_raw();
+
+ for (n = 0; n < prime; n++) {
+ request = i915_request_alloc(engine,
+
[Intel-gfx] [PATCH 05/23] drm/i915/execlists: Delay updating ring register state after resume
Now that we reload both RING_HEAD and RING_TAIL when rebinding the
context, we do not need to scrub those registers immediately on resume.
v2: Handle the perma-pinned contexts.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 647b984b365f..803f22ab275c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2796,13 +2796,14 @@ static int execlists_context_deferred_alloc(struct
i915_gem_context *ctx,
return ret;
}
-void intel_lr_context_resume(struct drm_i915_private *dev_priv)
+void intel_lr_context_resume(struct drm_i915_private *i915)
{
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
enum intel_engine_id id;
- /* Because we emit WA_TAIL_DWORDS there may be a disparity
+ /*
+* Because we emit WA_TAIL_DWORDS there may be a disparity
* between our bookkeeping in ce->ring->head and ce->ring->tail and
* that stored in context. As we only write new commands from
* ce->ring->tail onwards, everything before that is junk. If the GPU
@@ -2812,28 +2813,20 @@ void intel_lr_context_resume(struct drm_i915_private
*dev_priv)
* So to avoid that we reset the context images upon resume. For
* simplicity, we just zero everything out.
*/
- list_for_each_entry(ctx, _priv->contexts.list, link) {
- for_each_engine(engine, dev_priv, id) {
+ list_for_each_entry(ctx, >contexts.list, link) {
+ for_each_engine(engine, i915, id) {
struct intel_context *ce =
to_intel_context(ctx, engine);
- u32 *reg;
-
- if (!ce->state)
- continue;
- reg = i915_gem_object_pin_map(ce->state->obj,
- I915_MAP_WB);
- if (WARN_ON(IS_ERR(reg)))
+ if (!ce->ring)
continue;
- reg += LRC_STATE_PN * PAGE_SIZE / sizeof(*reg);
- reg[CTX_RING_HEAD+1] = 0;
- reg[CTX_RING_TAIL+1] = 0;
-
- ce->state->obj->mm.dirty = true;
- i915_gem_object_unpin_map(ce->state->obj);
-
intel_ring_reset(ce->ring, 0);
+
+ if (ce->pin_count) { /* otherwise done in context_pin */
+ ce->lrc_reg_state[CTX_RING_HEAD+1] = 0;
+ ce->lrc_reg_state[CTX_RING_TAIL+1] = 0;
+ }
}
}
}
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/23] drm/i915: Cache the error string
Currently, we convert the error state into a string every time we read
from sysfs (and sysfs reads in page size (4KiB) chunks). We do try to
window the string and only capture the portion that is being read, but
that means that we must always convert up to the window to find the
start. For a very large error state bordering on EXEC_OBJECT_CAPTURE
abuse, this is noticeable as it degrades to O(N^2)!
As we do not have a convenient hook for sysfs open(), and we would like
to keep the lazy conversion into a string, do the conversion of the
whole string on the first read and keep the string until the error state
is freed.
v2: Don't double advance simple_read_from_buffer
v3: Due to extreme pain of lack of vrealloc, use a scatterlist
v4: Keep the forward iterator loosely cached
Reported-by: Jason Ekstrand
Testcase: igt/gem_exec_capture/many*
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/i915_debugfs.c | 32 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 402 +++---
drivers/gpu/drm/i915/i915_gpu_error.h | 28 +-
drivers/gpu/drm/i915/i915_sysfs.c | 27 +-
4 files changed, 273 insertions(+), 216 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 26b7e5276b15..7620a919e066 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -943,30 +943,28 @@ static int i915_gem_fence_regs_info(struct seq_file *m,
void *data)
static ssize_t gpu_state_read(struct file *file, char __user *ubuf,
size_t count, loff_t *pos)
{
- struct i915_gpu_state *error = file->private_data;
- struct drm_i915_error_state_buf str;
+ struct i915_gpu_state *error;
ssize_t ret;
- loff_t tmp;
+ void *buf;
+ error = file->private_data;
if (!error)
return 0;
- ret = i915_error_state_buf_init(, error->i915, count, *pos);
- if (ret)
- return ret;
-
- ret = i915_error_state_to_str(, error);
- if (ret)
- goto out;
+ /* Bounce buffer required because of kernfs __user API convenience. */
+ buf = kmalloc(count, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
- tmp = 0;
- ret = simple_read_from_buffer(ubuf, count, , str.buf, str.bytes);
- if (ret < 0)
- goto out;
+ ret = i915_gpu_state_copy_to_buffer(error, buf, *pos, count);
+ if (ret > 0) {
+ if (!copy_to_user(ubuf, buf, ret))
+ *pos += ret;
+ else
+ ret = -EFAULT;
+ }
- *pos = str.start + ret;
-out:
- i915_error_state_buf_release();
+ kfree(buf);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index f7f2aa71d8d9..5c4e09b6a650 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -28,6 +28,8 @@
*/
#include
+#include
+#include
#include
#include
#include
@@ -77,112 +79,110 @@ static const char *purgeable_flag(int purgeable)
return purgeable ? " purgeable" : "";
}
-static bool __i915_error_ok(struct drm_i915_error_state_buf *e)
+static void __sg_set_buf(struct scatterlist *sg,
+void *addr, unsigned int len, loff_t it)
{
-
- if (!e->err && WARN(e->bytes > (e->size - 1), "overflow")) {
- e->err = -ENOSPC;
- return false;
- }
-
- if (e->bytes == e->size - 1 || e->err)
- return false;
-
- return true;
+ sg->page_link = (unsigned long)virt_to_page(addr);
+ sg->offset = offset_in_page(addr);
+ sg->length = len;
+ sg->dma_address = it;
}
-static bool __i915_error_seek(struct drm_i915_error_state_buf *e,
- unsigned len)
+static bool __i915_error_grow(struct drm_i915_error_state_buf *e, size_t len)
{
- if (e->pos + len <= e->start) {
- e->pos += len;
+ if (!len)
return false;
- }
- /* First vsnprintf needs to fit in its entirety for memmove */
- if (len >= e->size) {
- e->err = -EIO;
- return false;
- }
+ if (e->bytes + len + 1 > e->size) {
+ if (e->bytes) {
+ __sg_set_buf(e->cur++, e->buf, e->bytes, e->iter);
+ e->iter += e->bytes;
+ e->buf = NULL;
+ e->bytes = 0;
+ }
- return true;
-}
+ if (e->cur == e->end) {
+ struct scatterlist *sgl;
-static void __i915_error_advance(struct drm_i915_error_state_buf *e,
-unsigned len)
-{
- /* If this is first printf in this window, adjust it so that
-* start position matches start of the buffer
-*/
+
[Intel-gfx] [PATCH 14/23] drm/i915: Attach the pci match data to the device upon creation
Attach our device_info to the our i915 private on creation so that it is
always available for inspection.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 66 +++--
1 file changed, 38 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 35a012ffc03b..ade8d3c8c29f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -870,7 +870,6 @@ static void intel_detect_preproduction_hw(struct
drm_i915_private *dev_priv)
/**
* i915_driver_init_early - setup state not requiring device access
* @dev_priv: device private
- * @ent: the matching pci_device_id
*
* Initialize everything that is a "SW-only" state, that is state not
* requiring accessing the device or exposing the driver via kernel internal
@@ -878,25 +877,13 @@ static void intel_detect_preproduction_hw(struct
drm_i915_private *dev_priv)
* system memory allocation, setting up device specific attributes and
* function hooks not requiring accessing the device.
*/
-static int i915_driver_init_early(struct drm_i915_private *dev_priv,
- const struct pci_device_id *ent)
+static int i915_driver_init_early(struct drm_i915_private *dev_priv)
{
- const struct intel_device_info *match_info =
- (struct intel_device_info *)ent->driver_data;
- struct intel_device_info *device_info;
int ret = 0;
if (i915_inject_load_failure())
return -ENODEV;
- /* Setup the write-once "constant" device info */
- device_info = mkwrite_device_info(dev_priv);
- memcpy(device_info, match_info, sizeof(*device_info));
- device_info->device_id = dev_priv->drm.pdev->device;
-
- BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
-sizeof(device_info->platform_mask) * BITS_PER_BYTE);
- BUG_ON(device_info->gen > sizeof(device_info->gen_mask) *
BITS_PER_BYTE);
spin_lock_init(_priv->irq_lock);
spin_lock_init(_priv->gpu_error.lock);
mutex_init(_priv->backlight_lock);
@@ -1333,6 +1320,39 @@ static void i915_welcome_messages(struct
drm_i915_private *dev_priv)
DRM_INFO("DRM_I915_DEBUG_GEM enabled\n");
}
+static struct drm_i915_private *
+i915_driver_create(struct pci_dev *pdev, const struct pci_device_id *ent)
+{
+ const struct intel_device_info *match_info =
+ (struct intel_device_info *)ent->driver_data;
+ struct intel_device_info *device_info;
+ struct drm_i915_private *i915;
+
+ i915 = kzalloc(sizeof(*i915), GFP_KERNEL);
+ if (!i915)
+ return NULL;
+
+ if (drm_dev_init(>drm, , >dev)) {
+ kfree(i915);
+ return NULL;
+ }
+
+ i915->drm.pdev = pdev;
+ i915->drm.dev_private = i915;
+ pci_set_drvdata(pdev, >drm);
+
+ /* Setup the write-once "constant" device info */
+ device_info = mkwrite_device_info(i915);
+ memcpy(device_info, match_info, sizeof(*device_info));
+ device_info->device_id = pdev->device;
+
+ BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
+sizeof(device_info->platform_mask) * BITS_PER_BYTE);
+ BUG_ON(device_info->gen > sizeof(device_info->gen_mask) *
BITS_PER_BYTE);
+
+ return i915;
+}
+
/**
* i915_driver_load - setup chip and create an initial config
* @pdev: PCI device
@@ -1355,24 +1375,15 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (!i915_modparams.nuclear_pageflip && match_info->gen < 5)
driver.driver_features &= ~DRIVER_ATOMIC;
- ret = -ENOMEM;
- dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
- if (dev_priv)
- ret = drm_dev_init(_priv->drm, , >dev);
- if (ret) {
- DRM_DEV_ERROR(>dev, "allocation failed\n");
- goto out_free;
- }
-
- dev_priv->drm.pdev = pdev;
- dev_priv->drm.dev_private = dev_priv;
+ dev_priv = i915_driver_create(pdev, ent);
+ if (!dev_priv)
+ return -ENOMEM;
ret = pci_enable_device(pdev);
if (ret)
goto out_fini;
- pci_set_drvdata(pdev, _priv->drm);
- ret = i915_driver_init_early(dev_priv, ent);
+ ret = i915_driver_init_early(dev_priv);
if (ret < 0)
goto out_pci_disable;
@@ -1424,7 +1435,6 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
out_fini:
i915_load_error(dev_priv, "Device initialization failed (%d)\n", ret);
drm_dev_fini(_priv->drm);
-out_free:
kfree(dev_priv);
pci_set_drvdata(pdev, NULL);
return ret;
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/23] drm/i915: Report the number of closed vma held by each context in debugfs
Include the total size of closed vma when reporting the per_ctx_stats of
debugfs/i915_gem_objects.
Whilst adjusting the context tracking, note that we can simply use our
list of contexts in i915->contexts rather than circumlocute via
dev->filelist and the per-file context idr.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 113 +++-
1 file changed, 42 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 449fe7638474..c5a1bab7a337 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -302,6 +302,7 @@ struct file_stats {
u64 total, unbound;
u64 global, shared;
u64 active, inactive;
+ u64 closed;
};
static int per_file_stats(int id, void *ptr, void *data)
@@ -336,6 +337,9 @@ static int per_file_stats(int id, void *ptr, void *data)
stats->active += vma->node.size;
else
stats->inactive += vma->node.size;
+
+ if (i915_vma_is_closed(vma))
+ stats->closed += vma->node.size;
}
return 0;
@@ -343,7 +347,7 @@ static int per_file_stats(int id, void *ptr, void *data)
#define print_file_stats(m, name, stats) do { \
if (stats.count) \
- seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
inactive, %llu global, %llu shared, %llu unbound)\n", \
+ seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
inactive, %llu global, %llu shared, %llu unbound, %llu closed)\n", \
name, \
stats.count, \
stats.total, \
@@ -351,7 +355,8 @@ static int per_file_stats(int id, void *ptr, void *data)
stats.inactive, \
stats.global, \
stats.shared, \
- stats.unbound); \
+ stats.unbound, \
+ stats.closed); \
} while (0)
static void print_batch_pool_stats(struct seq_file *m,
@@ -377,44 +382,44 @@ static void print_batch_pool_stats(struct seq_file *m,
print_file_stats(m, "[k]batch pool", stats);
}
-static int per_file_ctx_stats(int idx, void *ptr, void *data)
+static void print_context_stats(struct seq_file *m,
+ struct drm_i915_private *i915)
{
- struct i915_gem_context *ctx = ptr;
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
- for_each_engine(engine, ctx->i915, id) {
- struct intel_context *ce = to_intel_context(ctx, engine);
+ struct file_stats kstats = {};
+ struct i915_gem_context *ctx;
- if (ce->state)
- per_file_stats(0, ce->state->obj, data);
- if (ce->ring)
- per_file_stats(0, ce->ring->vma->obj, data);
- }
+ list_for_each_entry(ctx, >contexts.list, link) {
+ struct file_stats stats = { .file_priv = ctx->file_priv };
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
- return 0;
-}
+ for_each_engine(engine, i915, id) {
+ struct intel_context *ce = to_intel_context(ctx,
engine);
-static void print_context_stats(struct seq_file *m,
- struct drm_i915_private *dev_priv)
-{
- struct drm_device *dev = _priv->drm;
- struct file_stats stats;
- struct drm_file *file;
+ if (ce->state)
+ per_file_stats(0, ce->state->obj, );
+ if (ce->ring)
+ per_file_stats(0, ce->ring->vma->obj, );
+ }
- memset(, 0, sizeof(stats));
+ if (!IS_ERR_OR_NULL(stats.file_priv)) {
+ struct drm_file *file = stats.file_priv->file;
+ struct task_struct *task;
- mutex_lock(>struct_mutex);
- if (dev_priv->kernel_context)
- per_file_ctx_stats(0, dev_priv->kernel_context, );
+ spin_lock(>table_lock);
+ idr_for_each(>object_idr, per_file_stats, );
+ spin_unlock(>table_lock);
- list_for_each_entry(file, >filelist, lhead) {
- struct drm_i915_file_private *fpriv = file->driver_priv;
- idr_for_each(>context_idr, per_file_ctx_stats, );
+ rcu_read_lock();
+ task = pid_task(ctx->pid ?: file->pid, PIDTYPE_PID);
+ print_file_stats(m,
+task ? task->comm : "",
+stats);
+ rcu_read_unlock();
+ }
}
- mutex_unlock(>struct_mutex);
-
[Intel-gfx] [PATCH 09/23] drm/i915: Remove debugfs/i915_ppgtt_info
The information presented here is not relevant to current development.
We can either use the context information, but more often we want to
inspect the active gpu state.
The ulterior motive is to eradicate dev->filelist.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 119
1 file changed, 119 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c5a1bab7a337..a8dbd2d89b72 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2032,124 +2032,6 @@ static int i915_swizzle_info(struct seq_file *m, void
*data)
return 0;
}
-static int per_file_ctx(int id, void *ptr, void *data)
-{
- struct i915_gem_context *ctx = ptr;
- struct seq_file *m = data;
- struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
-
- if (!ppgtt) {
- seq_printf(m, " no ppgtt for context %d\n",
- ctx->user_handle);
- return 0;
- }
-
- if (i915_gem_context_is_default(ctx))
- seq_puts(m, " default context:\n");
- else
- seq_printf(m, " context %d:\n", ctx->user_handle);
- ppgtt->debug_dump(ppgtt, m);
-
- return 0;
-}
-
-static void gen8_ppgtt_info(struct seq_file *m,
- struct drm_i915_private *dev_priv)
-{
- struct i915_hw_ppgtt *ppgtt = dev_priv->mm.aliasing_ppgtt;
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
- int i;
-
- if (!ppgtt)
- return;
-
- for_each_engine(engine, dev_priv, id) {
- seq_printf(m, "%s\n", engine->name);
- for (i = 0; i < 4; i++) {
- u64 pdp = I915_READ(GEN8_RING_PDP_UDW(engine, i));
- pdp <<= 32;
- pdp |= I915_READ(GEN8_RING_PDP_LDW(engine, i));
- seq_printf(m, "\tPDP%d 0x%016llx\n", i, pdp);
- }
- }
-}
-
-static void gen6_ppgtt_info(struct seq_file *m,
- struct drm_i915_private *dev_priv)
-{
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
- if (IS_GEN6(dev_priv))
- seq_printf(m, "GFX_MODE: 0x%08x\n", I915_READ(GFX_MODE));
-
- for_each_engine(engine, dev_priv, id) {
- seq_printf(m, "%s\n", engine->name);
- if (IS_GEN7(dev_priv))
- seq_printf(m, "GFX_MODE: 0x%08x\n",
- I915_READ(RING_MODE_GEN7(engine)));
- seq_printf(m, "PP_DIR_BASE: 0x%08x\n",
- I915_READ(RING_PP_DIR_BASE(engine)));
- seq_printf(m, "PP_DIR_BASE_READ: 0x%08x\n",
- I915_READ(RING_PP_DIR_BASE_READ(engine)));
- seq_printf(m, "PP_DIR_DCLV: 0x%08x\n",
- I915_READ(RING_PP_DIR_DCLV(engine)));
- }
- if (dev_priv->mm.aliasing_ppgtt) {
- struct i915_hw_ppgtt *ppgtt = dev_priv->mm.aliasing_ppgtt;
-
- seq_puts(m, "aliasing PPGTT:\n");
- seq_printf(m, "pd gtt offset: 0x%08x\n",
ppgtt->pd.base.ggtt_offset);
-
- ppgtt->debug_dump(ppgtt, m);
- }
-
- seq_printf(m, "ECOCHK: 0x%08x\n", I915_READ(GAM_ECOCHK));
-}
-
-static int i915_ppgtt_info(struct seq_file *m, void *data)
-{
- struct drm_i915_private *dev_priv = node_to_i915(m->private);
- struct drm_device *dev = _priv->drm;
- struct drm_file *file;
- int ret;
-
- mutex_lock(>filelist_mutex);
- ret = mutex_lock_interruptible(>struct_mutex);
- if (ret)
- goto out_unlock;
-
- intel_runtime_pm_get(dev_priv);
-
- if (INTEL_GEN(dev_priv) >= 8)
- gen8_ppgtt_info(m, dev_priv);
- else if (INTEL_GEN(dev_priv) >= 6)
- gen6_ppgtt_info(m, dev_priv);
-
- list_for_each_entry_reverse(file, >filelist, lhead) {
- struct drm_i915_file_private *file_priv = file->driver_priv;
- struct task_struct *task;
-
- task = get_pid_task(file->pid, PIDTYPE_PID);
- if (!task) {
- ret = -ESRCH;
- goto out_rpm;
- }
- seq_printf(m, "\nproc: %s\n", task->comm);
- put_task_struct(task);
- idr_for_each(_priv->context_idr, per_file_ctx,
-(void *)(unsigned long)m);
- }
-
-out_rpm:
- intel_runtime_pm_put(dev_priv);
- mutex_unlock(>struct_mutex);
-out_unlock:
- mutex_unlock(>filelist_mutex);
- return ret;
-}
-
static int count_irq_waiters(struct drm_i915_private *i915)
{
struct intel_engine_cs *engine;
@@ -4716,7 +4598,6 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_context_status", i915_context_status, 0},
{"i915_forcewake_domains",
[Intel-gfx] [PATCH 07/23] drm/i915/execlists: Onion unwind for logical_ring_init() failure
Fix up the error unwind for logical_ring_init() failing by moving the
cleanup into the callers who own the various bits of state during
initialisation.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4b9ae2d9bbbe..b7755fe1a356 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2410,7 +2410,7 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
ret = intel_engine_init_common(engine);
if (ret)
- goto error;
+ return ret;
if (HAS_LOGICAL_RING_ELSQ(i915)) {
execlists->submit_reg = i915->regs +
@@ -2452,10 +2452,6 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
reset_csb_pointers(execlists);
return 0;
-
-error:
- intel_logical_ring_cleanup(engine);
- return ret;
}
int logical_render_ring_init(struct intel_engine_cs *engine)
@@ -2478,10 +2474,14 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
engine->emit_breadcrumb = gen8_emit_breadcrumb_rcs;
engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_rcs_sz;
- ret = intel_engine_create_scratch(engine, PAGE_SIZE);
+ ret = logical_ring_init(engine);
if (ret)
return ret;
+ ret = intel_engine_create_scratch(engine, PAGE_SIZE);
+ if (ret)
+ goto err_cleanup_common;
+
ret = intel_init_workaround_bb(engine);
if (ret) {
/*
@@ -2493,7 +2493,11 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
ret);
}
- return logical_ring_init(engine);
+ return 0;
+
+err_cleanup_common:
+ intel_engine_cleanup_common(engine);
+ return ret;
}
int logical_xcs_ring_init(struct intel_engine_cs *engine)
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/23] drm/i915/execlists: Reset queue_priority on cancellation
If we have an available execlists port, the queue_priority should be INT_MIN to allow immediate direct submission. As we clear the ports in execlists_cancel_port_requests(), we should then reset queue_priority to show the available space. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 3b5f7bc83a34..32eab1c97622 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -795,6 +795,7 @@ execlists_cancel_port_requests(struct intel_engine_execlists * const execlists) } execlists_clear_all_active(execlists); + execlists->queue_priority = INT_MIN; } static void reset_csb_pointers(struct intel_engine_execlists *execlists) -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/23] drm/i915: Markup paired operations on display power domains
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get functions to their rpm_put counterpart. This
makes the pairing explicit, and given the required wakeref cookie the
compiler can verify that we pass an initialised value to the rpm_put
(quite handy for double checking error paths).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 35 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/intel_audio.c | 3 +-
drivers/gpu/drm/i915/intel_cdclk.c | 10 ++--
drivers/gpu/drm/i915/intel_crt.c| 25 +
drivers/gpu/drm/i915/intel_csr.c| 25 +++--
drivers/gpu/drm/i915/intel_ddi.c| 36 -
drivers/gpu/drm/i915/intel_display.c| 70 +++-
drivers/gpu/drm/i915/intel_dp.c | 29 +-
drivers/gpu/drm/i915/intel_dpll_mgr.c | 66 +++
drivers/gpu/drm/i915/intel_drv.h| 17 --
drivers/gpu/drm/i915/intel_hdmi.c | 20 ---
drivers/gpu/drm/i915/intel_i2c.c| 20 +++
drivers/gpu/drm/i915/intel_lvds.c | 8 +--
drivers/gpu/drm/i915/intel_pipe_crc.c | 6 ++-
drivers/gpu/drm/i915/intel_pm.c | 7 ++-
drivers/gpu/drm/i915/intel_runtime_pm.c | 71 -
drivers/gpu/drm/i915/intel_sprite.c | 24 ++---
drivers/gpu/drm/i915/vlv_dsi.c | 8 +--
20 files changed, 314 insertions(+), 172 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0cc0df54853f..3a9b77ae37f4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -627,10 +627,12 @@ static void gen8_display_interrupt_info(struct seq_file
*m)
for_each_pipe(dev_priv, pipe) {
enum intel_display_power_domain power_domain;
+ intel_wakeref_t wakeref;
power_domain = POWER_DOMAIN_PIPE(pipe);
- if (!intel_display_power_get_if_enabled(dev_priv,
- power_domain)) {
+ wakeref = intel_display_power_get_if_enabled(dev_priv,
+ power_domain);
+ if (!wakeref) {
seq_printf(m, "Pipe %c power disabled\n",
pipe_name(pipe));
continue;
@@ -645,7 +647,7 @@ static void gen8_display_interrupt_info(struct seq_file *m)
pipe_name(pipe),
I915_READ(GEN8_DE_PIPE_IER(pipe)));
- intel_display_power_put(dev_priv, power_domain);
+ intel_display_power_put(dev_priv, power_domain, wakeref);
}
seq_printf(m, "Display Engine port interrupt mask:\t%08x\n",
@@ -681,6 +683,8 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
wakeref = intel_runtime_pm_get(dev_priv);
if (IS_CHERRYVIEW(dev_priv)) {
+ intel_wakeref_t pref;
+
seq_printf(m, "Master Interrupt Control:\t%08x\n",
I915_READ(GEN8_MASTER_IRQ));
@@ -696,8 +700,9 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
enum intel_display_power_domain power_domain;
power_domain = POWER_DOMAIN_PIPE(pipe);
- if (!intel_display_power_get_if_enabled(dev_priv,
- power_domain)) {
+ pref = intel_display_power_get_if_enabled(dev_priv,
+ power_domain);
+ if (!pref) {
seq_printf(m, "Pipe %c power disabled\n",
pipe_name(pipe));
continue;
@@ -707,17 +712,17 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
pipe_name(pipe),
I915_READ(PIPESTAT(pipe)));
- intel_display_power_put(dev_priv, power_domain);
+ intel_display_power_put(dev_priv, power_domain, pref);
}
- intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
+ pref = intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
seq_printf(m, "Port hotplug:\t%08x\n",
I915_READ(PORT_HOTPLUG_EN));
seq_printf(m, "DPFLIPSTAT:\t%08x\n",
I915_READ(VLV_DPFLIPSTAT));
seq_printf(m, "DPINVGTT:\t%08x\n",
[Intel-gfx] [PATCH 13/23] drm/i915/execlists: Use direct submission to restart HW after reset
We can bypass ksoftirqd for restarting our submission queue after a GPU
reset and so avoid any inscrutable delays.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submission.c | 24 +
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 3c97bb00db50..3331d41c1258 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -836,6 +836,29 @@ guc_reset_prepare(struct intel_engine_cs *engine)
return i915_gem_find_active_request(engine);
}
+static void guc_reset_finish(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists * const execlists = >execlists;
+
+ /* After a GPU reset, we may have requests to replay */
+ if (!RB_EMPTY_ROOT(>queue.rb_root))
+ tasklet_schedule(>tasklet);
+
+ /*
+* Flush the tasklet while we still have the forcewake to be sure
+* that it is not allowed to sleep before we restart and reload a
+* context.
+*
+* As before (with execlists_reset_prepare) we rely on the caller
+* serialising multiple attempts to reset so that we know that we
+* are the only one manipulating tasklet state.
+*/
+ __tasklet_enable_sync_once(>tasklet);
+
+ GEM_TRACE("%s: depth->%d\n", engine->name,
+ atomic_read(>tasklet.count));
+}
+
/*
* Everything below here is concerned with setup & teardown, and is
* therefore not part of the somewhat time-critical batch-submission
@@ -1283,6 +1306,7 @@ static void guc_set_default_submission(struct
intel_engine_cs *engine)
engine->unpark = guc_submission_unpark;
engine->reset.prepare = guc_reset_prepare;
+ engine->reset.finish = guc_reset_finish;
engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 32eab1c97622..6e6e0ff123a9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1987,7 +1987,7 @@ static void execlists_reset_finish(struct intel_engine_cs
*engine)
/* After a GPU reset, we may have requests to replay */
if (!RB_EMPTY_ROOT(>queue.rb_root))
- tasklet_schedule(>tasklet);
+ execlists_submission_tasklet(execlists->tasklet.data);
/*
* Flush the tasklet while we still have the forcewake to be sure
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/23] drm/i915: Track all held rpm wakerefs
Everytime we take a wakeref, record the stack trace of where it was
taken; clearing the set if we ever drop back to no owners. For debugging
a rpm leak, we can look at all the current wakerefs and check if they
have a matching rpm_put.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug| 13 +
drivers/gpu/drm/i915/i915_debugfs.c | 6 +
drivers/gpu/drm/i915/i915_drv.c | 10 +-
drivers/gpu/drm/i915/i915_drv.h | 7 +
drivers/gpu/drm/i915/intel_drv.h | 44 ++-
drivers/gpu/drm/i915/intel_runtime_pm.c | 267 --
.../gpu/drm/i915/selftests/mock_gem_device.c | 8 +-
7 files changed, 306 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 459f8f88a34c..8b277258f62e 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -39,6 +39,19 @@ config DRM_I915_DEBUG
If in doubt, say "N".
+config DRM_I915_DEBUG_RUNTIME_PM
+bool "Insert extra checks into the runtime pm internals"
+depends on DRM_I915
+default n
+select STACKDEPOT
+help
+ Enable extra sanity checks (including BUGs) along the runtime pm
+ paths that may slow the system down and if hit hang the machine.
+
+ Recommended for driver developers only.
+
+ If in doubt, say "N".
+
config DRM_I915_DEBUG_GEM
bool "Insert extra checks into the GEM internals"
default n
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a8dbd2d89b72..d33e5f2e021a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2694,6 +2694,12 @@ static int i915_runtime_pm_status(struct seq_file *m,
void *unused)
pci_power_name(pdev->current_state),
pdev->current_state);
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)) {
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ print_intel_runtime_pm_wakeref(dev_priv, );
+ }
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ade8d3c8c29f..9c5efffebc95 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -895,6 +895,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv)
mutex_init(_priv->pps_mutex);
i915_memcpy_init_early(dev_priv);
+ intel_runtime_pm_init_early(dev_priv);
ret = i915_workqueues_init(dev_priv);
if (ret < 0)
@@ -1318,6 +1319,8 @@ static void i915_welcome_messages(struct drm_i915_private
*dev_priv)
DRM_INFO("DRM_I915_DEBUG enabled\n");
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
DRM_INFO("DRM_I915_DEBUG_GEM enabled\n");
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM))
+ DRM_INFO("DRM_I915_DEBUG_RUNTIME_PM enabled\n");
}
static struct drm_i915_private *
@@ -1478,8 +1481,7 @@ void i915_driver_unload(struct drm_device *dev)
i915_driver_cleanup_mmio(dev_priv);
enable_rpm_wakeref_asserts(dev_priv);
-
- WARN_ON(atomic_read(_priv->runtime_pm.wakeref_count));
+ intel_runtime_pm_cleanup(dev_priv);
}
static void i915_driver_release(struct drm_device *dev)
@@ -1685,6 +1687,8 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
out:
enable_rpm_wakeref_asserts(dev_priv);
+ if (!dev_priv->uncore.user_forcewake.count)
+ intel_runtime_pm_cleanup(dev_priv);
return ret;
}
@@ -2639,7 +2643,7 @@ static int intel_runtime_suspend(struct device *kdev)
}
enable_rpm_wakeref_asserts(dev_priv);
- WARN_ON_ONCE(atomic_read(_priv->runtime_pm.wakeref_count));
+ intel_runtime_pm_cleanup(dev_priv);
if (intel_uncore_arm_unclaimed_mmio_detection(dev_priv))
DRM_ERROR("Unclaimed access detected prior to suspending\n");
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b6eea715d506..8a931b0df95f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1287,6 +1288,12 @@ struct i915_runtime_pm {
atomic_t wakeref_count;
bool suspended;
bool irqs_enabled;
+
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
+ spinlock_t debug_lock;
+ depot_stack_handle_t *debug_owners;
+ unsigned long debug_count;
+#endif
};
enum intel_pipe_crc_source {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d0402051925b..dbe17576d47e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -40,6 +40,8 @@
#include
#include
+struct drm_printer;
+
/**
* __wait_for - magic wait
[Intel-gfx] [PATCH 10/23] drm/i915/execlists: Assert the queue is non-empty on unsubmitting
In the sequence <0>[ 531.960431] drv_self-48067 527402570us : intel_gpu_reset: engine_mask=1, ret=0, retry=0 <0>[ 531.960431] drv_self-48067 527402571us : execlists_reset: rcs0 request global=115de, current=71133 <0>[ 531.960431] drv_self-48067d..1 527402571us : execlists_cancel_port_requests: rcs0:port0 global=71134 (fence 826b:198), (current 71133) <0>[ 531.960431] drv_self-48067d..1 527402572us : execlists_cancel_port_requests: rcs0:port1 global=71135 (fence 826c:53), (current 71133) <0>[ 531.960431] drv_self-48067d..1 527402572us : __i915_request_unsubmit: rcs0 fence 826c:53 <- global=71135, current 71133 <0>[ 531.960431] drv_self-48067d..1 527402579us : __i915_request_unsubmit: rcs0 fence 826b:198 <- global=71134, current 71133 <0>[ 531.960431] drv_self-48067 527402613us : intel_engine_cancel_stop_cs: rcs0 <0>[ 531.960431] drv_self-48067 527402624us : execlists_reset_finish: rcs0 we are missing the execlists_submission_tasklet() invocation before the execlists_reset_fini() implying that either the queue is empty, or we failed to schedule and run the tasklet on finish. Add an assert so we are sure that on unsubmitting the incomplete request after reset, the queue is indeed populated. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index b7755fe1a356..3b5f7bc83a34 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -344,6 +344,7 @@ static void __unwind_incomplete_requests(struct intel_engine_cs *engine) last_prio = rq_prio(rq); p = lookup_priolist(engine, last_prio); } + GEM_BUG_ON(RB_EMPTY_ROOT(>execlists.queue.rb_root)); GEM_BUG_ON(p->priority != rq_prio(rq)); list_add(>sched.link, >requests); -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/23] drm/i915: Syntatic sugar for using intel_runtime_pm
Frequently, we use intel_runtime_pm_get/_put around a small block.
Formalise that usage by providing a macro to define such a block with an
automatic closure to scope the intel_runtime_pm wakeref to that block,
i.e. macro abuse smelling of python.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 163 ++-
drivers/gpu/drm/i915/i915_gem.c | 10 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 23 ++--
drivers/gpu/drm/i915/i915_gem_shrinker.c | 44 +++---
drivers/gpu/drm/i915/i915_pmu.c | 7 +-
drivers/gpu/drm/i915/i915_sysfs.c| 7 +-
drivers/gpu/drm/i915/intel_drv.h | 8 ++
drivers/gpu/drm/i915/intel_guc_log.c | 26 ++--
drivers/gpu/drm/i915/intel_huc.c | 7 +-
drivers/gpu/drm/i915/intel_panel.c | 18 +--
drivers/gpu/drm/i915/intel_uncore.c | 30 ++---
11 files changed, 162 insertions(+), 181 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4042a4528848..0cc0df54853f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -952,9 +952,9 @@ static int i915_gpu_info_open(struct inode *inode, struct
file *file)
struct i915_gpu_state *gpu;
intel_wakeref_t wakeref;
- wakeref = intel_runtime_pm_get(i915);
- gpu = i915_capture_gpu_state(i915);
- intel_runtime_pm_put(i915, wakeref);
+ gpu = NULL;
+ with_intel_runtime_pm(i915, wakeref)
+ gpu = i915_capture_gpu_state(i915);
if (!gpu)
return -ENOMEM;
@@ -1015,9 +1015,8 @@ i915_next_seqno_set(void *data, u64 val)
if (ret)
return ret;
- wakeref = intel_runtime_pm_get(dev_priv);
- ret = i915_gem_set_global_seqno(dev, val);
- intel_runtime_pm_put(dev_priv, wakeref);
+ with_intel_runtime_pm(dev_priv, wakeref)
+ ret = i915_gem_set_global_seqno(dev, val);
mutex_unlock(>struct_mutex);
@@ -1305,17 +1304,15 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
return 0;
}
- wakeref = intel_runtime_pm_get(dev_priv);
+ with_intel_runtime_pm(dev_priv, wakeref) {
+ for_each_engine(engine, dev_priv, id) {
+ acthd[id] = intel_engine_get_active_head(engine);
+ seqno[id] = intel_engine_get_seqno(engine);
+ }
- for_each_engine(engine, dev_priv, id) {
- acthd[id] = intel_engine_get_active_head(engine);
- seqno[id] = intel_engine_get_seqno(engine);
+ intel_engine_get_instdone(dev_priv->engine[RCS], );
}
- intel_engine_get_instdone(dev_priv->engine[RCS], );
-
- intel_runtime_pm_put(dev_priv, wakeref);
-
if (timer_pending(_priv->gpu_error.hangcheck_work.timer))
seq_printf(m, "Hangcheck active, timer fires in %dms\n",
jiffies_to_msecs(dev_priv->gpu_error.hangcheck_work.timer.expires -
@@ -1591,18 +1588,16 @@ static int i915_drpc_info(struct seq_file *m, void
*unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
intel_wakeref_t wakeref;
- int err;
-
- wakeref = intel_runtime_pm_get(dev_priv);
-
- if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
- err = vlv_drpc_info(m);
- else if (INTEL_GEN(dev_priv) >= 6)
- err = gen6_drpc_info(m);
- else
- err = ironlake_drpc_info(m);
+ int err = -ENODEV;
- intel_runtime_pm_put(dev_priv, wakeref);
+ with_intel_runtime_pm(dev_priv, wakeref) {
+ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+ err = vlv_drpc_info(m);
+ else if (INTEL_GEN(dev_priv) >= 6)
+ err = gen6_drpc_info(m);
+ else
+ err = ironlake_drpc_info(m);
+ }
return err;
}
@@ -2164,9 +2159,8 @@ static int i915_huc_load_status_info(struct seq_file *m,
void *data)
p = drm_seq_file_printer(m);
intel_uc_fw_dump(_priv->huc.fw, );
- wakeref = intel_runtime_pm_get(dev_priv);
- seq_printf(m, "\nHuC status 0x%08x:\n", I915_READ(HUC_STATUS2));
- intel_runtime_pm_put(dev_priv, wakeref);
+ with_intel_runtime_pm(dev_priv, wakeref)
+ seq_printf(m, "\nHuC status 0x%08x:\n", I915_READ(HUC_STATUS2));
return 0;
}
@@ -2176,7 +2170,6 @@ static int i915_guc_load_status_info(struct seq_file *m,
void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
intel_wakeref_t wakeref;
struct drm_printer p;
- u32 tmp, i;
if (!HAS_GUC(dev_priv))
return -ENODEV;
@@ -2184,22 +2177,23 @@ static int i915_guc_load_status_info(struct seq_file
*m, void *data)
p = drm_seq_file_printer(m);
[Intel-gfx] [PATCH 12/23] drm/i915/execlists: Include reset depth in traces
Show the reset depth (the tasklet disable count) in the GEM_TRACE to
indicate when we might not expect tasklets to be flushed.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_guc_submission.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 2f0d5155b1bb..3c97bb00db50 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -809,7 +809,8 @@ guc_reset_prepare(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = >execlists;
- GEM_TRACE("%s\n", engine->name);
+ GEM_TRACE("%s: depth<-%d\n", engine->name,
+ atomic_read(>tasklet.count));
/*
* Prevent request submission to the hardware until we have
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/23] drm/i915/dp: Markup pps lock power well
Track where and when we acquire and release the power well for pps
access along the dp aux link, with a view to detecting if we leak any
wakerefs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_dp.c | 227 +---
1 file changed, 118 insertions(+), 109 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b4c22c0bc595..c83dca0f06b8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -659,28 +659,35 @@ intel_dp_init_panel_power_sequencer_registers(struct
intel_dp *intel_dp,
static void
intel_dp_pps_init(struct intel_dp *intel_dp);
-static void pps_lock(struct intel_dp *intel_dp)
+static intel_wakeref_t pps_lock(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
+ intel_wakeref_t wakeref;
/*
* See intel_power_sequencer_reset() why we need
* a power domain reference here.
*/
- intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
+ wakeref = intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
mutex_lock(_priv->pps_mutex);
+
+ return wakeref;
}
-static void pps_unlock(struct intel_dp *intel_dp)
+static intel_wakeref_t pps_unlock(struct intel_dp *intel_dp, intel_wakeref_t
wakeref)
{
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
mutex_unlock(_priv->pps_mutex);
- intel_display_power_put_unchecked(dev_priv, intel_dp->aux_power_domain);
+ intel_display_power_put(dev_priv, intel_dp->aux_power_domain, wakeref);
+ return 0;
}
+#define with_pps_lock(dp, wf) \
+ for (wf = pps_lock(dp); wf; wf = pps_unlock(dp, wf))
+
static void
vlv_power_sequencer_kick(struct intel_dp *intel_dp)
{
@@ -1026,33 +1033,33 @@ _pp_stat_reg(struct intel_dp *intel_dp)
static int edp_notify_handler(struct notifier_block *this, unsigned long code,
void *unused)
{
- struct intel_dp *intel_dp = container_of(this, typeof(* intel_dp),
-edp_notifier);
+ struct intel_dp *intel_dp =
+ container_of(this, typeof(* intel_dp), edp_notifier);
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
+ intel_wakeref_t wakeref;
if (!intel_dp_is_edp(intel_dp) || code != SYS_RESTART)
return 0;
- pps_lock(intel_dp);
-
- if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
- enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
- i915_reg_t pp_ctrl_reg, pp_div_reg;
- u32 pp_div;
-
- pp_ctrl_reg = PP_CONTROL(pipe);
- pp_div_reg = PP_DIVISOR(pipe);
- pp_div = I915_READ(pp_div_reg);
- pp_div &= PP_REFERENCE_DIVIDER_MASK;
-
- /* 0x1F write to PP_DIV_REG sets max cycle delay */
- I915_WRITE(pp_div_reg, pp_div | 0x1F);
- I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
- msleep(intel_dp->panel_power_cycle_delay);
+ with_pps_lock(intel_dp, wakeref) {
+ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+ enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
+ i915_reg_t pp_ctrl_reg, pp_div_reg;
+ u32 pp_div;
+
+ pp_ctrl_reg = PP_CONTROL(pipe);
+ pp_div_reg = PP_DIVISOR(pipe);
+ pp_div = I915_READ(pp_div_reg);
+ pp_div &= PP_REFERENCE_DIVIDER_MASK;
+
+ /* 0x1F write to PP_DIV_REG sets max cycle delay */
+ I915_WRITE(pp_div_reg, pp_div | 0x1F);
+ I915_WRITE(pp_ctrl_reg,
+ PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
+ msleep(intel_dp->panel_power_cycle_delay);
+ }
}
- pps_unlock(intel_dp);
-
return 0;
}
@@ -1238,16 +1245,17 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
to_i915(intel_dig_port->base.base.dev);
i915_reg_t ch_ctl, ch_data[5];
uint32_t aux_clock_divider;
+ intel_wakeref_t wakeref;
int i, ret, recv_bytes;
- uint32_t status;
int try, clock = 0;
+ uint32_t status;
bool vdd;
ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
for (i = 0; i < ARRAY_SIZE(ch_data); i++)
ch_data[i] = intel_dp->aux_ch_data_reg(intel_dp, i);
- pps_lock(intel_dp);
+ wakeref = pps_lock(intel_dp);
/*
* We will be called with VDD already enabled for dpcd/edid/oui reads.
@@ -1391,7 +1399,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
if (vdd)
edp_panel_vdd_off(intel_dp, false);
-
[Intel-gfx] [PATCH 22/23] drm/i915: Mark up Ironlake ips with rpm wakerefs
Currently Ironlake operates under the assumption that rpm awake (and its
error checking is disabled). As such, we have missed a few places where we
access registers without taking the rpm wakeref and thus trigger
warnings. intel_ips being one culprit.
As this involved adding a potentially sleeping rpm_get, we have to
rearrange the spinlocks slightly and so switch to acquiring a device-ref
under the spinlock rather than hold the spinlock for the whole
operation. To be consistent, we make the change in pattern common to the
intel_ips interface even though this adds a few more atomic operations
than necessary in a few cases.
v2: Sagar noted the mb around setting mch_dev were overkill as we only
need ordering there, and that i915_emon_status was still using
struct_mutex for no reason, but lacked rpm.
Signed-off-by: Chris Wilson
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_debugfs.c | 29 +++--
drivers/gpu/drm/i915/i915_drv.c | 3 +
drivers/gpu/drm/i915/intel_pm.c | 172 ++--
3 files changed, 103 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 74183340f97c..7e7f0730714d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1758,27 +1758,24 @@ static int i915_sr_status(struct seq_file *m, void
*unused)
static int i915_emon_status(struct seq_file *m, void *unused)
{
- struct drm_i915_private *dev_priv = node_to_i915(m->private);
- struct drm_device *dev = _priv->drm;
- unsigned long temp, chipset, gfx;
- int ret;
+ struct drm_i915_private *i915 = node_to_i915(m->private);
+ intel_wakeref_t wakeref;
- if (!IS_GEN5(dev_priv))
+ if (!IS_GEN5(i915))
return -ENODEV;
- ret = mutex_lock_interruptible(>struct_mutex);
- if (ret)
- return ret;
+ with_intel_runtime_pm(i915, wakeref) {
+ unsigned long temp, chipset, gfx;
- temp = i915_mch_val(dev_priv);
- chipset = i915_chipset_val(dev_priv);
- gfx = i915_gfx_val(dev_priv);
- mutex_unlock(>struct_mutex);
+ temp = i915_mch_val(i915);
+ chipset = i915_chipset_val(i915);
+ gfx = i915_gfx_val(i915);
- seq_printf(m, "GMCH temp: %ld\n", temp);
- seq_printf(m, "Chipset power: %ld\n", chipset);
- seq_printf(m, "GFX power: %ld\n", gfx);
- seq_printf(m, "Total power: %ld\n", chipset + gfx);
+ seq_printf(m, "GMCH temp: %ld\n", temp);
+ seq_printf(m, "Chipset power: %ld\n", chipset);
+ seq_printf(m, "GFX power: %ld\n", gfx);
+ seq_printf(m, "Total power: %ld\n", chipset + gfx);
+ }
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9c5efffebc95..ace7706d1d5e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1452,6 +1452,9 @@ void i915_driver_unload(struct drm_device *dev)
i915_driver_unregister(dev_priv);
+ /* Flush any external code that still may be under the RCU lock */
+ synchronize_rcu();
+
if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 409825ab890c..d10ded624025 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6141,10 +6141,6 @@ void intel_init_ipc(struct drm_i915_private *dev_priv)
*/
DEFINE_SPINLOCK(mchdev_lock);
-/* Global for IPS driver to get at the current i915 device. Protected by
- * mchdev_lock. */
-static struct drm_i915_private *i915_mch_dev;
-
bool ironlake_set_drps(struct drm_i915_private *dev_priv, u8 val)
{
u16 rgvswctl;
@@ -7787,16 +7783,17 @@ static unsigned long __i915_chipset_val(struct
drm_i915_private *dev_priv)
unsigned long i915_chipset_val(struct drm_i915_private *dev_priv)
{
- unsigned long val;
+ intel_wakeref_t wakeref;
+ unsigned long val = 0;
if (!IS_GEN5(dev_priv))
return 0;
- spin_lock_irq(_lock);
-
- val = __i915_chipset_val(dev_priv);
-
- spin_unlock_irq(_lock);
+ with_intel_runtime_pm(dev_priv, wakeref) {
+ spin_lock_irq(_lock);
+ val = __i915_chipset_val(dev_priv);
+ spin_unlock_irq(_lock);
+ }
return val;
}
@@ -7873,14 +7870,16 @@ static void __i915_update_gfx_val(struct
drm_i915_private *dev_priv)
void i915_update_gfx_val(struct drm_i915_private *dev_priv)
{
+ intel_wakeref_t wakeref;
+
if (!IS_GEN5(dev_priv))
return;
- spin_lock_irq(_lock);
-
- __i915_update_gfx_val(dev_priv);
-
- spin_unlock_irq(_lock);
+ with_intel_runtime_pm(dev_priv, wakeref) {
+ spin_lock_irq(_lock);
+
[Intel-gfx] [PATCH 19/23] drm/i915: Track the wakeref used to initialise display power domains
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
transfer them to the runtime-pm code. We can use our wakeref tracking to
verify that the wakeref is indeed passed from init to enable, and
disable to fini; and across suspend.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 133 +---
3 files changed, 79 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3a9b77ae37f4..74183340f97c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2690,6 +2690,9 @@ static int i915_runtime_pm_status(struct seq_file *m,
void *unused)
if (!HAS_RUNTIME_PM(dev_priv))
seq_puts(m, "Runtime power management not supported\n");
+ seq_printf(m, "Runtime power management: %s\n",
+ enableddisabled(!dev_priv->power_domains.wakeref));
+
seq_printf(m, "GPU idle: %s (epoch %u)\n",
yesno(!dev_priv->gt.awake), dev_priv->gt.epoch);
seq_printf(m, "IRQs disabled: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 712cb1e80e59..f8bd165c1f03 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -943,6 +943,8 @@ struct i915_power_domains {
bool display_core_suspended;
int power_well_count;
+ intel_wakeref_t wakeref;
+
struct mutex lock;
int domain_use_count[POWER_DOMAIN_NUM];
struct i915_power_well *power_wells;
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 7dffe8aca7a6..99e88a4ab49d 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -3973,7 +3973,7 @@ static void vlv_cmnlane_wa(struct drm_i915_private
*dev_priv)
/**
* intel_power_domains_init_hw - initialize hardware power domain state
- * @dev_priv: i915 device instance
+ * @i915: i915 device instance
* @resume: Called from resume code paths or not
*
* This function initializes the hardware power domain state and enables all
@@ -3986,27 +3986,27 @@ static void vlv_cmnlane_wa(struct drm_i915_private
*dev_priv)
* intel_power_domains_enable()) and must be paired with
* intel_power_domains_fini_hw().
*/
-void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool
resume)
+void intel_power_domains_init_hw(struct drm_i915_private *i915, bool resume)
{
- struct i915_power_domains *power_domains = _priv->power_domains;
+ struct i915_power_domains *power_domains = >power_domains;
power_domains->initializing = true;
- if (IS_ICELAKE(dev_priv)) {
- icl_display_core_init(dev_priv, resume);
- } else if (IS_CANNONLAKE(dev_priv)) {
- cnl_display_core_init(dev_priv, resume);
- } else if (IS_GEN9_BC(dev_priv)) {
- skl_display_core_init(dev_priv, resume);
- } else if (IS_GEN9_LP(dev_priv)) {
- bxt_display_core_init(dev_priv, resume);
- } else if (IS_CHERRYVIEW(dev_priv)) {
+ if (IS_ICELAKE(i915)) {
+ icl_display_core_init(i915, resume);
+ } else if (IS_CANNONLAKE(i915)) {
+ cnl_display_core_init(i915, resume);
+ } else if (IS_GEN9_BC(i915)) {
+ skl_display_core_init(i915, resume);
+ } else if (IS_GEN9_LP(i915)) {
+ bxt_display_core_init(i915, resume);
+ } else if (IS_CHERRYVIEW(i915)) {
mutex_lock(_domains->lock);
- chv_phy_control_init(dev_priv);
+ chv_phy_control_init(i915);
mutex_unlock(_domains->lock);
- } else if (IS_VALLEYVIEW(dev_priv)) {
+ } else if (IS_VALLEYVIEW(i915)) {
mutex_lock(_domains->lock);
- vlv_cmnlane_wa(dev_priv);
+ vlv_cmnlane_wa(i915);
mutex_unlock(_domains->lock);
}
@@ -4016,17 +4016,19 @@ void intel_power_domains_init_hw(struct
drm_i915_private *dev_priv, bool resume)
* resources powered until display HW readout is complete. We drop
* this reference in intel_power_domains_enable().
*/
- intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
+ power_domains->wakeref =
+ intel_display_power_get(i915, POWER_DOMAIN_INIT);
+
/* Disable power support if the user asked so. */
if (!i915_modparams.disable_power_well)
- intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
- intel_power_domains_sync_hw(dev_priv);
+ intel_display_power_get(i915, POWER_DOMAIN_INIT);
+ intel_power_domains_sync_hw(i915);
power_domains->initializing = false;
}
/**
* intel_power_domains_fini_hw - deinitialize hw power domain state
- * @dev_priv:
[Intel-gfx] [PATCH 16/23] drm/i915: Markup paired operations on wakerefs
The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various rpm_get functions to their rpm_put counterpart. This makes the pairing explicit, and given the required wakeref cookie the compiler can verify that we pass an initialised value to the rpm_put (quite handy for double checking error paths). For regular builds, the compiler should be able to eliminate the unused local variables and the program growth should be minimal. Fwiw, it came out as a net improvement as gcc was able to refactor rpm_get and rpm_get_if_in_use together, add/remove: 1/1 grow/shrink: 20/9 up/down: 191/-268 (-77) Function old new delta intel_runtime_pm_put_unchecked - 136+136 i915_gem_unpark 396 406 +10 intel_runtime_pm_get 135 141 +6 intel_runtime_pm_get_noresume136 141 +5 i915_perf_open_ioctl43754379 +4 i915_gpu_busy 72 76 +4 i915_gem_idle_work_handler 954 958 +4 capture 68146818 +4 mock_gem_device 14331436 +3 __execlists_submission_tasklet 25732576 +3 i915_sample 756 758 +2 intel_guc_submission_disable 364 365 +1 igt_mmap_offset_exhaustion 10351036 +1 i915_runtime_pm_status 257 258 +1 i915_rps_boost_info 13581359 +1 i915_hangcheck_info 12291230 +1 i915_gem_switch_to_kernel_context682 683 +1 i915_gem_suspend 410 411 +1 i915_gem_resume 254 255 +1 i915_gem_park190 191 +1 i915_engine_info 279 280 +1 intel_rps_mark_interactive 194 193 -1 i915_hangcheck_elapsed 15261525 -1 i915_gem_wait_for_idle 298 297 -1 i915_drop_caches_set 555 554 -1 execlists_submission_tasklet 126 125 -1 aliasing_gtt_bind_vma235 234 -1 i915_gem_retire_work_handler 144 142 -2 igt_evict_contexts.part 916 910 -6 intel_runtime_pm_get_if_in_use 141 23-118 intel_runtime_pm_put 136 --136 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gvt/aperture_gm.c| 8 +- drivers/gpu/drm/i915/gvt/gvt.h| 2 +- drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +- drivers/gpu/drm/i915/gvt/scheduler.c | 4 +- drivers/gpu/drm/i915/i915_debugfs.c | 122 +++--- drivers/gpu/drm/i915/i915_drv.h | 6 +- drivers/gpu/drm/i915/i915_gem.c | 57 drivers/gpu/drm/i915/i915_gem_execbuffer.c| 5 +- drivers/gpu/drm/i915/i915_gem_fence_reg.c | 6 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 22 ++-- drivers/gpu/drm/i915/i915_gem_shrinker.c | 27 ++-- drivers/gpu/drm/i915/i915_irq.c | 5 +- drivers/gpu/drm/i915/i915_perf.c | 10 +- drivers/gpu/drm/i915/i915_pmu.c | 26 ++-- drivers/gpu/drm/i915/i915_sysfs.c | 24 ++-- drivers/gpu/drm/i915/intel_display.c | 5 +- drivers/gpu/drm/i915/intel_drv.h | 15 ++- drivers/gpu/drm/i915/intel_engine_cs.c| 12 +- drivers/gpu/drm/i915/intel_fbdev.c| 7 +- drivers/gpu/drm/i915/intel_guc_log.c | 15 ++- drivers/gpu/drm/i915/intel_hotplug.c | 5 +- drivers/gpu/drm/i915/intel_huc.c | 5 +- drivers/gpu/drm/i915/intel_panel.c| 5 +- drivers/gpu/drm/i915/intel_runtime_pm.c | 89 ++--- drivers/gpu/drm/i915/intel_uncore.c | 5 +- drivers/gpu/drm/i915/selftests/huge_pages.c | 5 +- .../gpu/drm/i915/selftests/i915_gem_context.c | 12 +- .../gpu/drm/i915/selftests/i915_gem_evict.c | 11 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 10 +- .../gpu/drm/i915/selftests/i915_gem_object.c | 18 ++- .../gpu/drm/i915/selftests/intel_hangcheck.c | 5 +- 31 files changed, 357 insertions(+), 193 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c b/drivers/gpu/drm/i915/gvt/aperture_gm.c index fe754022e356..6372ece10880 100644 --- a/drivers/gpu/drm/i915/gvt/aperture_gm.c +++
[Intel-gfx] [PATCH 21/23] drm/i915: Complain if hsw_get_pipe_config acquires the same power well twice
As we only release each power well once, we assume that each transcoder
maps to a different domain. Complain if this is not so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5d01144cced4..f5ee399240d1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9388,6 +9388,8 @@ static bool hsw_get_transcoder_state(struct intel_crtc
*crtc,
power_domain = POWER_DOMAIN_TRANSCODER(pipe_config->cpu_transcoder);
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
return false;
+
+ WARN_ON(*power_domain_mask & BIT_ULL(power_domain));
*power_domain_mask |= BIT_ULL(power_domain);
tmp = I915_READ(PIPECONF(pipe_config->cpu_transcoder));
@@ -9415,6 +9417,8 @@ static bool bxt_get_dsi_transcoder_state(struct
intel_crtc *crtc,
power_domain = POWER_DOMAIN_TRANSCODER(cpu_transcoder);
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
+
+ WARN_ON(*power_domain_mask & BIT_ULL(power_domain));
*power_domain_mask |= BIT_ULL(power_domain);
/*
@@ -9546,7 +9550,9 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
+ WARN_ON(power_domain_mask & BIT_ULL(power_domain));
power_domain_mask |= BIT_ULL(power_domain);
+
if (INTEL_GEN(dev_priv) >= 9)
skylake_get_pfit_config(crtc, pipe_config);
else
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 23/23] drm/i915: Enable runtime-pm debugging by default for CI
Select the runtime-pm kconfig option if the general i915 debug option is selected so that anyone using CI/IGT should be co-opted into enabling the extra debug tracking. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 8b277258f62e..20c185d88c7a 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -21,15 +21,16 @@ config DRM_I915_DEBUG select DEBUG_FS select PREEMPT_COUNT select I2C_CHARDEV +select STACKDEPOT select DRM_DP_AUX_CHARDEV select X86_MSR # used by igt/pm_rpm select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks) select DRM_DEBUG_MM if DRM=y -select STACKDEPOT if DRM=y # for DRM_DEBUG_MM select DRM_DEBUG_SELFTEST select SW_SYNC # signaling validation framework (igt/syncobj*) select DRM_I915_SW_FENCE_DEBUG_OBJECTS select DRM_I915_SELFTEST + select DRM_I915_DEBUG_RUNTIME_PM default n help Choose this option to turn on extra driver debugging that may affect -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/23] drm/i915: Missed interrupt simulation is no more, tell the world
Using the guc, we cannot disable the user interrupt generation as we use
it for driving submission. And from Icelake, we no longer have the
ability to individually mask interrupt generation from each engine,
disabling our ability to fake missed interrupts.
In both cases, report back to userspace that the missed interrupt
generator is no longer available.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7620a919e066..449fe7638474 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4110,6 +4110,17 @@ i915_ring_test_irq_set(void *data, u64 val)
{
struct drm_i915_private *i915 = data;
+ /* GuC keeps the user interrupt permanently enabled for submission */
+ if (USES_GUC_SUBMISSION(i915))
+ return -ENODEV;
+
+ /*
+* From icl, we can no longer individually mask interrupt generation
+* from each engine.
+*/
+ if (INTEL_GEN(i915) >= 11)
+ return -ENODEV;
+
val &= INTEL_INFO(i915)->ring_mask;
DRM_DEBUG_DRIVER("Masking interrupts on rings 0x%08llx\n", val);
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/23] drm/i915/execlists: Avoid kicking priority on the current context
If the request is currently on the HW (in port 0), then we do not need
to kick the submission tasklet to evaluate whether we should be
preempting itself in order to execute it again.
In the case that was annoying me:
execlists_schedule: rq(18:211173).prio=0 -> 2
need_preempt: last(18:211174).prio=0, queue.prio=2
We are bumping the priority of the first of a pair of requests running
in the current context. Then when evaluating preempt, we would see that
that our priority request is higher than the last executing request in
ELSP0 and so trigger preemption, not realising that our intended request
was already executing.
v2: As we assume state of the execlists->port[] that is only valid while
we hold the timeline lock we have to repeat some earlier tests that on
the validity of the node.
v3: Wrap guc submission under the timeline.lock as is now the way of all
things.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_guc_submission.c | 18 +++--
drivers/gpu/drm/i915/intel_lrc.c| 41 +++--
2 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 195adbd0ebf7..2f0d5155b1bb 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -764,19 +764,8 @@ static bool __guc_dequeue(struct intel_engine_cs *engine)
static void guc_dequeue(struct intel_engine_cs *engine)
{
- unsigned long flags;
- bool submit;
-
- local_irq_save(flags);
-
- spin_lock(>timeline.lock);
- submit = __guc_dequeue(engine);
- spin_unlock(>timeline.lock);
-
- if (submit)
+ if ( __guc_dequeue(engine))
guc_submit(engine);
-
- local_irq_restore(flags);
}
static void guc_submission_tasklet(unsigned long data)
@@ -785,6 +774,9 @@ static void guc_submission_tasklet(unsigned long data)
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port *port = execlists->port;
struct i915_request *rq;
+ unsigned long flags;
+
+ spin_lock_irqsave(>timeline.lock, flags);
rq = port_request(port);
while (rq && i915_request_completed(rq)) {
@@ -808,6 +800,8 @@ static void guc_submission_tasklet(unsigned long data)
if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT))
guc_dequeue(engine);
+
+ spin_unlock_irqrestore(>timeline.lock, flags);
}
static struct i915_request *
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..647b984b365f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -355,13 +355,8 @@ execlists_unwind_incomplete_requests(struct
intel_engine_execlists *execlists)
{
struct intel_engine_cs *engine =
container_of(execlists, typeof(*engine), execlists);
- unsigned long flags;
-
- spin_lock_irqsave(>timeline.lock, flags);
__unwind_incomplete_requests(engine);
-
- spin_unlock_irqrestore(>timeline.lock, flags);
}
static inline void
@@ -1233,9 +1228,13 @@ static void execlists_schedule(struct i915_request
*request,
engine = sched_lock_engine(node, engine);
+ /* Recheck after acquiring the engine->timeline.lock */
if (prio <= node->attr.priority)
continue;
+ if (i915_sched_node_signaled(node))
+ continue;
+
node->attr.priority = prio;
if (!list_empty(>link)) {
if (last != engine) {
@@ -1244,14 +1243,34 @@ static void execlists_schedule(struct i915_request
*request,
}
GEM_BUG_ON(pl->priority != prio);
list_move_tail(>link, >requests);
+ } else {
+ /*
+* If the request is not in the priolist queue because
+* it is not yet runnable, then it doesn't contribute
+* to our preemption decisions. On the other hand,
+* if the request is on the HW, it too is not in the
+* queue; but in that case we may still need to reorder
+* the inflight requests.
+*/
+ if
(!i915_sw_fence_done(_to_request(node)->submit))
+ continue;
}
- if (prio > engine->execlists.queue_priority &&
- i915_sw_fence_done(_to_request(node)->submit)) {
- /* defer submission until after all of our updates */
- __update_queue(engine, prio);
- tasklet_hi_schedule(>execlists.tasklet);
- }
+ if (prio <=
[Intel-gfx] [PATCH 06/23] drm/i915/execlists: Use coherent writes into the context image
That we use a WB mapping for updating the RING_TAIL register inside the
context image even on !llc machines has been a source of consternation
for every reader. It appears to work on bsw+, but it may just have been
that we have been incredibly bad at detecting the errors.
v2: With extra enthusiasm.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_perf.c| 3 ++-
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 8 +---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
6 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e5b9d3c77139..b6eea715d506 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3070,6 +3070,12 @@ enum i915_map_type {
I915_MAP_FORCE_WC = I915_MAP_WC | I915_MAP_OVERRIDE,
};
+static inline enum i915_map_type
+i915_coherent_map_type(struct drm_i915_private *i915)
+{
+ return HAS_LLC(i915) ? I915_MAP_WB : I915_MAP_WC;
+}
+
/**
* i915_gem_object_pin_map - return a contiguous mapping of the entire object
* @obj: the object to map into kernel address space
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0453eb42a1a3..71832e2c85ad 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5404,6 +5404,8 @@ static int __intel_engines_record_defaults(struct
drm_i915_private *i915)
for_each_engine(engine, i915, id) {
struct i915_vma *state;
+ GEM_BUG_ON(to_intel_context(ctx, engine)->pin_count);
+
state = to_intel_context(ctx, engine)->state;
if (!state)
continue;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 0376338d1f8d..d2ba7a641866 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1849,7 +1849,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
if (!ce->state)
continue;
- regs = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
+ regs = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(dev_priv));
if (IS_ERR(regs)) {
ret = PTR_ERR(regs);
goto out;
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 8628567d8f6e..2579151c1e05 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1157,7 +1157,7 @@ void intel_engines_unpark(struct drm_i915_private *i915)
map = NULL;
if (engine->default_state)
map = i915_gem_object_pin_map(engine->default_state,
- I915_MAP_WB);
+ I915_MAP_FORCE_WB);
if (!IS_ERR_OR_NULL(map))
engine->pinned_default_state = map;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 803f22ab275c..4b9ae2d9bbbe 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1311,7 +1311,7 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
* on an active context (which by nature is already on the GPU).
*/
if (!(vma->flags & I915_VMA_GLOBAL_BIND)) {
- err = i915_gem_object_set_to_gtt_domain(vma->obj, true);
+ err = i915_gem_object_set_to_wc_domain(vma->obj, true);
if (err)
return err;
}
@@ -1339,7 +1339,9 @@ __execlists_context_pin(struct intel_engine_cs *engine,
if (ret)
goto err;
- vaddr = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(ctx->i915) |
+ I915_MAP_OVERRIDE);
if (IS_ERR(vaddr)) {
ret = PTR_ERR(vaddr);
goto unpin_vma;
@@ -2706,7 +2708,7 @@ populate_lr_context(struct i915_gem_context *ctx,
void *defaults;
defaults = i915_gem_object_pin_map(engine->default_state,
- I915_MAP_WB);
+ I915_MAP_FORCE_WB);
if (IS_ERR(defaults)) {
ret = PTR_ERR(defaults);
goto err_unpin_ctx;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index d40f55a8dc34..3d82f6b5c229 100644
---
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume (rev2)
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume (rev2) URL : https://patchwork.freedesktop.org/series/48310/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4680_full -> Patchwork_9964_full = == Summary - SUCCESS == No regressions found. == Changes == No changes found == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4680 -> Patchwork_9964 CI_DRM_4680: c0adc75a6340ba5a3f9cf07c5064627ee73b9ba9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4603: 1598fdb717546e25e8077935daa8e97768ad245d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9964: b4088e6d50cf60b7cd68152b5a81bf7d7ad77128 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9964/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave, Here goes drm-intel-next-fixes-2018-08-16-1: Fixes for: - DP full color range. - selftest for gem_object - forcewake on suspend - GPU reset This also include accumulated fixes from GVT: - Fix an error code in gvt_dma_map_page() (Dan) - Fix off by one error in intel_vgpu_write_fence() (Dan) - Fix potential Spectre v1 (Gustavo) - Fix workload free in vgpu release (Henry) - Fix cleanup sequence in intel_gvt_clean_device (Henry) - dmabuf mutex init place fix (Henry) - possible memory leak in intel_vgpu_ioctl() err path (Yi) - return error on cmd access check failure (Yan) Thanks, Rodrigo. The following changes since commit 557ce95051c8eff67af48612ab350d8408aa0541: Merge branch 'drm-next-4.19' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-08-10 11:43:02 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2018-08-16-1 for you to fetch changes up to 4795ac626a2fe5ce99ff788080ace343faf4c886: Merge tag 'gvt-next-fixes-2018-08-14' of https://github.com/intel/gvt-linux into drm-intel-next-fixes (2018-08-15 13:42:32 -0700) Fixes for: - DP full color range. - selftest for gem_object - forcewake on suspend - GPU reset This also include accumulated fixes from GVT: - Fix an error code in gvt_dma_map_page() (Dan) - Fix off by one error in intel_vgpu_write_fence() (Dan) - Fix potential Spectre v1 (Gustavo) - Fix workload free in vgpu release (Henry) - Fix cleanup sequence in intel_gvt_clean_device (Henry) - dmabuf mutex init place fix (Henry) - possible memory leak in intel_vgpu_ioctl() err path (Yi) - return error on cmd access check failure (Yan) Chris Wilson (3): drm/i915: Unmask user interrupts writes into HWSP on snb/ivb/vlv/hsw drm/i915: Restore user forcewake domains across suspend drm/i915/selftests: Hold rpm for unparking Dan Carpenter (2): drm/i915/kvmgt: fix an error code in gvt_dma_map_page() drm/i915/gvt: Off by one in intel_vgpu_write_fence() Gustavo A. R. Silva (1): drm/i915/kvmgt: Fix potential Spectre v1 Hang Yuan (3): drm/i915/gvt: free workload in vgpu release drm/i915/gvt: fix cleanup sequence in intel_gvt_clean_device drm/i915/gvt: initialize dmabuf mutex in vgpu_create Jani Nikula (1): drm/i915: set DP Main Stream Attribute for color range on DDI platforms Rodrigo Vivi (1): Merge tag 'gvt-next-fixes-2018-08-14' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Yi Wang (1): drm/i915/gvt: fix memory leak in intel_vgpu_ioctl() Zhao Yan (1): drm/i915/gvt: return error on cmd access drivers/gpu/drm/i915/gvt/aperture_gm.c | 2 +- drivers/gpu/drm/i915/gvt/cmd_parser.c| 2 +- drivers/gpu/drm/i915/gvt/gvt.c | 15 drivers/gpu/drm/i915/gvt/gvt.h | 4 ++- drivers/gpu/drm/i915/gvt/kvmgt.c | 26 +- drivers/gpu/drm/i915/gvt/scheduler.c | 7 ++-- drivers/gpu/drm/i915/gvt/scheduler.h | 3 ++ drivers/gpu/drm/i915/gvt/vgpu.c | 23 ++-- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_ddi.c | 4 +++ drivers/gpu/drm/i915/intel_ringbuffer.c | 14 ++-- drivers/gpu/drm/i915/intel_uncore.c | 46 +--- drivers/gpu/drm/i915/intel_uncore.h | 1 + drivers/gpu/drm/i915/selftests/i915_gem_object.c | 20 +++ drivers/gpu/drm/i915/selftests/intel_uncore.c| 2 +- 15 files changed, 117 insertions(+), 53 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/3] drm/i915: remove confusing GPIO vs PCH_GPIO
On Thu, Aug 16, 2018 at 11:49:26AM -0700, Rodrigo Vivi wrote:
> On Fri, Jul 27, 2018 at 12:36:47PM -0700, Lucas De Marchi wrote:
> > Instead of defining all registers twice, define just a PCH_GPIO_BASE
> > that has the same address as PCH_GPIO_A and use that to calculate all
> > the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing
> > the same thing.
> >
> > v2: Fix GMBUS registers to be relative to gpio base; create GPIO()
> > macro to return a particular gpio address and move the enum out of
> > i915_reg.h (suggested by Jani)
> >
> > v3: Move base offset inside the GPIO() macro so the GMBUS defines don't
> > actually need to be changed (suggested by Daniel/Ville)
> >
> > v4: Move definition of i915_gpio to intel_display.h and remove
> > GMBUS/GPIO handling from gvt since now they have their own
> > defines.
> >
> > Signed-off-by: Lucas De Marchi
>
> Reviewed-by: Rodrigo Vivi
and pushed
>
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> > drivers/gpu/drm/i915/i915_reg.h | 24 +---
> > drivers/gpu/drm/i915/intel_display.h | 16
> > drivers/gpu/drm/i915/intel_i2c.c | 16
> > 4 files changed, 31 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 0f49f9988dfa..19ad2a52ab04 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1604,7 +1604,8 @@ struct drm_i915_private {
> > struct mutex gmbus_mutex;
> >
> > /**
> > -* Base address of the gmbus and gpio block.
> > +* Base address of where the gmbus and gpio blocks are located (either
> > +* on PCH or on SoC for platforms without PCH).
> > */
> > uint32_t gpio_mmio_base;
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 07606677168c..827d442e1b12 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3168,18 +3168,9 @@ enum i915_power_well_id {
> > /*
> > * GPIO regs
> > */
> > -#define GPIOA _MMIO(0x5010)
> > -#define GPIOB _MMIO(0x5014)
> > -#define GPIOC _MMIO(0x5018)
> > -#define GPIOD _MMIO(0x501c)
> > -#define GPIOE _MMIO(0x5020)
> > -#define GPIOF _MMIO(0x5024)
> > -#define GPIOG _MMIO(0x5028)
> > -#define GPIOH _MMIO(0x502c)
> > -#define GPIOJ _MMIO(0x5034)
> > -#define GPIOK _MMIO(0x5038)
> > -#define GPIOL _MMIO(0x503C)
> > -#define GPIOM _MMIO(0x5040)
> > +#define GPIO(gpio) _MMIO(dev_priv->gpio_mmio_base + 0x5010 + \
> > + 4 * (gpio))
> > +
> > # define GPIO_CLOCK_DIR_MASK (1 << 0)
> > # define GPIO_CLOCK_DIR_IN (0 << 1)
> > # define GPIO_CLOCK_DIR_OUT(1 << 1)
> > @@ -7574,6 +7565,8 @@ enum {
> >
> > /* PCH */
> >
> > +#define PCH_DISPLAY_BASE 0xcu
> > +
> > /* south display engine interrupt: IBX */
> > #define SDE_AUDIO_POWER_D (1 << 27)
> > #define SDE_AUDIO_POWER_C (1 << 26)
> > @@ -7868,13 +7861,6 @@ enum {
> > #define ICP_TC_HPD_LONG_DETECT(tc_port) (2 << (tc_port) * 4)
> > #define ICP_TC_HPD_SHORT_DETECT(tc_port) (1 << (tc_port) * 4)
> >
> > -#define PCH_GPIOA _MMIO(0xc5010)
> > -#define PCH_GPIOB _MMIO(0xc5014)
> > -#define PCH_GPIOC _MMIO(0xc5018)
> > -#define PCH_GPIOD _MMIO(0xc501c)
> > -#define PCH_GPIOE _MMIO(0xc5020)
> > -#define PCH_GPIOF _MMIO(0xc5024)
> > -
> > #define _PCH_DPLL_A 0xc6014
> > #define _PCH_DPLL_B 0xc6018
> > #define PCH_DPLL(pll) _MMIO((pll) == 0 ? _PCH_DPLL_A : _PCH_DPLL_B)
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index 0a79a46d5805..e7f49f107e57 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -25,6 +25,22 @@
> > #ifndef _INTEL_DISPLAY_H_
> > #define _INTEL_DISPLAY_H_
> >
> > +enum i915_gpio {
> > + GPIOA,
> > + GPIOB,
> > + GPIOC,
> > + GPIOD,
> > + GPIOE,
> > + GPIOF,
> > + GPIOG,
> > + GPIOH,
> > + __GPIOI_UNUSED,
> > + GPIOJ,
> > + GPIOK,
> > + GPIOL,
> > + GPIOM,
> > +};
> > +
> > enum pipe {
> > INVALID_PIPE = -1,
> >
> > diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> > b/drivers/gpu/drm/i915/intel_i2c.c
> > index bef32b7c248e..33d87ab93fdd 100644
> > --- a/drivers/gpu/drm/i915/intel_i2c.c
> > +++ b/drivers/gpu/drm/i915/intel_i2c.c
> > @@ -37,7 +37,7 @@
> >
> > struct gmbus_pin {
> > const char *name;
> > - i915_reg_t reg;
> > + enum i915_gpio gpio;
> > };
> >
> > /* Map gmbus pin pairs to names and
Re: [Intel-gfx] [PATCH v4 3/3] drm/i915: remove confusing GPIO vs PCH_GPIO
On Fri, Jul 27, 2018 at 12:36:47PM -0700, Lucas De Marchi wrote:
> Instead of defining all registers twice, define just a PCH_GPIO_BASE
> that has the same address as PCH_GPIO_A and use that to calculate all
> the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing
> the same thing.
>
> v2: Fix GMBUS registers to be relative to gpio base; create GPIO()
> macro to return a particular gpio address and move the enum out of
> i915_reg.h (suggested by Jani)
>
> v3: Move base offset inside the GPIO() macro so the GMBUS defines don't
> actually need to be changed (suggested by Daniel/Ville)
>
> v4: Move definition of i915_gpio to intel_display.h and remove
> GMBUS/GPIO handling from gvt since now they have their own
> defines.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> drivers/gpu/drm/i915/i915_reg.h | 24 +---
> drivers/gpu/drm/i915/intel_display.h | 16
> drivers/gpu/drm/i915/intel_i2c.c | 16
> 4 files changed, 31 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0f49f9988dfa..19ad2a52ab04 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1604,7 +1604,8 @@ struct drm_i915_private {
> struct mutex gmbus_mutex;
>
> /**
> - * Base address of the gmbus and gpio block.
> + * Base address of where the gmbus and gpio blocks are located (either
> + * on PCH or on SoC for platforms without PCH).
>*/
> uint32_t gpio_mmio_base;
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 07606677168c..827d442e1b12 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3168,18 +3168,9 @@ enum i915_power_well_id {
> /*
> * GPIO regs
> */
> -#define GPIOA_MMIO(0x5010)
> -#define GPIOB_MMIO(0x5014)
> -#define GPIOC_MMIO(0x5018)
> -#define GPIOD_MMIO(0x501c)
> -#define GPIOE_MMIO(0x5020)
> -#define GPIOF_MMIO(0x5024)
> -#define GPIOG_MMIO(0x5028)
> -#define GPIOH_MMIO(0x502c)
> -#define GPIOJ_MMIO(0x5034)
> -#define GPIOK_MMIO(0x5038)
> -#define GPIOL_MMIO(0x503C)
> -#define GPIOM_MMIO(0x5040)
> +#define GPIO(gpio) _MMIO(dev_priv->gpio_mmio_base + 0x5010 + \
> + 4 * (gpio))
> +
> # define GPIO_CLOCK_DIR_MASK (1 << 0)
> # define GPIO_CLOCK_DIR_IN (0 << 1)
> # define GPIO_CLOCK_DIR_OUT (1 << 1)
> @@ -7574,6 +7565,8 @@ enum {
>
> /* PCH */
>
> +#define PCH_DISPLAY_BASE 0xcu
> +
> /* south display engine interrupt: IBX */
> #define SDE_AUDIO_POWER_D(1 << 27)
> #define SDE_AUDIO_POWER_C(1 << 26)
> @@ -7868,13 +7861,6 @@ enum {
> #define ICP_TC_HPD_LONG_DETECT(tc_port)(2 << (tc_port) * 4)
> #define ICP_TC_HPD_SHORT_DETECT(tc_port) (1 << (tc_port) * 4)
>
> -#define PCH_GPIOA _MMIO(0xc5010)
> -#define PCH_GPIOB _MMIO(0xc5014)
> -#define PCH_GPIOC _MMIO(0xc5018)
> -#define PCH_GPIOD _MMIO(0xc501c)
> -#define PCH_GPIOE _MMIO(0xc5020)
> -#define PCH_GPIOF _MMIO(0xc5024)
> -
> #define _PCH_DPLL_A 0xc6014
> #define _PCH_DPLL_B 0xc6018
> #define PCH_DPLL(pll) _MMIO((pll) == 0 ? _PCH_DPLL_A : _PCH_DPLL_B)
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 0a79a46d5805..e7f49f107e57 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -25,6 +25,22 @@
> #ifndef _INTEL_DISPLAY_H_
> #define _INTEL_DISPLAY_H_
>
> +enum i915_gpio {
> + GPIOA,
> + GPIOB,
> + GPIOC,
> + GPIOD,
> + GPIOE,
> + GPIOF,
> + GPIOG,
> + GPIOH,
> + __GPIOI_UNUSED,
> + GPIOJ,
> + GPIOK,
> + GPIOL,
> + GPIOM,
> +};
> +
> enum pipe {
> INVALID_PIPE = -1,
>
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index bef32b7c248e..33d87ab93fdd 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -37,7 +37,7 @@
>
> struct gmbus_pin {
> const char *name;
> - i915_reg_t reg;
> + enum i915_gpio gpio;
> };
>
> /* Map gmbus pin pairs to names and registers. */
> @@ -121,8 +121,7 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private
> *dev_priv,
> else
> size = ARRAY_SIZE(gmbus_pins);
>
> - return pin < size &&
> - i915_mmio_reg_valid(get_gmbus_pin(dev_priv, pin)->reg);
> +
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
On Thu, Aug 16, 2018 at 10:36:43AM +0200, Fredrik Schön wrote:
> Shashank,
>
> Den tors 16 aug. 2018 kl 10:15 skrev Sharma, Shashank
> :
> >
> > Hey Chris,
> >
> >
> > On 8/16/2018 1:13 PM, Chris Wilson wrote:
> > > Quoting Sharma, Shashank (2018-08-16 08:33:36)
> > >> Regards
> > >>
> > >> Shashank
> > >>
> > >>
> > >> On 8/16/2018 12:47 PM, Jani Nikula wrote:
> > >>> On Wed, 15 Aug 2018, Rodrigo Vivi wrote:
> > On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
> > > On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wrote:
> > >
> > > First of all we need to fix the commit subject:
> > >
> > > drm/i915: Increase LSPCON timeout
> > >
> > > (this can be done when merging, no need to resend)
> > >
> > >> 100 ms is not enough time for the LSPCON adapter on Intel NUC
> > >> devices to
> > >> settle. This causes dropped display modes at driver initialisation.
> > >>
> > >> Increase timeout to 1000 ms.
> > >>
> > >> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> > > Missusage of "Fixes:" tag, please read
> > >
> > > https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
> > >
> > > But also no need for resending... could be fixed when merging
> > >
> > > The right one would be:
> > >
> > > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> > > Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode
> > > to settle")
> > > Cc: Shashank Sharma
> > > Cc: Imre Deak
> > > Cc: Jani Nikula
> > > Cc: # v4.11+
> > >
> > > Since initial 100 seemed to be empirical and this increase seems to
> > > help other cases I'm in favor of this move so
> > >
> > > Reviewed-by: Rodrigo Vivi
> > >
> > > However I will wait a bit before merging it
> > > so Imre, Shashank, and/or Jani can take a look here...
> > now, really cc'ing them...
> > >>> Shashank? Does this slow down non-LSPCON paths?
> > >> This will slow down the lspcon probing and resume part, but both of them
> > >> happen only when LSPCON device is found. So to answer your question,
> > >> this will not slow down the non-lspcon path, but will slow down the
> > >> LSPCON connector resume and probe time. but I would recommend, instead
> > >> of increasing it to 1000 ms in a single shot, we might want to gradually
> > >> pick this up, on a wake-and-check way.
> > > wait_for() checks every [10us, 1ms] until the condition is met, or it
> > > times out. So, so long as we don't enter this path for !LPSCON where we
> > > know that it will timeout, the wait_for() will only take as long as is
> > > required for the connector to settle.
> > We wont hit !LSPCON timeout case here, as we have already read the
> > dongle signature successfully by now. But I was thinking that, if the
> > spec recommends max wait time as 100ms (which is of course doesn't seem
> > enough), if we can't detect i2c-over-aux after first 500ms, I guess we
> > wont be able to do that in next 500ms too. So is it really ok to wait
> > this long in the resume sequence ?
> >
> > I guess Fredrik can provide some inputs here on if there are some
> > experiments behind this number of 1000ms, or this is just a safe bet ?
> > >
>
> My first patch attempt - which is attached to the Redhat and FDO Bugzilla
> bugs - added a retry loop around the original 100 ms timeout. The retry loop
> did trigger, but never more than once in a row in my testing.
>
> So possibly 200 ms would be a sufficient timeout, but as the wait_for() loop
> terminates early on success I suggested a conservative value of 1000 ms.
Since Shashank mentioned 100us came from some spec, maybe the double is already
a conservative value.
Since there is the concerns of delaying something when LSPCON fails
and we are possibly looping on connectors somewhere/somehow I believe we need
to have a balanced approach here.
could you please try the 200 ms approach on your case there for a while and
see how it goes?
>
> > > Can we do other connectors at the same time, or does probing LSPCON
> > > block the system?
> > We can do other connectors at the same time in DRM layer at-least,
> > LSPCON blocks only this connector. I was curious if are we doing this
> > during the resume scenario or is this in the sequential get_connector()
> > type of call ?
> > - Shashank
> > > -Chris
> /F
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib: Poll for snd_hda_intel discovery
Loading the sounds modules is asynchronous with the sysfs device
hierarchy being instantiated sometime after modprobe returns. As such
while we are probing for the sound device, poll a few times to
accommodate the async discovery.
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: Tvrtko Ursulin
---
lib/igt_pm.c | 65 +---
1 file changed, 41 insertions(+), 24 deletions(-)
diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 6e96db22b..f82707231 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -138,31 +138,17 @@ static void strchomp(char *str)
str[len - 1] = 0;
}
-/**
- * igt_pm_enable_audio_runtime_pm:
- *
- * We know that if we don't enable audio runtime PM, snd_hda_intel will never
- * release its power well refcount, and we'll never reach the LPSP state.
- * There's no guarantee that it will release the power well if we enable
- * runtime PM, but at least we can try.
- *
- * We don't have any assertions on open since the user may not even have
- * snd_hda_intel loaded, which is not a problem.
- */
-void igt_pm_enable_audio_runtime_pm(void)
+static int __igt_pm_enable_audio_runtime_pm(void)
{
char *path = NULL;
struct dirent *de;
DIR *dir;
+ int err;
int fd;
- /* Check if already enabled. */
- if (__igt_pm_audio_runtime_power_save[0])
- return;
-
dir = opendir("/sys/class/sound");
if (!dir)
- return;
+ return 0;
/* Find PCI device claimed by snd_hda_intel and tied to i915. */
while ((de = readdir(dir))) {
@@ -196,18 +182,17 @@ void igt_pm_enable_audio_runtime_pm(void)
de->d_name));
igt_debug("Audio device path is %s\n", path);
-
break;
}
fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
if (fd < 0)
- return;
+ return 0;
/* snd_hda_intel loaded but no path found is an error. */
if (!path) {
close(fd);
- errno = ESRCH;
+ err = -ESRCH;
goto err;
}
@@ -219,8 +204,10 @@ void igt_pm_enable_audio_runtime_pm(void)
close(fd);
fd = open(path, O_RDWR);
- if (fd < 0)
+ if (fd < 0) {
+ err = -errno;
goto err;
+ }
igt_assert(read(fd, __igt_pm_audio_runtime_control,
sizeof(__igt_pm_audio_runtime_control)) > 0);
@@ -236,12 +223,42 @@ void igt_pm_enable_audio_runtime_pm(void)
/* Give some time for it to react. */
sleep(1);
-
- return;
+ return 0;
err:
- igt_warn("Failed to enable audio runtime PM! (%d)", errno);
free(path);
+ return err;
+}
+
+/**
+ * igt_pm_enable_audio_runtime_pm:
+ *
+ * We know that if we don't enable audio runtime PM, snd_hda_intel will never
+ * release its power well refcount, and we'll never reach the LPSP state.
+ * There's no guarantee that it will release the power well if we enable
+ * runtime PM, but at least we can try.
+ *
+ * We don't have any assertions on open since the user may not even have
+ * snd_hda_intel loaded, which is not a problem.
+ */
+void igt_pm_enable_audio_runtime_pm(void)
+{
+ int err;
+
+ /* Check if already enabled. */
+ if (__igt_pm_audio_runtime_power_save[0])
+ return;
+
+ for (int count = 0; count < 5; count++) {
+ err = __igt_pm_enable_audio_runtime_pm();
+ if (!err)
+ return;
+
+ /* modprobe(sna-hda-intel) is async so poll for sysfs */
+ sleep(1);
+ }
+
+ igt_warn("Failed to enable audio runtime PM! (%d)\n", -err);
}
/**
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] v3 drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"
On Wed, Aug 08, 2018 at 10:53:35AM +0200, Jan-Marek Glogowski wrote:
> This re-applies the workaround for "some DP sinks, [which] are a
> little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
> quality check unconditionally during long pulse").
> It makes the secondary AOC E2460P monitor connected via DP to an
> acer Veriton N4640G usable again.
Would be nice to add in the commit message that this sink sends a
long pulse to indicate link loss, hence check link status during long pulse.
If there is a FDO bug associated with this you could also add the
Bugzilla link before Sign off tag.
But other than that this looks good to me.
Manasi
>
> This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST
> DP link retraining into the ->post_hotplug() hook")
>
> Signed-off-by: Jan-Marek Glogowski
> ---
> drivers/gpu/drm/i915/intel_dp.c | 33 +++--
> 1 file changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8e0e14b..22b2452 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4333,18 +4333,6 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> }
>
> -/*
> - * If display is now connected check links status,
> - * there has been known issues of link loss triggering
> - * long pulse.
> - *
> - * Some sinks (eg. ASUS PB287Q) seem to perform some
> - * weird HPD ping pong during modesets. So we can apparently
> - * end up with HPD going low during a modeset, and then
> - * going back up soon after. And once that happens we must
> - * retrain the link to get a picture. That's in case no
> - * userspace component reacted to intermittent HPD dip.
> - */
> int intel_dp_retrain_link(struct intel_encoder *encoder,
> struct drm_modeset_acquire_ctx *ctx)
> {
> @@ -4923,7 +4911,8 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> }
>
> static int
> -intel_dp_long_pulse(struct intel_connector *connector)
> +intel_dp_long_pulse(struct intel_connector *connector,
> + struct drm_modeset_acquire_ctx *ctx)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_dp *intel_dp = intel_attached_dp(>base);
> @@ -4982,6 +4971,22 @@ intel_dp_long_pulse(struct intel_connector *connector)
>*/
> status = connector_status_disconnected;
> goto out;
> + } else {
> + /*
> + * If display is now connected check links status,
> + * there has been known issues of link loss triggering
> + * long pulse.
> + *
> + * Some sinks (eg. ASUS PB287Q) seem to perform some
> + * weird HPD ping pong during modesets. So we can apparently
> + * end up with HPD going low during a modeset, and then
> + * going back up soon after. And once that happens we must
> + * retrain the link to get a picture. That's in case no
> + * userspace component reacted to intermittent HPD dip.
> + */
> + struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> +
> + intel_dp_retrain_link(encoder, ctx);
> }
>
> /*
> @@ -5043,7 +5048,7 @@ intel_dp_detect(struct drm_connector *connector,
> return ret;
> }
>
> - status = intel_dp_long_pulse(intel_dp->attached_connector);
> + status = intel_dp_long_pulse(intel_dp->attached_connector, ctx);
> }
>
> intel_dp->detect_done = false;
> --
> 2.1.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/3] igt/gem_sync: Exercise sync after context switch
Quoting Antonio Argenziano (2018-08-16 18:42:17)
>
>
> On 16/08/18 00:08, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-08-16 00:59:30)
> >>
> >>
> >> On 15/08/18 10:24, Chris Wilson wrote:
> >>> Quoting Antonio Argenziano (2018-08-15 18:20:10)
>
>
> On 15/08/18 03:26, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-08-15 00:50:43)
> >>
> >>
> >> On 10/08/18 04:01, Chris Wilson wrote:
> >>> This exercises a special case that may be of interest, waiting for a
> >>> context that may be preempted in order to reduce the wait.
> >>>
> >>> Signed-off-by: Chris Wilson
> >>> ---
> >>> + cycles = 0;
> >>> + elapsed = 0;
> >>> + start = gettime();
> >>> + do {
> >>> + do {
> >>> + double this;
> >>> +
> >>> + gem_execbuf(fd, [0].execbuf);
> >>> + gem_execbuf(fd, [1].execbuf);
> >>
> >> I'm not sure where the preemption, mentioned in the commit message, is
> >> coming in.
> >
> > Internally. I've suggested that we reorder equivalent contexts in order
> > to satisfy client waits earlier. So having created two independent
> > request queues, userspace should be oblivious to the execution order.
>
> But there isn't an assert because you don't want that to be part of the
> contract between the driver and userspace, is that correct?
> >>>
> >>> Correct. Userspace hasn't specified an order between the two contexts so
> >>> can't actually assert it happens in a particular order. We are free then
> >>> to do whatever we like, but that also means no assertion. Just the
> >>> figures look pretty and ofc we have to check that nothing actually
> >>> breaks.
> >>
> >> The last question I have is about the batches, why not choosing a spin
> >> batch so to make sure that context[0] (and [1]) hasn't completed by the
> >> time it starts waiting.
> >
> > It would be exercising fewer possibilities. Not that it would be any
> > less valid. (If I can't do a pair of trivial execbuf faster than the gpu
> > can execute a no-op from idle, shoot me. Each execbuf will take ~500ns,
> > the gpu will take 20-50us [bdw-kbl] to execute the first batch from idle.)
>
> It would generate some odd looking numbers anyways.
It would give an indirect measure of preemption latency. I think we have
a slightly better measure via gem_exec_latency, but it's an interesting
variation at least. Certainly deserves to be in the magic cookbook of
the ultimate microbenchmarks.
Too much magic, not enough casting, alas.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/3] igt/gem_sync: Exercise sync after context switch
On 16/08/18 00:08, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-16 00:59:30)
On 15/08/18 10:24, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-15 18:20:10)
On 15/08/18 03:26, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-15 00:50:43)
On 10/08/18 04:01, Chris Wilson wrote:
This exercises a special case that may be of interest, waiting for a
context that may be preempted in order to reduce the wait.
Signed-off-by: Chris Wilson
---
+ cycles = 0;
+ elapsed = 0;
+ start = gettime();
+ do {
+ do {
+ double this;
+
+ gem_execbuf(fd, [0].execbuf);
+ gem_execbuf(fd, [1].execbuf);
I'm not sure where the preemption, mentioned in the commit message, is
coming in.
Internally. I've suggested that we reorder equivalent contexts in order
to satisfy client waits earlier. So having created two independent
request queues, userspace should be oblivious to the execution order.
But there isn't an assert because you don't want that to be part of the
contract between the driver and userspace, is that correct?
Correct. Userspace hasn't specified an order between the two contexts so
can't actually assert it happens in a particular order. We are free then
to do whatever we like, but that also means no assertion. Just the
figures look pretty and ofc we have to check that nothing actually
breaks.
The last question I have is about the batches, why not choosing a spin
batch so to make sure that context[0] (and [1]) hasn't completed by the
time it starts waiting.
It would be exercising fewer possibilities. Not that it would be any
less valid. (If I can't do a pair of trivial execbuf faster than the gpu
can execute a no-op from idle, shoot me. Each execbuf will take ~500ns,
the gpu will take 20-50us [bdw-kbl] to execute the first batch from idle.)
It would generate some odd looking numbers anyways.
Reviewed-By: Antonio Argenziano
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm: Add P010, P012, P016 format definitions and fourcc
== Series Details == Series: series starting with [1/4] drm: Add P010, P012, P016 format definitions and fourcc URL : https://patchwork.freedesktop.org/series/48316/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4678_full -> Patchwork_9963_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9963_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9963_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_9963_full: === IGT changes === Warnings igt@kms_ccs@pipe-a-crc-sprite-planes-basic: shard-glk: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_9963_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_await@wide-contexts: shard-kbl: NOTRUN -> FAIL (fdo#105900) igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#105454, fdo#106509) Possible fixes igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4678 -> Patchwork_9963 CI_DRM_4678: 433fa6ccf8553afcc0159a996297b82bf50d1fac @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4603: 1598fdb717546e25e8077935daa8e97768ad245d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9963: 0b2785973f162407d58fb38784e80126cf2130bd @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9963/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume (rev2)
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Delay updating ring
register state after resume (rev2)
URL : https://patchwork.freedesktop.org/series/48310/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4680 -> Patchwork_9964 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48310/revisions/2/mbox/
== Known issues ==
Here are the changes found in Patchwork_9964 that come from known issues:
=== IGT changes ===
Issues hit
{igt@amdgpu/amd_basic@userptr}:
{fi-kbl-8809g}: PASS -> INCOMPLETE (fdo#107402)
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614)
{fi-byt-clapper}: PASS -> FAIL (fdo#103167)
Possible fixes
igt@drv_selftest@live_hangcheck:
fi-kbl-guc: DMESG-FAIL (fdo#106947) -> PASS
igt@kms_busy@basic-flip-a:
fi-kbl-r: DMESG-WARN (fdo#105602) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107402 https://bugs.freedesktop.org/show_bug.cgi?id=107402
== Participating hosts (52 -> 47) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4680 -> Patchwork_9964
CI_DRM_4680: c0adc75a6340ba5a3f9cf07c5064627ee73b9ba9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4603: 1598fdb717546e25e8077935daa8e97768ad245d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9964: b4088e6d50cf60b7cd68152b5a81bf7d7ad77128 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b4088e6d50cf drm/i915/execlists: Use coherent writes into the context image
b8bbc947a979 drm/i915/execlists: Delay updating ring register state after resume
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9964/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable
== Series Details == Series: series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable URL : https://patchwork.freedesktop.org/series/48315/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4678_full -> Patchwork_9962_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9962_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#105454, fdo#106509) fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4678 -> Patchwork_9962 CI_DRM_4678: 433fa6ccf8553afcc0159a996297b82bf50d1fac @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4603: 1598fdb717546e25e8077935daa8e97768ad245d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9962: 2e47b9b2aba3b18febcc6978f6c2b2d55f4d7ff1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9962/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume (rev2)
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume (rev2) URL : https://patchwork.freedesktop.org/series/48310/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/execlists: Delay updating ring register state after resume Okay! Commit: drm/i915/execlists: Use coherent writes into the context image -drivers/gpu/drm/i915/selftests/../i915_drv.h:3684:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3690:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume (rev2)
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume (rev2) URL : https://patchwork.freedesktop.org/series/48310/ State : warning == Summary == $ dim checkpatch origin/drm-tip b8bbc947a979 drm/i915/execlists: Delay updating ring register state after resume -:68: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV) #68: FILE: drivers/gpu/drm/i915/intel_lrc.c:2806: + ce->lrc_reg_state[CTX_RING_HEAD+1] = 0; ^ -:69: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV) #69: FILE: drivers/gpu/drm/i915/intel_lrc.c:2807: + ce->lrc_reg_state[CTX_RING_TAIL+1] = 0; ^ total: 0 errors, 0 warnings, 2 checks, 52 lines checked b4088e6d50cf drm/i915/execlists: Use coherent writes into the context image -:56: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #56: FILE: drivers/gpu/drm/i915/i915_perf.c:1853: + regs = i915_gem_object_pin_map(ce->state->obj, + i915_coherent_map_type(dev_priv)); total: 0 errors, 0 warnings, 1 checks, 71 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: enable P010, P012, P016 formats for primary and sprite planes
Op 16-08-18 om 14:55 schreef Juha-Pekka Heikkila:
> Enabling of P010, P012 and P016 formats. These formats will
> extend NV12 for larger bit depths.
>
> Signed-off-by: Juha-Pekka Heikkila
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 24 +-
> drivers/gpu/drm/i915/intel_sprite.c | 39
> +++-
> 2 files changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 80ce742..5c7dc96 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -104,6 +104,25 @@ static const uint32_t skl_pri_planar_formats[] = {
> DRM_FORMAT_NV12,
> };
>
> +static const uint32_t glk_primary_formats[] = {
> + DRM_FORMAT_C8,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_XRGB2101010,
> + DRM_FORMAT_XBGR2101010,
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_YVYU,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_VYUY,
> + DRM_FORMAT_NV12,
> + DRM_FORMAT_P010,
> + DRM_FORMAT_P012,
> + DRM_FORMAT_P016,
> +};
> +
> static const uint64_t skl_format_modifiers_noccs[] = {
> I915_FORMAT_MOD_Yf_TILED,
> I915_FORMAT_MOD_Y_TILED,
> @@ -13721,7 +13740,10 @@ intel_primary_plane_create(struct drm_i915_private
> *dev_priv, enum pipe pipe)
> primary->has_ccs = skl_plane_has_ccs(dev_priv, pipe,
>PLANE_PRIMARY);
>
> - if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY)) {
> + if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> + intel_primary_formats = glk_primary_formats;
> + num_formats = ARRAY_SIZE(glk_primary_formats);
> + } else if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY))
> {
> intel_primary_formats = skl_pri_planar_formats;
> num_formats = ARRAY_SIZE(skl_pri_planar_formats);
> } else {
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 68db026..5cc97ba 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1292,6 +1292,22 @@ static uint32_t skl_planar_formats[] = {
> DRM_FORMAT_NV12,
> };
>
> +static uint32_t glk_planar_formats[] = {
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_YVYU,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_VYUY,
> + DRM_FORMAT_NV12,
> + DRM_FORMAT_P010,
> + DRM_FORMAT_P012,
> + DRM_FORMAT_P016,
> +};
> +
> static const uint64_t skl_plane_format_modifiers_noccs[] = {
> I915_FORMAT_MOD_Yf_TILED,
> I915_FORMAT_MOD_Y_TILED,
> @@ -1537,7 +1553,28 @@ intel_sprite_plane_create(struct drm_i915_private
> *dev_priv,
> }
> intel_plane->base.state = >base;
>
> - if (INTEL_GEN(dev_priv) >= 9) {
> + if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> + intel_plane->can_scale = true;
> + state->scaler_id = -1;
> +
> + intel_plane->update_plane = skl_update_plane;
> + intel_plane->disable_plane = skl_disable_plane;
> + intel_plane->get_hw_state = skl_plane_get_hw_state;
> +
> + if (skl_plane_has_planar(dev_priv, pipe,
> + PLANE_SPRITE0 + plane)) {
> + plane_formats = glk_planar_formats;
> + num_plane_formats = ARRAY_SIZE(glk_planar_formats);
> + } else {
> + plane_formats = skl_plane_formats;
> + num_plane_formats = ARRAY_SIZE(skl_plane_formats);
> + }
> +
> + if (skl_plane_has_ccs(dev_priv, pipe, PLANE_SPRITE0 + plane))
> + modifiers = skl_plane_format_modifiers_ccs;
> + else
> + modifiers = skl_plane_format_modifiers_noccs;
> + } else if (INTEL_GEN(dev_priv) >= 9) {
> intel_plane->can_scale = true;
> state->scaler_id = -1;
>
Tested, still works ok against IGT. :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/execlists: Use coherent writes into the context image
That we use a WB mapping for updating the RING_TAIL register inside the
context image even on !llc machines has been a source of consternation
for every reader. It appears to work on bsw+, but it may just have been
that we have been incredibly bad at detecting the errors.
v2: With extra enthusiasm.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_perf.c| 3 ++-
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 8 +---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
6 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 74482753a04e..28973e692045 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3069,6 +3069,12 @@ enum i915_map_type {
I915_MAP_FORCE_WC = I915_MAP_WC | I915_MAP_OVERRIDE,
};
+static inline enum i915_map_type
+i915_coherent_map_type(struct drm_i915_private *i915)
+{
+ return HAS_LLC(i915) ? I915_MAP_WB : I915_MAP_WC;
+}
+
/**
* i915_gem_object_pin_map - return a contiguous mapping of the entire object
* @obj: the object to map into kernel address space
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0453eb42a1a3..71832e2c85ad 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5404,6 +5404,8 @@ static int __intel_engines_record_defaults(struct
drm_i915_private *i915)
for_each_engine(engine, i915, id) {
struct i915_vma *state;
+ GEM_BUG_ON(to_intel_context(ctx, engine)->pin_count);
+
state = to_intel_context(ctx, engine)->state;
if (!state)
continue;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 0376338d1f8d..d2ba7a641866 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1849,7 +1849,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
if (!ce->state)
continue;
- regs = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
+ regs = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(dev_priv));
if (IS_ERR(regs)) {
ret = PTR_ERR(regs);
goto out;
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 8628567d8f6e..2579151c1e05 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1157,7 +1157,7 @@ void intel_engines_unpark(struct drm_i915_private *i915)
map = NULL;
if (engine->default_state)
map = i915_gem_object_pin_map(engine->default_state,
- I915_MAP_WB);
+ I915_MAP_FORCE_WB);
if (!IS_ERR_OR_NULL(map))
engine->pinned_default_state = map;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3632521a5fb2..7718836c2ada 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1292,7 +1292,7 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
* on an active context (which by nature is already on the GPU).
*/
if (!(vma->flags & I915_VMA_GLOBAL_BIND)) {
- err = i915_gem_object_set_to_gtt_domain(vma->obj, true);
+ err = i915_gem_object_set_to_wc_domain(vma->obj, true);
if (err)
return err;
}
@@ -1320,7 +1320,9 @@ __execlists_context_pin(struct intel_engine_cs *engine,
if (ret)
goto err;
- vaddr = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(ctx->i915) |
+ I915_MAP_OVERRIDE);
if (IS_ERR(vaddr)) {
ret = PTR_ERR(vaddr);
goto unpin_vma;
@@ -2685,7 +2687,7 @@ populate_lr_context(struct i915_gem_context *ctx,
void *defaults;
defaults = i915_gem_object_pin_map(engine->default_state,
- I915_MAP_WB);
+ I915_MAP_FORCE_WB);
if (IS_ERR(defaults)) {
ret = PTR_ERR(defaults);
goto err_unpin_ctx;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index d40f55a8dc34..3d82f6b5c229 100644
---
[Intel-gfx] [PATCH i-g-t] igt/pm_rpm: Skip counting modes if modprobed with disable_display
If we've explicitly disabled the display, we will never find any
connected outputs or modes. Checking for them will fail and report the
missing requirement instead.
v2: Sigh, avoid more comparisons against enabled displays
v3: Try occasionally compiling patches
Signed-off-by: Chris Wilson
Cc: Imre Deak
Reviewed-by: Imre Deak
---
tests/pm_rpm.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index fefcb1beb..bbe36e59e 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -2045,9 +2045,7 @@ int main(int argc, char *argv[])
igt_assert_eq(igt_i915_driver_load("disable_display=1"), 0);
igt_assert(setup_environment());
- basic_subtest();
- drm_resources_equal_subtest();
- pci_d3_state_subtest();
+ igt_assert(igt_wait(device_in_pci_d3(), 2000, 100));
teardown_environment();
igt_debug("Reload as normal\n");
@@ -2055,9 +2053,9 @@ int main(int argc, char *argv[])
igt_assert_eq(igt_i915_driver_load(NULL), 0);
igt_assert(setup_environment());
- basic_subtest();
- drm_resources_equal_subtest();
- pci_d3_state_subtest();
+ igt_assert(igt_wait(device_in_pci_d3(), 2000, 100));
+ if (enable_one_screen_with_type(_data, SCREEN_TYPE_ANY))
+ drm_resources_equal_subtest();
teardown_environment();
}
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
Shashank,
Den tors 16 aug. 2018 kl 10:15 skrev Sharma, Shashank
:
>
> Hey Chris,
>
>
> On 8/16/2018 1:13 PM, Chris Wilson wrote:
> > Quoting Sharma, Shashank (2018-08-16 08:33:36)
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 8/16/2018 12:47 PM, Jani Nikula wrote:
> >>> On Wed, 15 Aug 2018, Rodrigo Vivi wrote:
> On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
> > On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wrote:
> >
> > First of all we need to fix the commit subject:
> >
> > drm/i915: Increase LSPCON timeout
> >
> > (this can be done when merging, no need to resend)
> >
> >> 100 ms is not enough time for the LSPCON adapter on Intel NUC devices
> >> to
> >> settle. This causes dropped display modes at driver initialisation.
> >>
> >> Increase timeout to 1000 ms.
> >>
> >> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> > Missusage of "Fixes:" tag, please read
> >
> > https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
> >
> > But also no need for resending... could be fixed when merging
> >
> > The right one would be:
> >
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> > Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode to
> > settle")
> > Cc: Shashank Sharma
> > Cc: Imre Deak
> > Cc: Jani Nikula
> > Cc: # v4.11+
> >
> > Since initial 100 seemed to be empirical and this increase seems to
> > help other cases I'm in favor of this move so
> >
> > Reviewed-by: Rodrigo Vivi
> >
> > However I will wait a bit before merging it
> > so Imre, Shashank, and/or Jani can take a look here...
> now, really cc'ing them...
> >>> Shashank? Does this slow down non-LSPCON paths?
> >> This will slow down the lspcon probing and resume part, but both of them
> >> happen only when LSPCON device is found. So to answer your question,
> >> this will not slow down the non-lspcon path, but will slow down the
> >> LSPCON connector resume and probe time. but I would recommend, instead
> >> of increasing it to 1000 ms in a single shot, we might want to gradually
> >> pick this up, on a wake-and-check way.
> > wait_for() checks every [10us, 1ms] until the condition is met, or it
> > times out. So, so long as we don't enter this path for !LPSCON where we
> > know that it will timeout, the wait_for() will only take as long as is
> > required for the connector to settle.
> We wont hit !LSPCON timeout case here, as we have already read the
> dongle signature successfully by now. But I was thinking that, if the
> spec recommends max wait time as 100ms (which is of course doesn't seem
> enough), if we can't detect i2c-over-aux after first 500ms, I guess we
> wont be able to do that in next 500ms too. So is it really ok to wait
> this long in the resume sequence ?
>
> I guess Fredrik can provide some inputs here on if there are some
> experiments behind this number of 1000ms, or this is just a safe bet ?
> >
My first patch attempt - which is attached to the Redhat and FDO Bugzilla
bugs - added a retry loop around the original 100 ms timeout. The retry loop
did trigger, but never more than once in a row in my testing.
So possibly 200 ms would be a sufficient timeout, but as the wait_for() loop
terminates early on success I suggested a conservative value of 1000 ms.
> > Can we do other connectors at the same time, or does probing LSPCON
> > block the system?
> We can do other connectors at the same time in DRM layer at-least,
> LSPCON blocks only this connector. I was curious if are we doing this
> during the resume scenario or is this in the sequential get_connector()
> type of call ?
> - Shashank
> > -Chris
/F
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt/pm_rpm: Skip counting modes if modprobed with disable_display
If we've explicitly disabled the display, we will never find any
connected outputs or modes. Checking for them will fail and report the
missing requirement instead.
v2: Sigh, avoid more comparisons against enabled displays
Signed-off-by: Chris Wilson
Cc: Imre Deak
---
tests/pm_rpm.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index fefcb1beb..7bde26972 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -2045,9 +2045,7 @@ int main(int argc, char *argv[])
igt_assert_eq(igt_i915_driver_load("disable_display=1"), 0);
igt_assert(setup_environment());
- basic_subtest();
- drm_resources_equal_subtest();
- pci_d3_state_subtest();
+ igt_assert(igt_wait(device_in_pci_d3(), 2000, 100));
teardown_environment();
igt_debug("Reload as normal\n");
@@ -2055,9 +2053,9 @@ int main(int argc, char *argv[])
igt_assert_eq(igt_i915_driver_load(NULL), 0);
igt_assert(setup_environment());
- basic_subtest();
- drm_resources_equal_subtest();
- pci_d3_state_subtest();
+ igt_assert(igt_wait(device_in_pci_d3(), 2000, 100));
+ if (enable_one_screen_with_type(data, SCREEN_TYPE_ANY))
+ drm_resources_equal_subtest();
teardown_environment();
}
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable
On Thu, Aug 16, 2018 at 01:47:08PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Introduce
> intel_runtime_pm_disable to pair intel_runtime_pm_enable
> URL : https://patchwork.freedesktop.org/series/48315/
> State : success
Pushed to -dinq, thanks for the review.
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4678 -> Patchwork_9962 =
>
> == Summary - SUCCESS ==
>
> No regressions found.
>
> External URL:
> https://patchwork.freedesktop.org/api/1.0/series/48315/revisions/1/mbox/
>
> == Known issues ==
>
> Here are the changes found in Patchwork_9962 that come from known issues:
>
> === IGT changes ===
>
> Issues hit
>
> igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
> {fi-byt-clapper}: PASS -> FAIL (fdo#107362, fdo#103191)
>
> igt@kms_setmode@basic-clone-single-crtc:
> fi-glk-j4005: PASS -> DMESG-WARN (fdo#106745)
>
>
> Possible fixes
>
> igt@drv_selftest@live_hangcheck:
> fi-skl-guc: DMESG-FAIL (fdo#107174) -> PASS
> fi-cfl-s3: DMESG-FAIL (fdo#106560) -> PASS
>
> igt@kms_pipe_crc_basic@read-crc-pipe-b:
> {fi-byt-clapper}: FAIL (fdo#107362) -> PASS
>
> igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
> fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
>
>
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
> fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
> fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
> fdo#106745 https://bugs.freedesktop.org/show_bug.cgi?id=106745
> fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
> fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
>
>
> == Participating hosts (54 -> 47) ==
>
> Missing(7): fi-ilk-m540 fi-icl-u fi-hsw-4200u fi-byt-squawks
> fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u
>
>
> == Build changes ==
>
> * Linux: CI_DRM_4678 -> Patchwork_9962
>
> CI_DRM_4678: 433fa6ccf8553afcc0159a996297b82bf50d1fac @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_4603: 1598fdb717546e25e8077935daa8e97768ad245d @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> Patchwork_9962: 2e47b9b2aba3b18febcc6978f6c2b2d55f4d7ff1 @
> git://anongit.freedesktop.org/gfx-ci/linux
>
>
> == Linux commits ==
>
> 2e47b9b2aba3 drm/i915: Refactor intel_display_set_init_power() logic
> 62108989ff60 drm/i915: Introduce intel_runtime_pm_disable to pair
> intel_runtime_pm_enable
>
> == Logs ==
>
> For more details see:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9962/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt/pm_rpm: Skip counting modes if modprobed with disable_display
If we've explicitly disabled the display, we will never find any connected outputs or modes. Checking for them will fail and report the missing requirement instead. Signed-off-by: Chris Wilson Cc: Imre Deak --- tests/pm_rpm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c index fefcb1beb..2c4bf529c 100644 --- a/tests/pm_rpm.c +++ b/tests/pm_rpm.c @@ -2046,7 +2046,6 @@ int main(int argc, char *argv[]) igt_assert(setup_environment()); basic_subtest(); - drm_resources_equal_subtest(); pci_d3_state_subtest(); teardown_environment(); @@ -2056,7 +2055,8 @@ int main(int argc, char *argv[]) igt_assert(setup_environment()); basic_subtest(); - drm_resources_equal_subtest(); + if (enable_one_screen_with_type(data, SCREEN_TYPE_ANY)) + drm_resources_equal_subtest(); pci_d3_state_subtest(); teardown_environment(); } -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm: Add P010, P012, P016 format definitions and fourcc
== Series Details ==
Series: series starting with [1/4] drm: Add P010, P012, P016 format definitions
and fourcc
URL : https://patchwork.freedesktop.org/series/48316/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4678 -> Patchwork_9963 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48316/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9963:
=== IGT changes ===
Warnings
igt@drv_selftest@live_guc:
{fi-bdw-samus}: PASS -> SKIP +1
== Known issues ==
Here are the changes found in Patchwork_9963 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
{fi-bdw-samus}: PASS -> DMESG-FAIL (fdo#106560)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362, fdo#103191)
Possible fixes
igt@drv_selftest@live_hangcheck:
fi-skl-guc: DMESG-FAIL (fdo#107174) -> PASS
fi-cfl-s3: DMESG-FAIL (fdo#106560) -> PASS
igt@kms_pipe_crc_basic@read-crc-pipe-b:
{fi-byt-clapper}: FAIL (fdo#107362) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-FAIL (fdo#107372) -> DMESG-WARN (fdo#107372)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
== Participating hosts (54 -> 47) ==
Missing(7): fi-ilk-m540 fi-icl-u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-kbl-7560u
== Build changes ==
* Linux: CI_DRM_4678 -> Patchwork_9963
CI_DRM_4678: 433fa6ccf8553afcc0159a996297b82bf50d1fac @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4603: 1598fdb717546e25e8077935daa8e97768ad245d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9963: 0b2785973f162407d58fb38784e80126cf2130bd @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0b2785973f16 drm/i915: enable P010, P012, P016 formats for primary and sprite
planes
0fa291bb82d1 drm/i915: preparations for enabling P010, P012, P016 formats
7090dcc775cc drm/i915: Add P010, P012, P016 plane control definitions
0cb3dff0a6d4 drm: Add P010, P012, P016 format definitions and fourcc
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9963/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm: Add P010, P012, P016 format definitions and fourcc
== Series Details == Series: series starting with [1/4] drm: Add P010, P012, P016 format definitions and fourcc URL : https://patchwork.freedesktop.org/series/48316/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm: Add P010, P012, P016 format definitions and fourcc Okay! Commit: drm/i915: Add P010, P012, P016 plane control definitions Okay! Commit: drm/i915: preparations for enabling P010, P012, P016 formats -O:drivers/gpu/drm/i915/intel_display.c:13185:21: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_display.c:13185:21: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_display.c:13199:21: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_display.c:13199:21: warning: expression using sizeof(void) Commit: drm/i915: enable P010, P012, P016 formats for primary and sprite planes Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm: Add P010, P012, P016 format definitions and fourcc
== Series Details ==
Series: series starting with [1/4] drm: Add P010, P012, P016 format definitions
and fourcc
URL : https://patchwork.freedesktop.org/series/48316/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0cb3dff0a6d4 drm: Add P010, P012, P016 format definitions and fourcc
-:29: WARNING:LONG_LINE: line over 100 characters
#29: FILE: drivers/gpu/drm/drm_fourcc.c:176:
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
-:30: WARNING:LONG_LINE: line over 100 characters
#30: FILE: drivers/gpu/drm/drm_fourcc.c:177:
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
-:31: WARNING:LONG_LINE: line over 100 characters
#31: FILE: drivers/gpu/drm/drm_fourcc.c:178:
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
-:49: WARNING:LONG_LINE_COMMENT: line over 100 characters
#49: FILE: include/uapi/drm/drm_fourcc.h:150:
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane, 10 bit per channel */
-:50: WARNING:LONG_LINE_COMMENT: line over 100 characters
#50: FILE: include/uapi/drm/drm_fourcc.h:151:
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cr:Cb plane, 12 bit per channel */
-:51: WARNING:LONG_LINE_COMMENT: line over 100 characters
#51: FILE: include/uapi/drm/drm_fourcc.h:152:
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane, 16 bit per channel */
total: 0 errors, 6 warnings, 0 checks, 25 lines checked
7090dcc775cc drm/i915: Add P010, P012, P016 plane control definitions
0fa291bb82d1 drm/i915: preparations for enabling P010, P012, P016 formats
-:137: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#137: FILE: drivers/gpu/drm/i915/intel_display.c:14583:
+
drm_get_format_name(mode_cmd->pixel_format,
+ _name));
-:143: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#143: FILE: drivers/gpu/drm/i915/intel_display.c:14589:
+
drm_get_format_name(mode_cmd->pixel_format,
+ _name));
total: 0 errors, 0 warnings, 2 checks, 233 lines checked
0b2785973f16 drm/i915: enable P010, P012, P016 formats for primary and sprite
planes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable
== Series Details ==
Series: series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable
to pair intel_runtime_pm_enable
URL : https://patchwork.freedesktop.org/series/48315/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4678 -> Patchwork_9962 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48315/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9962 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362, fdo#103191)
igt@kms_setmode@basic-clone-single-crtc:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106745)
Possible fixes
igt@drv_selftest@live_hangcheck:
fi-skl-guc: DMESG-FAIL (fdo#107174) -> PASS
fi-cfl-s3: DMESG-FAIL (fdo#106560) -> PASS
igt@kms_pipe_crc_basic@read-crc-pipe-b:
{fi-byt-clapper}: FAIL (fdo#107362) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106745 https://bugs.freedesktop.org/show_bug.cgi?id=106745
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
== Participating hosts (54 -> 47) ==
Missing(7): fi-ilk-m540 fi-icl-u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-kbl-7560u
== Build changes ==
* Linux: CI_DRM_4678 -> Patchwork_9962
CI_DRM_4678: 433fa6ccf8553afcc0159a996297b82bf50d1fac @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4603: 1598fdb717546e25e8077935daa8e97768ad245d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9962: 2e47b9b2aba3b18febcc6978f6c2b2d55f4d7ff1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2e47b9b2aba3 drm/i915: Refactor intel_display_set_init_power() logic
62108989ff60 drm/i915: Introduce intel_runtime_pm_disable to pair
intel_runtime_pm_enable
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9962/issues.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: Report the number of closed vma held by each context in debugfs
Quoting Mika Kuoppala (2018-08-16 14:29:33) > Chris Wilson writes: > > > Include a count of closed vma when reporting the per_ctx_stats of > > debugfs/i915_gem_objects. > > > > The code corresponds for you to report a count of bytes of a closed vmas > and I am not sure which one do you want. Bytes, since its neighbours on that line are expressed in bytes and you do want to know at a glance how much memory is being held. -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: Report the number of closed vma held by each context in debugfs
Chris Wilson writes:
> Include a count of closed vma when reporting the per_ctx_stats of
> debugfs/i915_gem_objects.
>
The code corresponds for you to report a count of bytes of a closed vmas
and I am not sure which one do you want.
-Mika
> Whilst adjusting the context tracking, note that we can simply use our
> list of contexts in i915->contexts rather than circumlocute via
> dev->filelist and the per-file context idr.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 113 +++-
> 1 file changed, 42 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 26b7e5276b15..a05d4bbc0318 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -302,6 +302,7 @@ struct file_stats {
> u64 total, unbound;
> u64 global, shared;
> u64 active, inactive;
> + u64 closed;
> };
>
> static int per_file_stats(int id, void *ptr, void *data)
> @@ -336,6 +337,9 @@ static int per_file_stats(int id, void *ptr, void *data)
> stats->active += vma->node.size;
> else
> stats->inactive += vma->node.size;
> +
> + if (i915_vma_is_closed(vma))
> + stats->closed += vma->node.size;
> }
>
> return 0;
> @@ -343,7 +347,7 @@ static int per_file_stats(int id, void *ptr, void *data)
>
> #define print_file_stats(m, name, stats) do { \
> if (stats.count) \
> - seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
> inactive, %llu global, %llu shared, %llu unbound)\n", \
> + seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
> inactive, %llu global, %llu shared, %llu unbound, %llu closed)\n", \
> name, \
> stats.count, \
> stats.total, \
> @@ -351,7 +355,8 @@ static int per_file_stats(int id, void *ptr, void *data)
> stats.inactive, \
> stats.global, \
> stats.shared, \
> -stats.unbound); \
> +stats.unbound, \
> +stats.closed); \
> } while (0)
>
> static void print_batch_pool_stats(struct seq_file *m,
> @@ -377,44 +382,44 @@ static void print_batch_pool_stats(struct seq_file *m,
> print_file_stats(m, "[k]batch pool", stats);
> }
>
> -static int per_file_ctx_stats(int idx, void *ptr, void *data)
> +static void print_context_stats(struct seq_file *m,
> + struct drm_i915_private *i915)
> {
> - struct i915_gem_context *ctx = ptr;
> - struct intel_engine_cs *engine;
> - enum intel_engine_id id;
> -
> - for_each_engine(engine, ctx->i915, id) {
> - struct intel_context *ce = to_intel_context(ctx, engine);
> + struct file_stats kstats = {};
> + struct i915_gem_context *ctx;
>
> - if (ce->state)
> - per_file_stats(0, ce->state->obj, data);
> - if (ce->ring)
> - per_file_stats(0, ce->ring->vma->obj, data);
> - }
> + list_for_each_entry(ctx, >contexts.list, link) {
> + struct file_stats stats = { .file_priv = ctx->file_priv };
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
>
> - return 0;
> -}
> + for_each_engine(engine, i915, id) {
> + struct intel_context *ce = to_intel_context(ctx,
> engine);
>
> -static void print_context_stats(struct seq_file *m,
> - struct drm_i915_private *dev_priv)
> -{
> - struct drm_device *dev = _priv->drm;
> - struct file_stats stats;
> - struct drm_file *file;
> + if (ce->state)
> + per_file_stats(0, ce->state->obj, );
> + if (ce->ring)
> + per_file_stats(0, ce->ring->vma->obj, );
> + }
>
> - memset(, 0, sizeof(stats));
> + if (!IS_ERR_OR_NULL(stats.file_priv)) {
> + struct drm_file *file = stats.file_priv->file;
> + struct task_struct *task;
>
> - mutex_lock(>struct_mutex);
> - if (dev_priv->kernel_context)
> - per_file_ctx_stats(0, dev_priv->kernel_context, );
> + spin_lock(>table_lock);
> + idr_for_each(>object_idr, per_file_stats, );
> + spin_unlock(>table_lock);
>
> - list_for_each_entry(file, >filelist, lhead) {
> - struct drm_i915_file_private *fpriv = file->driver_priv;
> - idr_for_each(>context_idr, per_file_ctx_stats, );
> + rcu_read_lock();
> + task = pid_task(ctx->pid ?: file->pid, PIDTYPE_PID);
> + print_file_stats(m,
> +
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable
== Series Details == Series: series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable URL : https://patchwork.freedesktop.org/series/48315/ State : warning == Summary == $ dim checkpatch origin/drm-tip 62108989ff60 drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable 2e47b9b2aba3 drm/i915: Refactor intel_display_set_init_power() logic -:436: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "dev_priv->csr.dmc_payload" #436: FILE: drivers/gpu/drm/i915/intel_runtime_pm.c:3848: + dev_priv->csr.dmc_payload != NULL) total: 0 errors, 0 warnings, 1 checks, 402 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: preparations for enabling P010, P012, P016 formats
Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 3 +-
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 46 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 19 ++---
drivers/gpu/drm/i915/intel_sprite.c | 18 +++-
6 files changed, 69 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index b04952b..ab76b72 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -334,8 +334,7 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
/* set scaler mode */
if ((INTEL_GEN(dev_priv) >= 9) &&
plane_state && plane_state->base.fb &&
- plane_state->base.fb->format->format ==
- DRM_FORMAT_NV12) {
+ is_planar_yuv_format(plane_state->base.fb->format->format))
{
if (INTEL_GEN(dev_priv) == 9 &&
!IS_GEMINILAKE(dev_priv) &&
!IS_SKYLAKE(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index dcba645..58b2fc6 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -182,7 +182,7 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
else
crtc_state->active_planes &= ~BIT(intel_plane->id);
- if (state->visible && state->fb->format->format == DRM_FORMAT_NV12)
+ if (state->visible && is_planar_yuv_format(state->fb->format->format))
crtc_state->nv12_planes |= BIT(intel_plane->id);
else
crtc_state->nv12_planes &= ~BIT(intel_plane->id);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 690e1e8..80ce742 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2667,6 +2667,12 @@ int skl_format_to_fourcc(int format, bool rgb_order,
bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+ case PLANE_CTL_FORMAT_P010:
+ return DRM_FORMAT_P010;
+ case PLANE_CTL_FORMAT_P012:
+ return DRM_FORMAT_P012;
+ case PLANE_CTL_FORMAT_P016:
+ return DRM_FORMAT_P016;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3182,7 +3188,7 @@ int skl_check_plane_surface(const struct intel_crtc_state
*crtc_state,
* Handle the AUX surface first since
* the main surface setup depends on it.
*/
- if (fb->format->format == DRM_FORMAT_NV12) {
+ if (is_planar_yuv_format(fb->format->format)) {
ret = skl_check_nv12_surface(crtc_state, plane_state);
if (ret)
return ret;
@@ -3507,6 +3513,12 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_P010:
+ return PLANE_CTL_FORMAT_P010;
+ case DRM_FORMAT_P012:
+ return PLANE_CTL_FORMAT_P012;
+ case DRM_FORMAT_P016:
+ return PLANE_CTL_FORMAT_P016;
default:
MISSING_CASE(pixel_format);
}
@@ -4808,8 +4820,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
need_scaling = src_w != dst_w || src_h != dst_h;
if (plane_scaler_check)
- if (pixel_format == DRM_FORMAT_NV12)
- need_scaling = true;
+ need_scaling = is_planar_yuv_format(pixel_format);
if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
need_scaling = true;
@@ -4850,7 +4861,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
return 0;
}
- if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12 &&
+ if (plane_scaler_check && is_planar_yuv_format(pixel_format) &&
(src_h < SKL_MIN_YUV_420_SRC_H || src_w < SKL_MIN_YUV_420_SRC_W)) {
DRM_DEBUG_KMS("NV12: src dimensions not met\n");
return -EINVAL;
@@ -4955,6 +4966,9 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_P010:
+ case DRM_FORMAT_P012:
+ case DRM_FORMAT_P016:
break;
[Intel-gfx] [PATCH 4/4] drm/i915: enable P010, P012, P016 formats for primary and sprite planes
Enabling of P010, P012 and P016 formats. These formats will
extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 24 +-
drivers/gpu/drm/i915/intel_sprite.c | 39 +++-
2 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 80ce742..5c7dc96 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -104,6 +104,25 @@ static const uint32_t skl_pri_planar_formats[] = {
DRM_FORMAT_NV12,
};
+static const uint32_t glk_primary_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_P010,
+ DRM_FORMAT_P012,
+ DRM_FORMAT_P016,
+};
+
static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13721,7 +13740,10 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
primary->has_ccs = skl_plane_has_ccs(dev_priv, pipe,
PLANE_PRIMARY);
- if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY)) {
+ if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
+ intel_primary_formats = glk_primary_formats;
+ num_formats = ARRAY_SIZE(glk_primary_formats);
+ } else if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY))
{
intel_primary_formats = skl_pri_planar_formats;
num_formats = ARRAY_SIZE(skl_pri_planar_formats);
} else {
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 68db026..5cc97ba 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1292,6 +1292,22 @@ static uint32_t skl_planar_formats[] = {
DRM_FORMAT_NV12,
};
+static uint32_t glk_planar_formats[] = {
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_P010,
+ DRM_FORMAT_P012,
+ DRM_FORMAT_P016,
+};
+
static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1537,7 +1553,28 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
}
intel_plane->base.state = >base;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
+ intel_plane->can_scale = true;
+ state->scaler_id = -1;
+
+ intel_plane->update_plane = skl_update_plane;
+ intel_plane->disable_plane = skl_disable_plane;
+ intel_plane->get_hw_state = skl_plane_get_hw_state;
+
+ if (skl_plane_has_planar(dev_priv, pipe,
+PLANE_SPRITE0 + plane)) {
+ plane_formats = glk_planar_formats;
+ num_plane_formats = ARRAY_SIZE(glk_planar_formats);
+ } else {
+ plane_formats = skl_plane_formats;
+ num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+ }
+
+ if (skl_plane_has_ccs(dev_priv, pipe, PLANE_SPRITE0 + plane))
+ modifiers = skl_plane_format_modifiers_ccs;
+ else
+ modifiers = skl_plane_format_modifiers_noccs;
+ } else if (INTEL_GEN(dev_priv) >= 9) {
intel_plane->can_scale = true;
state->scaler_id = -1;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Add P010, P012, P016 plane control definitions
Add needed plane control flag definitions for P010, P012 and
P016 formats.
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0c9f03d..06d4d90 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6506,8 +6506,11 @@ enum {
#define PLANE_CTL_FORMAT_YUV422 (0 << 24)
#define PLANE_CTL_FORMAT_NV12(1 << 24)
#define PLANE_CTL_FORMAT_XRGB_2101010(2 << 24)
+#define PLANE_CTL_FORMAT_P010(3 << 24)
#define PLANE_CTL_FORMAT_XRGB_ (4 << 24)
+#define PLANE_CTL_FORMAT_P012(5 << 24)
#define PLANE_CTL_FORMAT_XRGB_16161616F (6 << 24)
+#define PLANE_CTL_FORMAT_P016(7 << 24)
#define PLANE_CTL_FORMAT_AYUV(8 << 24)
#define PLANE_CTL_FORMAT_INDEXED (12 << 24)
#define PLANE_CTL_FORMAT_RGB_565 (14 << 24)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm: Add P010, P012, P016 format definitions and fourcc
Add P010 definition, semi-planar yuv format where each component
is 16 bits 10 msb containing color value. First come Y plane [10:6]
followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
Add P012 definition, semi-planar yuv format where each component
is 16 bits 12 msb containing color value. First come Y plane [12:4]
followed by 2x2 subsampled Cr:Cb plane [12:4:12:4]
Add P016 definition, semi-planar yuv format where each component
is 16 bits. First come Y plane followed by 2x2 subsampled Cr:Cb
plane [16:16]
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 10 ++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 35c1e27..32e07a2 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 721ab7e..cfb8873 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -142,6 +142,16 @@ extern "C" {
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr
+ * index 0 = Y plane, [15:0] Y little endian where Pxxx indicate
+ * component xxx msb Y [xxx:16-xxx]
+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb little endian [xxx:16-xxx:xxx:16-xxx]
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane, 10 bit per channel */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cr:Cb plane, 12 bit per channel */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane, 16 bit per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
--
2.7.4
___
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: Stop holding a ref to the ppgtt from each vma
Quoting Mika Kuoppala (2018-08-16 13:14:37)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-08-16 12:42:08)
> >> Chris Wilson writes:
> >>
> >> > The context owns both the ppgtt and the vma within it, and our activity
> >> > tracking on the context ensures that we do not release active ppgtt. As
> >> > the context fulfils our obligations for active memory tracking, we can
> >> > relinquish the reference from the vma.
> >> >
> >>
> >> The part of owning the vma within it escapes me. The vma is tied
> >> to the object. Is it about that active objects, with their vmas
> >> hold the refs to the context they are executing on?
> >
> > The vma belongs to the (object, context). If the context is closed (or
> > on close(/dev/dri/card0)), so is the ppgtt. Closing the object
> > (gem_close(fd, obj)) closes the vma that match the contexts for the fd,
> > and if it was the last handle, then frees the object.
> >
> >> > This fixes a silly transient refleak from closed vma being kept alive
> >> > until the entire system was idle, keeping all vm alive as well.
> >> >
> >> > Reported-by: Paulo Zanoni
> >> > Testcase: igt/gem_ctx_create/files
> >> > Fixes: 3365e2268b6b ("drm/i915: Lazily unbind vma on close")
> >> > Signed-off-by: Chris Wilson
> >> > Cc: Tvrtko Ursulin
> >> > Cc: Paulo Zanoni
> >> > ---
> >> > drivers/gpu/drm/i915/i915_vma.c | 4
> >> > 1 file changed, 4 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_vma.c
> >> > b/drivers/gpu/drm/i915/i915_vma.c
> >> > index 274fd2a7bcb6..31efc971a3a8 100644
> >> > --- a/drivers/gpu/drm/i915/i915_vma.c
> >> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> >> > @@ -199,7 +199,6 @@ vma_create(struct drm_i915_gem_object *obj,
> >> > vma->flags |= I915_VMA_GGTT;
> >> > list_add(>obj_link, >vma_list);
> >> > } else {
> >> > - i915_ppgtt_get(i915_vm_to_ppgtt(vm));
> >>
> >> It seems this is the sole user of i915_ppgtt_get so you can
> >> remove that too.
> >
> > Such shortsightedness; it will reappear shortly. See the patches to
> > share vm between contexts.
>
> Ok let it float in there for a while.
>
> Reviewed-by: Mika Kuoppala
>
> Also
>
> Tested-by: Mika Kuoppala
Applied the bug fix, thank you for the review.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Refactor intel_display_set_init_power() logic
Quoting Imre Deak (2018-08-16 13:37:57) > The device global init_power_on flag is somewhat arbitrary and makes > debugging power refcounting problems difficult. Instead arrange things > so that all display power domain get has a corresponding put call. After > this change we have the following sequences: > > driver loading: > intel_power_domains_init_hw(); > > intel_power_domains_enable(); > > driver unloading: > intel_power_domains_disable(); > > intel_power_domains_fini_hw(); > > system suspend: > intel_power_domains_disable(); > > intel_power_domains_suspend(); > > system resume: > intel_power_domains_resume(); > > intel_power_domains_enable(); > > at other times while the driver is loaded: > intel_display_power_get(); > ... > intel_display_power_put(); > > Suggested-by: Chris Wilson > Cc: Chris Wilson > Signed-off-by: Imre Deak I could follow the phases and was able to add the wakeref tracing (though I resorted to keeping it stored in i915_power_domains), so Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Refactor intel_display_set_init_power() logic
The device global init_power_on flag is somewhat arbitrary and makes
debugging power refcounting problems difficult. Instead arrange things
so that all display power domain get has a corresponding put call. After
this change we have the following sequences:
driver loading:
intel_power_domains_init_hw();
intel_power_domains_enable();
driver unloading:
intel_power_domains_disable();
intel_power_domains_fini_hw();
system suspend:
intel_power_domains_disable();
intel_power_domains_suspend();
system resume:
intel_power_domains_resume();
intel_power_domains_enable();
at other times while the driver is loaded:
intel_display_power_get();
...
intel_display_power_put();
Suggested-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 65 +++-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_display.c| 5 +-
drivers/gpu/drm/i915/intel_drv.h| 15 +++-
drivers/gpu/drm/i915/intel_runtime_pm.c | 133 +++-
5 files changed, 142 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 021304e252eb..35a012ffc03b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1282,6 +1282,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
if (INTEL_INFO(dev_priv)->num_pipes)
drm_kms_helper_poll_init(dev);
+ intel_power_domains_enable(dev_priv);
intel_runtime_pm_enable(dev_priv);
}
@@ -1292,6 +1293,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
static void i915_driver_unregister(struct drm_i915_private *dev_priv)
{
intel_runtime_pm_disable(dev_priv);
+ intel_power_domains_disable(dev_priv);
intel_fbdev_unregister(dev_priv);
intel_audio_deinit(dev_priv);
@@ -1374,7 +1376,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret < 0)
goto out_pci_disable;
- intel_runtime_pm_get(dev_priv);
+ disable_rpm_wakeref_asserts(dev_priv);
ret = i915_driver_init_mmio(dev_priv);
if (ret < 0)
@@ -1404,7 +1406,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
intel_init_ipc(dev_priv);
- intel_runtime_pm_put(dev_priv);
+ enable_rpm_wakeref_asserts(dev_priv);
i915_welcome_messages(dev_priv);
@@ -1415,7 +1417,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
out_cleanup_mmio:
i915_driver_cleanup_mmio(dev_priv);
out_runtime_pm_put:
- intel_runtime_pm_put(dev_priv);
+ enable_rpm_wakeref_asserts(dev_priv);
i915_driver_cleanup_early(dev_priv);
out_pci_disable:
pci_disable_device(pdev);
@@ -1433,7 +1435,7 @@ void i915_driver_unload(struct drm_device *dev)
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
- intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
+ disable_rpm_wakeref_asserts(dev_priv);
i915_driver_unregister(dev_priv);
@@ -1465,7 +1467,8 @@ void i915_driver_unload(struct drm_device *dev)
i915_driver_cleanup_hw(dev_priv);
i915_driver_cleanup_mmio(dev_priv);
- intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
+ enable_rpm_wakeref_asserts(dev_priv);
+
WARN_ON(atomic_read(_priv->runtime_pm.wakeref_count));
}
@@ -1575,7 +1578,7 @@ static int i915_drm_suspend(struct drm_device *dev)
/* We do a lot of poking in a lot of registers, make sure they work
* properly. */
- intel_display_set_init_power(dev_priv, true);
+ intel_power_domains_disable(dev_priv);
drm_kms_helper_poll_disable(dev);
@@ -1612,6 +1615,18 @@ static int i915_drm_suspend(struct drm_device *dev)
return 0;
}
+static enum i915_drm_suspend_mode
+get_suspend_mode(struct drm_i915_private *dev_priv, bool hibernate)
+{
+ if (hibernate)
+ return I915_DRM_SUSPEND_HIBERNATE;
+
+ if (suspend_to_idle(dev_priv))
+ return I915_DRM_SUSPEND_IDLE;
+
+ return I915_DRM_SUSPEND_MEM;
+}
+
static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation)
{
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -1622,21 +1637,10 @@ static int i915_drm_suspend_late(struct drm_device
*dev, bool hibernation)
i915_gem_suspend_late(dev_priv);
- intel_display_set_init_power(dev_priv, false);
intel_uncore_suspend(dev_priv);
- /*
-* In case of firmware assisted context save/restore don't manually
-* deinit the power domains. This also means the CSR/DMC firmware will
-* stay active, it will power down any HW resources as required and
-* also enable deeper system power states that would be blocked if the
-* firmware was
[Intel-gfx] [PATCH 1/2] drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable
From: Chris Wilson
Currently, we cancel the extra wakeref we have for !runtime-pm devices
inside power_wells_fini_hw. However, this is not strictly paired with
the acquisition of that wakeref in runtime_pm_enable (as the fini_hw may
be called on errors paths before we even call runtime_pm_enable). Make
the symmetry more explicit and include a check that we do release all of
our rpm wakerefs.
v2: Fixup transfer of ownership back to core whilst keeping our wakeref
count balanced.
Signed-off-by: Chris Wilson
Cc: Imre Deak
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 27 -
drivers/gpu/drm/i915/intel_drv.h| 1 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 43 ++---
3 files changed, 40 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4f2a9c39..021304e252eb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1281,6 +1281,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
*/
if (INTEL_INFO(dev_priv)->num_pipes)
drm_kms_helper_poll_init(dev);
+
+ intel_runtime_pm_enable(dev_priv);
}
/**
@@ -1289,6 +1291,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
*/
static void i915_driver_unregister(struct drm_i915_private *dev_priv)
{
+ intel_runtime_pm_disable(dev_priv);
+
intel_fbdev_unregister(dev_priv);
intel_audio_deinit(dev_priv);
@@ -1366,16 +1370,6 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
goto out_fini;
pci_set_drvdata(pdev, _priv->drm);
- /*
-* Disable the system suspend direct complete optimization, which can
-* leave the device suspended skipping the driver's suspend handlers
-* if the device was already runtime suspended. This is needed due to
-* the difference in our runtime and system suspend sequence and
-* becaue the HDA driver may require us to enable the audio power
-* domain during system suspend.
-*/
- dev_pm_set_driver_flags(>dev, DPM_FLAG_NEVER_SKIP);
-
ret = i915_driver_init_early(dev_priv, ent);
if (ret < 0)
goto out_pci_disable;
@@ -1408,8 +1402,6 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
i915_driver_register(dev_priv);
- intel_runtime_pm_enable(dev_priv);
-
intel_init_ipc(dev_priv);
intel_runtime_pm_put(dev_priv);
@@ -1441,13 +1433,13 @@ void i915_driver_unload(struct drm_device *dev)
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
- i915_driver_unregister(dev_priv);
-
- if (i915_gem_suspend(dev_priv))
- DRM_ERROR("failed to idle hardware; continuing to unload!\n");
-
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
+ i915_driver_unregister(dev_priv);
+
+ if (i915_gem_suspend(dev_priv))
+ DRM_ERROR("failed to idle hardware; continuing to unload!\n");
+
drm_atomic_helper_shutdown(dev);
intel_gvt_cleanup(dev_priv);
@@ -1474,6 +1466,7 @@ void i915_driver_unload(struct drm_device *dev)
i915_driver_cleanup_mmio(dev_priv);
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
+ WARN_ON(atomic_read(_priv->runtime_pm.wakeref_count));
}
static void i915_driver_release(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7b984aefce98..3f012716f2dc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1959,6 +1959,7 @@ void intel_power_domains_verify_state(struct
drm_i915_private *dev_priv);
void bxt_display_core_init(struct drm_i915_private *dev_priv, bool resume);
void bxt_display_core_uninit(struct drm_i915_private *dev_priv);
void intel_runtime_pm_enable(struct drm_i915_private *dev_priv);
+void intel_runtime_pm_disable(struct drm_i915_private *dev_priv);
const char *
intel_display_power_domain_str(enum intel_display_power_domain domain);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index e209edbc561d..c0983f0e46ac 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -3793,29 +3793,19 @@ void intel_power_domains_init_hw(struct
drm_i915_private *dev_priv, bool resume)
*/
void intel_power_domains_fini_hw(struct drm_i915_private *dev_priv)
{
- struct device *kdev = _priv->drm.pdev->dev;
-
/*
* The i915.ko module is still not prepared to be loaded when
* the power well is not enabled, so just enable it in case
* we're going to unload/reload.
-* The following also reacquires the RPM reference the core passed
-* to the driver during
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Stop holding a ref to the ppgtt from each vma
Quoting Mika Kuoppala (2018-08-16 13:14:37)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-08-16 12:42:08)
> >> Chris Wilson writes:
> >>
> >> > The context owns both the ppgtt and the vma within it, and our activity
> >> > tracking on the context ensures that we do not release active ppgtt. As
> >> > the context fulfils our obligations for active memory tracking, we can
> >> > relinquish the reference from the vma.
> >> >
> >>
> >> The part of owning the vma within it escapes me. The vma is tied
> >> to the object. Is it about that active objects, with their vmas
> >> hold the refs to the context they are executing on?
> >
> > The vma belongs to the (object, context). If the context is closed (or
> > on close(/dev/dri/card0)), so is the ppgtt. Closing the object
> > (gem_close(fd, obj)) closes the vma that match the contexts for the fd,
> > and if it was the last handle, then frees the object.
> >
> >> > This fixes a silly transient refleak from closed vma being kept alive
> >> > until the entire system was idle, keeping all vm alive as well.
> >> >
> >> > Reported-by: Paulo Zanoni
> >> > Testcase: igt/gem_ctx_create/files
> >> > Fixes: 3365e2268b6b ("drm/i915: Lazily unbind vma on close")
> >> > Signed-off-by: Chris Wilson
> >> > Cc: Tvrtko Ursulin
> >> > Cc: Paulo Zanoni
> >> > ---
> >> > drivers/gpu/drm/i915/i915_vma.c | 4
> >> > 1 file changed, 4 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_vma.c
> >> > b/drivers/gpu/drm/i915/i915_vma.c
> >> > index 274fd2a7bcb6..31efc971a3a8 100644
> >> > --- a/drivers/gpu/drm/i915/i915_vma.c
> >> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> >> > @@ -199,7 +199,6 @@ vma_create(struct drm_i915_gem_object *obj,
> >> > vma->flags |= I915_VMA_GGTT;
> >> > list_add(>obj_link, >vma_list);
> >> > } else {
> >> > - i915_ppgtt_get(i915_vm_to_ppgtt(vm));
> >>
> >> It seems this is the sole user of i915_ppgtt_get so you can
> >> remove that too.
> >
> > Such shortsightedness; it will reappear shortly. See the patches to
> > share vm between contexts.
>
> Ok let it float in there for a while.
>
> Reviewed-by: Mika Kuoppala
>
> Also
>
> Tested-by: Mika Kuoppala
>
> I also been after this one previously and managed to bring
> up a testcase where we create a mapping to an object and
> then create context, do execbuf with mapped object as relocatable,
> and destroy context. That would also end up keeping ppgtts
> alive until client closes.
>
> Would it be worthwhile to include such test or do you think
> gem_ctx_create@files covers enough?
There's no linkage between the mmap and context, so it doesn't strike me
as novel. gem_exec_reloc (and friends) include passing mmap(obj) as the
execbuf, objects and/or relocations, so that should be covered; and
gem_ctx_create covers using lots of temporary and long lived contexts.
We put previous bugs in gem_ppgtt, e.g. the vma-leak, but part of the
challenge there is that to stabilise the counters you need an idle
system.
However, bug discovery is serendipitous and minor differences between
similar tests (even doing the same setup in a different order) can be
all the difference between finding a bug and not. So don't let me stop
you...
You can use the igt_kcov tools to tell if a test case is similar to any
existing one.
-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: Stop holding a ref to the ppgtt from each vma
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-08-16 12:42:08)
>> Chris Wilson writes:
>>
>> > The context owns both the ppgtt and the vma within it, and our activity
>> > tracking on the context ensures that we do not release active ppgtt. As
>> > the context fulfils our obligations for active memory tracking, we can
>> > relinquish the reference from the vma.
>> >
>>
>> The part of owning the vma within it escapes me. The vma is tied
>> to the object. Is it about that active objects, with their vmas
>> hold the refs to the context they are executing on?
>
> The vma belongs to the (object, context). If the context is closed (or
> on close(/dev/dri/card0)), so is the ppgtt. Closing the object
> (gem_close(fd, obj)) closes the vma that match the contexts for the fd,
> and if it was the last handle, then frees the object.
>
>> > This fixes a silly transient refleak from closed vma being kept alive
>> > until the entire system was idle, keeping all vm alive as well.
>> >
>> > Reported-by: Paulo Zanoni
>> > Testcase: igt/gem_ctx_create/files
>> > Fixes: 3365e2268b6b ("drm/i915: Lazily unbind vma on close")
>> > Signed-off-by: Chris Wilson
>> > Cc: Tvrtko Ursulin
>> > Cc: Paulo Zanoni
>> > ---
>> > drivers/gpu/drm/i915/i915_vma.c | 4
>> > 1 file changed, 4 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_vma.c
>> > b/drivers/gpu/drm/i915/i915_vma.c
>> > index 274fd2a7bcb6..31efc971a3a8 100644
>> > --- a/drivers/gpu/drm/i915/i915_vma.c
>> > +++ b/drivers/gpu/drm/i915/i915_vma.c
>> > @@ -199,7 +199,6 @@ vma_create(struct drm_i915_gem_object *obj,
>> > vma->flags |= I915_VMA_GGTT;
>> > list_add(>obj_link, >vma_list);
>> > } else {
>> > - i915_ppgtt_get(i915_vm_to_ppgtt(vm));
>>
>> It seems this is the sole user of i915_ppgtt_get so you can
>> remove that too.
>
> Such shortsightedness; it will reappear shortly. See the patches to
> share vm between contexts.
Ok let it float in there for a while.
Reviewed-by: Mika Kuoppala
Also
Tested-by: Mika Kuoppala
I also been after this one previously and managed to bring
up a testcase where we create a mapping to an object and
then create context, do execbuf with mapped object as relocatable,
and destroy context. That would also end up keeping ppgtts
alive until client closes.
Would it be worthwhile to include such test or do you think
gem_ctx_create@files covers enough?
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/execlists: Use coherent writes into the context image
Quoting Chris Wilson (2018-08-16 12:11:49) > That we use a WB mapping for updating the RING_TAIL register inside the > context image even on !llc machines has been a source of consternation > for every reader. It appears to work on bsw+, but it may just have been > that we have been incredibly bad at detecting the errors. Drat, I had hoped we had removed the conflicting mapping already. -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: Stop holding a ref to the ppgtt from each vma
Quoting Mika Kuoppala (2018-08-16 12:42:08)
> Chris Wilson writes:
>
> > The context owns both the ppgtt and the vma within it, and our activity
> > tracking on the context ensures that we do not release active ppgtt. As
> > the context fulfils our obligations for active memory tracking, we can
> > relinquish the reference from the vma.
> >
>
> The part of owning the vma within it escapes me. The vma is tied
> to the object. Is it about that active objects, with their vmas
> hold the refs to the context they are executing on?
The vma belongs to the (object, context). If the context is closed (or
on close(/dev/dri/card0)), so is the ppgtt. Closing the object
(gem_close(fd, obj)) closes the vma that match the contexts for the fd,
and if it was the last handle, then frees the object.
> > This fixes a silly transient refleak from closed vma being kept alive
> > until the entire system was idle, keeping all vm alive as well.
> >
> > Reported-by: Paulo Zanoni
> > Testcase: igt/gem_ctx_create/files
> > Fixes: 3365e2268b6b ("drm/i915: Lazily unbind vma on close")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/i915_vma.c | 4
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_vma.c
> > b/drivers/gpu/drm/i915/i915_vma.c
> > index 274fd2a7bcb6..31efc971a3a8 100644
> > --- a/drivers/gpu/drm/i915/i915_vma.c
> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > @@ -199,7 +199,6 @@ vma_create(struct drm_i915_gem_object *obj,
> > vma->flags |= I915_VMA_GGTT;
> > list_add(>obj_link, >vma_list);
> > } else {
> > - i915_ppgtt_get(i915_vm_to_ppgtt(vm));
>
> It seems this is the sole user of i915_ppgtt_get so you can
> remove that too.
Such shortsightedness; it will reappear shortly. See the patches to
share vm between contexts.
-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: Stop holding a ref to the ppgtt from each vma
Chris Wilson writes:
> The context owns both the ppgtt and the vma within it, and our activity
> tracking on the context ensures that we do not release active ppgtt. As
> the context fulfils our obligations for active memory tracking, we can
> relinquish the reference from the vma.
>
The part of owning the vma within it escapes me. The vma is tied
to the object. Is it about that active objects, with their vmas
hold the refs to the context they are executing on?
> This fixes a silly transient refleak from closed vma being kept alive
> until the entire system was idle, keeping all vm alive as well.
>
> Reported-by: Paulo Zanoni
> Testcase: igt/gem_ctx_create/files
> Fixes: 3365e2268b6b ("drm/i915: Lazily unbind vma on close")
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_vma.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 274fd2a7bcb6..31efc971a3a8 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -199,7 +199,6 @@ vma_create(struct drm_i915_gem_object *obj,
> vma->flags |= I915_VMA_GGTT;
> list_add(>obj_link, >vma_list);
> } else {
> - i915_ppgtt_get(i915_vm_to_ppgtt(vm));
It seems this is the sole user of i915_ppgtt_get so you can
remove that too.
-Mika
> list_add_tail(>obj_link, >vma_list);
> }
>
> @@ -810,9 +809,6 @@ static void __i915_vma_destroy(struct i915_vma *vma)
> if (vma->obj)
> rb_erase(>obj_node, >obj->vma_tree);
>
> - if (!i915_vma_is_ggtt(vma))
> - i915_ppgtt_put(i915_vm_to_ppgtt(vma->vm));
> -
> rbtree_postorder_for_each_entry_safe(iter, n, >active, node) {
> GEM_BUG_ON(i915_gem_active_isset(>base));
> kfree(iter);
> --
> 2.18.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Delay updating ring
register state after resume
URL : https://patchwork.freedesktop.org/series/48310/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4677 -> Patchwork_9961 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9961 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9961, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48310/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9961:
=== IGT changes ===
Possible regressions
igt@core_auth@basic-auth:
fi-bsw-n3050: PASS -> INCOMPLETE
{fi-bsw-kefka}: PASS -> INCOMPLETE
== Known issues ==
Here are the changes found in Patchwork_9961 that come from known issues:
=== IGT changes ===
Issues hit
igt@core_auth@basic-auth:
fi-glk-j4005: PASS -> INCOMPLETE (fdo#103359, k.org#198133)
fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)
fi-bxt-j4205: PASS -> INCOMPLETE (fdo#103927)
fi-glk-dsi: PASS -> INCOMPLETE (fdo#103359, k.org#198133)
igt@drv_selftest@live_hangcheck:
fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
fi-kbl-7567u: PASS -> DMESG-FAIL (fdo#106947, fdo#106560)
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614)
Possible fixes
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-WARN (fdo#107372) -> DMESG-FAIL (fdo#107372)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133
== Participating hosts (54 -> 49) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4677 -> Patchwork_9961
CI_DRM_4677: 1af9e170b6469a64c82f5a4961a2be2f0fc1ff0a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4601: 0b5235db8d4c647a23cafe344c099d3699c8927e @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9961: dd07b00413ba3fbfafc9ae50c2a2b0a2046d3cfa @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
dd07b00413ba drm/i915/execlists: Use coherent writes into the context image
af4e727f9fdd drm/i915/execlists: Delay updating ring register state after resume
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9961/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume URL : https://patchwork.freedesktop.org/series/48310/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/execlists: Delay updating ring register state after resume Okay! Commit: drm/i915/execlists: Use coherent writes into the context image -drivers/gpu/drm/i915/selftests/../i915_drv.h:3684:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3690:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume URL : https://patchwork.freedesktop.org/series/48310/ State : warning == Summary == $ dim checkpatch origin/drm-tip af4e727f9fdd drm/i915/execlists: Delay updating ring register state after resume -:68: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV) #68: FILE: drivers/gpu/drm/i915/intel_lrc.c:2806: + ce->lrc_reg_state[CTX_RING_HEAD+1] = 0; ^ -:69: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV) #69: FILE: drivers/gpu/drm/i915/intel_lrc.c:2807: + ce->lrc_reg_state[CTX_RING_TAIL+1] = 0; ^ total: 0 errors, 0 warnings, 2 checks, 52 lines checked dd07b00413ba drm/i915/execlists: Use coherent writes into the context image ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/execlists: Use coherent writes into the context image
That we use a WB mapping for updating the RING_TAIL register inside the
context image even on !llc machines has been a source of consternation
for every reader. It appears to work on bsw+, but it may just have been
that we have been incredibly bad at detecting the errors.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/intel_lrc.c | 5 +++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5fa13887b911..8abd96c0ba79 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3069,6 +3069,12 @@ enum i915_map_type {
I915_MAP_FORCE_WC = I915_MAP_WC | I915_MAP_OVERRIDE,
};
+static inline enum i915_map_type
+i915_coherent_map_type(struct drm_i915_private *i915)
+{
+ return HAS_LLC(i915) ? I915_MAP_WB : I915_MAP_WC;
+}
+
/**
* i915_gem_object_pin_map - return a contiguous mapping of the entire object
* @obj: the object to map into kernel address space
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3632521a5fb2..2c36c5befe5f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1292,7 +1292,7 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
* on an active context (which by nature is already on the GPU).
*/
if (!(vma->flags & I915_VMA_GLOBAL_BIND)) {
- err = i915_gem_object_set_to_gtt_domain(vma->obj, true);
+ err = i915_gem_object_set_to_wc_domain(vma->obj, true);
if (err)
return err;
}
@@ -1320,7 +1320,8 @@ __execlists_context_pin(struct intel_engine_cs *engine,
if (ret)
goto err;
- vaddr = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(ctx->i915));
if (IS_ERR(vaddr)) {
ret = PTR_ERR(vaddr);
goto unpin_vma;
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Delay updating ring register state after resume
Now that we reload both RING_HEAD and RING_TAIL when rebinding the
context, we do not need to scrub those registers immediately on resume.
v2: Handle the perma-pinned contexts.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 841895cfb05f..3632521a5fb2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2775,13 +2775,14 @@ static int execlists_context_deferred_alloc(struct
i915_gem_context *ctx,
return ret;
}
-void intel_lr_context_resume(struct drm_i915_private *dev_priv)
+void intel_lr_context_resume(struct drm_i915_private *i915)
{
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
enum intel_engine_id id;
- /* Because we emit WA_TAIL_DWORDS there may be a disparity
+ /*
+* Because we emit WA_TAIL_DWORDS there may be a disparity
* between our bookkeeping in ce->ring->head and ce->ring->tail and
* that stored in context. As we only write new commands from
* ce->ring->tail onwards, everything before that is junk. If the GPU
@@ -2791,28 +2792,20 @@ void intel_lr_context_resume(struct drm_i915_private
*dev_priv)
* So to avoid that we reset the context images upon resume. For
* simplicity, we just zero everything out.
*/
- list_for_each_entry(ctx, _priv->contexts.list, link) {
- for_each_engine(engine, dev_priv, id) {
+ list_for_each_entry(ctx, >contexts.list, link) {
+ for_each_engine(engine, i915, id) {
struct intel_context *ce =
to_intel_context(ctx, engine);
- u32 *reg;
-
- if (!ce->state)
- continue;
- reg = i915_gem_object_pin_map(ce->state->obj,
- I915_MAP_WB);
- if (WARN_ON(IS_ERR(reg)))
+ if (!ce->ring)
continue;
- reg += LRC_STATE_PN * PAGE_SIZE / sizeof(*reg);
- reg[CTX_RING_HEAD+1] = 0;
- reg[CTX_RING_TAIL+1] = 0;
-
- ce->state->obj->mm.dirty = true;
- i915_gem_object_unpin_map(ce->state->obj);
-
intel_ring_reset(ce->ring, 0);
+
+ if (ce->pin_count) { /* otherwise done in context_pin */
+ ce->lrc_reg_state[CTX_RING_HEAD+1] = 0;
+ ce->lrc_reg_state[CTX_RING_TAIL+1] = 0;
+ }
}
}
}
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Include reset depth in traces
Quoting Mika Kuoppala (2018-08-16 12:04:28)
> Chris Wilson writes:
>
> > Show the reset depth (the tasklet disable count) in the GEM_TRACE to
> > indicate when we might not expect tasklets to be flushed.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 178a74e29400..257d6f5f44d1 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1834,7 +1834,8 @@ execlists_reset_prepare(struct intel_engine_cs
> > *engine)
> > struct i915_request *request, *active;
> > unsigned long flags;
> >
> > - GEM_TRACE("%s\n", engine->name);
> > + GEM_TRACE("%s: depth<-%d\n", engine->name,
> > + atomic_read(>tasklet.count));
>
> Interesting notation but yes, entry and exit will be visible.
>
> I can't think of the details on a case when this would matter.
> Regardless, the knowledge of at what point we flushed or not
> is beneficial.
Grasping at straws trying to explain the trace and I wanted to rule out
that we were leaking the tasklet_disable(). For the record, we weren't.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Include reset depth in traces
Chris Wilson writes:
> Show the reset depth (the tasklet disable count) in the GEM_TRACE to
> indicate when we might not expect tasklets to be flushed.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 178a74e29400..257d6f5f44d1 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1834,7 +1834,8 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
> struct i915_request *request, *active;
> unsigned long flags;
>
> - GEM_TRACE("%s\n", engine->name);
> + GEM_TRACE("%s: depth<-%d\n", engine->name,
> + atomic_read(>tasklet.count));
Interesting notation but yes, entry and exit will be visible.
I can't think of the details on a case when this would matter.
Regardless, the knowledge of at what point we flushed or not
is beneficial.
Reviewed-by: Mika Kuoppala
>
> /*
>* Prevent request submission to the hardware until we have
> @@ -1982,7 +1983,8 @@ static void execlists_reset_finish(struct
> intel_engine_cs *engine)
>*/
> __tasklet_enable_sync_once(>tasklet);
>
> - GEM_TRACE("%s\n", engine->name);
> + GEM_TRACE("%s: depth->%d\n", engine->name,
> + atomic_read(>tasklet.count));
> }
>
> static int intel_logical_ring_emit_pdps(struct i915_request *rq)
> --
> 2.18.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915/perf: lock powergating configuration to default when active
On 16/08/18 08:31, Tvrtko Ursulin wrote: On 15/08/2018 12:58, Tvrtko Ursulin wrote: On 14/08/2018 15:59, Lionel Landwerlin wrote: Hey Tvrtko, Thanks for taking over this series. I've been talking to developers using the i915/perf interface and from their point of view, they expect the system to be in a stable configuration when doing measurements. One issue with this patch on Gen11 is that it will lock the system in a configuration that isn't workable for media workloads (all subslices enabled). So I think we should set the value for the locked configuration per generation (gen8-10: all slices/subslices, gen11: only subslices that contain VME samplers) so that we always get a functional configurations for all workloads. Could we want to select that configuration when opening perf? This would be via i915_perf.c/gen8_configure_all_contexts? Sounds like an unfortunate but workable compromise. As long as there doesn't appear another asymmetric slice feature in the future, which doesn't align with VME. Like one workloads wants slices 0 & 2, another wants 1 & 3, or whatever. If that happens then I don't know what we do apart from locking out perf/OA. Another question is how do we expose the selected value to the user. But that can be solved in a different series. SSEU get_param would cut it? Although it would be perhaps be unexpected to get different results depending on whether perf/OA is active or not.. Hm... export device and available bitmasks via get param? Device bitmask would be fixed and available would change depending on whether perf/OA is active or not. I would avoid changing the get_param. This is supposed to report the physical device's properties. Maybe add an ioctl entry to report that configuration onto the i915_perf fd? Big downside to this is that observing something via OA would cause slow down of the whole system - since the SSEU config would be locked to a subset of slices on Gen11. :( Regardless or not of the details.. say even if we choose to lock only if there is one non-default SSEU context, that still locks all whilst perf/OA is active. That's quite bad I think. But the alternative is to lock out perf/OA while non-default SSEU contexts are present. Which is also very bad. :( Overall I don't see a solution. Latter is maybe better by being more explicit? Who are the perf/OA users and what would they prefer? The other solution I could think of would be to prevent schedule contexts that are not compatible with the OA configuration. That doesn't sound great either... Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
Hi,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Jani Nikula
> Sent: torstai 16. elokuuta 2018 10.18
> To: Vivi, Rodrigo ; Fredrik Schön
>
> Cc: intel-gfx@lists.freedesktop.org; Fredrik Schön
>
> Subject: Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
>
> On Wed, 15 Aug 2018, Rodrigo Vivi wrote:
> > On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
> >> On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wrote:
> >>
> >> First of all we need to fix the commit subject:
> >>
> >> drm/i915: Increase LSPCON timeout
> >>
> >> (this can be done when merging, no need to resend)
> >>
> >> > 100 ms is not enough time for the LSPCON adapter on Intel NUC
> >> > devices to settle. This causes dropped display modes at driver
> initialisation.
> >> >
> >> > Increase timeout to 1000 ms.
> >> >
> >> > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> >>
> >> Missusage of "Fixes:" tag, please read
> >>
> >> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
> >> #fixes
> >>
> >> But also no need for resending... could be fixed when merging
> >>
> >> The right one would be:
> >>
> >> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> >> Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode
> >> to settle")
> >> Cc: Shashank Sharma
> >> Cc: Imre Deak
> >> Cc: Jani Nikula
> >> Cc: # v4.11+
> >>
> >> Since initial 100 seemed to be empirical and this increase seems to
> >> help other cases I'm in favor of this move so
> >>
> >> Reviewed-by: Rodrigo Vivi
> >>
> >> However I will wait a bit before merging it so Imre, Shashank, and/or
> >> Jani can take a look here...
> >
> > now, really cc'ing them...
>
> Shashank? Does this slow down non-LSPCON paths?
+ Shashank for real
>
> BR,
> Jani.
>
>
> >
> >>
> >> > Signed-off-by: Fredrik Schön
> >> > ---
> >> > drivers/gpu/drm/i915/intel_lspcon.c | 2 +-
> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
> >> > b/drivers/gpu/drm/i915/intel_lspcon.c
> >> > index 8ae8f42f430a..be1b08f589a4 100644
> >> > --- a/drivers/gpu/drm/i915/intel_lspcon.c
> >> > +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> >> > @@ -74,7 +74,7 @@ static enum drm_lspcon_mode
> lspcon_wait_mode(struct intel_lspcon *lspcon,
> >> > DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
> >> >lspcon_mode_name(mode));
> >> >
> >> > -wait_for((current_mode = lspcon_get_current_mode(lspcon)) ==
> mode, 100);
> >> > +wait_for((current_mode = lspcon_get_current_mode(lspcon)) ==
> >> > +mode, 1000);
> >> > if (current_mode != mode)
> >> > DRM_ERROR("LSPCON mode hasn't settled\n");
> >> >
> >> > --
> >> > 2.17.1
> >> >
> >> > ___
> >> > Intel-gfx mailing list
> >> > Intel-gfx@lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Exclude pm_rpm module-reload from full testing
Quoting Petri Latvala (2018-08-16 09:43:10) > On Thu, Aug 16, 2018 at 09:00:37AM +0100, Chris Wilson wrote: > > Quoting Petri Latvala (2018-08-16 08:56:27) > > > On Thu, Aug 16, 2018 at 07:06:46AM +0100, Chris Wilson wrote: > > > > The pm_rpm module-reload exists to exercise a rpm wakeref leak, and > > > > affects the random selection of tests run after it. Similar to the > > > > normal module-reload tests, care must be taken in its execution to avoid > > > > causing spurious failures elsewhere. > > > > > > > > Signed-off-by: Chris Wilson > > > > --- > > > > tests/intel-ci/blacklist.txt | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt > > > > index c93554a37..88b2fe313 100644 > > > > --- a/tests/intel-ci/blacklist.txt > > > > +++ b/tests/intel-ci/blacklist.txt > > > > @@ -13,6 +13,7 @@ igt@drm_mm(@.*)? > > > > # failures in tests run afterwards. > > > > ### > > > > igt@drv_module_reload(@.*)? > > > > +igt@pm_rpm@module-reload > > > > > > > > > As we don't have machinery in place yet to run these reloading tests > > > in shards in a controlled manner, should this be added to > > > fast-feedback to not lose the coverage entirely? > > > > It already is in fast-feedback awaiting us landing the wakeref fix. :-p > > > Blindness is bad, kids. > > > Acked-by: Petri Latvala Got an irc r-b from Imre for the pm_rpm/module-reload fix, so pushed all 3. All that we have to do now is to fix the wakeref and rejoice in a green BAT. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Stop holding a ref to the ppgtt from each vma
== Series Details == Series: series starting with [1/3] drm/i915: Stop holding a ref to the ppgtt from each vma URL : https://patchwork.freedesktop.org/series/48297/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4676_full -> Patchwork_9960_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9960_full that come from known issues: === IGT changes === Issues hit igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4676 -> Patchwork_9960 CI_DRM_4676: 8171ee8227a2633ffb5808841f08cc1a3bfaffbb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4599: 940cb5f46433a8ae48d21c6672e4d8ecd1358bbf @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9960: 589db09a699919150858461c3e2d6bf3e0f2bb42 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9960/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Exclude pm_rpm module-reload from full testing
On Thu, Aug 16, 2018 at 09:00:37AM +0100, Chris Wilson wrote: > Quoting Petri Latvala (2018-08-16 08:56:27) > > On Thu, Aug 16, 2018 at 07:06:46AM +0100, Chris Wilson wrote: > > > The pm_rpm module-reload exists to exercise a rpm wakeref leak, and > > > affects the random selection of tests run after it. Similar to the > > > normal module-reload tests, care must be taken in its execution to avoid > > > causing spurious failures elsewhere. > > > > > > Signed-off-by: Chris Wilson > > > --- > > > tests/intel-ci/blacklist.txt | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt > > > index c93554a37..88b2fe313 100644 > > > --- a/tests/intel-ci/blacklist.txt > > > +++ b/tests/intel-ci/blacklist.txt > > > @@ -13,6 +13,7 @@ igt@drm_mm(@.*)? > > > # failures in tests run afterwards. > > > ### > > > igt@drv_module_reload(@.*)? > > > +igt@pm_rpm@module-reload > > > > > > As we don't have machinery in place yet to run these reloading tests > > in shards in a controlled manner, should this be added to > > fast-feedback to not lose the coverage entirely? > > It already is in fast-feedback awaiting us landing the wakeref fix. :-p Blindness is bad, kids. Acked-by: Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
Hey Chris,
On 8/16/2018 1:13 PM, Chris Wilson wrote:
Quoting Sharma, Shashank (2018-08-16 08:33:36)
Regards
Shashank
On 8/16/2018 12:47 PM, Jani Nikula wrote:
On Wed, 15 Aug 2018, Rodrigo Vivi wrote:
On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wrote:
First of all we need to fix the commit subject:
drm/i915: Increase LSPCON timeout
(this can be done when merging, no need to resend)
100 ms is not enough time for the LSPCON adapter on Intel NUC devices to
settle. This causes dropped display modes at driver initialisation.
Increase timeout to 1000 ms.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
Missusage of "Fixes:" tag, please read
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
But also no need for resending... could be fixed when merging
The right one would be:
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode to settle")
Cc: Shashank Sharma
Cc: Imre Deak
Cc: Jani Nikula
Cc: # v4.11+
Since initial 100 seemed to be empirical and this increase seems to
help other cases I'm in favor of this move so
Reviewed-by: Rodrigo Vivi
However I will wait a bit before merging it
so Imre, Shashank, and/or Jani can take a look here...
now, really cc'ing them...
Shashank? Does this slow down non-LSPCON paths?
This will slow down the lspcon probing and resume part, but both of them
happen only when LSPCON device is found. So to answer your question,
this will not slow down the non-lspcon path, but will slow down the
LSPCON connector resume and probe time. but I would recommend, instead
of increasing it to 1000 ms in a single shot, we might want to gradually
pick this up, on a wake-and-check way.
wait_for() checks every [10us, 1ms] until the condition is met, or it
times out. So, so long as we don't enter this path for !LPSCON where we
know that it will timeout, the wait_for() will only take as long as is
required for the connector to settle.
We wont hit !LSPCON timeout case here, as we have already read the
dongle signature successfully by now. But I was thinking that, if the
spec recommends max wait time as 100ms (which is of course doesn't seem
enough), if we can't detect i2c-over-aux after first 500ms, I guess we
wont be able to do that in next 500ms too. So is it really ok to wait
this long in the resume sequence ?
I guess Fredrik can provide some inputs here on if there are some
experiments behind this number of 1000ms, or this is just a safe bet ?
Can we do other connectors at the same time, or does probing LSPCON
block the system?
We can do other connectors at the same time in DRM layer at-least,
LSPCON blocks only this connector. I was curious if are we doing this
during the resume scenario or is this in the sequential get_connector()
type of call ?
- Shashank
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Exclude pm_rpm module-reload from full testing
Quoting Petri Latvala (2018-08-16 08:56:27) > On Thu, Aug 16, 2018 at 07:06:46AM +0100, Chris Wilson wrote: > > The pm_rpm module-reload exists to exercise a rpm wakeref leak, and > > affects the random selection of tests run after it. Similar to the > > normal module-reload tests, care must be taken in its execution to avoid > > causing spurious failures elsewhere. > > > > Signed-off-by: Chris Wilson > > --- > > tests/intel-ci/blacklist.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt > > index c93554a37..88b2fe313 100644 > > --- a/tests/intel-ci/blacklist.txt > > +++ b/tests/intel-ci/blacklist.txt > > @@ -13,6 +13,7 @@ igt@drm_mm(@.*)? > > # failures in tests run afterwards. > > ### > > igt@drv_module_reload(@.*)? > > +igt@pm_rpm@module-reload > > > As we don't have machinery in place yet to run these reloading tests > in shards in a controlled manner, should this be added to > fast-feedback to not lose the coverage entirely? It already is in fast-feedback awaiting us landing the wakeref fix. :-p -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Stop holding a ref to the ppgtt from each vma
== Series Details ==
Series: series starting with [1/3] drm/i915: Stop holding a ref to the ppgtt
from each vma
URL : https://patchwork.freedesktop.org/series/48297/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4676 -> Patchwork_9960 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48297/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9960 that come from known issues:
=== IGT changes ===
Possible fixes
igt@drv_selftest@live_coherency:
fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS
igt@drv_selftest@live_hangcheck:
fi-skl-guc: DMESG-FAIL (fdo#107174) -> PASS
fi-kbl-7567u: DMESG-FAIL (fdo#106560, fdo#106947) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-WARN (fdo#107372) -> DMESG-FAIL (fdo#107372)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
== Participating hosts (53 -> 47) ==
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600
== Build changes ==
* Linux: CI_DRM_4676 -> Patchwork_9960
CI_DRM_4676: 8171ee8227a2633ffb5808841f08cc1a3bfaffbb @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4599: 940cb5f46433a8ae48d21c6672e4d8ecd1358bbf @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9960: 589db09a699919150858461c3e2d6bf3e0f2bb42 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
589db09a6999 drm/i915: Remove debugfs/i915_ppgtt_info
05f97b88f2b5 drm/i915: Report the number of closed vma held by each context in
debugfs
179bc3e01013 drm/i915: Stop holding a ref to the ppgtt from each vma
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9960/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Exclude pm_rpm module-reload from full testing
On Thu, Aug 16, 2018 at 07:06:46AM +0100, Chris Wilson wrote: > The pm_rpm module-reload exists to exercise a rpm wakeref leak, and > affects the random selection of tests run after it. Similar to the > normal module-reload tests, care must be taken in its execution to avoid > causing spurious failures elsewhere. > > Signed-off-by: Chris Wilson > --- > tests/intel-ci/blacklist.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt > index c93554a37..88b2fe313 100644 > --- a/tests/intel-ci/blacklist.txt > +++ b/tests/intel-ci/blacklist.txt > @@ -13,6 +13,7 @@ igt@drm_mm(@.*)? > # failures in tests run afterwards. > ### > igt@drv_module_reload(@.*)? > +igt@pm_rpm@module-reload As we don't have machinery in place yet to run these reloading tests in shards in a controlled manner, should this be added to fast-feedback to not lose the coverage entirely? -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
Quoting Sharma, Shashank (2018-08-16 08:33:36)
> Regards
>
> Shashank
>
>
> On 8/16/2018 12:47 PM, Jani Nikula wrote:
> > On Wed, 15 Aug 2018, Rodrigo Vivi wrote:
> >> On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
> >>> On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wrote:
> >>>
> >>> First of all we need to fix the commit subject:
> >>>
> >>> drm/i915: Increase LSPCON timeout
> >>>
> >>> (this can be done when merging, no need to resend)
> >>>
> 100 ms is not enough time for the LSPCON adapter on Intel NUC devices to
> settle. This causes dropped display modes at driver initialisation.
>
> Increase timeout to 1000 ms.
>
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> >>> Missusage of "Fixes:" tag, please read
> >>>
> >>> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
> >>>
> >>> But also no need for resending... could be fixed when merging
> >>>
> >>> The right one would be:
> >>>
> >>> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
> >>> Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode to
> >>> settle")
> >>> Cc: Shashank Sharma
> >>> Cc: Imre Deak
> >>> Cc: Jani Nikula
> >>> Cc: # v4.11+
> >>>
> >>> Since initial 100 seemed to be empirical and this increase seems to
> >>> help other cases I'm in favor of this move so
> >>>
> >>> Reviewed-by: Rodrigo Vivi
> >>>
> >>> However I will wait a bit before merging it
> >>> so Imre, Shashank, and/or Jani can take a look here...
> >> now, really cc'ing them...
> > Shashank? Does this slow down non-LSPCON paths?
> This will slow down the lspcon probing and resume part, but both of them
> happen only when LSPCON device is found. So to answer your question,
> this will not slow down the non-lspcon path, but will slow down the
> LSPCON connector resume and probe time. but I would recommend, instead
> of increasing it to 1000 ms in a single shot, we might want to gradually
> pick this up, on a wake-and-check way.
wait_for() checks every [10us, 1ms] until the condition is met, or it
times out. So, so long as we don't enter this path for !LPSCON where we
know that it will timeout, the wait_for() will only take as long as is
required for the connector to settle.
Can we do other connectors at the same time, or does probing LSPCON
block the system?
-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 series starting with [1/3] drm/i915: Stop holding a ref to the ppgtt from each vma
== Series Details == Series: series starting with [1/3] drm/i915: Stop holding a ref to the ppgtt from each vma URL : https://patchwork.freedesktop.org/series/48297/ State : warning == Summary == $ dim checkpatch origin/drm-tip 179bc3e01013 drm/i915: Stop holding a ref to the ppgtt from each vma 05f97b88f2b5 drm/i915: Report the number of closed vma held by each context in debugfs -:43: WARNING:LONG_LINE: line over 100 characters #43: FILE: drivers/gpu/drm/i915/i915_debugfs.c:350: + seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu inactive, %llu global, %llu shared, %llu unbound, %llu closed)\n", \ total: 0 errors, 1 warnings, 0 checks, 169 lines checked 589db09a6999 drm/i915: Remove debugfs/i915_ppgtt_info ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] i915: make the probe asynchronous
On Tue, Aug 14, 2018 at 11:39:48AM +0200, Takashi Iwai wrote:
> On Tue, 14 Aug 2018 11:34:07 +0200,
> Daniel Vetter wrote:
> >
> > On Tue, Aug 14, 2018 at 02:54:31PM +0800, Feng Tang wrote:
> > > Hi Jani, Daniel
> > >
> > > Could you help to comment? thanks,
> > >
> > > - Feng
> > >
> > > On Thu, Jul 12, 2018 at 03:51:34PM +0800, Feng Tang wrote:
> > > > Hi Daniel,
> > > >
> > > > On Thu, Jul 12, 2018 at 08:54:34AM +0200, Daniel Vetter wrote:
> > > > > On Thu, Jul 12, 2018 at 09:29:01AM +0800, Feng Tang wrote:
> > > > > > On Tue, Jun 26, 2018 at 10:29:16AM +0800, Feng Tang wrote:
> > > > > > > On Mon, Jun 25, 2018 at 05:36:32PM +0200, Daniel Vetter wrote:
> > > > > >
> > > > > > > Hi Daneil/Jani/Takashi,
> > > > > > >
> > > > > > > When I was testing this patch from Takashi, I further checked the
> > > > > > > kernel
> > > > > > > module code, and found that: we may need NOT to add any new codes
> > > > > > > to
> > > > > > > prepare for i915's async probe feature!
> > > > > > >
> > > > > > > Say when i915 module is being loader due to HDA's
> > > > > > > request_module() call,
> > > > > > > in the callchain, do_init_module() has such code:
> > > > > > >
> > > > > > > if (!mod->async_probe_requested && (current->flags &
> > > > > > > PF_USED_ASYNC))
> > > > > > > async_synchronize_full();
> > > > > > >
> > > > > > > This will garantee the asynced probe is done before it returns.
> > > > > > >
> > > > > > > I have just tested and this seems to be enough. If I am not
> > > > > > > wrong, then
> > > > > > > we can take the i915 async patch directly. What do you think?
> > > > > >
> > > > > > Ping for comments, thanks!
> > > > >
> > > > > Ram (who's working on the hdcp2 code) just learned the hard way that
> > > > > if
> > > > > i915 registration gets delayed then audio fails to load. So if you
> > > > > want to
> > > > > make i915 fully async, then you _must_ fix the audio load stuff.
> > > >
> > > > Thanks for sharing this info, this is a real concern. I just did a quick
> > > > search of intel-gfx mail list archive, but failed to find the details :(
> >
> > Sorry this wa all irc discussions around the hdcp2 patches from
> > Ramalingam. There's hacks in his latest patch series to work around the
> > audio issues.
> >
> > > > > The above code just shows that if you're loading things with
> > > > > request_module(), then there's not actually any async probing going
> > > > > on.
> > > > > Which kinda defeats the point.
> > > > >
> > > > > So yeah, I still think we need to fix this properly, or it's
> > > > > pointless.
> > > >
> > > > Agree, this has to be fixed. Can we just do as the hdac_i915.c to
> > > > explicitly
> > > > claim this dependency by using the similar request_module("i915"), as
> > > > there
> > > > may be similar dependency on i915 in the future.
> >
> > Erm, the entire point of this discussion was the request_module() doesn't
> > work. request_module() does _not_ make dependencies explicit at all.
>
> FYI, the upcoming 4.19 will have the completion in audio side binding,
> so this problem should be solved there.
Really a great news! thanks for sharing
Thanks,
Feng
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Remove debugfs/i915_ppgtt_info
The information presented here is not relevant to current development.
We can either use the context information, but more often we want to
inspect the active gpu state.
The ulterior motive is to eradicate dev->filelist.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 119
1 file changed, 119 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a05d4bbc0318..bff95abd1b6a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2034,124 +2034,6 @@ static int i915_swizzle_info(struct seq_file *m, void
*data)
return 0;
}
-static int per_file_ctx(int id, void *ptr, void *data)
-{
- struct i915_gem_context *ctx = ptr;
- struct seq_file *m = data;
- struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
-
- if (!ppgtt) {
- seq_printf(m, " no ppgtt for context %d\n",
- ctx->user_handle);
- return 0;
- }
-
- if (i915_gem_context_is_default(ctx))
- seq_puts(m, " default context:\n");
- else
- seq_printf(m, " context %d:\n", ctx->user_handle);
- ppgtt->debug_dump(ppgtt, m);
-
- return 0;
-}
-
-static void gen8_ppgtt_info(struct seq_file *m,
- struct drm_i915_private *dev_priv)
-{
- struct i915_hw_ppgtt *ppgtt = dev_priv->mm.aliasing_ppgtt;
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
- int i;
-
- if (!ppgtt)
- return;
-
- for_each_engine(engine, dev_priv, id) {
- seq_printf(m, "%s\n", engine->name);
- for (i = 0; i < 4; i++) {
- u64 pdp = I915_READ(GEN8_RING_PDP_UDW(engine, i));
- pdp <<= 32;
- pdp |= I915_READ(GEN8_RING_PDP_LDW(engine, i));
- seq_printf(m, "\tPDP%d 0x%016llx\n", i, pdp);
- }
- }
-}
-
-static void gen6_ppgtt_info(struct seq_file *m,
- struct drm_i915_private *dev_priv)
-{
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
- if (IS_GEN6(dev_priv))
- seq_printf(m, "GFX_MODE: 0x%08x\n", I915_READ(GFX_MODE));
-
- for_each_engine(engine, dev_priv, id) {
- seq_printf(m, "%s\n", engine->name);
- if (IS_GEN7(dev_priv))
- seq_printf(m, "GFX_MODE: 0x%08x\n",
- I915_READ(RING_MODE_GEN7(engine)));
- seq_printf(m, "PP_DIR_BASE: 0x%08x\n",
- I915_READ(RING_PP_DIR_BASE(engine)));
- seq_printf(m, "PP_DIR_BASE_READ: 0x%08x\n",
- I915_READ(RING_PP_DIR_BASE_READ(engine)));
- seq_printf(m, "PP_DIR_DCLV: 0x%08x\n",
- I915_READ(RING_PP_DIR_DCLV(engine)));
- }
- if (dev_priv->mm.aliasing_ppgtt) {
- struct i915_hw_ppgtt *ppgtt = dev_priv->mm.aliasing_ppgtt;
-
- seq_puts(m, "aliasing PPGTT:\n");
- seq_printf(m, "pd gtt offset: 0x%08x\n",
ppgtt->pd.base.ggtt_offset);
-
- ppgtt->debug_dump(ppgtt, m);
- }
-
- seq_printf(m, "ECOCHK: 0x%08x\n", I915_READ(GAM_ECOCHK));
-}
-
-static int i915_ppgtt_info(struct seq_file *m, void *data)
-{
- struct drm_i915_private *dev_priv = node_to_i915(m->private);
- struct drm_device *dev = _priv->drm;
- struct drm_file *file;
- int ret;
-
- mutex_lock(>filelist_mutex);
- ret = mutex_lock_interruptible(>struct_mutex);
- if (ret)
- goto out_unlock;
-
- intel_runtime_pm_get(dev_priv);
-
- if (INTEL_GEN(dev_priv) >= 8)
- gen8_ppgtt_info(m, dev_priv);
- else if (INTEL_GEN(dev_priv) >= 6)
- gen6_ppgtt_info(m, dev_priv);
-
- list_for_each_entry_reverse(file, >filelist, lhead) {
- struct drm_i915_file_private *file_priv = file->driver_priv;
- struct task_struct *task;
-
- task = get_pid_task(file->pid, PIDTYPE_PID);
- if (!task) {
- ret = -ESRCH;
- goto out_rpm;
- }
- seq_printf(m, "\nproc: %s\n", task->comm);
- put_task_struct(task);
- idr_for_each(_priv->context_idr, per_file_ctx,
-(void *)(unsigned long)m);
- }
-
-out_rpm:
- intel_runtime_pm_put(dev_priv);
- mutex_unlock(>struct_mutex);
-out_unlock:
- mutex_unlock(>filelist_mutex);
- return ret;
-}
-
static int count_irq_waiters(struct drm_i915_private *i915)
{
struct intel_engine_cs *engine;
@@ -4707,7 +4589,6 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_context_status", i915_context_status, 0},
{"i915_forcewake_domains",
[Intel-gfx] [PATCH 1/3] drm/i915: Stop holding a ref to the ppgtt from each vma
The context owns both the ppgtt and the vma within it, and our activity
tracking on the context ensures that we do not release active ppgtt. As
the context fulfils our obligations for active memory tracking, we can
relinquish the reference from the vma.
This fixes a silly transient refleak from closed vma being kept alive
until the entire system was idle, keeping all vm alive as well.
Reported-by: Paulo Zanoni
Testcase: igt/gem_ctx_create/files
Fixes: 3365e2268b6b ("drm/i915: Lazily unbind vma on close")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_vma.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 274fd2a7bcb6..31efc971a3a8 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -199,7 +199,6 @@ vma_create(struct drm_i915_gem_object *obj,
vma->flags |= I915_VMA_GGTT;
list_add(>obj_link, >vma_list);
} else {
- i915_ppgtt_get(i915_vm_to_ppgtt(vm));
list_add_tail(>obj_link, >vma_list);
}
@@ -810,9 +809,6 @@ static void __i915_vma_destroy(struct i915_vma *vma)
if (vma->obj)
rb_erase(>obj_node, >obj->vma_tree);
- if (!i915_vma_is_ggtt(vma))
- i915_ppgtt_put(i915_vm_to_ppgtt(vma->vm));
-
rbtree_postorder_for_each_entry_safe(iter, n, >active, node) {
GEM_BUG_ON(i915_gem_active_isset(>base));
kfree(iter);
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Report the number of closed vma held by each context in debugfs
Include a count of closed vma when reporting the per_ctx_stats of
debugfs/i915_gem_objects.
Whilst adjusting the context tracking, note that we can simply use our
list of contexts in i915->contexts rather than circumlocute via
dev->filelist and the per-file context idr.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 113 +++-
1 file changed, 42 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 26b7e5276b15..a05d4bbc0318 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -302,6 +302,7 @@ struct file_stats {
u64 total, unbound;
u64 global, shared;
u64 active, inactive;
+ u64 closed;
};
static int per_file_stats(int id, void *ptr, void *data)
@@ -336,6 +337,9 @@ static int per_file_stats(int id, void *ptr, void *data)
stats->active += vma->node.size;
else
stats->inactive += vma->node.size;
+
+ if (i915_vma_is_closed(vma))
+ stats->closed += vma->node.size;
}
return 0;
@@ -343,7 +347,7 @@ static int per_file_stats(int id, void *ptr, void *data)
#define print_file_stats(m, name, stats) do { \
if (stats.count) \
- seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
inactive, %llu global, %llu shared, %llu unbound)\n", \
+ seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
inactive, %llu global, %llu shared, %llu unbound, %llu closed)\n", \
name, \
stats.count, \
stats.total, \
@@ -351,7 +355,8 @@ static int per_file_stats(int id, void *ptr, void *data)
stats.inactive, \
stats.global, \
stats.shared, \
- stats.unbound); \
+ stats.unbound, \
+ stats.closed); \
} while (0)
static void print_batch_pool_stats(struct seq_file *m,
@@ -377,44 +382,44 @@ static void print_batch_pool_stats(struct seq_file *m,
print_file_stats(m, "[k]batch pool", stats);
}
-static int per_file_ctx_stats(int idx, void *ptr, void *data)
+static void print_context_stats(struct seq_file *m,
+ struct drm_i915_private *i915)
{
- struct i915_gem_context *ctx = ptr;
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
- for_each_engine(engine, ctx->i915, id) {
- struct intel_context *ce = to_intel_context(ctx, engine);
+ struct file_stats kstats = {};
+ struct i915_gem_context *ctx;
- if (ce->state)
- per_file_stats(0, ce->state->obj, data);
- if (ce->ring)
- per_file_stats(0, ce->ring->vma->obj, data);
- }
+ list_for_each_entry(ctx, >contexts.list, link) {
+ struct file_stats stats = { .file_priv = ctx->file_priv };
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
- return 0;
-}
+ for_each_engine(engine, i915, id) {
+ struct intel_context *ce = to_intel_context(ctx,
engine);
-static void print_context_stats(struct seq_file *m,
- struct drm_i915_private *dev_priv)
-{
- struct drm_device *dev = _priv->drm;
- struct file_stats stats;
- struct drm_file *file;
+ if (ce->state)
+ per_file_stats(0, ce->state->obj, );
+ if (ce->ring)
+ per_file_stats(0, ce->ring->vma->obj, );
+ }
- memset(, 0, sizeof(stats));
+ if (!IS_ERR_OR_NULL(stats.file_priv)) {
+ struct drm_file *file = stats.file_priv->file;
+ struct task_struct *task;
- mutex_lock(>struct_mutex);
- if (dev_priv->kernel_context)
- per_file_ctx_stats(0, dev_priv->kernel_context, );
+ spin_lock(>table_lock);
+ idr_for_each(>object_idr, per_file_stats, );
+ spin_unlock(>table_lock);
- list_for_each_entry(file, >filelist, lhead) {
- struct drm_i915_file_private *fpriv = file->driver_priv;
- idr_for_each(>context_idr, per_file_ctx_stats, );
+ rcu_read_lock();
+ task = pid_task(ctx->pid ?: file->pid, PIDTYPE_PID);
+ print_file_stats(m,
+task ? task->comm : "",
+stats);
+ rcu_read_unlock();
+ }
}
- mutex_unlock(>struct_mutex);
- print_file_stats(m,
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
Regards
Shashank
On 8/16/2018 12:47 PM, Jani Nikula wrote:
On Wed, 15 Aug 2018, Rodrigo Vivi wrote:
On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wrote:
First of all we need to fix the commit subject:
drm/i915: Increase LSPCON timeout
(this can be done when merging, no need to resend)
100 ms is not enough time for the LSPCON adapter on Intel NUC devices to
settle. This causes dropped display modes at driver initialisation.
Increase timeout to 1000 ms.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
Missusage of "Fixes:" tag, please read
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
But also no need for resending... could be fixed when merging
The right one would be:
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode to settle")
Cc: Shashank Sharma
Cc: Imre Deak
Cc: Jani Nikula
Cc: # v4.11+
Since initial 100 seemed to be empirical and this increase seems to
help other cases I'm in favor of this move so
Reviewed-by: Rodrigo Vivi
However I will wait a bit before merging it
so Imre, Shashank, and/or Jani can take a look here...
now, really cc'ing them...
Shashank? Does this slow down non-LSPCON paths?
This will slow down the lspcon probing and resume part, but both of them
happen only when LSPCON device is found. So to answer your question,
this will not slow down the non-lspcon path, but will slow down the
LSPCON connector resume and probe time. but I would recommend, instead
of increasing it to 1000 ms in a single shot, we might want to gradually
pick this up, on a wake-and-check way.
- Shashank
BR,
Jani.
Signed-off-by: Fredrik Schön
---
drivers/gpu/drm/i915/intel_lspcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index 8ae8f42f430a..be1b08f589a4 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -74,7 +74,7 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct
intel_lspcon *lspcon,
DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
lspcon_mode_name(mode));
- wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 100);
+ wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode,
1000);
if (current_mode != mode)
DRM_ERROR("LSPCON mode hasn't settled\n");
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915/perf: lock powergating configuration to default when active
On 15/08/2018 12:58, Tvrtko Ursulin wrote: On 14/08/2018 15:59, Lionel Landwerlin wrote: Hey Tvrtko, Thanks for taking over this series. I've been talking to developers using the i915/perf interface and from their point of view, they expect the system to be in a stable configuration when doing measurements. One issue with this patch on Gen11 is that it will lock the system in a configuration that isn't workable for media workloads (all subslices enabled). So I think we should set the value for the locked configuration per generation (gen8-10: all slices/subslices, gen11: only subslices that contain VME samplers) so that we always get a functional configurations for all workloads. Could we want to select that configuration when opening perf? This would be via i915_perf.c/gen8_configure_all_contexts? Sounds like an unfortunate but workable compromise. As long as there doesn't appear another asymmetric slice feature in the future, which doesn't align with VME. Like one workloads wants slices 0 & 2, another wants 1 & 3, or whatever. If that happens then I don't know what we do apart from locking out perf/OA. Another question is how do we expose the selected value to the user. But that can be solved in a different series. SSEU get_param would cut it? Although it would be perhaps be unexpected to get different results depending on whether perf/OA is active or not.. Hm... export device and available bitmasks via get param? Device bitmask would be fixed and available would change depending on whether perf/OA is active or not. Big downside to this is that observing something via OA would cause slow down of the whole system - since the SSEU config would be locked to a subset of slices on Gen11. :( Regardless or not of the details.. say even if we choose to lock only if there is one non-default SSEU context, that still locks all whilst perf/OA is active. That's quite bad I think. But the alternative is to lock out perf/OA while non-default SSEU contexts are present. Which is also very bad. :( Overall I don't see a solution. Latter is maybe better by being more explicit? Who are the perf/OA users and what would they prefer? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
On Wed, 15 Aug 2018, Rodrigo Vivi wrote:
> On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
>> On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wrote:
>>
>> First of all we need to fix the commit subject:
>>
>> drm/i915: Increase LSPCON timeout
>>
>> (this can be done when merging, no need to resend)
>>
>> > 100 ms is not enough time for the LSPCON adapter on Intel NUC devices to
>> > settle. This causes dropped display modes at driver initialisation.
>> >
>> > Increase timeout to 1000 ms.
>> >
>> > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
>>
>> Missusage of "Fixes:" tag, please read
>>
>> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html#fixes
>>
>> But also no need for resending... could be fixed when merging
>>
>> The right one would be:
>>
>> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
>> Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode to
>> settle")
>> Cc: Shashank Sharma
>> Cc: Imre Deak
>> Cc: Jani Nikula
>> Cc: # v4.11+
>>
>> Since initial 100 seemed to be empirical and this increase seems to
>> help other cases I'm in favor of this move so
>>
>> Reviewed-by: Rodrigo Vivi
>>
>> However I will wait a bit before merging it
>> so Imre, Shashank, and/or Jani can take a look here...
>
> now, really cc'ing them...
Shashank? Does this slow down non-LSPCON paths?
BR,
Jani.
>
>>
>> > Signed-off-by: Fredrik Schön
>> > ---
>> > drivers/gpu/drm/i915/intel_lspcon.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
>> > b/drivers/gpu/drm/i915/intel_lspcon.c
>> > index 8ae8f42f430a..be1b08f589a4 100644
>> > --- a/drivers/gpu/drm/i915/intel_lspcon.c
>> > +++ b/drivers/gpu/drm/i915/intel_lspcon.c
>> > @@ -74,7 +74,7 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct
>> > intel_lspcon *lspcon,
>> >DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
>> > lspcon_mode_name(mode));
>> >
>> > - wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 100);
>> > + wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode,
>> > 1000);
>> >if (current_mode != mode)
>> >DRM_ERROR("LSPCON mode hasn't settled\n");
>> >
>> > --
>> > 2.17.1
>> >
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 i-g-t 1/3] igt/gem_sync: Exercise sync after context switch
Quoting Antonio Argenziano (2018-08-16 00:59:30)
>
>
> On 15/08/18 10:24, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-08-15 18:20:10)
> >>
> >>
> >> On 15/08/18 03:26, Chris Wilson wrote:
> >>> Quoting Antonio Argenziano (2018-08-15 00:50:43)
>
>
> On 10/08/18 04:01, Chris Wilson wrote:
> > This exercises a special case that may be of interest, waiting for a
> > context that may be preempted in order to reduce the wait.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > + cycles = 0;
> > + elapsed = 0;
> > + start = gettime();
> > + do {
> > + do {
> > + double this;
> > +
> > + gem_execbuf(fd, [0].execbuf);
> > + gem_execbuf(fd, [1].execbuf);
>
> I'm not sure where the preemption, mentioned in the commit message, is
> coming in.
> >>>
> >>> Internally. I've suggested that we reorder equivalent contexts in order
> >>> to satisfy client waits earlier. So having created two independent
> >>> request queues, userspace should be oblivious to the execution order.
> >>
> >> But there isn't an assert because you don't want that to be part of the
> >> contract between the driver and userspace, is that correct?
> >
> > Correct. Userspace hasn't specified an order between the two contexts so
> > can't actually assert it happens in a particular order. We are free then
> > to do whatever we like, but that also means no assertion. Just the
> > figures look pretty and ofc we have to check that nothing actually
> > breaks.
>
> The last question I have is about the batches, why not choosing a spin
> batch so to make sure that context[0] (and [1]) hasn't completed by the
> time it starts waiting.
It would be exercising fewer possibilities. Not that it would be any
less valid. (If I can't do a pair of trivial execbuf faster than the gpu
can execute a no-op from idle, shoot me. Each execbuf will take ~500ns,
the gpu will take 20-50us [bdw-kbl] to execute the first batch from idle.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
