Re: [Intel-gfx] [PATCH i-g-t 3/3] intel-ci: Add fast chamelium tests to the fast-feedback list
I have to revert locally to use fast-feedback.testlist here today... it seems chamelium is not compiling by default... first I thought it was a dirty build so I make distclean && autogen && make and chamelium wasn't still compiled... I end up not investigating this here, but I can do this next week... just dropping the message here in case someone has a quick insight... On Wed, Aug 23, 2017 at 8:21 AM, Paul Kocialkowski wrote: > This adds the fastest chamelium tests to the Intel CI fast-feedback > list, with the objective of running in under a minute. > > Signed-off-by: Paul Kocialkowski > --- > tests/intel-ci/fast-feedback.testlist | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/tests/intel-ci/fast-feedback.testlist > b/tests/intel-ci/fast-feedback.testlist > index 79160624..a8e9c5be 100644 > --- a/tests/intel-ci/fast-feedback.testlist > +++ b/tests/intel-ci/fast-feedback.testlist > @@ -1,5 +1,14 @@ > # Keep alphabetically sorted by default > > +igt@chamelium@dp-hpd-fast > +igt@chamelium@dp-edid-read > +igt@chamelium@dp-crc-fast > +igt@chamelium@hdmi-hpd-fast > +igt@chamelium@hdmi-edid-read > +igt@chamelium@hdmi-crc-fast > +igt@chamelium@vga-hpd-fast > +igt@chamelium@vga-edid-read > +igt@chamelium@common-hpd-after-suspend > igt@core_auth@basic-auth > igt@core_prop_blob@basic > igt@debugfs_test@read_all_entries > -- > 2.14.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: don't hardcode DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT
== Series Details == Series: drm/i915/cnl: don't hardcode DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT URL : https://patchwork.freedesktop.org/series/29373/ State : success == Summary == shard-hswtotal:2230 pass:1230 dwarn:0 dfail:0 fail:18 skip:982 time:9615s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5498/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for igt/vgem_basic: Load and unload the module first (rev2)
== Series Details == Series: igt/vgem_basic: Load and unload the module first (rev2) URL : https://patchwork.freedesktop.org/series/29371/ State : success == Summary == Test vgem_basic: Subgroup unload: skip -> PASS (shard-hsw) shard-hswtotal:2230 pass:1231 dwarn:0 dfail:0 fail:18 skip:981 time:9645s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_105/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for igt/vgem_basic: Load and unload the module first
== Series Details == Series: igt/vgem_basic: Load and unload the module first URL : https://patchwork.freedesktop.org/series/29371/ State : success == Summary == Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2230 pass:1229 dwarn:0 dfail:0 fail:19 skip:982 time:9649s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_104/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] lib: Add some syncobj helpers (v2)
== Series Details == Series: series starting with [1/4] lib: Add some syncobj helpers (v2) URL : https://patchwork.freedesktop.org/series/29370/ State : success == Summary == Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2300 pass:1230 dwarn:0 dfail:0 fail:19 skip:1051 time:9632s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_103/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for lib/kmod: Fix error reporting for kmod load/unload
== Series Details == Series: lib/kmod: Fix error reporting for kmod load/unload URL : https://patchwork.freedesktop.org/series/29368/ State : success == Summary == Test vgem_basic: Subgroup unload: skip -> PASS (shard-hsw) Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2230 pass:1230 dwarn:0 dfail:0 fail:19 skip:981 time:9623s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_102/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6] drm/i915: Fix FBC cfb stride programming for non X-tiled FB
Em Sex, 2017-08-11 às 00:00 +0530, Praveen Paneri escreveu:
> When FBC is enabled for linear, legacy Y-tiled and Yf-tiled
> surfaces on gen9, the cfb stride must be programmed by SW as
>
> cfb_stride = ceiling[(at least plane width in pixels)/
> (32 * compression limit factor)] * 8
>
> v2: Minor fix for a build error
> v3: Fixed subject, register name and platform check (Ville)
> v4: Added WA details in comment (Paulo)
> v5:
> - Read modified reg write to preserve other bit values (Paulo)
> - Store modified stride value in reg_params (Paulo)
> - Keep GLK out of the WA (Paulo)
> v6:
> - added additional field in reg_params for gen9_wa_cfb_stride
> (Paulo)
> - Used appropriate bit mask while writing the register (Paulo)
>
> Cc: Paulo Zanoni
> Signed-off-by: Praveen Paneri
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 4
> drivers/gpu/drm/i915/intel_fbc.c | 27 +++
> 3 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 907603c..1d40a7c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1106,6 +1106,7 @@ struct intel_fbc {
> } fb;
>
> int cfb_size;
> + unsigned int gen9_wa_cfb_stride;
> } params;
>
> struct intel_fbc_work {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 56df86e..51cab2f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6801,6 +6801,10 @@ enum {
> #define GLK_CL1_PWR_DOWN(1 << 11)
> #define GLK_CL0_PWR_DOWN(1 << 10)
>
> +#define CHICKEN_MISC_4 _MMIO(0x4208c)
> +#define FBC_STRIDE_OVERRIDE(1<<13)
See the new comment at the top of this file. (1 << 13) is preferred.
> +#define FBC_STRIDE_MASK0x1FFF
> +
> #define _CHICKEN_PIPESL_1_A 0x420b0
> #define _CHICKEN_PIPESL_1_B 0x420b4
> #define HSW_FBCQ_DIS(1 << 22)
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 860b8c2..21f6b33 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -291,6 +291,21 @@ static void gen7_fbc_activate(struct
> drm_i915_private *dev_priv)
> u32 dpfc_ctl;
> int threshold = dev_priv->fbc.threshold;
>
> + /* Display WA #0529: skl, kbl, bxt but not for glk*/
Don't need to list excluded platforms. Also, missing space before the
asterisk.
> + if (IS_GEN9(dev_priv) && !IS_GEMINILAKE(dev_priv)) {
> + u32 chicken_misc4 = I915_READ(CHICKEN_MISC_4);
In our driver, variables with the name of register usually contain its
address. We generally use "val" for values.
> +
> + if (i915_gem_object_get_tiling(params->vma->obj)
> + != I915_TILING_X) {
> + I915_WRITE(CHICKEN_MISC_4, chicken_misc4 |
> + FBC_STRIDE_OVERRIDE |
> + (params->gen9_wa_cfb_stride &
> FBC_STRIDE_MASK));
We're not masking the old value before overwriting it, eventually
everything is going to be 0xFFF if we keep changing the stride without
disabling it.
> + } else {
> + I915_WRITE(CHICKEN_MISC_4, chicken_misc4 &
> + ~(FBC_STRIDE_OVERRIDE |
> FBC_STRIDE_MASK));
> + }
> + }
> +
Major issue with spaces instead of tabs in the whole chunk above.
> dpfc_ctl = 0;
> if (IS_IVYBRIDGE(dev_priv))
> dpfc_ctl |= IVB_DPFC_CTL_PLANE(params->crtc.plane);
> @@ -865,6 +880,7 @@ static void intel_fbc_get_reg_params(struct
> intel_crtc *crtc,
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> struct intel_fbc *fbc = &dev_priv->fbc;
> struct intel_fbc_state_cache *cache = &fbc->state_cache;
> + int threshold = dev_priv->fbc.threshold;
>
> /* Since all our fields are integer types, use memset here
> so the
> * comparison function can rely on memcmp because the
> padding will be
> @@ -880,6 +896,17 @@ static void intel_fbc_get_reg_params(struct
> intel_crtc *crtc,
> params->fb.format = cache->fb.format;
> params->fb.stride = cache->fb.stride;
>
> + /* Display WA #0529: skl, kbl, bxt but not for glk*/
> + if (IS_GEN9(dev_priv) && !IS_GEMINILAKE(dev_priv)) {
> + /* calculate cfb stride for y-tiled mode */
> + if (i915_gem_object_get_tiling(params->vma->obj)
> + != I915_TILING_X) {
We don't need the check here, it's already done in the other part of
the code.
Anyway, to save time on yet another iteration of this patch I went
ahead and fixed the styling issues and the masking problem and merged
the patch. Thanks for the patch!
> + int cfb_stride = DIV_ROUND_UP(cache-
> >plane.src_w
Re: [Intel-gfx] [PATCH] drm/i915/cnl: don't hardcode DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT
Em Sex, 2017-08-25 às 12:51 -0700, Rodrigo Vivi escreveu: > Reviewed-by: Rodrigo Vivi Merged. Thanks for the review! > > On Fri, Aug 25, 2017 at 12:40 PM, Paulo Zanoni com> wrote: > > We have the macro, use it. Makes the code a little easier to > > understand. > > > > Cc: Rodrigo Vivi > > Signed-off-by: Paulo Zanoni > > --- > > drivers/gpu/drm/i915/intel_display.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index 6bfd0de..868d65c 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -9022,7 +9022,7 @@ static void cannonlake_get_ddi_pll(struct > > drm_i915_private *dev_priv, > > u32 temp; > > > > temp = I915_READ(DPCLKA_CFGCR0) & > > DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port); > > - id = temp >> (port * 2); > > + id = temp >> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port); > > > > if (WARN_ON(id < SKL_DPLL0 || id > SKL_DPLL2)) > > return; > > -- > > 2.9.5 > > > > ___ > > 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.IGT: warning for drm/i915: Mark wait_for_engine() as maybe_unused
== Series Details == Series: drm/i915: Mark wait_for_engine() as maybe_unused URL : https://patchwork.freedesktop.org/series/29365/ State : warning == Summary == Test kms_draw_crc: Subgroup draw-method-xrgb-blt-untiled: pass -> SKIP (shard-hsw) shard-hswtotal:2230 pass:1229 dwarn:0 dfail:0 fail:18 skip:983 time:9537s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5497/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915, drm/fourcc: Improve the CCS modifier documentation
On Fri, Aug 25, 2017 at 8:10 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:
> On Fri, Aug 18, 2017 at 11:34:40AM -0700, Jason Ekstrand wrote:
> > This updates the documentation on the intel CCS modifiers for a couple
> > of reasons:
> >
> > 1) The old documentation required that the CCS modifier only be used
> > with formats. While i915 currently only supports CCS scanout
> > with formats (and advertises such through the blob format), CCS
> > can be used with many other formats. Mesa, in particular, can
> > handle CCS on the full range of formats supported by the hardware.
> > For image sharing entirely within userspace, we don't want this
> > restriction.
> >
> > 2) The old documentation specified the scaling factor in terms of
> > pixels which breaks down when you start using formats which are not
> > 32-bit. By specifying it in terms of cache lines and tiles, we can
> > properly specify the scale-down relationship with no format size
> > assumptions.
> >
> > 3) The new comment provides more detail about the "real" layout of CCS
> > on Sky Lake and also points out that the reason why Y tiling is
> > important is because it affects row pitch calculations.
> >
> > 4) We shouldn't be documenting the Yf CCS modifier yet. Userspace is
> > incapable of generating it right now and we don't fully know how it
> > works yet. Trying to fully describe it is premature.
> >
> > Signed-off-by: Jason Ekstrand
> > Cc: Ben Widawsky
> > Cc: Ville Syrjälä
> > ---
> > include/uapi/drm/drm_fourcc.h | 35 ++-
> > 1 file changed, 22 insertions(+), 13 deletions(-)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> > index 3ad838d..9670da4 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -266,21 +266,30 @@ extern "C" {
> > /*
> > * Intel color control surface (CCS) for render compression
> > *
> > - * The framebuffer format must be one of the 8:8:8:8 RGB formats.
> > - * The main surface will be plane index 0 and must be Y/Yf-tiled,
> > - * the CCS will be plane index 1.
> > - *
> > - * Each CCS tile matches a 1024x512 pixel area of the main surface.
> > - * To match certain aspects of the 3D hardware the CCS is
> > - * considered to be made up of normal 128Bx32 Y tiles, Thus
> > - * the CCS pitch must be specified in multiples of 128 bytes.
> > - *
> > - * In reality the CCS tile appears to be a 64Bx64 Y tile, composed
> > - * of QWORD (8 bytes) chunks instead of OWORD (16 bytes) chunks.
> > - * But that fact is not relevant unless the memory is accessed
> > - * directly.
> > + * The image format must be compatible with CCS_E (lossless render
> > + * compression) as specified in the PRM for the relevant hardware.
> > + * The main surface will be plane index 0 and must be Y-tiled,
> > + * the CCS will be plane index 1 and is also Y-tiled.
> > + *
> > + * Each 64B cache line in the CCS (a region of 16B x 4 rows when
> > + * Y-tiled) corresponds to a region of 32x16 cache lines in the main
> > + * surface. (As a corollary, each CCS tile corresponds to an area of
> > + * 32x16 tiles in the main surface.) This relationship holds regardless
> > + * of the size of the number of bits per pixel of the image format.
> > + *
> > + * In reality, the cache lines in the CCS tile are proportioned in an
> > + * 8B x 8 row configuration with each byte being 2x2 2-bit CCS entries.
> > + * However, CCS is documented as Y-tiled with the scaling relationship
> > + * described in terms of cache lines as above so we consider it to be
> > + * Y-tiled for the purpose of specifying this modifier. This means that
> > + * the row pitch for the CCS assumes 128B/tile.
> > */
> > #define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
> > +
> > +/* Reserved for the Yf version of the TILED_CCS modifier.
> > + *
> > + * Exact definition TBD.
> > + */
>
> IIRC the same explanation can be used for both Y and Yf. The CCS
> surface is still using the wonky Y tile layout even if the main
> surface is Yf.
>
My reading of the docs indicates that the cache line correlation above
holds even for Yf and Ys. However, I'm reluctant to base too much off your
R-E work because it was, as far as I know, entirely done with 32-bit
formats. For 32-bit formats, Yf and Y have the same tile size. The only
difference is that the cache lines are swizzled about a bit more with Yf.
I'd like to confirm with some 64 and 128-bit formats before trying to spec
it.
--Jason
___
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] lib/igt_core: Use HTML character for documentation comment in example
== Series Details == Series: series starting with [1/3] lib/igt_core: Use HTML character for documentation comment in example URL : https://patchwork.freedesktop.org/series/29363/ State : success == Summary == shard-hswtotal:2230 pass:1230 dwarn:0 dfail:0 fail:18 skip:982 time:9617s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_101/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Add GuC Load time to debugfs
>-Original Message-
>From: Wajdeczko, Michal
>Sent: Friday, August 25, 2017 5:35 AM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Mateo Lozano, Oscar
>
>Subject: Re: [PATCH] drm/i915/guc: Add GuC Load time to debugfs
>
>On Thu, Aug 24, 2017 at 09:38:06PM -0700, Anusha Srivatsa wrote:
>> Calculate the time that GuC takes to load.
>> This information could be very useful in determining if GuC is taking
>> unreasonably long time to load in a certain platforms.
>>
>> Cc: Oscar Mateo
>> Cc: Michal Wajdeczko
>> Signed-off-by: Anusha Srivatsa
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.c | 4
>> drivers/gpu/drm/i915/intel_guc_loader.c | 4
>> drivers/gpu/drm/i915/intel_uc.h | 3 +++
>> 3 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index 48572b157222..9283fc714705 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -2379,6 +2379,10 @@ static int i915_guc_load_status_info(struct seq_file
>*m, void *data)
>> guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
>> seq_printf(m, "\tversion found: %d.%d\n",
>> guc_fw->major_ver_found, guc_fw->minor_ver_found);
>> +seq_printf(m, "\tLoad time is %lu ms\n",
>> + jiffies_to_msecs(dev_priv->guc.guc_finish_load -
>> + dev_priv->guc.guc_start_load));
>> +
>> seq_printf(m, "\theader: offset is %d; size = %d\n",
>> guc_fw->header_offset, guc_fw->header_size);
>> seq_printf(m, "\tuCode: offset is %d; size = %d\n", diff --git
>> a/drivers/gpu/drm/i915/intel_guc_loader.c
>> b/drivers/gpu/drm/i915/intel_guc_loader.c
>> index 8b0ae7fce7f2..1c5059b930f9 100644
>> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
>> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
>> @@ -194,6 +194,7 @@ static inline bool guc_ucode_response(struct
>> drm_i915_private *dev_priv, static int guc_ucode_xfer_dma(struct
>drm_i915_private *dev_priv,
>>struct i915_vma *vma)
>> {
>> +struct intel_guc *guc = &dev_priv->guc;
>> struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
>> unsigned long offset;
>> struct sg_table *sg = vma->pages;
>> @@ -226,6 +227,7 @@ static int guc_ucode_xfer_dma(struct
>> drm_i915_private *dev_priv,
>>
>> /* Finally start the DMA */
>> I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(UOS_MOVE |
>START_DMA));
>> +guc->guc_start_load = jiffies;
>>
>> /*
>> * Wait for the DMA to complete & the GuC to start up.
>> @@ -240,6 +242,8 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
>*dev_priv,
>> DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",
>> I915_READ(DMA_CTRL), status);
>>
>> +guc->guc_finish_load = jiffies;
>> +
>
>On error/timeout we don't know if loading was finished/completed and your
>calculations will be wrong. End time shall be captured before any debug logs to
>more accurate. Btw, if loading time is so important, maybe it should be also
>printed here as part of above DRM_DEBUG ?
Hmmm... I thought by this time in the code the load will be over and hence we
read the stautus registers.
Yes adding as a dmesg too, will be helpful.
Anusha
>
>> if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
>> DRM_ERROR("GuC firmware signature verification failed\n");
>> ret = -ENOEXEC;
>> diff --git a/drivers/gpu/drm/i915/intel_uc.h
>> b/drivers/gpu/drm/i915/intel_uc.h index 22ae52b17b0f..3d5a15ed1995
>> 100644
>> --- a/drivers/gpu/drm/i915/intel_uc.h
>> +++ b/drivers/gpu/drm/i915/intel_uc.h
>> @@ -210,6 +210,9 @@ struct intel_guc {
>>
>> /* GuC's FW specific notify function */
>> void (*notify)(struct intel_guc *guc);
>> +
>> +unsigned long guc_start_load;
>> +unsigned long guc_finish_load;
>
>No need to keep both jiffies here. Calculate "load_time_in_ms" in the loader
>function and store only final result. Maybe better place for this result would
>be
>"intel_uc_fw" ? Then we can do the same for Huc.
Adding to intel_uc_fw makes sense. But I wonder if we need a usecase to know
the huc load time nothing wrong to add though.
Thanks for your inputs!
Anusha
>
>-Michal
>
>> };
>>
>> struct intel_huc {
>> --
>> 2.11.0
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] mm: Track actual nr_scanned during shrink_slab()
On Thu, 24 Aug 2017 10:00:49 +0200 Vlastimil Babka wrote: > > Even if a > > shrinker has a mistake, VM will have big trouble like infinite loop. > > We could fake 0 as 1 or something, at least. If the shrinker returns sc->nr_scanned==0 then that's a buggy shrinker - it should return SHRINK_STOP in that case. Only a single shrinker (i915) presently uses sc->nr_scanned and that one gets it right. I think it's OK - there's a limit to how far we should go defending against buggy kernel code, surely. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Quietly cancel FBC activation if CRTC is turned off before worker
== Series Details == Series: drm/i915: Quietly cancel FBC activation if CRTC is turned off before worker URL : https://patchwork.freedesktop.org/series/29362/ State : failure == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test kms_flip: Subgroup plain-flip-ts-check-interruptible: pass -> FAIL (shard-hsw) fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-hswtotal:2230 pass:1228 dwarn:0 dfail:0 fail:20 skip:982 time:9578s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5496/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc : Removing enable_guc_loading module
On 23/08/17 15:11, Sujaritha Sundaresan wrote: Whenever we need i915.enable_guc_submission=1, we also need enable_guc_loading=1. We also need enable_guc_loading=1 when we want to verify the HuC, which is every time we have a HuC (but all platforms with HuC have a GuC and viceversa). We don't need the user to tell when to enable the GuC loading Drive-by comment: I'd call out more explicitly that with this patch as long as both GuC and HuC FW are on the machine they will always be loaded, which is a change to the current behavior. I'm not implying that the change is bad, but it alters timing in some scenarios (e.g. resume) and interested parties might miss it if we aren't explicit about it. Thanks, Daniele Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Signed-off-by: Sujaritha Sundaresan --- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/10] drm/i915: decouple gen9 and gen10 dp signal levels.
Let's decouple bxt, glk and cnl dp signal levels
from other DDIs to avoid confusion.
No functional change. Only a reorg to avoid messing
with currently working DP signal levels when
moving voltage swing sequences around to match spec.
v2: ddi_signal_levels is also called from other ddi
platforms, so don't remove IS_GEN9_BC check from
skl_ddi_set_iboos. (Ville).
Cc: Ville Syrjälä
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 27 ++-
drivers/gpu/drm/i915/intel_dp.c | 10 --
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 7e875e05d053..9a887780f99f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2063,23 +2063,32 @@ static uint32_t intel_ddi_dp_level(struct intel_dp
*intel_dp)
return translate_signal_level(signal_levels);
}
-uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
+u32 bxt_signal_levels(struct intel_dp *intel_dp)
{
struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dport->base.base.dev);
struct intel_encoder *encoder = &dport->base;
enum port port = dport->port;
+ u32 level = intel_ddi_dp_level(intel_dp);
+
+ if (IS_CANNONLAKE(dev_priv))
+ cnl_ddi_vswing_sequence(encoder, level);
+ else
+ bxt_ddi_vswing_sequence(dev_priv, level, port, encoder->type);
+
+ return 0;
+}
+
+uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
+ struct drm_i915_private *dev_priv = to_i915(dport->base.base.dev);
+ struct intel_encoder *encoder = &dport->base;
uint32_t level = intel_ddi_dp_level(intel_dp);
if (IS_GEN9_BC(dev_priv))
- skl_ddi_set_iboost(encoder, level);
- else if (IS_GEN9_LP(dev_priv))
- bxt_ddi_vswing_sequence(dev_priv, level, port, encoder->type);
- else if (IS_CANNONLAKE(dev_priv)) {
- cnl_ddi_vswing_sequence(encoder, level);
- /* DDI_BUF_CTL bits 27:24 are reserved on CNL */
- return 0;
- }
+ skl_ddi_set_iboost(encoder, level);
+
return DDI_BUF_TRANS_SELECT(level);
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d3e5fdf0d2fa..49a8c339b2b0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3506,13 +3506,11 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp)
uint32_t signal_levels, mask = 0;
uint8_t train_set = intel_dp->train_set[0];
- if (HAS_DDI(dev_priv)) {
+ if (IS_GEN9_LP(dev_priv) || IS_CANNONLAKE(dev_priv)) {
+ signal_levels = bxt_signal_levels(intel_dp);
+ } else if (HAS_DDI(dev_priv)) {
signal_levels = ddi_signal_levels(intel_dp);
-
- if (IS_GEN9_LP(dev_priv) || IS_CANNONLAKE(dev_priv))
- signal_levels = 0;
- else
- mask = DDI_BUF_EMP_MASK;
+ mask = DDI_BUF_EMP_MASK;
} else if (IS_CHERRYVIEW(dev_priv)) {
signal_levels = chv_signal_levels(intel_dp);
} else if (IS_VALLEYVIEW(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 17649f13091c..469c06000774 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1271,6 +1271,7 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config);
void intel_ddi_set_vc_payload_alloc(const struct intel_crtc_state *crtc_state,
bool state);
+u32 bxt_signal_levels(struct intel_dp *intel_dp);
uint32_t ddi_signal_levels(struct intel_dp *intel_dp);
u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/23] mm/shmem: introduce shmem_file_setup_with_mnt
On Thu, 24 Aug 2017 13:04:09 +0100 Matthew Auld wrote: > On 23 August 2017 at 23:34, Andrew Morton wrote: > > On Wed, 23 Aug 2017 12:31:28 +0300 Joonas Lahtinen > > wrote: > > > >> This patch has been floating around for a while now Acked and without > >> further comments. It is blocking us from merging huge page support to > >> drm/i915. > >> > >> Would you mind merging it, or prodding the right people to get it in? > >> > >> Regards, Joonas > >> > >> On Mon, 2017-08-21 at 19:34 +0100, Matthew Auld wrote: > >> > We are planning to use our own tmpfs mnt in i915 in place of the > >> > shm_mnt, such that we can control the mount options, in particular > >> > huge=, which we require to support huge-gtt-pages. So rather than roll > >> > our own version of __shmem_file_setup, it would be preferred if we could > >> > just give shmem our mnt, and let it do the rest. > > > > hm, it's a bit odd. I'm having trouble locating the code which handles > > huge=within_size (and any other options?). > > See here https://patchwork.freedesktop.org/patch/172771/, currently we > only care about huge=within_size. > > > What other approaches were considered? > > We also tried https://patchwork.freedesktop.org/patch/156528/, where > it was suggested that we mount our own tmpfs instance. > > Following from that we now have our own tmps mnt mounted with > huge=within_size. With this patch we avoid having to roll our own > __shmem_file_setup like in > https://patchwork.freedesktop.org/patch/163024/. > > > Was it not feasible to add i915-specific mount options to > > mm/shmem.c (for example?). > > Hmm, I think within_size should suffice for our needs. hm, ok, well, unless someone can think of something cleaner, please add my ack and include it in the appropriate drm tree. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Deal with upside-down mounted LCD panels (rev2)
== Series Details == Series: drm/i915: Deal with upside-down mounted LCD panels (rev2) URL : https://patchwork.freedesktop.org/series/29161/ State : success == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2230 pass:1230 dwarn:0 dfail:0 fail:18 skip:982 time:9586s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5495/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: don't hardcode DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT
== Series Details == Series: drm/i915/cnl: don't hardcode DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT URL : https://patchwork.freedesktop.org/series/29373/ State : success == Summary == Series 29373v1 drm/i915/cnl: don't hardcode DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT https://patchwork.freedesktop.org/api/1.0/series/29373/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test kms_frontbuffer_tracking: Subgroup basic: dmesg-warn -> PASS (fi-bdw-5557u) fdo#102410 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#102410 https://bugs.freedesktop.org/show_bug.cgi?id=102410 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:461s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:437s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:362s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:552s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:251s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:522s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:524s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:529s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:434s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:618s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:445s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:425s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:429s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:501s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:479s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:603s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:595s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:529s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:468s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:481s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:442s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:480s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:554s fi-snb-2600 total:279 pass:248 dwarn:0 dfail:0 fail:2 skip:29 time:402s fi-skl-6770hq failed to connect after reboot 4823f19b979cd7b6a27a9d6861fa3e98c1e1fea2 drm-tip: 2017y-08m-25d-15h-55m-05s UTC integration manifest fd38ece874be drm/i915/cnl: don't hardcode DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5498/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/bios: additional vbt definition cleanups
== Series Details == Series: drm/i915/bios: additional vbt definition cleanups URL : https://patchwork.freedesktop.org/series/29357/ State : success == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2230 pass:1230 dwarn:0 dfail:0 fail:18 skip:982 time:9635s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5494/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: don't hardcode DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT
Reviewed-by: Rodrigo Vivi On Fri, Aug 25, 2017 at 12:40 PM, Paulo Zanoni wrote: > We have the macro, use it. Makes the code a little easier to > understand. > > Cc: Rodrigo Vivi > Signed-off-by: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 6bfd0de..868d65c 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -9022,7 +9022,7 @@ static void cannonlake_get_ddi_pll(struct > drm_i915_private *dev_priv, > u32 temp; > > temp = I915_READ(DPCLKA_CFGCR0) & > DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port); > - id = temp >> (port * 2); > + id = temp >> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port); > > if (WARN_ON(id < SKL_DPLL0 || id > SKL_DPLL2)) > return; > -- > 2.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/cnl: don't hardcode DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT
We have the macro, use it. Makes the code a little easier to understand. Cc: Rodrigo Vivi Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 6bfd0de..868d65c 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -9022,7 +9022,7 @@ static void cannonlake_get_ddi_pll(struct drm_i915_private *dev_priv, u32 temp; temp = I915_READ(DPCLKA_CFGCR0) & DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port); - id = temp >> (port * 2); + id = temp >> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port); if (WARN_ON(id < SKL_DPLL0 || id > SKL_DPLL2)) return; -- 2.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for igt/vgem_basic: Load and unload the module first (rev2)
== Series Details == Series: igt/vgem_basic: Load and unload the module first (rev2) URL : https://patchwork.freedesktop.org/series/29371/ State : success == Summary == IGT patchset tested on top of latest successful build 60f6a12195395934f179d5ecc080353190d19a6c tests: chamelium: Eliminate reset when preparing output with latest DRM-Tip kernel build CI_DRM_3006 4823f19b979c drm-tip: 2017y-08m-25d-15h-55m-05s UTC integration manifest Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 +1 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-x1585l) fdo#101781 Test kms_frontbuffer_tracking: Subgroup basic: dmesg-warn -> PASS (fi-bdw-5557u) fdo#102410 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#102410 https://bugs.freedesktop.org/show_bug.cgi?id=102410 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:461s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:444s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:363s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:548s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:251s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:523s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:521s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:520s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:439s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:612s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:456s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:427s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:424s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:507s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:600s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:594s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:522s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:476s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:481s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:487s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:444s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:505s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:553s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:403s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_105/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v2 3/3] drm/i915/pmu: deny perf driver level sampling of i915 PMU
Returning mailing list back. Just tried ./intel-gpu-overlay. From what I see it wonderfully works even when I wiped out event->sampling_period from i915 RFC PMU and prohibited it. Mind that I did not remove sampling inside i915 RFC PMU: I removed only timer staff which is exposed to the perf core. Sampling itself is still there and works as far as I see. Thus, the question: why event->hw->hrtimer staff was introduced in i915 RFC PMU? Right now it does not make sense to me. Dmitry. -Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Friday, August 25, 2017 11:19 AM To: Rogozhkin, Dmitry V ; Wilson, Chris Subject: RE: [RFC v2 3/3] drm/i915/pmu: deny perf driver level sampling of i915 PMU Quoting Rogozhkin, Dmitry V (2017-08-25 19:06:13) > Hi Chris, not sure you saw my mail. So, I try to remind. It's integral to all the sampling counters we use; which are the majority of the events exposed and used by intel-gpu-overlay. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for lib: Avoid actually throttling from igt_require_gem() (rev2)
On Fri, Aug 25, 2017 at 06:39:01PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-08-25 18:11:56) > > On Thu, Aug 24, 2017 at 01:22:40PM -, Patchwork wrote: > > > == Series Details == > > > > > > Series: lib: Avoid actually throttling from igt_require_gem() (rev2) > > > URL : https://patchwork.freedesktop.org/series/28983/ > > > State : failure > > > > 2 r-b tags and no comment on why it failed CI? > > It failed CI? CI failed it and gave no reason. It looks like the network > gave up in the middle of a transfer. We've had a few runs where kbl-7560u died due to dp mst plugged in, which haven't been handled. And if you fail BAT it won't run the more complete IGT set, so you pretty much have to resend either way. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for igt/vgem_basic: Load and unload the module first
== Series Details == Series: igt/vgem_basic: Load and unload the module first URL : https://patchwork.freedesktop.org/series/29371/ State : warning == Summary == IGT patchset tested on top of latest successful build 29d488034a50cd6fbad792cae61321995f0ab51c aubdump: Log some information about the execbuf calls with latest DRM-Tip kernel build CI_DRM_3006 4823f19b979c drm-tip: 2017y-08m-25d-15h-55m-05s UTC integration manifest Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 +1 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-x1585l) fdo#101781 Test vgem_basic: Subgroup unload: pass -> SKIP (fi-blb-e6850) pass -> SKIP (fi-pnv-d510) pass -> SKIP (fi-bwr-2160) pass -> SKIP (fi-elk-e7500) pass -> SKIP (fi-ilk-650) pass -> SKIP (fi-snb-2520m) pass -> SKIP (fi-snb-2600) pass -> SKIP (fi-ivb-3520m) pass -> SKIP (fi-ivb-3770) pass -> SKIP (fi-byt-j1900) pass -> SKIP (fi-byt-n2820) pass -> SKIP (fi-hsw-4770) pass -> SKIP (fi-hsw-4770r) pass -> SKIP (fi-bdw-5557u) pass -> SKIP (fi-bdw-gvtdvm) pass -> SKIP (fi-bsw-n3050) pass -> SKIP (fi-skl-6260u) pass -> SKIP (fi-skl-6700k) pass -> SKIP (fi-skl-6770hq) pass -> SKIP (fi-skl-gvtdvm) pass -> SKIP (fi-skl-x1585l) pass -> SKIP (fi-bxt-j4205) pass -> SKIP (fi-kbl-7500u) pass -> SKIP (fi-kbl-7560u) pass -> SKIP (fi-kbl-r) pass -> SKIP (fi-glk-2a) fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fi-bdw-5557u total:279 pass:266 dwarn:1 dfail:0 fail:0 skip:12 time:454s fi-bdw-gvtdvmtotal:279 pass:264 dwarn:0 dfail:0 fail:0 skip:15 time:437s fi-blb-e6850 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:363s fi-bsw-n3050 total:279 pass:242 dwarn:0 dfail:0 fail:0 skip:37 time:566s fi-bwr-2160 total:279 pass:183 dwarn:0 dfail:0 fail:0 skip:96 time:252s fi-bxt-j4205 total:279 pass:259 dwarn:0 dfail:0 fail:0 skip:20 time:521s fi-byt-j1900 total:279 pass:253 dwarn:1 dfail:0 fail:0 skip:25 time:523s fi-byt-n2820 total:279 pass:249 dwarn:1 dfail:0 fail:0 skip:29 time:517s fi-elk-e7500 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:438s fi-glk-2atotal:279 pass:259 dwarn:0 dfail:0 fail:0 skip:20 time:607s fi-hsw-4770 total:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:448s fi-hsw-4770r total:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:423s fi-ilk-650 total:279 pass:228 dwarn:0 dfail:0 fail:0 skip:51 time:423s fi-ivb-3520m total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:500s fi-ivb-3770 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:473s fi-kbl-7500u total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:475s fi-kbl-7560u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:597s fi-kbl-r total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:601s fi-pnv-d510 total:279 pass:222 dwarn:1 dfail:0 fail:0 skip:56 time:525s fi-skl-6260u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:473s fi-skl-6700k total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:477s fi-skl-6770hqtotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:493s fi-skl-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:447s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:505s fi-snb-2520m total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:544s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:0 skip:30 time:407s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_104/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop
[Intel-gfx] [PATCH igt v2] igt/vgem_basic: Load and unload the module first
To ensure the module exists, first load it. Then when we try to unload the module (to check that our modprobe interface works), we will not get spurious failures due to -ENOENT (in this case meaning the module did not exist): (vgem_basic:18361) igt-core-DEBUG: Starting subtest: unload (vgem_basic:18361) igt-kmod-DEBUG: Could not remove module vgem (No such file or directory) Test requirement not met in function test_unload, file vgem_basic.c:331: Test requirement: module_unload() == 0 Last errno: 2, No such file or directory Signed-off-by: Chris Wilson --- tests/vgem_basic.c | 4 1 file changed, 4 insertions(+) diff --git a/tests/vgem_basic.c b/tests/vgem_basic.c index 982da73a..1a952c54 100644 --- a/tests/vgem_basic.c +++ b/tests/vgem_basic.c @@ -328,6 +328,10 @@ static void test_unload(void) int vgem, dmabuf; uint32_t *ptr; + /* Load and unload vgem just to make sure it exists */ + vgem = __drm_open_driver(DRIVER_VGEM); + igt_require(vgem != -1); + close(vgem); igt_require(module_unload() == 0); vgem = __drm_open_driver(DRIVER_VGEM); -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests: chamelium: Eliminate reset when preparing output
R-B'd and pushed, thanks! On Fri, 2017-08-25 at 15:03 +0300, Paul Kocialkowski wrote: > Resetting the Chamelium when preparing the video output is > unnecessary > and significant increases the tests run-time. Since all video-related > tests work just as well without it, eliminate it. > > This also adds a call to reset_test in the analog frame dump test, > that > was missing before, although the chamelium was still reset by the > call > to prepare_output. > > Signed-off-by: Paul Kocialkowski > --- > tests/chamelium.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tests/chamelium.c b/tests/chamelium.c > index 00ae484b..484bb537 100644 > --- a/tests/chamelium.c > +++ b/tests/chamelium.c > @@ -417,8 +417,6 @@ prepare_output(data_t *data, > drmModeConnector *connector = > chamelium_port_get_connector(data->chamelium, port, > false); > > - chamelium_reset(data->chamelium); > - > igt_assert(res = drmModeGetResources(data->drm_fd)); > kmstest_unset_all_crtcs(data->drm_fd, res); > > @@ -626,6 +624,8 @@ test_analog_frame_dump(data_t *data, struct > chamelium_port *port) > int fb_id, i; > bool bridge; > > + reset_state(data, port); > + > output = prepare_output(data, &display, port); > connector = chamelium_port_get_connector(data->chamelium, > port, false); > primary = igt_output_get_plane_type(output, > DRM_PLANE_TYPE_PRIMARY); -- Cheers, Lyude ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] igt/vgem_basic: Load and unload the module first
To ensure the module exists, first load it. Then when we try to unload the module (to check that our modprobe interface works), we will not get spurious failures due to -ENOENT (in this case meaning the module did not exist): (vgem_basic:18361) igt-core-DEBUG: Starting subtest: unload (vgem_basic:18361) igt-kmod-DEBUG: Could not remove module vgem (No such file or directory) Test requirement not met in function test_unload, file vgem_basic.c:331: Test requirement: module_unload() == 0 Last errno: 2, No such file or directory Signed-off-by: Chris Wilson --- tests/vgem_basic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/vgem_basic.c b/tests/vgem_basic.c index 982da73a..cfd94071 100644 --- a/tests/vgem_basic.c +++ b/tests/vgem_basic.c @@ -328,6 +328,9 @@ static void test_unload(void) int vgem, dmabuf; uint32_t *ptr; + /* Load and unload vgem just to make sure it exists */ + vgem = __drm_open_driver(DRIVER_VGEM); + igt_require(vgem != -1); igt_require(module_unload() == 0); vgem = __drm_open_driver(DRIVER_VGEM); -- 2.14.1 ___ 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] lib: Add some syncobj helpers (v2)
== Series Details == Series: series starting with [1/4] lib: Add some syncobj helpers (v2) URL : https://patchwork.freedesktop.org/series/29370/ State : success == Summary == IGT patchset tested on top of latest successful build 29d488034a50cd6fbad792cae61321995f0ab51c aubdump: Log some information about the execbuf calls with latest DRM-Tip kernel build CI_DRM_3006 4823f19b979c drm-tip: 2017y-08m-25d-15h-55m-05s UTC integration manifest Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 +1 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:279 pass:267 dwarn:1 dfail:0 fail:0 skip:11 time:455s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:439s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:365s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:555s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:252s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:527s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:527s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:519s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:438s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:615s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:446s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:431s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:426s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:512s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:482s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:481s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:602s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:603s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:521s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:476s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:495s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:441s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:483s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:555s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:408s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_103/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/4] tests/syncobj: Add some wait and reset tests (v6)
This adds both trivial error-checking tests as well as more complex
tests which actually test whether or not waits do what they're supposed
to do. They only currently work on i915 but it should be simple to hook
them up for other drivers by simply implementing the little function
pointer hook provided at the top for triggering a syncobj.
v2:
- Actually add the reset tests.
v3:
- Only do one execbuf for trigger
- Use do_ioctl and do_ioctl_err
- Better check for syncobj support
- Add local_/LOCAL_ defines of things
- Use a timer instead of a pthread
v4:
- Use ioctl wrappers
- Use VGEM instead of i915
- Combine a bunch of the simple tests into one function
v5:
- Combinatorially generate basic tests
- Use sw_sync instead of using vgem directly
- Add even more tests
Signed-off-by: Jason Ekstrand
---
tests/Makefile.sources | 1 +
tests/syncobj_wait.c | 909 +
2 files changed, 910 insertions(+)
create mode 100644 tests/syncobj_wait.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index bb013c7..430b637 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -230,6 +230,7 @@ TESTS_progs = \
prime_vgem \
sw_sync \
syncobj_basic \
+ syncobj_wait \
template \
tools_test \
vgem_basic \
diff --git a/tests/syncobj_wait.c b/tests/syncobj_wait.c
new file mode 100644
index 000..2cb8f14
--- /dev/null
+++ b/tests/syncobj_wait.c
@@ -0,0 +1,909 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "igt.h"
+#include "sw_sync.h"
+#include "igt_syncobj.h"
+#include
+#include
+#include
+#include "drm.h"
+
+IGT_TEST_DESCRIPTION("Tests for the drm sync object wait API");
+
+/* One tenth of a second */
+#define SHORT_TIME_NSEC 1ull
+
+#define NSECS_PER_SEC 10ull
+
+static uint64_t
+gettime_ns(void)
+{
+ struct timespec current;
+ clock_gettime(CLOCK_MONOTONIC, ¤t);
+ return (uint64_t)current.tv_sec * NSECS_PER_SEC + current.tv_nsec;
+}
+
+static void
+sleep_nsec(uint64_t time_nsec)
+{
+ struct timespec t;
+ t.tv_sec = time_nsec / NSECS_PER_SEC;
+ t.tv_nsec = time_nsec % NSECS_PER_SEC;
+ igt_assert_eq(nanosleep(&t, NULL), 0);
+}
+
+static uint64_t
+short_timeout(void)
+{
+ return gettime_ns() + SHORT_TIME_NSEC;
+}
+
+static int
+syncobj_attach_sw_sync(int fd, uint32_t handle)
+{
+ struct drm_syncobj_handle;
+ int timeline, fence;
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_timeline_create_fence(timeline, 1);
+ syncobj_import_sync_file(fd, handle, fence);
+ close(fence);
+
+ return timeline;
+}
+
+static void
+syncobj_trigger(int fd, uint32_t handle)
+{
+ int timeline = syncobj_attach_sw_sync(fd, handle);
+ sw_sync_timeline_inc(timeline, 1);
+ close(timeline);
+}
+
+static timer_t
+set_timer(void (*cb)(union sigval), void *ptr, int i, uint64_t nsec)
+{
+timer_t timer;
+struct sigevent sev;
+struct itimerspec its;
+
+memset(&sev, 0, sizeof(sev));
+sev.sigev_notify = SIGEV_THREAD;
+ if (ptr)
+ sev.sigev_value.sival_ptr = ptr;
+ else
+ sev.sigev_value.sival_int = i;
+sev.sigev_notify_function = cb;
+igt_assert(timer_create(CLOCK_MONOTONIC, &sev, &timer) == 0);
+
+memset(&its, 0, sizeof(its));
+its.it_value.tv_sec = nsec / NSEC_PER_SEC;
+its.it_value.tv_nsec = nsec % NSEC_PER_SEC;
+igt_assert(timer_settime(timer, 0, &its, NULL) == 0);
+
+ return timer;
+}
+
+struct fd_handle_pair {
+ int fd;
+ uint32_t handle;
+};
+
+static void
+timeline_inc_func(union sigval sigval)
+{
+ sw_sync_timeline_inc(sigval.sival_int, 1);
+}
+
+static void
+syncobj_trigger_free_pair_func(union sigval sigva
[Intel-gfx] [PATCH i-g-t 4/4] syncobj: Add a test for SYNCOBJ_CREATE_SIGNALED
---
tests/syncobj_basic.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/tests/syncobj_basic.c b/tests/syncobj_basic.c
index 0a304f1..acc4a64 100644
--- a/tests/syncobj_basic.c
+++ b/tests/syncobj_basic.c
@@ -146,6 +146,16 @@ test_bad_create_flags(int fd)
igt_assert(ret == -1 && errno == EINVAL);
}
+static void
+test_create_signaled(int fd)
+{
+ uint32_t syncobj = syncobj_create(fd, LOCAL_SYNCOBJ_CREATE_SIGNALED);
+
+ igt_assert_eq(syncobj_wait_err(fd, &syncobj, 1, 0, 0), 0);
+
+ syncobj_destroy(fd, syncobj);
+}
+
/*
* currently don't do handle deduplication
* test we get a different handle back.
@@ -215,6 +225,9 @@ igt_main
igt_subtest("bad-destroy-pad")
test_bad_destroy_pad(fd);
+ igt_subtest("create-signaled")
+ test_create_signaled(fd);
+
igt_subtest("test-valid-cycle")
test_valid_cycle(fd);
--
2.5.0.400.gff86faf
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/4] tests/syncobj: Convert the basic test over to the helpers
Signed-off-by: Jason Ekstrand
---
tests/syncobj_basic.c | 77 +--
1 file changed, 19 insertions(+), 58 deletions(-)
diff --git a/tests/syncobj_basic.c b/tests/syncobj_basic.c
index a7a6742..0a304f1 100644
--- a/tests/syncobj_basic.c
+++ b/tests/syncobj_basic.c
@@ -22,6 +22,7 @@
*/
#include "igt.h"
+#include "igt_syncobj.h"
#include
#include
#include "drm.h"
@@ -48,14 +49,11 @@ static void
test_bad_handle_to_fd(int fd)
{
struct drm_syncobj_handle handle;
- int ret;
handle.handle = 0xdeadbeef;
handle.flags = 0;
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &handle);
-
- igt_assert(ret == -1 && errno == EINVAL);
+ igt_assert_eq(__syncobj_handle_to_fd(fd, &handle), -EINVAL);
}
/* fd to handle a bad fd */
@@ -63,14 +61,11 @@ static void
test_bad_fd_to_handle(int fd)
{
struct drm_syncobj_handle handle;
- int ret;
handle.fd = -1;
handle.flags = 0;
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
-
- igt_assert(ret == -1 && errno == EINVAL);
+ igt_assert_eq(__syncobj_fd_to_handle(fd, &handle), -EINVAL);
}
/* fd to handle an fd but not a sync file one */
@@ -78,58 +73,47 @@ static void
test_illegal_fd_to_handle(int fd)
{
struct drm_syncobj_handle handle;
- int ret;
handle.fd = fd;
handle.flags = 0;
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
-
- igt_assert(ret == -1 && errno == EINVAL);
+ igt_assert_eq(__syncobj_fd_to_handle(fd, &handle), -EINVAL);
}
static void
test_bad_flags_fd_to_handle(int fd)
{
struct drm_syncobj_handle handle = { 0 };
- int ret;
handle.flags = 0xdeadbeef;
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
- igt_assert(ret == -1 && errno == EINVAL);
+ igt_assert_eq(__syncobj_fd_to_handle(fd, &handle), -EINVAL);
}
static void
test_bad_flags_handle_to_fd(int fd)
{
struct drm_syncobj_handle handle = { 0 };
- int ret;
handle.flags = 0xdeadbeef;
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &handle);
- igt_assert(ret == -1 && errno == EINVAL);
+ igt_assert_eq(__syncobj_handle_to_fd(fd, &handle), -EINVAL);
}
static void
test_bad_pad_handle_to_fd(int fd)
{
struct drm_syncobj_handle handle = { 0 };
- int ret;
handle.pad = 0xdeadbeef;
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &handle);
- igt_assert(ret == -1 && errno == EINVAL);
+ igt_assert_eq(__syncobj_handle_to_fd(fd, &handle), -EINVAL);
}
static void
test_bad_pad_fd_to_handle(int fd)
{
struct drm_syncobj_handle handle = { 0 };
- int ret;
handle.pad = 0xdeadbeef;
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
- igt_assert(ret == -1 && errno == EINVAL);
+ igt_assert_eq(__syncobj_fd_to_handle(fd, &handle), -EINVAL);
}
@@ -138,24 +122,17 @@ test_bad_pad_fd_to_handle(int fd)
static void
test_bad_destroy_pad(int fd)
{
- struct drm_syncobj_create create = { 0 };
struct drm_syncobj_destroy destroy;
int ret;
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, &create);
-
- destroy.handle = create.handle;
+ destroy.handle = syncobj_create(fd, 0);
destroy.pad = 0xdeadbeef;
ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, &destroy);
igt_assert(ret == -1 && errno == EINVAL);
- destroy.handle = create.handle;
- destroy.pad = 0;
-
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, &destroy);
- igt_assert(ret == 0);
+ syncobj_destroy(fd, destroy.handle);
}
static void
@@ -176,34 +153,18 @@ test_bad_create_flags(int fd)
static void
test_valid_cycle(int fd)
{
- int ret;
- struct drm_syncobj_create create = { 0 };
- struct drm_syncobj_handle handle = { 0 };
- struct drm_syncobj_destroy destroy = { 0 };
- uint32_t first_handle;
-
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, &create);
- igt_assert(ret == 0);
+ uint32_t first_handle, second_handle;
+ int syncobj_fd;
- first_handle = create.handle;
+ first_handle = syncobj_create(fd, 0);
+ syncobj_fd = syncobj_handle_to_fd(fd, first_handle, 0);
+ second_handle = syncobj_fd_to_handle(fd, syncobj_fd, 0);
+ close(syncobj_fd);
- handle.handle = create.handle;
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &handle);
- igt_assert(ret == 0);
- handle.handle = 0;
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, &handle);
- close(handle.fd);
- igt_assert(ret == 0);
+ igt_assert(first_handle != second_handle);
- igt_assert(handle.handle != first_handle);
-
- destroy.handle = handle.handle;
- ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, &destroy);
- igt_assert(ret == 0);
-
- destroy.handle =
[Intel-gfx] [PATCH i-g-t 1/4] lib: Add some syncobj helpers (v2)
Signed-off-by: Jason Ekstrand
---
lib/Makefile.sources | 2 +
lib/igt_syncobj.c| 207 +++
lib/igt_syncobj.h| 71 ++
3 files changed, 280 insertions(+)
create mode 100644 lib/igt_syncobj.c
create mode 100644 lib/igt_syncobj.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 53fdb54..692fe30 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -83,6 +83,8 @@ lib_source_list = \
uwildmat/uwildmat.c \
igt_kmod.c \
igt_kmod.h \
+ igt_syncobj.c \
+ igt_syncobj.h \
$(NULL)
.PHONY: version.h.tmp
diff --git a/lib/igt_syncobj.c b/lib/igt_syncobj.c
new file mode 100644
index 000..5caef2a
--- /dev/null
+++ b/lib/igt_syncobj.c
@@ -0,0 +1,207 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include
+#include
+
+#include "igt.h"
+#include "igt_syncobj.h"
+
+static int
+__syncobj_create(int fd, uint32_t *handle, uint32_t flags)
+{
+ struct drm_syncobj_create create = { 0 };
+ int err = 0;
+
+ create.flags = flags;
+ if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, &create))
+ err = -errno;
+ *handle = create.handle;
+ return err;
+}
+
+uint32_t
+syncobj_create(int fd, uint32_t flags)
+{
+ uint32_t handle;
+ igt_assert_eq(__syncobj_create(fd, &handle, flags), 0);
+ igt_assert(handle);
+ return handle;
+}
+
+static int
+__syncobj_destroy(int fd, uint32_t handle)
+{
+ struct drm_syncobj_destroy destroy = { 0 };
+ int err = 0;
+
+ destroy.handle = handle;
+ if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, &destroy))
+ err = -errno;
+ return err;
+}
+
+void
+syncobj_destroy(int fd, uint32_t handle)
+{
+ igt_assert_eq(__syncobj_destroy(fd, handle), 0);
+}
+
+int
+__syncobj_handle_to_fd(int fd, struct drm_syncobj_handle *args)
+{
+ int err = 0;
+ if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, args))
+ err = -errno;
+ return err;
+}
+
+int
+syncobj_handle_to_fd(int fd, uint32_t handle, uint32_t flags)
+{
+ struct drm_syncobj_handle args = { 0 };
+ args.handle = handle;
+ args.flags = flags;
+ igt_assert_eq(__syncobj_handle_to_fd(fd, &args), 0);
+ igt_assert(args.fd >= 0);
+ return args.fd;
+}
+
+int
+__syncobj_fd_to_handle(int fd, struct drm_syncobj_handle *args)
+{
+ int err = 0;
+ if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, args))
+ err = -errno;
+ return err;
+}
+
+uint32_t
+syncobj_fd_to_handle(int fd, int syncobj_fd, uint32_t flags)
+{
+ struct drm_syncobj_handle args = { 0 };
+ args.fd = syncobj_fd;
+ args.flags = flags;
+ igt_assert_eq(__syncobj_fd_to_handle(fd, &args), 0);
+ igt_assert(args.handle > 0);
+ return args.handle;
+}
+
+void
+syncobj_import_sync_file(int fd, uint32_t handle, int sync_file)
+{
+ struct drm_syncobj_handle args = { 0 };
+ args.handle = handle;
+ args.fd = sync_file;
+ args.flags = DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE;
+ igt_assert_eq(__syncobj_fd_to_handle(fd, &args), 0);
+}
+
+int
+__syncobj_wait(int fd, struct local_syncobj_wait *args)
+{
+ int err = 0;
+ if (drmIoctl(fd, LOCAL_IOCTL_SYNCOBJ_WAIT, args))
+ err = -errno;
+ return err;
+}
+
+int
+syncobj_wait_err(int fd, uint32_t *handles, uint32_t count,
+uint64_t abs_timeout_nsec, uint32_t flags)
+{
+ struct local_syncobj_wait wait;
+
+ wait.handles = to_user_pointer(handles);
+ wait.timeout_nsec = abs_timeout_nsec;
+ wait.count_handles = count;
+ wait.flags = flags;
+ wait.first_signaled = 0;
+ wait.pad = 0;
+
+ return __syncobj_w
[Intel-gfx] ✓ Fi.CI.BAT: success for lib/kmod: Fix error reporting for kmod load/unload
== Series Details == Series: lib/kmod: Fix error reporting for kmod load/unload URL : https://patchwork.freedesktop.org/series/29368/ State : success == Summary == IGT patchset tested on top of latest successful build 29d488034a50cd6fbad792cae61321995f0ab51c aubdump: Log some information about the execbuf calls with latest DRM-Tip kernel build CI_DRM_3006 4823f19b979c drm-tip: 2017y-08m-25d-15h-55m-05s UTC integration manifest Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_frontbuffer_tracking: Subgroup basic: dmesg-warn -> PASS (fi-bdw-5557u) fdo#102410 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#102410 https://bugs.freedesktop.org/show_bug.cgi?id=102410 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:455s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:439s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:362s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:554s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:252s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:524s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:527s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:517s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:438s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:617s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:449s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:426s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:424s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:506s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:479s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:478s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:600s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:602s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:528s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:474s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:484s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:488s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:444s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:486s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:551s fi-snb-2600 total:279 pass:248 dwarn:0 dfail:0 fail:2 skip:29 time:407s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_102/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for tests: chamelium: Eliminate reset when preparing output
== Series Details == Series: tests: chamelium: Eliminate reset when preparing output URL : https://patchwork.freedesktop.org/series/29346/ State : success == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 Test vgem_basic: Subgroup unload: skip -> PASS (shard-hsw) fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2230 pass:1232 dwarn:0 dfail:0 fail:17 skip:981 time:9643s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_100/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s (rev2)
== Series Details == Series: tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s (rev2) URL : https://patchwork.freedesktop.org/series/26479/ State : success == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2230 pass:1230 dwarn:0 dfail:0 fail:18 skip:982 time:9668s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_99/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for lib: Avoid actually throttling from igt_require_gem() (rev2)
Quoting Daniel Vetter (2017-08-25 18:11:56) > On Thu, Aug 24, 2017 at 01:22:40PM -, Patchwork wrote: > > == Series Details == > > > > Series: lib: Avoid actually throttling from igt_require_gem() (rev2) > > URL : https://patchwork.freedesktop.org/series/28983/ > > State : failure > > 2 r-b tags and no comment on why it failed CI? It failed CI? CI failed it and gave no reason. It looks like the network gave up in the middle of a transfer. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] lib/kmod: Fix error reporting for kmod load/unload
A "return -err ? err < 0 : err" managed to slip through. So if err was set, we returned 0 or 1 based on sign, or 0 if err was zero. If err is negative, we want treat it as an error, so report it back to the caller, all other values were a success, so convert those to 0. This should actually be no functional change, as all errors were reported as 1, and everything else as 0. Signed-off-by: Chris Wilson --- lib/igt_kmod.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c index b366adeb..26691e30 100644 --- a/lib/igt_kmod.c +++ b/lib/igt_kmod.c @@ -155,7 +155,7 @@ igt_kmod_load(const char *mod_name, const char *opts) } out: kmod_module_unref(kmod); - return -err ? err < 0 : err; + return err < 0 ? err : 0; } @@ -192,7 +192,7 @@ igt_kmod_unload(const char *mod_name, unsigned int flags) out: kmod_module_unref(kmod); - return -err ? err < 0 : err; + return err < 0 ? err : 0; } /** -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Mark wait_for_engine() as maybe_unused
== Series Details == Series: drm/i915: Mark wait_for_engine() as maybe_unused URL : https://patchwork.freedesktop.org/series/29365/ State : success == Summary == Series 29365v1 drm/i915: Mark wait_for_engine() as maybe_unused https://patchwork.freedesktop.org/api/1.0/series/29365/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-x1585l) fdo#101781 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:267 dwarn:1 dfail:0 fail:0 skip:11 time:458s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:442s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:360s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:553s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:253s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:518s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:518s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:513s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:435s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:616s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:444s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:423s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:423s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:497s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:474s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:472s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:598s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:594s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:523s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:470s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:482s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:489s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:444s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:506s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:549s fi-snb-2600 total:279 pass:248 dwarn:0 dfail:0 fail:2 skip:29 time:407s 4823f19b979cd7b6a27a9d6861fa3e98c1e1fea2 drm-tip: 2017y-08m-25d-15h-55m-05s UTC integration manifest 513a406f75e5 drm/i915: Mark wait_for_engine() as maybe_unused == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5497/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Quietly cancel FBC activation if CRTC is turned off before worker
On Fri, Aug 25, 2017 at 04:02:15PM +0100, Chris Wilson wrote:
> Since we use a worker to enable FBC on the CRTC, it is possible for the
> CRTC to be switched off before we run. In this case, the CRTC will not
> allow us to wait upon a vblank, so remove the DRM_ERROR as this is very
> much expected.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102410
> Fixes: ca18d51d77eb ("drm/i915/fbc: wait for a vblank instead of 50ms when
> enabling")
> Signed-off-by: Chris Wilson
> Cc: Paulo Zanoni
> Cc: Rodrigo Vivi
full igt results haven't come in yet, but under the assumption you get a
pass on that (the hsw box runs all fbc tests, hoooray!):
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index e535615b6188..dbff5854296f 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -406,9 +406,7 @@ static void intel_fbc_work_fn(struct work_struct *__work)
> struct drm_vblank_crtc *vblank = &dev_priv->drm.vblank[crtc->pipe];
>
> if (drm_crtc_vblank_get(&crtc->base)) {
> - DRM_ERROR("vblank not available for FBC on pipe %c\n",
> - pipe_name(crtc->pipe));
> -
> + /* CRTC is now off, leave FBC deactivated */
> mutex_lock(&fbc->lock);
> work->scheduled = false;
> mutex_unlock(&fbc->lock);
> --
> 2.14.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for Fixing make install
On Fri, Aug 25, 2017 at 02:08:33PM -, Patchwork wrote: > == Series Details == > > Series: Fixing make install > URL : https://patchwork.freedesktop.org/series/29338/ > State : warning > > == Summary == > > Test vgem_basic: > Subgroup unload: > pass -> SKIP (shard-hsw) Also happens on snb, kbl&apl, so looks very real. Please investigate before pushing. -Daniel > > shard-hswtotal:2230 pass:1230 dwarn:0 dfail:0 fail:18 skip:982 > time:9623s > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_98/shards.html > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] drm/i915: Fix up the CCS code
On Thu, Aug 24, 2017 at 10:10:48PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Looks like we ended up with a stale version of my CCS code in dinq. > This series contains the remainder in smaller chunks. I also ended > up adding a bunch of extra cleanup etc. on top. > > The most important thing we need to get in is the change > to the fb->offsets[] interpretation since that's ABI territory. > The hash mode apparently doesn't require the nasty virtual address > alignment tricks so that shouldn't have any ABI issues after all. > > Entire series available here: > git://github.com/vsyrjala/linux.git ccs_fixes > > Cc: Ben Widawsky > Cc: Jason Ekstrand > Cc: Daniel Stone Which of these do we need to cherry-pick over to -next-fixes? There's no annotations about that. If the answer is "most" I'm leaning towards disabling CCS for 4.14, minimal set would be ideal (and first in the patch series). Thanks, Daniel > > Ville Syrjälä (12): > drm/i915: Treat fb->offsets[] as a raw byte offset instead of a linear > offset > drm/i915: Skip fence alignemnt check for the CCS plane > drm/i915: Switch over to the LLC/eLLC hotspot avoidance hash mode for > CCS > drm/i915: Add a comment exlaining CCS hsub/vsub > drm/i915: Nuke a pointless unreachable() > drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites > drm/i915: Clean up the sprite modifier checks > drm/i915: Add CCS capability for sprites > drm/i915: Allow up to 32KB stride on SKL+ "sprites" > drm: Fix modifiers_property kernel doc > drm: Check that the plane supports the request format+modifier combo > drm/i915: Remove the pipe/plane ID checks from > skl_check_ccs_aux_surface() > > drivers/gpu/drm/drm_atomic.c | 8 +- > drivers/gpu/drm/drm_crtc.c | 8 +- > drivers/gpu/drm/drm_crtc_internal.h| 4 +- > drivers/gpu/drm/drm_plane.c| 31 +-- > drivers/gpu/drm/i915/i915_reg.h| 8 +- > drivers/gpu/drm/i915/intel_display.c | 145 > + > drivers/gpu/drm/i915/intel_drv.h | 2 + > drivers/gpu/drm/i915/intel_engine_cs.c | 13 +++ > drivers/gpu/drm/i915/intel_pm.c| 27 +++--- > drivers/gpu/drm/i915/intel_sprite.c| 102 +++ > include/drm/drm_mode_config.h | 2 +- > 11 files changed, 217 insertions(+), 133 deletions(-) > > -- > 2.13.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for lib: Avoid actually throttling from igt_require_gem() (rev2)
On Thu, Aug 24, 2017 at 01:22:40PM -, Patchwork wrote: > == Series Details == > > Series: lib: Avoid actually throttling from igt_require_gem() (rev2) > URL : https://patchwork.freedesktop.org/series/28983/ > State : failure 2 r-b tags and no comment on why it failed CI? Smells like review not entirely done ... tsk. Most likely this is the dp-mst hang right when there wasn't a cibuglog entry. Chris, can you pls resend so we can get a full igt run on this too? Thanks, Daniel > > == Summary == > > IGT patchset tested on top of latest successful build > 80cc54023e198165eca34450e9cc75c9cffcb072 lib/core: Use igt_info instead of > printf > > with latest DRM-Tip kernel build CI_DRM_2998 > 3adc9e3cacef drm-tip: 2017y-08m-23d-21h-35m-35s UTC integration manifest > > Test kms_cursor_legacy: > Subgroup basic-busy-flip-before-cursor-atomic: > pass -> FAIL (fi-snb-2600) fdo#100215 > Test kms_flip: > Subgroup basic-flip-vs-modeset: > skip -> PASS (fi-skl-x1585l) fdo#101781 > pass -> INCOMPLETE (fi-kbl-7560u) > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-b: > pass -> DMESG-WARN (fi-byt-n2820) fdo#101705 > Subgroup suspend-read-crc-pipe-c: > fail -> PASS (fi-skl-6700k) fdo#100367 > > fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 > fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 > fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 > fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367 > > fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 > time:450s > fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 > time:448s > fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 > time:366s > fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 > time:560s > fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 > time:254s > fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:530s > fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 > time:530s > fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 > time:516s > fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 > time:435s > fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:613s > fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > time:449s > fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > time:424s > fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 > time:427s > fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:510s > fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:475s > fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:479s > fi-kbl-7560u total:209 pass:205 dwarn:0 dfail:0 fail:0 skip:3 > fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:602s > fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 > time:524s > fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:474s > fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:479s > fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:494s > fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 > time:443s > fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:509s > fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 > time:405s > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_94/ > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Mark wait_for_engine() as maybe_unused
The only call of wait_for_engine() is wrapped in a GEM_WARN_ON macro,
which confusingly suppresses the call unless CONFIG_DRM_I915_DEBUG_GEM
is set.
According to http://www.spinics.net/lists/intel-gfx/msg128768.html the
current behavior is correct, even though it's not obvious. Different
solutions to improve GEM_WARN_ON were discussed, but no conclusion
was reached.
Mark wait_for_engine() as maybe_unused to avoid a compiler warning,
according to the above discussion this is still needed evein if
GEM_WARN_ON is eventually refactored.
Reported-by: Nick Desaulniers
Signed-off-by: Matthias Kaehlcke
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 969bac8404f1..52d0b7d0082b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3364,7 +3364,8 @@ static int wait_for_timeline(struct i915_gem_timeline
*tl, unsigned int flags)
return 0;
}
-static int wait_for_engine(struct intel_engine_cs *engine, int timeout_ms)
+static __maybe_unused int wait_for_engine(
+ struct intel_engine_cs *engine, int timeout_ms)
{
return wait_for(intel_engine_is_idle(engine), timeout_ms);
}
--
2.14.1.342.g6490525c54-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Add GuC Load time to debugfs
>-Original Message-
>From: Mateo Lozano, Oscar
>Sent: Friday, August 25, 2017 8:18 AM
>To: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Cc: Wajdeczko, Michal ; Sundaresan, Sujaritha
>
>Subject: Re: [PATCH] drm/i915/guc: Add GuC Load time to debugfs
>
>Cc: Sujaritha
>
Thanks Oscar for adding Sujaritha.
Do you think the approach here is accurate?
Anusha
>On 08/24/2017 09:38 PM, Anusha Srivatsa wrote:
>> Calculate the time that GuC takes to load.
>> This information could be very useful in determining if GuC is taking
>> unreasonably long time to load in a certain platforms.
>>
>> Cc: Oscar Mateo
>> Cc: Michal Wajdeczko
>> Signed-off-by: Anusha Srivatsa
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.c | 4
>> drivers/gpu/drm/i915/intel_guc_loader.c | 4
>> drivers/gpu/drm/i915/intel_uc.h | 3 +++
>> 3 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index 48572b157222..9283fc714705 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -2379,6 +2379,10 @@ static int i915_guc_load_status_info(struct seq_file
>*m, void *data)
>> guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
>> seq_printf(m, "\tversion found: %d.%d\n",
>> guc_fw->major_ver_found, guc_fw->minor_ver_found);
>> +seq_printf(m, "\tLoad time is %lu ms\n",
>> + jiffies_to_msecs(dev_priv->guc.guc_finish_load -
>> + dev_priv->guc.guc_start_load));
>> +
>> seq_printf(m, "\theader: offset is %d; size = %d\n",
>> guc_fw->header_offset, guc_fw->header_size);
>> seq_printf(m, "\tuCode: offset is %d; size = %d\n", diff --git
>> a/drivers/gpu/drm/i915/intel_guc_loader.c
>> b/drivers/gpu/drm/i915/intel_guc_loader.c
>> index 8b0ae7fce7f2..1c5059b930f9 100644
>> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
>> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
>> @@ -194,6 +194,7 @@ static inline bool guc_ucode_response(struct
>drm_i915_private *dev_priv,
>> static int guc_ucode_xfer_dma(struct drm_i915_private *dev_priv,
>>struct i915_vma *vma)
>> {
>> +struct intel_guc *guc = &dev_priv->guc;
>> struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
>> unsigned long offset;
>> struct sg_table *sg = vma->pages;
>> @@ -226,6 +227,7 @@ static int guc_ucode_xfer_dma(struct
>> drm_i915_private *dev_priv,
>>
>> /* Finally start the DMA */
>> I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(UOS_MOVE |
>START_DMA));
>> +guc->guc_start_load = jiffies;
>>
>> /*
>> * Wait for the DMA to complete & the GuC to start up.
>> @@ -240,6 +242,8 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
>*dev_priv,
>> DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",
>> I915_READ(DMA_CTRL), status);
>>
>> +guc->guc_finish_load = jiffies;
>> +
>> if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
>> DRM_ERROR("GuC firmware signature verification failed\n");
>> ret = -ENOEXEC;
>> diff --git a/drivers/gpu/drm/i915/intel_uc.h
>> b/drivers/gpu/drm/i915/intel_uc.h index 22ae52b17b0f..3d5a15ed1995
>> 100644
>> --- a/drivers/gpu/drm/i915/intel_uc.h
>> +++ b/drivers/gpu/drm/i915/intel_uc.h
>> @@ -210,6 +210,9 @@ struct intel_guc {
>>
>> /* GuC's FW specific notify function */
>> void (*notify)(struct intel_guc *guc);
>> +
>> +unsigned long guc_start_load;
>> +unsigned long guc_finish_load;
>> };
>>
>> struct intel_huc {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaForceEnableNonCoherent
On 08/25/2017 12:41 AM, Michał Winiarski wrote: On Thu, Aug 24, 2017 at 03:42:05PM -0700, Oscar Mateo wrote: On 08/23/2017 03:02 PM, Rodrigo Vivi wrote: Must Force Non-Coherent whenever executing a 3D context. This is a workaround for a possible hang in the unlikely event a TLB invalidation occurs during a PSD flush. Set masked bit 4 in 0x7300 during boot. This bug should not be present in HW anymore. A different reason to keep doing this is performance, though. Doesn't userspace already has a choice between coherent and non-coherent access. Why would we want to cheat, and force non-coherent when it clearly wants to use coherent one? But does it? I cannot find anything in i915 to allow userspace to flip this chicken bit (the register is not whitelisted and we don't have any execbuf flag/hint). Or am I missing something? (well, because that's what we've been always doing is one reason, the other one may be that "clearly" can sometimes turn out to be "by accident") -Michał Cc: Mika Kuoppala Cc: Oscar Mateo Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_engine_cs.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index a6ac9d0a4156..7dfc78b038c4 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -1071,8 +1071,11 @@ static int cnl_init_workarounds(struct intel_engine_cs *engine) int ret; /* WaForceContextSaveRestoreNonCoherent:cnl */ + /* WaForceEnableNonCoherent:cnl */ WA_SET_BIT_MASKED(CNL_HDC_CHICKEN0, - HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT); + HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT | + HDC_FORCE_NON_COHERENT); + /* WaDisableReplayBufferBankArbitrationOptimization:cnl */ WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2, ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] lib/igt_core: Use HTML character for documentation comment in example
== Series Details == Series: series starting with [1/3] lib/igt_core: Use HTML character for documentation comment in example URL : https://patchwork.freedesktop.org/series/29363/ State : success == Summary == IGT patchset tested on top of latest successful build 29d488034a50cd6fbad792cae61321995f0ab51c aubdump: Log some information about the execbuf calls with latest DRM-Tip kernel build CI_DRM_3005 84896d875643 drm-tip: 2017y-08m-25d-14h-00m-21s UTC integration manifest Test gem_ringfill: Subgroup basic-default: pass -> SKIP (fi-bsw-n3050) fdo#101915 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-x1585l) fdo#101781 Test kms_frontbuffer_tracking: Subgroup basic: pass -> DMESG-WARN (fi-bdw-5557u) fdo#102410 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-n2820) fdo#101705 fdo#101915 https://bugs.freedesktop.org/show_bug.cgi?id=101915 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#102410 https://bugs.freedesktop.org/show_bug.cgi?id=102410 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:267 dwarn:1 dfail:0 fail:0 skip:11 time:461s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:438s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:372s fi-bsw-n3050 total:279 pass:242 dwarn:0 dfail:0 fail:0 skip:37 time:547s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:250s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:525s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:525s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:522s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:436s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:614s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:447s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:428s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:431s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:507s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:474s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:601s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:597s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:522s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:474s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:491s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:450s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:508s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:550s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:410s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_101/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Nuke a pointless unreachable()
On 25 August 2017 at 05:40, Ben Widawsky wrote: > This was specifically requested by Emil. > Not quite, a gist is below. Regardless, I do not want inspire lengthy discussions over a trivial suggestion. Please proceed as you gents prefer. Thanks Emil a)Original code if X return A; else if Y return B; else return C; return false; b)My suggestion if X return A; if Y return B; return C; c)Ben's counter suggestion if X return A; else if Y return B; else return C; unreachable(); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Quietly cancel FBC activation if CRTC is turned off before worker
== Series Details == Series: drm/i915: Quietly cancel FBC activation if CRTC is turned off before worker URL : https://patchwork.freedesktop.org/series/29362/ State : success == Summary == Series 29362v1 drm/i915: Quietly cancel FBC activation if CRTC is turned off before worker https://patchwork.freedesktop.org/api/1.0/series/29362/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: fail -> PASS (fi-snb-2600) fdo#100215 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:459s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:440s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:360s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:549s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:252s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:519s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:516s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:514s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:436s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:613s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:446s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:423s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:423s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:497s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:598s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:595s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:522s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:465s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:478s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:491s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:444s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:484s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:547s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:408s 84896d875643281c82beba90c3ce632b5b328c52 drm-tip: 2017y-08m-25d-14h-00m-21s UTC integration manifest e692bd24024d drm/i915: Quietly cancel FBC activation if CRTC is turned off before worker == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5496/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/3] lib/igt_core: Use HTML character for documentation comment in example
The gtkdoc output for the example configuration given in the file confuses gtkdoc because of the use of # for comments, that is interpreted as a headline (although it is an example block). This uses the HTML character instead to ensure the rendering is correct. Signed-off-by: Paul Kocialkowski --- lib/igt_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/igt_core.c b/lib/igt_core.c index 58d64dc2..c8753a6f 100644 --- a/lib/igt_core.c +++ b/lib/igt_core.c @@ -235,12 +235,12 @@ * An example configuration follows: * * |[ - * # The common configuration secton follows. + * # The common configuration secton follows. * [Common] * FrameDumpPath=/tmp # The path to dump frames that fail comparison checks * - * # The following section is used for configuring the Device Under Test. - * # It is not mandatory and allows overriding default values. + * # The following section is used for configuring the Device Under Test. + * # It is not mandatory and allows overriding default values. * [DUT] * SuspendResumeDelay=10 * ]| -- 2.14.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/3] docs: Add user and developer documentation about Chamelium support
This introduces plain-text documentation about the Chamelium aimed at users who wish to deploy the platform, as well as developers who wish to work on improving IGT support for it. Given the contents of this documentation, it felt more relevant to make it part of the tree instead of the API reference. Signed-off-by: Paul Kocialkowski --- docs/chamelium.txt | 146 + 1 file changed, 146 insertions(+) create mode 100644 docs/chamelium.txt diff --git a/docs/chamelium.txt b/docs/chamelium.txt new file mode 100644 index ..8d02ba44 --- /dev/null +++ b/docs/chamelium.txt @@ -0,0 +1,146 @@ +Chamelium Support in IGT + + +This document provides information, instructions and a tasks list for Chamelium +support in IGT. + +Introduction + + +The Chamelium is a platform that acts as a display monitor emulator. It provides +advanced access and control over the various signals a display receives. + +As such, it allows testing display features that can otherwise not be tested in +IGT without external hardware. + +The platform was developed by Google in order to test display and audio-related +features of ChromeOS devices. It was initially developed internally by Google as +part of the ChromeOS effort under the name Chameleon and was later made external +as part of the ChromiumOS effort, under the name Chamelium. + +It consists of a custom-made display emulator board connected to an Arrow SoCKit +via a flexible cable, with two DisplayPort connectors, one HDMI and one VGA. + +The SoCKit uses a Cyclone V SoC, with both a FPGA and an ARM CPU. While the FPGA +is used for logic control, the CPU runs daemons that allow the board to be +controlled over the network via a XMLRPC interface. + +Documentation +- + +Documentation about the Chamelium is made available by Google through the +ChromiumOS projet wiki: https://www.chromium.org/chromium-os/testing/chamelium + +Deploying the Chamelium With IGT + + +Instructions from the ChromiumOS wiki detail how to setup the Chamelium: +https://www.chromium.org/chromium-os/testing/chamelium#TOC-Setting-up-Chamelium + +The should be followed up until the "Setup your Linux host, DUT and the FPGA" +section. At this point, IGT has to be configured to connect to the Chamelium. + +It may be necessary to give the Chamelium a static IP address, depending on +the network setup. This can be configured (via the serial console) by editing +the Debian-styled /etc/network/interfaces configuration file. + +Chamelium support requires setting up dedicated IGT configuration, as explained +in the Core and Chamelium parts of the IGT API Reference in the documentation. + +An sample fully-featured configuration follows: +[Common] +FrameDumpPath=/root/ + +[Chamelium] +URL=http://192.168.72.1:9992 + +[Chamelium:DP-1] +ChameliumPortID=1 + +[Chamelium:HDMI-A-2] +ChameliumPortID=3 + +[Chamelium:VGA-1] +ChameliumPortID=4 + +[DUT] +SuspendResumeDelay=2 + +Debugging the Chamelium +--- + +Logs that may be useful for debugging can be obtained either by connecting to +the board via SSH or serial console and looking at the daemon logs from +/var/log, such as: +$ tail -f /var/log/chameleon* + +Daemon Source, Build and Deploy +--- + +Source code for the daemon running on the Chamelium is available at: +https://chromium.googlesource.com/chromiumos/platform/chameleon/ + +Building the daemon requires a GNU EABI ARMv7 GCC toolchain, that must be +specified via the CC variable, such as: +$ make CC=arm-linux-gnueabihf-gcc + +The result can be deployed to the chamelium with the remote-install target and +specifying the network address for the chamelium via the CHAMELEON_HOST +variable, such as: +$ make remote-install CHAMELEON_HOST=192.168.72.1 + +The process requires the Chamelium to be connected to the Internet to succeed. + +Contributing Changes to the Daemon +-- + +Contributions to the Chamelium daemon, just like any contribution to ChromiumOS, +are submitted and reviewed at: https://chromium-review.googlesource.com/ + +The ChromiumOS project provides an extensive developer guide: +https://www.chromium.org/chromium-os/developer-guide that assumes running within +the ChromiumOS build system. Since this is likely not the case for contributing +to the Chamelium daemon, only the part about uploading changes is relevant: +https://www.chromium.org/chromium-os/developer-guide#TOC-Upload-your-changes-and-get-a-code-review + +Most of the process is about using the Gerrit web interface for submitting and +having the change reviewed and not forgetting the Change-Id, TEST= and BUG= +fields in the commit. + +Current Support in IGT +-- + +Support for the Chamelium platform in IGT is found in the following places: +* lib/igt_chamelium.c: library with Chamelium-related helpers +* tests/chamelium.c: su
[Intel-gfx] [PATCH i-g-t 3/3] docs: Add user documentation about audio support
This introduces plain-text documentation about the audio test, aimed at users who wish to setup and run the audio tests. Given the contents of this documentation, it felt more relevant to make it part of the tree instead of the API reference. Signed-off-by: Paul Kocialkowski --- docs/audio.txt | 45 + 1 file changed, 45 insertions(+) create mode 100644 docs/audio.txt diff --git a/docs/audio.txt b/docs/audio.txt new file mode 100644 index ..158ad5d1 --- /dev/null +++ b/docs/audio.txt @@ -0,0 +1,45 @@ +Audio Support in IGT + + +This document provides information and instructions about audio support in IGT. + +Introduction + + +The audio test is aimed at testing the audio features of display connectors, +such as HDMI. + +Test setup +-- + +The setup required for the audio test consists of using an HDMI-VGA adapter with +an audio-out 3.5 mm jack to extract the audio from the HDMI interface. +The audio-out jack is connected back to the device-under-test's line-in. + +Depending on the behavior of the adapter, it may be necessary to connect a +ghost VGA dongle to it (in order to emulate a connected display) to enable the +audio output. There are guides available detailing how to build these. + +When executed, the test will automatically send the test audio signal to all +ALSA audio HDMI outputs and record from the standard ALSA capture device. + +Configuration +- + +In order to deploy the test, ALSA controls have to be configured to set the +ALSA capture source to line-in. On Intel x86 systems, this can be achieved +with the following calls to the amixer utility: +# amixer sset Line 31 on +# amixer sset "Input Source" Line + +It is then useful to store the ALSA state permanently with the alsactl utility: +# alsactl store + +These settings can be restored with the alsactl utility: +# alsactl restore + +It is desirable to ensure that the alsa-restore and alsa-state systemd services +are enabled to do this job automatically, especially in the case of an +automated testing system: +# systemctl enable alsa-restore +# systemctl enable alsa-state -- 2.14.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Add GuC Load time to debugfs
Cc: Sujaritha
On 08/24/2017 09:38 PM, Anusha Srivatsa wrote:
Calculate the time that GuC takes to load.
This information could be very useful in
determining if GuC is taking unreasonably long time
to load in a certain platforms.
Cc: Oscar Mateo
Cc: Michal Wajdeczko
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
drivers/gpu/drm/i915/intel_guc_loader.c | 4
drivers/gpu/drm/i915/intel_uc.h | 3 +++
3 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 48572b157222..9283fc714705 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2379,6 +2379,10 @@ static int i915_guc_load_status_info(struct seq_file *m,
void *data)
guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
seq_printf(m, "\tversion found: %d.%d\n",
guc_fw->major_ver_found, guc_fw->minor_ver_found);
+ seq_printf(m, "\tLoad time is %lu ms\n",
+ jiffies_to_msecs(dev_priv->guc.guc_finish_load -
+ dev_priv->guc.guc_start_load));
+
seq_printf(m, "\theader: offset is %d; size = %d\n",
guc_fw->header_offset, guc_fw->header_size);
seq_printf(m, "\tuCode: offset is %d; size = %d\n",
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 8b0ae7fce7f2..1c5059b930f9 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -194,6 +194,7 @@ static inline bool guc_ucode_response(struct
drm_i915_private *dev_priv,
static int guc_ucode_xfer_dma(struct drm_i915_private *dev_priv,
struct i915_vma *vma)
{
+ struct intel_guc *guc = &dev_priv->guc;
struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
unsigned long offset;
struct sg_table *sg = vma->pages;
@@ -226,6 +227,7 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
*dev_priv,
/* Finally start the DMA */
I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(UOS_MOVE | START_DMA));
+ guc->guc_start_load = jiffies;
/*
* Wait for the DMA to complete & the GuC to start up.
@@ -240,6 +242,8 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
*dev_priv,
DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",
I915_READ(DMA_CTRL), status);
+ guc->guc_finish_load = jiffies;
+
if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
DRM_ERROR("GuC firmware signature verification failed\n");
ret = -ENOEXEC;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 22ae52b17b0f..3d5a15ed1995 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -210,6 +210,9 @@ struct intel_guc {
/* GuC's FW specific notify function */
void (*notify)(struct intel_guc *guc);
+
+ unsigned long guc_start_load;
+ unsigned long guc_finish_load;
};
struct intel_huc {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Deal with upside-down mounted LCD panels (rev2)
== Series Details == Series: drm/i915: Deal with upside-down mounted LCD panels (rev2) URL : https://patchwork.freedesktop.org/series/29161/ State : success == Summary == Series 29161v2 drm/i915: Deal with upside-down mounted LCD panels https://patchwork.freedesktop.org/api/1.0/series/29161/revisions/2/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: fail -> PASS (fi-snb-2600) fdo#100215 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:454s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:364s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:543s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:258s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:521s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:520s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:512s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:430s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:609s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:441s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:422s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:423s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:509s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:483s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:595s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:602s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:521s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:465s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:483s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:486s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:444s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:481s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:546s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:407s fi-bdw-gvtdvm failed to connect after reboot 84896d875643281c82beba90c3ce632b5b328c52 drm-tip: 2017y-08m-25d-14h-00m-21s UTC integration manifest c5fe897477a7 drm/i915: Deal with upside-down mounted LCD panels == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5495/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915, drm/fourcc: Improve the CCS modifier documentation
On Fri, Aug 18, 2017 at 11:34:40AM -0700, Jason Ekstrand wrote:
> This updates the documentation on the intel CCS modifiers for a couple
> of reasons:
>
> 1) The old documentation required that the CCS modifier only be used
> with formats. While i915 currently only supports CCS scanout
> with formats (and advertises such through the blob format), CCS
> can be used with many other formats. Mesa, in particular, can
> handle CCS on the full range of formats supported by the hardware.
> For image sharing entirely within userspace, we don't want this
> restriction.
>
> 2) The old documentation specified the scaling factor in terms of
> pixels which breaks down when you start using formats which are not
> 32-bit. By specifying it in terms of cache lines and tiles, we can
> properly specify the scale-down relationship with no format size
> assumptions.
>
> 3) The new comment provides more detail about the "real" layout of CCS
> on Sky Lake and also points out that the reason why Y tiling is
> important is because it affects row pitch calculations.
>
> 4) We shouldn't be documenting the Yf CCS modifier yet. Userspace is
> incapable of generating it right now and we don't fully know how it
> works yet. Trying to fully describe it is premature.
>
> Signed-off-by: Jason Ekstrand
> Cc: Ben Widawsky
> Cc: Ville Syrjälä
> ---
> include/uapi/drm/drm_fourcc.h | 35 ++-
> 1 file changed, 22 insertions(+), 13 deletions(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3ad838d..9670da4 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -266,21 +266,30 @@ extern "C" {
> /*
> * Intel color control surface (CCS) for render compression
> *
> - * The framebuffer format must be one of the 8:8:8:8 RGB formats.
> - * The main surface will be plane index 0 and must be Y/Yf-tiled,
> - * the CCS will be plane index 1.
> - *
> - * Each CCS tile matches a 1024x512 pixel area of the main surface.
> - * To match certain aspects of the 3D hardware the CCS is
> - * considered to be made up of normal 128Bx32 Y tiles, Thus
> - * the CCS pitch must be specified in multiples of 128 bytes.
> - *
> - * In reality the CCS tile appears to be a 64Bx64 Y tile, composed
> - * of QWORD (8 bytes) chunks instead of OWORD (16 bytes) chunks.
> - * But that fact is not relevant unless the memory is accessed
> - * directly.
> + * The image format must be compatible with CCS_E (lossless render
> + * compression) as specified in the PRM for the relevant hardware.
> + * The main surface will be plane index 0 and must be Y-tiled,
> + * the CCS will be plane index 1 and is also Y-tiled.
> + *
> + * Each 64B cache line in the CCS (a region of 16B x 4 rows when
> + * Y-tiled) corresponds to a region of 32x16 cache lines in the main
> + * surface. (As a corollary, each CCS tile corresponds to an area of
> + * 32x16 tiles in the main surface.) This relationship holds regardless
> + * of the size of the number of bits per pixel of the image format.
> + *
> + * In reality, the cache lines in the CCS tile are proportioned in an
> + * 8B x 8 row configuration with each byte being 2x2 2-bit CCS entries.
> + * However, CCS is documented as Y-tiled with the scaling relationship
> + * described in terms of cache lines as above so we consider it to be
> + * Y-tiled for the purpose of specifying this modifier. This means that
> + * the row pitch for the CCS assumes 128B/tile.
> */
> #define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
> +
> +/* Reserved for the Yf version of the TILED_CCS modifier.
> + *
> + * Exact definition TBD.
> + */
IIRC the same explanation can be used for both Y and Yf. The CCS
surface is still using the wonky Y tile layout even if the main
surface is Yf.
> #define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
>
> /*
> --
> 2.5.0.400.gff86faf
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Quietly cancel FBC activation if CRTC is turned off before worker
Since we use a worker to enable FBC on the CRTC, it is possible for the
CRTC to be switched off before we run. In this case, the CRTC will not
allow us to wait upon a vblank, so remove the DRM_ERROR as this is very
much expected.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102410
Fixes: ca18d51d77eb ("drm/i915/fbc: wait for a vblank instead of 50ms when
enabling")
Signed-off-by: Chris Wilson
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_fbc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index e535615b6188..dbff5854296f 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -406,9 +406,7 @@ static void intel_fbc_work_fn(struct work_struct *__work)
struct drm_vblank_crtc *vblank = &dev_priv->drm.vblank[crtc->pipe];
if (drm_crtc_vblank_get(&crtc->base)) {
- DRM_ERROR("vblank not available for FBC on pipe %c\n",
- pipe_name(crtc->pipe));
-
+ /* CRTC is now off, leave FBC deactivated */
mutex_lock(&fbc->lock);
work->scheduled = false;
mutex_unlock(&fbc->lock);
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Deal with upside-down mounted LCD panels
On some (Bay Trail) devices the LCD panel is mounted upside-down.
This commit uses the code to read back the initial rotation of the
primary plane in get_initial_plane_config from Ville Syrjala's
"drm/fb-helper: Inherit rotation wip" patch and when re-using the
initial fb it stores that in intel_crtc.initial_rotation.
It adds an intel_plane_get_rotation helper which combines this
initial_rotation with any rotation requested by userspace and
uses this in all places which look at a planes rotation, thus
transparently dealing with upside-down LCD panels without requiring
any user-space or fbcon changes.
This fixes the kernel boot messages switching from being shown the right
way up in efifb to being shown upside down as soon as a native kms driver
loads, as well as any graphics displayed by userspace being upside-down.
Note this only deals with upside-down LCD panels / 180 degrees
rotation as the hardware in question only supports 180 degrees
rotation in hardware. The one model known which has a panel mounted
with 90/270 degrees rotation will need to be fully dealt with in
userspace, even the firmware boot screen / menus are rotated 90 degrees
on this one and there simply is nothing the kernel can do about this.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=94894
Cc: Ville Syrjala
Signed-off-by: Hans de Goede
---
Changes in v2:
-Fix brown paperbag bug s/val & mask/val & ~mask/ to clear old rotation bits
Changes in v3:
-Rebase on current (2017 aug. 22) drm-intel-next-queued
Changes in v4:
-Fix compiler warning from unhandled case in intel_fixup_initial_subpixel_order
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 7 ++-
drivers/gpu/drm/i915/intel_display.c | 93 +--
drivers/gpu/drm/i915/intel_drv.h | 32 +++
drivers/gpu/drm/i915/intel_fbc.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 6 +-
drivers/gpu/drm/i915/intel_sprite.c | 14 ++---
6 files changed, 123 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index ee76fab7bb6f..824aaba5112b 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -116,6 +116,7 @@ int intel_plane_atomic_check_with_state(struct
intel_crtc_state *crtc_state,
struct intel_plane *intel_plane = to_intel_plane(plane);
const struct drm_display_mode *adjusted_mode =
&crtc_state->base.adjusted_mode;
+ unsigned int rotation = intel_plane_get_rotation(state);
int ret;
/*
@@ -135,7 +136,7 @@ int intel_plane_atomic_check_with_state(struct
intel_crtc_state *crtc_state,
intel_state->clip.y2 =
crtc_state->base.enable ? crtc_state->pipe_src_h : 0;
- if (state->fb && drm_rotation_90_or_270(state->rotation)) {
+ if (state->fb && drm_rotation_90_or_270(rotation)) {
struct drm_format_name_buf format_name;
if (state->fb->modifier != I915_FORMAT_MOD_Y_TILED &&
@@ -164,8 +165,8 @@ int intel_plane_atomic_check_with_state(struct
intel_crtc_state *crtc_state,
/* CHV ignores the mirror bit when the rotate bit is set :( */
if (IS_CHERRYVIEW(dev_priv) &&
- state->rotation & DRM_MODE_ROTATE_180 &&
- state->rotation & DRM_MODE_REFLECT_X) {
+ rotation & DRM_MODE_ROTATE_180 &&
+ rotation & DRM_MODE_REFLECT_X) {
DRM_DEBUG_KMS("Cannot rotate and reflect at the same time\n");
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eda1aa0c343c..a5fe9f9f1bf0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2277,7 +2277,7 @@ void intel_add_fb_offsets(int *x, int *y,
{
const struct intel_framebuffer *intel_fb =
to_intel_framebuffer(state->base.fb);
- unsigned int rotation = state->base.rotation;
+ unsigned int rotation = intel_plane_get_rotation(&state->base);
if (drm_rotation_90_or_270(rotation)) {
*x += intel_fb->rotated[plane].x;
@@ -2330,7 +2330,7 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
const struct drm_i915_private *dev_priv =
to_i915(state->base.plane->dev);
const struct drm_framebuffer *fb = state->base.fb;
unsigned int cpp = fb->format->cpp[plane];
- unsigned int rotation = state->base.rotation;
+ unsigned int rotation = intel_plane_get_rotation(&state->base);
unsigned int pitch = intel_fb_pitch(fb, plane, rotation);
WARN_ON(new_offset > old_offset);
@@ -2434,7 +2434,7 @@ u32 intel_compute_tile_offset(int *x, int *y,
struct intel_plane *intel_plane = to_intel_plane(state->base.plane);
struct drm_i915_private *dev_priv = to_i915(intel_plane->base.dev);
const struct drm_framebuffer *fb = state->base.fb;
- unsigned i
[Intel-gfx] [PATCH v4 0/1] drm/i915: Deal with upside-down mounted LCD panels
Hi All, When I last send this patch not everyone was enthusiastic about this patch. As already mentioned in the v2 discussion, solving this in userspace is not really feasible since there is no single place to fix it there, it will need fixing in at least 6 different places from the top of my head (basically any app/server/"driver" talking directly to kms needs fixing) Also fixing it in userspace will be quite complicated even in a single consumer of the kms API. It has been 3 months since my last version and no other solution has materialized, so I would like to move forward with this patch. The only technical objection against my previous version was that it did not fix the subpixel order reported to userspace, that has been fixed in this version and it has been rebased on top of the latest drm-intel-next-queued. New in v4: Fix compiler warning introduced in v3. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bios: additional vbt definition cleanups
== Series Details == Series: drm/i915/bios: additional vbt definition cleanups URL : https://patchwork.freedesktop.org/series/29357/ State : success == Summary == Series 29357v1 drm/i915/bios: additional vbt definition cleanups https://patchwork.freedesktop.org/api/1.0/series/29357/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: pass -> FAIL (fi-snb-2600) fdo#100215 +1 Test kms_frontbuffer_tracking: Subgroup basic: pass -> DMESG-WARN (fi-bdw-5557u) fdo#102410 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#102410 https://bugs.freedesktop.org/show_bug.cgi?id=102410 fi-bdw-5557u total:279 pass:267 dwarn:1 dfail:0 fail:0 skip:11 time:454s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:452s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:360s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:543s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:252s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:517s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:527s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:517s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:436s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:605s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:447s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:426s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:428s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:510s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:479s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:594s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:594s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:521s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:462s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:491s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:439s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:491s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:550s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:411s 84896d875643281c82beba90c3ce632b5b328c52 drm-tip: 2017y-08m-25d-14h-00m-21s UTC integration manifest 7a34b086c012 drm/i915/bios: amend edp block based on intel_vbt_decode d5d24f1959b5 drm/i915/bios: amend child device flags based on intel_vbt_decode dc5a715cd957 drm/i915/bios: amend bdb_general_features 275cb431c2cc drm/i915/bios: split up iboost to hdmi and dp bitfields == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5494/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/bios: amend child device flags based on intel_vbt_decode
On Fri, Aug 25, 2017 at 05:11:22PM +0300, Jani Nikula wrote:
> Copy over some fields defined in the intel_vbt_decode tool. No
> functional changes.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_vbt_defs.h | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index 14623748b388..ea508ecc74b3 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -380,7 +380,11 @@ struct child_device_config {
> } __packed;
> } __packed;
>
> - u8 capabilities;
> + u8 pipe_cap:2;
> + u8 sdvo_stall:1;
igt has a /* 158 */ comment here.
Otherwise it all looks to match. For the series
Reviewed-by: Ville Syrjälä
> + u8 hpd_status:2;
> + u8 integrated_encoder:1;
> + u8 capabilities_reserved:2;
> u8 dvo_wiring; /* See DEVICE_WIRE_* above */
>
> union {
> @@ -390,7 +394,8 @@ struct child_device_config {
>
> u16 extended_type;
> u8 dvo_function;
> - u8 flags2; /* 195 */
> + u8 dp_usb_type_c:1; /* 195 */
> + u8 flags2_reserved:7; /* 195 */
> u8 dp_gpio_index; /* 195 */
> u16 dp_gpio_pin_num;/* 195 */
> u8 dp_iboost_level:4; /* 196 */
> --
> 2.11.0
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] drm/i915/bios: additional vbt definition cleanups
On Fri, 25 Aug 2017, Jani Nikula wrote: > Follow-up to [1]. Oh, and part of the rationale is that I'm migrating intel_vbt_decode to use intel_vbt_defs.h copied over verbatim from the kernel. Going forward, we should not duplicate this stuff. BR, Jani. > > BR, > Jani. > > > [1] cover.1503600621.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1503600621.git.jani.nikula@intel.com > > Jani Nikula (4): > drm/i915/bios: split up iboost to hdmi and dp bitfields > drm/i915/bios: amend bdb_general_features > drm/i915/bios: amend child device flags based on intel_vbt_decode > drm/i915/bios: amend edp block based on intel_vbt_decode > > drivers/gpu/drm/i915/intel_bios.c | 8 +++--- > drivers/gpu/drm/i915/intel_vbt_defs.h | 53 > ++- > 2 files changed, 43 insertions(+), 18 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/bios: amend edp block based on intel_vbt_decode
Copy over some fields defined in the intel_vbt_decode tool. No
functional changes.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 4 ++--
drivers/gpu/drm/i915/intel_vbt_defs.h | 25 -
2 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 92e484e78ea0..5949750a35ee 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -576,7 +576,7 @@ parse_edp(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
{
const struct bdb_edp *edp;
const struct edp_power_seq *edp_pps;
- const struct edp_link_params *edp_link_params;
+ const struct edp_fast_link_params *edp_link_params;
int panel_type = dev_priv->vbt.panel_type;
edp = find_section(bdb, BDB_EDP);
@@ -600,7 +600,7 @@ parse_edp(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
/* Get the eDP sequencing and link info */
edp_pps = &edp->power_seqs[panel_type];
- edp_link_params = &edp->link_params[panel_type];
+ edp_link_params = &edp->fast_link_params[panel_type];
dev_priv->vbt.edp.pps = *edp_pps;
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index ea508ecc74b3..61d590db3675 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -688,23 +688,38 @@ struct bdb_driver_features {
#define EDP_VSWING_1_2V3
-struct edp_link_params {
+struct edp_fast_link_params {
u8 rate:4;
u8 lanes:4;
u8 preemphasis:4;
u8 vswing:4;
} __packed;
+struct edp_pwm_delays {
+ u16 pwm_on_to_backlight_enable;
+ u16 backlight_disable_to_pwm_off;
+} __packed;
+
+struct edp_full_link_params {
+ u8 preemphasis:4;
+ u8 vswing:4;
+} __packed;
+
struct bdb_edp {
struct edp_power_seq power_seqs[16];
u32 color_depth;
- struct edp_link_params link_params[16];
+ struct edp_fast_link_params fast_link_params[16];
u32 sdrrs_msa_timing_delay;
/* ith bit indicates enabled/disabled for (i+1)th panel */
- u16 edp_s3d_feature;
- u16 edp_t3_optimization;
- u64 edp_vswing_preemph; /* v173 */
+ u16 edp_s3d_feature;/* 162 */
+ u16 edp_t3_optimization;/* 165 */
+ u64 edp_vswing_preemph; /* 173 */
+ u16 fast_link_training; /* 182 */
+ u16 dpcd_600h_write_required; /* 185 */
+ struct edp_pwm_delays pwm_delays[16]; /* 186 */
+ u16 full_link_params_provided; /* 199 */
+ struct edp_full_link_params full_link_params[16]; /* 199 */
} __packed;
struct psr_table {
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/bios: amend bdb_general_features
Copy over some fields defined in the intel_vbt_tool. No functional
changes.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_vbt_defs.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index fd1484113811..14623748b388 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -149,16 +149,19 @@ struct bdb_general_features {
u8 ssc_freq:1;
u8 enable_lfp_on_override:1;
u8 disable_ssc_ddt:1;
- u8 rsvd7:1;
+ u8 underscan_vga_timings:1;
u8 display_clock_mode:1;
- u8 rsvd8:1; /* finish byte */
+ u8 vbios_hotplug_support:1;
/* bits 3 */
u8 disable_smooth_vision:1;
u8 single_dvi:1;
- u8 rsvd9:1;
+ u8 rotate_180:1;/* 181 */
u8 fdi_rx_polarity_inverted:1;
- u8 rsvd10:4; /* finish byte */
+ u8 vbios_extended_mode:1; /* 160 */
+ u8 copy_ilfp_dtd_to_sdvo_lvds_dtd:1;/* 160 */
+ u8 panel_best_fit_timing:1; /* 160 */
+ u8 ignore_strap_state:1;/* 160 */
/* bits 4 */
u8 legacy_monitor_detect;
@@ -167,9 +170,10 @@ struct bdb_general_features {
u8 int_crt_support:1;
u8 int_tv_support:1;
u8 int_efp_support:1;
- u8 dp_ssc_enb:1;/* PCH attached eDP supports SSC */
+ u8 dp_ssc_enable:1; /* PCH attached eDP supports SSC */
u8 dp_ssc_freq:1; /* SSC freq for PCH attached eDP */
- u8 rsvd11:3; /* finish byte */
+ u8 dp_ssc_dongle_supported:1;
+ u8 rsvd11:2; /* finish byte */
} __packed;
/* pre-915 */
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/bios: split up iboost to hdmi and dp bitfields
This is according to the style all over the place. No functional
changes.
Cc: Ville Syrjälä
Suggested-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 4 ++--
drivers/gpu/drm/i915/intel_vbt_defs.h | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 991e2ab98749..92e484e78ea0 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1218,10 +1218,10 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
/* Parse the I_boost config for SKL and above */
if (bdb->version >= 196 && child->iboost) {
- info->dp_boost_level = translate_iboost(child->iboost_level &
0xF);
+ info->dp_boost_level = translate_iboost(child->dp_iboost_level);
DRM_DEBUG_KMS("VBT (e)DP boost level for port %c: %d\n",
port_name(port), info->dp_boost_level);
- info->hdmi_boost_level = translate_iboost(child->iboost_level
>> 4);
+ info->hdmi_boost_level =
translate_iboost(child->hdmi_iboost_level);
DRM_DEBUG_KMS("VBT HDMI boost level for port %c: %d\n",
port_name(port), info->hdmi_boost_level);
}
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index f6cb4825c57c..fd1484113811 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -389,7 +389,8 @@ struct child_device_config {
u8 flags2; /* 195 */
u8 dp_gpio_index; /* 195 */
u16 dp_gpio_pin_num;/* 195 */
- u8 iboost_level;
+ u8 dp_iboost_level:4; /* 196 */
+ u8 hdmi_iboost_level:4; /* 196 */
} __packed;
struct bdb_general_definitions {
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/bios: amend child device flags based on intel_vbt_decode
Copy over some fields defined in the intel_vbt_decode tool. No
functional changes.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_vbt_defs.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 14623748b388..ea508ecc74b3 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -380,7 +380,11 @@ struct child_device_config {
} __packed;
} __packed;
- u8 capabilities;
+ u8 pipe_cap:2;
+ u8 sdvo_stall:1;
+ u8 hpd_status:2;
+ u8 integrated_encoder:1;
+ u8 capabilities_reserved:2;
u8 dvo_wiring; /* See DEVICE_WIRE_* above */
union {
@@ -390,7 +394,8 @@ struct child_device_config {
u16 extended_type;
u8 dvo_function;
- u8 flags2; /* 195 */
+ u8 dp_usb_type_c:1; /* 195 */
+ u8 flags2_reserved:7; /* 195 */
u8 dp_gpio_index; /* 195 */
u16 dp_gpio_pin_num;/* 195 */
u8 dp_iboost_level:4; /* 196 */
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] drm/i915/bios: additional vbt definition cleanups
Follow-up to [1]. BR, Jani. [1] cover.1503600621.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1503600621.git.jani.nikula@intel.com Jani Nikula (4): drm/i915/bios: split up iboost to hdmi and dp bitfields drm/i915/bios: amend bdb_general_features drm/i915/bios: amend child device flags based on intel_vbt_decode drm/i915/bios: amend edp block based on intel_vbt_decode drivers/gpu/drm/i915/intel_bios.c | 8 +++--- drivers/gpu/drm/i915/intel_vbt_defs.h | 53 ++- 2 files changed, 43 insertions(+), 18 deletions(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for Fixing make install
== Series Details == Series: Fixing make install URL : https://patchwork.freedesktop.org/series/29338/ State : warning == Summary == Test vgem_basic: Subgroup unload: pass -> SKIP (shard-hsw) shard-hswtotal:2230 pass:1230 dwarn:0 dfail:0 fail:18 skip:982 time:9623s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_98/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/12] drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites
Hi, On 25 August 2017 at 12:34, Ville Syrjälä wrote: > On Fri, Aug 25, 2017 at 10:40:28AM +0100, Daniel Stone wrote: >> On 24 August 2017 at 20:10, wrote: >> > Y/Yf somehow dropped out from the SKL+ sprite modifier list. Add them >> > in. >> >> There's no 'somehow': >> https://lists.freedesktop.org/archives/intel-gfx/2017-August/134932.html >> >> I would prefer to not see this pushed whilst it doesn't actually work. > > Works fine here. Well, I should say it works just as well as it does for > the primary plane. There are no plane specific checks in the wm/ddb code > IIRC so if something is broken for sprites then it's most likely equally > broken for the primary plane. How did you test it? The failure mode I observed was that the primary plane had a giant allocation, having previously had plain Y-tiling or Y-CCS enabled. After switching the primary to linear or X-tiled, trying to configure a 256x256 sprite plane with either Y-tiled or CCS failed, as it only had a DDB allocation of 31 blocks, where it needed 33. So it's not that there are plane-specific checks rejecting anything, it's that the allocations never got drawn up to give the sprite plane enough room to do anything other than X-tiled. I saw this on both SKL (3200x1800 or 2560x1440) and APL (1920x1080). Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10] drm/i915/bios: amend child device config parameters
On Fri, 25 Aug 2017, Ville Syrjälä wrote:
> On Thu, Aug 24, 2017 at 09:53:59PM +0300, Jani Nikula wrote:
>> Add both some new and some old fields to child device config
>> parameters. Prepare for switching to just one child device config. Use
>> naming from struct old_child_dev_config for common fields.
>>
>> No functional changes.
>>
>> Cc: Animesh Manna
>> Cc: Paulo Zanoni
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_vbt_defs.h | 31 +++
>> 1 file changed, 27 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
>> b/drivers/gpu/drm/i915/intel_vbt_defs.h
>> index a92e7762f596..9ad05b2c44e0 100644
>> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
>> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
>> @@ -260,13 +260,28 @@ struct old_child_dev_config {
>> /* This one contains field offsets that are known to be common for all BDB
>> * versions. Notice that the meaning of the contents contents may still
>> change,
>> * but at least the offsets are consistent. */
>> -
>> struct common_child_dev_config {
>> u16 handle;
>> u16 device_type;
>> -u8 not_common1[12];
>> +u8 i2c_speed;
>> +u8 dp_onboard_redriver; /* 158 */
>> +u8 dp_ondock_redriver; /* 158 */
>> +u8 hdmi_level_shifter_value:4; /* 169 */
>> +u8 hdmi_max_data_rate:4;/* 204 */
>> +u16 dtd_buf_ptr;/* 161 */
>> +u8 edidless_efp:1; /* 161 */
>> +u8 compression_enable:1;/* 198 */
>> +u8 compression_method:1;/* 198 */
>> +u8 ganged_edp:1;/* 202 */
>> +u8 reserved0:4;
>> +u8 compression_structure_index:4; /* 198 */
>> +u8 reserved1:4;
>> +u8 slave_port; /* 202 */
>> +u8 reserved2;
>> +u16 addin_offset;
>> u8 dvo_port;
>> -u8 not_common2[2];
>> +u8 i2c_pin;
>> +u8 slave_addr;
>> u8 ddc_pin;
>> u16 edid_ptr;
>> u8 dvo_cfg; /* See DEVICE_CFG_* above */
>> @@ -281,7 +296,15 @@ struct common_child_dev_config {
>> u8 tmds_support:1;
>> u8 support_reserved:5;
>> u8 aux_channel;
>> -u8 not_common3[11];
>> +u8 dongle_detect;
>> +u8 capabilities;
>> +u8 dvo_wiring; /* See DEVICE_WIRE_* above */
>> +u8 mipi_bridge_type;/* 171 */
>> +u16 extended_type;
>> +u8 dvo_function;
>> +u8 flags2; /* 195 */
>> +u8 dp_gpio_index; /* 195 */
>> +u16 dp_gpio_pin_num;/* 195 */
>> u8 iboost_level;
>
> The iboost stuff could also use the version comments, and it could be
> made to use a bitfield since that seems to be what we do for VBT stuff.
Patches follow.
> Series lgtm, or at least I wasn't able to spot any mistakes. So for the
> series
> Reviewed-by: Ville Syrjälä
Thank you very much, pushed the lot.
BR,
Jani.
>
>> } __packed;
>>
>> --
>> 2.11.0
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm: Check that the plane supports the request format+modifier combo
On Thu, Aug 24, 2017 at 10:10:59PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we only check that the plane supports the pixel format of the
> fb we're about to feed to it. Extend it to check also the modifier, and
> more specifically that the combination of the format and modifier is
> supported.
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: Ben Widawsky
> Cc: Jason Ekstrand
> Cc: Daniel Stone
> Signed-off-by: Ville Syrjälä
I think Daniel Stone is on the hook to augment kms_ccs to properly test
this all in igt. Would be nice to add the corresponding Testcase: lines
when that's done.
With the test coverage gap addressed:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c| 8 +---
> drivers/gpu/drm/drm_crtc.c | 8 +---
> drivers/gpu/drm/drm_crtc_internal.h | 4 ++--
> drivers/gpu/drm/drm_plane.c | 31 +--
> 4 files changed, 37 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 2fd383d7253a..51cd05a7360b 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -884,12 +884,14 @@ static int drm_atomic_plane_check(struct drm_plane
> *plane,
> }
>
> /* Check whether this plane supports the fb pixel format. */
> - ret = drm_plane_check_pixel_format(plane, state->fb->format->format);
> + ret = drm_plane_check_pixel_format(plane, state->fb->format->format,
> +state->fb->modifier);
> if (ret) {
> struct drm_format_name_buf format_name;
> - DRM_DEBUG_ATOMIC("Invalid pixel format %s\n",
> + DRM_DEBUG_ATOMIC("Invalid pixel format %s, modifier 0x%llx\n",
>drm_get_format_name(state->fb->format->format,
> - &format_name));
> + &format_name),
> + state->fb->modifier);
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 5af25ce5bf7c..dd54deb75c0d 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -625,12 +625,14 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>*/
> if (!crtc->primary->format_default) {
> ret = drm_plane_check_pixel_format(crtc->primary,
> -fb->format->format);
> +fb->format->format,
> +fb->modifier);
> if (ret) {
> struct drm_format_name_buf format_name;
> - DRM_DEBUG_KMS("Invalid pixel format %s\n",
> + DRM_DEBUG_KMS("Invalid pixel format %s,
> modifier 0x%llx\n",
>
> drm_get_format_name(fb->format->format,
> -
> &format_name));
> + &format_name),
> + fb->modifier);
> goto out;
> }
> }
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> b/drivers/gpu/drm/drm_crtc_internal.h
> index a43582076b20..81865841b656 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -194,8 +194,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> /* drm_plane.c */
> int drm_plane_register_all(struct drm_device *dev);
> void drm_plane_unregister_all(struct drm_device *dev);
> -int drm_plane_check_pixel_format(const struct drm_plane *plane,
> - u32 format);
> +int drm_plane_check_pixel_format(struct drm_plane *plane,
> + u32 format, u64 modifier);
>
> /* drm_bridge.c */
> void drm_bridge_detach(struct drm_bridge *bridge);
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 7a00351d5b5d..c63a81e32e23 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -555,16 +555,33 @@ int drm_mode_getplane(struct drm_device *dev, void
> *data,
> return 0;
> }
>
> -int drm_plane_check_pixel_format(const struct drm_plane *plane, u32 format)
> +int drm_plane_check_pixel_format(struct drm_plane *plane,
> + u32 format, u64 modifier)
> {
> unsigned int i;
>
> for (i = 0; i < plane->format_count; i++) {
> if (format == plane->format_types[i])
> - return 0;
> + break;
> + }
> + if (i == plane->format_count)
> + return -EINVAL;
> +
> + if (!plane->modifier_count)
>
Re: [Intel-gfx] [PATCH 10/12] drm: Fix modifiers_property kernel doc
On Thu, Aug 24, 2017 at 10:10:58PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The member is called 'modifiers_property' instead of 'modifiers'. Adjust
> the kernel docs to match.
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: Ben Widawsky
> Cc: Jason Ekstrand
> Cc: Daniel Stone
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
Pls push to drm-misc-next (imo no need to for this to land in 4.14).
-Daniel
> ---
> include/drm/drm_mode_config.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 1b37368416c8..6040c4b73e6d 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -758,7 +758,7 @@ struct drm_mode_config {
> bool allow_fb_modifiers;
>
> /**
> - * @modifiers: Plane property to list support modifier/format
> + * @modifiers_property: Plane property to list support modifier/format
>* combination.
>*/
> struct drm_property *modifiers_property;
> --
> 2.13.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s
+paulo
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, August 25, 2017 4:12 PM
> To: Lofstedt, Marta ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking:
> increase FBC wait timeout to 5s
>
> Quoting Lofstedt, Marta (2017-08-25 13:50:16)
> >
> >
> > > -Original Message-
> > > From: Lofstedt, Marta
> > > Sent: Friday, August 25, 2017 2:54 PM
> > > To: 'Chris Wilson' ;
> > > intel-gfx@lists.freedesktop.org
> > > Subject: RE: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking:
> > > increase FBC wait timeout to 5s
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > Sent: Friday, August 25, 2017 1:47 PM
> > > > To: Lofstedt, Marta ; intel-
> > > > g...@lists.freedesktop.org
> > > > Subject: Re: [Intel-gfx] [PATCH i-g-t v2]
> tests/kms_frontbuffer_tracking:
> > > > increase FBC wait timeout to 5s
> > > >
> > > > Quoting Marta Lofstedt (2017-08-25 11:40:29)
> > > > > From: "Lofstedt, Marta"
> > > > >
> > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw*
> > > > > has non-consistent results, pending between fail and pass.
> > > > > The fails are always due to "FBC disabled".
> > > > > With this increase in timeout the flip-flop behavior is no
> > > > > longer reproducible.
> > > > >
> > > > > This is a partial revert of:
> > > > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54,
> > > > > where the timeout was decreased from 5s to 2s.
> > > > > After investigating the timeout needed, the conclusion is that
> > > > > the longer timeout is only needed when the test swaps between
> > > > > some specific draw domains, typically blt vs. mmap_cpu.
> > > > > The objective of the FBC part of the tests is not to benchmark
> > > > > draw domain changes, it is to check that FBC was (re-)enabled.
> > > > >
> > > > > V2: Added documentation
> > > > >
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623
> > > > > Signed-off-by: Marta Lofstedt
> > > > > Acked-by: Paulo Zanoni
> > > > > ---
> > > > > tests/kms_frontbuffer_tracking.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/tests/kms_frontbuffer_tracking.c
> > > > > b/tests/kms_frontbuffer_tracking.c
> > > > > index e03524f1..2538450c 100644
> > > > > --- a/tests/kms_frontbuffer_tracking.c
> > > > > +++ b/tests/kms_frontbuffer_tracking.c
> > > > > @@ -924,7 +924,7 @@ static bool fbc_stride_not_supported(void)
> > > > >
> > > > > static bool fbc_wait_until_enabled(void) {
> > > >
> > > > Try igt_drop_caches_set(device, DROP_RETIRE); instead of relaxing
> > > > the timeout.
> > > > -Chris
> > >
> > > OK, I will test that and do a V3 if it works!
> > > /Marta
> >
> > I did some initial testing with igt_drop_caches_set inside
> fbc_wait_until_enabled and it looks good, I will add this to my weekend tests
> to get more results. This also appear to improve the runtime of the tests
> quite a bit. So, maybe the igt_drop_caches_set should be placed somewhere
> else so it will give runtime improvements not only for the FBC related sub-
> tests.
>
> Sure, all the waits can do with the retire first, give it a common function
> and a
> comment for the rationale (which should pretty much the same as given in
> the changelog). Anytime we use the GPU to invalidate the frontbuffer
> tracking, we have to wait for a retire to do the flush.
> Retirement is lazy, and is normally driven by GPU activity but we have a
> background kworker to make sure we notice when the system becomes idle
> independent of userspace - except it's low frequency.
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for igt/gem_fence_thresh: Use streaming reads for verify
== Series Details == Series: igt/gem_fence_thresh: Use streaming reads for verify URL : https://patchwork.freedesktop.org/series/29208/ State : warning == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 Test kms_atomic_transition: Subgroup plane-all-modeset-transition: pass -> DMESG-WARN (shard-hsw) fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2230 pass:1230 dwarn:1 dfail:0 fail:18 skip:981 time:9459s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_97/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 v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s
Quoting Lofstedt, Marta (2017-08-25 13:50:16)
>
>
> > -Original Message-
> > From: Lofstedt, Marta
> > Sent: Friday, August 25, 2017 2:54 PM
> > To: 'Chris Wilson' ;
> > intel-gfx@lists.freedesktop.org
> > Subject: RE: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking:
> > increase FBC wait timeout to 5s
> >
> >
> >
> > > -Original Message-
> > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > Sent: Friday, August 25, 2017 1:47 PM
> > > To: Lofstedt, Marta ; intel-
> > > g...@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking:
> > > increase FBC wait timeout to 5s
> > >
> > > Quoting Marta Lofstedt (2017-08-25 11:40:29)
> > > > From: "Lofstedt, Marta"
> > > >
> > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw*
> > > > has non-consistent results, pending between fail and pass.
> > > > The fails are always due to "FBC disabled".
> > > > With this increase in timeout the flip-flop behavior is no longer
> > > > reproducible.
> > > >
> > > > This is a partial revert of:
> > > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54,
> > > > where the timeout was decreased from 5s to 2s.
> > > > After investigating the timeout needed, the conclusion is that the
> > > > longer timeout is only needed when the test swaps between some
> > > > specific draw domains, typically blt vs. mmap_cpu.
> > > > The objective of the FBC part of the tests is not to benchmark draw
> > > > domain changes, it is to check that FBC was (re-)enabled.
> > > >
> > > > V2: Added documentation
> > > >
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623
> > > > Signed-off-by: Marta Lofstedt
> > > > Acked-by: Paulo Zanoni
> > > > ---
> > > > tests/kms_frontbuffer_tracking.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/tests/kms_frontbuffer_tracking.c
> > > > b/tests/kms_frontbuffer_tracking.c
> > > > index e03524f1..2538450c 100644
> > > > --- a/tests/kms_frontbuffer_tracking.c
> > > > +++ b/tests/kms_frontbuffer_tracking.c
> > > > @@ -924,7 +924,7 @@ static bool fbc_stride_not_supported(void)
> > > >
> > > > static bool fbc_wait_until_enabled(void) {
> > >
> > > Try igt_drop_caches_set(device, DROP_RETIRE); instead of relaxing the
> > > timeout.
> > > -Chris
> >
> > OK, I will test that and do a V3 if it works!
> > /Marta
>
> I did some initial testing with igt_drop_caches_set inside
> fbc_wait_until_enabled and it looks good, I will add this to my weekend tests
> to get more results. This also appear to improve the runtime of the tests
> quite a bit. So, maybe the igt_drop_caches_set should be placed somewhere
> else so it will give runtime improvements not only for the FBC related
> sub-tests.
Sure, all the waits can do with the retire first, give it a common
function and a comment for the rationale (which should pretty much the
same as given in the changelog). Anytime we use the GPU to invalidate
the frontbuffer tracking, we have to wait for a retire to do the flush.
Retirement is lazy, and is normally driven by GPU activity but we have a
background kworker to make sure we notice when the system becomes idle
independent of userspace - except it's low frequency.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: decouple gen9 and gen10 dp signal levels.
On Fri, Aug 25, 2017 at 03:46:33PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 16, 2017 at 01:19:49PM -0700, Rodrigo Vivi wrote:
> > Let's decouple bxt, glk and cnl dp signal levels
> > from other DDIs to avoid confusion.
> >
> > No functional change. Only a reorg to avoid messing
> > with currently working DP signal levels when
> > moving voltage swing sequences around to match spec.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 26 --
> > drivers/gpu/drm/i915/intel_dp.c | 10 --
> > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > 3 files changed, 21 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index dd2bdbe82b47..9891ad40d1dc 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2063,23 +2063,29 @@ static uint32_t intel_ddi_dp_level(struct intel_dp
> > *intel_dp)
> > return translate_signal_level(signal_levels);
> > }
> >
> > -uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
> > +u32 bxt_signal_levels(struct intel_dp *intel_dp)
> > {
> > struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
> > struct drm_i915_private *dev_priv = to_i915(dport->base.base.dev);
> > struct intel_encoder *encoder = &dport->base;
> > enum port port = dport->port;
> > - uint32_t level = intel_ddi_dp_level(intel_dp);
> > + u32 level = intel_ddi_dp_level(intel_dp);
> >
> > - if (IS_GEN9_BC(dev_priv))
> > - skl_ddi_set_iboost(encoder, level);
> > - else if (IS_GEN9_LP(dev_priv))
> > - bxt_ddi_vswing_sequence(dev_priv, level, port, encoder->type);
> > - else if (IS_CANNONLAKE(dev_priv)) {
> > + if (IS_CANNONLAKE(dev_priv))
> > cnl_ddi_vswing_sequence(encoder, level);
> > - /* DDI_BUF_CTL bits 27:24 are reserved on CNL */
> > - return 0;
> > - }
> > + else
> > + bxt_ddi_vswing_sequence(dev_priv, level, port, encoder->type);
> > +
> > + return 0;
> > +}
> > +
> > +uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
>
> skl_signal_levels() perhaps?
Oh, it actuall gets called on all older DDI platforms. So I guess the
name is OK, but the iboost call needs a platform check then,
>
> > +{
> > + struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
> > + struct intel_encoder *encoder = &dport->base;
> > + uint32_t level = intel_ddi_dp_level(intel_dp);
> > +
> > + skl_ddi_set_iboost(encoder, level);
> > return DDI_BUF_TRANS_SELECT(level);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 4fd4853b2250..1af4b227e758 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3506,13 +3506,11 @@ intel_dp_set_signal_levels(struct intel_dp
> > *intel_dp)
> > uint32_t signal_levels, mask = 0;
> > uint8_t train_set = intel_dp->train_set[0];
> >
> > - if (HAS_DDI(dev_priv)) {
> > + if (IS_GEN9_LP(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> > + signal_levels = bxt_signal_levels(intel_dp);
> > + } else if (HAS_DDI(dev_priv)) {
> > signal_levels = ddi_signal_levels(intel_dp);
> > -
> > - if (IS_GEN9_LP(dev_priv) || IS_CANNONLAKE(dev_priv))
> > - signal_levels = 0;
> > - else
> > - mask = DDI_BUF_EMP_MASK;
> > + mask = DDI_BUF_EMP_MASK;
> > } else if (IS_CHERRYVIEW(dev_priv)) {
> > signal_levels = chv_signal_levels(intel_dp);
> > } else if (IS_VALLEYVIEW(dev_priv)) {
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index fa47285918f4..91354ad2 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1272,6 +1272,7 @@ void intel_ddi_clock_get(struct intel_encoder
> > *encoder,
> > struct intel_crtc_state *pipe_config);
> > void intel_ddi_set_vc_payload_alloc(const struct intel_crtc_state
> > *crtc_state,
> > bool state);
> > +u32 bxt_signal_levels(struct intel_dp *intel_dp);
> > uint32_t ddi_signal_levels(struct intel_dp *intel_dp);
> > u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
> >
> > --
> > 2.13.2
>
> --
> Ville Syrjälä
> Intel OTC
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 4/4] drm/i915: Enable voltage swing before enabling DDI_BUF_CTL.
On Wed, Aug 16, 2017 at 01:19:51PM -0700, Rodrigo Vivi wrote: > Sequences for DisplayPort asks us to > " Configure voltage swing and related IO settings. > Refer to DDI Buffer section." > > before "Configure and enable DDI_BUF_CTL" > > On BXT and CNL this means to execute the ddi vswing sequences. > > At this point these sequences calls are getting duplicated for DP > because they are all called from DP link trainning sequences. > > However this patch is not yet removing it before a futher discussion > since spec also allows that during link training without disabling > anything: > > " > Notes > Changing voltage swing during link training: > Change the swing setting following the DDI Buffer section. > The port does not need to be disabled. > " > > Cc: Ville Syrjälä > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_ddi.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > b/drivers/gpu/drm/i915/intel_ddi.c > index a6056bb4f801..8ea0368e15b1 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -2133,6 +2133,7 @@ static void intel_ddi_pre_enable_dp(struct > intel_encoder *encoder, > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > enum port port = intel_ddi_get_encoder_port(encoder); > struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base); > + uint32_t level = intel_ddi_dp_level(intel_dp); > > WARN_ON(link_mst && (port == PORT_A || port == PORT_E)); > > @@ -2145,7 +2146,11 @@ static void intel_ddi_pre_enable_dp(struct > intel_encoder *encoder, > > intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain); > > - if (!IS_GEN9_LP(dev_priv) && !IS_CANNONLAKE(dev_priv)) > + if (IS_CANNONLAKE(dev_priv)) > + cnl_ddi_vswing_sequence(encoder, level); > + else if (IS_GEN9_LP(dev_priv)) > + bxt_ddi_vswing_sequence(dev_priv, level, port, encoder->type); Hmm. Yeah, I guess it would make sense to set these up already before we enable DDI_BUF_CTL, which I think would happend from the .prepare_link_retrain() hook on DDI, and that does get called before the signal levels have been set up. So I'm fine with this change. Imre, any thoughts? > + else > intel_prepare_dp_ddi_buffers(encoder); > > intel_ddi_init_dp_buf_reg(encoder); > -- > 2.13.2 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v14 0/7] drm/i915/gvt: Dma-buf support for GVT-g
Hi Gerd: Thanks for the testing. We will find out the problem and refresh the whole patch series. Thanks, Zhi. -Original Message- From: Gerd Hoffmann [mailto:kra...@redhat.com] Sent: Friday, August 25, 2017 2:47 PM To: Zhang, Tina ; zhen...@linux.intel.com; Lv, Zhiyuan ; Wang, Zhi A ; Tian, Kevin ; alex.william...@redhat.com; ch...@chris-wilson.co.uk; dan...@ffwll.ch; joonas.lahti...@linux.intel.com; kwankh...@nvidia.com Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org Subject: Re: [PATCH v14 0/7] drm/i915/gvt: Dma-buf support for GVT-g On Fri, 2017-08-18 at 18:21 +0800, Tina Zhang wrote: > v13->v14: > 1) add PROBE, DMABUF and REGION flags. (Alex) > 2) return -ENXIO when gem proxy object is banned by ioctl. > (Chris) (Daniel) > 3) add some details about the float pixel format. (Daniel) > 4) add F suffix to the defined name. (Daniel) > 5) refine pixel format table. (Zhenyu) Ok, patch series applies cleanly to 4.13-rc6. The new flags are working fine. However, I see VFIO_DEVICE_QUERY_GFX_PLANE failures which I think should not be there. When the guest didn't define a plane yet I get "No such device" errors instead of a plane_info struct with fields (drm_format, width, height, size) set to zero. I also see "Bad address" errors now and then with no obvious cause. Cursor support isn't working too. I'm testing with "-display egl-headless -spice gl=off,port=...". In that configuration qemu will import the dma-bufs as textures and reads them using ReadPixels for display. qemu branch: https://www.kraxel.org/cgit/qemu/log/?h=work/intel-vgpu The qemu branch has support for both dmabufs and regions. The region- based display code is totaly untested though. cheers, Gerd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s
> -Original Message-
> From: Lofstedt, Marta
> Sent: Friday, August 25, 2017 2:54 PM
> To: 'Chris Wilson' ; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking:
> increase FBC wait timeout to 5s
>
>
>
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Friday, August 25, 2017 1:47 PM
> > To: Lofstedt, Marta ; intel-
> > g...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking:
> > increase FBC wait timeout to 5s
> >
> > Quoting Marta Lofstedt (2017-08-25 11:40:29)
> > > From: "Lofstedt, Marta"
> > >
> > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw*
> > > has non-consistent results, pending between fail and pass.
> > > The fails are always due to "FBC disabled".
> > > With this increase in timeout the flip-flop behavior is no longer
> > > reproducible.
> > >
> > > This is a partial revert of:
> > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54,
> > > where the timeout was decreased from 5s to 2s.
> > > After investigating the timeout needed, the conclusion is that the
> > > longer timeout is only needed when the test swaps between some
> > > specific draw domains, typically blt vs. mmap_cpu.
> > > The objective of the FBC part of the tests is not to benchmark draw
> > > domain changes, it is to check that FBC was (re-)enabled.
> > >
> > > V2: Added documentation
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623
> > > Signed-off-by: Marta Lofstedt
> > > Acked-by: Paulo Zanoni
> > > ---
> > > tests/kms_frontbuffer_tracking.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tests/kms_frontbuffer_tracking.c
> > > b/tests/kms_frontbuffer_tracking.c
> > > index e03524f1..2538450c 100644
> > > --- a/tests/kms_frontbuffer_tracking.c
> > > +++ b/tests/kms_frontbuffer_tracking.c
> > > @@ -924,7 +924,7 @@ static bool fbc_stride_not_supported(void)
> > >
> > > static bool fbc_wait_until_enabled(void) {
> >
> > Try igt_drop_caches_set(device, DROP_RETIRE); instead of relaxing the
> > timeout.
> > -Chris
>
> OK, I will test that and do a V3 if it works!
> /Marta
I did some initial testing with igt_drop_caches_set inside
fbc_wait_until_enabled and it looks good, I will add this to my weekend tests
to get more results. This also appear to improve the runtime of the tests quite
a bit. So, maybe the igt_drop_caches_set should be placed somewhere else so it
will give runtime improvements not only for the FBC related sub-tests.
/Marta
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: decouple gen9 and gen10 dp signal levels.
On Wed, Aug 16, 2017 at 01:19:49PM -0700, Rodrigo Vivi wrote:
> Let's decouple bxt, glk and cnl dp signal levels
> from other DDIs to avoid confusion.
>
> No functional change. Only a reorg to avoid messing
> with currently working DP signal levels when
> moving voltage swing sequences around to match spec.
>
> Cc: Ville Syrjälä
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 26 --
> drivers/gpu/drm/i915/intel_dp.c | 10 --
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> 3 files changed, 21 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index dd2bdbe82b47..9891ad40d1dc 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2063,23 +2063,29 @@ static uint32_t intel_ddi_dp_level(struct intel_dp
> *intel_dp)
> return translate_signal_level(signal_levels);
> }
>
> -uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
> +u32 bxt_signal_levels(struct intel_dp *intel_dp)
> {
> struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
> struct drm_i915_private *dev_priv = to_i915(dport->base.base.dev);
> struct intel_encoder *encoder = &dport->base;
> enum port port = dport->port;
> - uint32_t level = intel_ddi_dp_level(intel_dp);
> + u32 level = intel_ddi_dp_level(intel_dp);
>
> - if (IS_GEN9_BC(dev_priv))
> - skl_ddi_set_iboost(encoder, level);
> - else if (IS_GEN9_LP(dev_priv))
> - bxt_ddi_vswing_sequence(dev_priv, level, port, encoder->type);
> - else if (IS_CANNONLAKE(dev_priv)) {
> + if (IS_CANNONLAKE(dev_priv))
> cnl_ddi_vswing_sequence(encoder, level);
> - /* DDI_BUF_CTL bits 27:24 are reserved on CNL */
> - return 0;
> - }
> + else
> + bxt_ddi_vswing_sequence(dev_priv, level, port, encoder->type);
> +
> + return 0;
> +}
> +
> +uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
skl_signal_levels() perhaps?
> +{
> + struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
> + struct intel_encoder *encoder = &dport->base;
> + uint32_t level = intel_ddi_dp_level(intel_dp);
> +
> + skl_ddi_set_iboost(encoder, level);
> return DDI_BUF_TRANS_SELECT(level);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4fd4853b2250..1af4b227e758 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3506,13 +3506,11 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp)
> uint32_t signal_levels, mask = 0;
> uint8_t train_set = intel_dp->train_set[0];
>
> - if (HAS_DDI(dev_priv)) {
> + if (IS_GEN9_LP(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> + signal_levels = bxt_signal_levels(intel_dp);
> + } else if (HAS_DDI(dev_priv)) {
> signal_levels = ddi_signal_levels(intel_dp);
> -
> - if (IS_GEN9_LP(dev_priv) || IS_CANNONLAKE(dev_priv))
> - signal_levels = 0;
> - else
> - mask = DDI_BUF_EMP_MASK;
> + mask = DDI_BUF_EMP_MASK;
> } else if (IS_CHERRYVIEW(dev_priv)) {
> signal_levels = chv_signal_levels(intel_dp);
> } else if (IS_VALLEYVIEW(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index fa47285918f4..91354ad2 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1272,6 +1272,7 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config);
> void intel_ddi_set_vc_payload_alloc(const struct intel_crtc_state
> *crtc_state,
> bool state);
> +u32 bxt_signal_levels(struct intel_dp *intel_dp);
> uint32_t ddi_signal_levels(struct intel_dp *intel_dp);
> u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
>
> --
> 2.13.2
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for tests: chamelium: Eliminate reset when preparing output
== Series Details == Series: tests: chamelium: Eliminate reset when preparing output URL : https://patchwork.freedesktop.org/series/29346/ State : success == Summary == IGT patchset tested on top of latest successful build 29d488034a50cd6fbad792cae61321995f0ab51c aubdump: Log some information about the execbuf calls with latest DRM-Tip kernel build CI_DRM_3003 f22dadc265b3 drm-tip: 2017y-08m-25d-11h-48m-56s UTC integration manifest Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_frontbuffer_tracking: Subgroup basic: dmesg-warn -> PASS (fi-bdw-5557u) fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:457s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:442s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:364s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:557s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:254s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:518s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:529s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:515s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:438s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:614s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:445s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:431s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:428s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:497s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:474s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:482s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:599s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:594s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:522s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:477s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:479s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:494s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:443s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:497s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:546s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:406s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_100/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10] drm/i915/bios: amend child device config parameters
On Thu, Aug 24, 2017 at 09:53:59PM +0300, Jani Nikula wrote:
> Add both some new and some old fields to child device config
> parameters. Prepare for switching to just one child device config. Use
> naming from struct old_child_dev_config for common fields.
>
> No functional changes.
>
> Cc: Animesh Manna
> Cc: Paulo Zanoni
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_vbt_defs.h | 31 +++
> 1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index a92e7762f596..9ad05b2c44e0 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -260,13 +260,28 @@ struct old_child_dev_config {
> /* This one contains field offsets that are known to be common for all BDB
> * versions. Notice that the meaning of the contents contents may still
> change,
> * but at least the offsets are consistent. */
> -
> struct common_child_dev_config {
> u16 handle;
> u16 device_type;
> - u8 not_common1[12];
> + u8 i2c_speed;
> + u8 dp_onboard_redriver; /* 158 */
> + u8 dp_ondock_redriver; /* 158 */
> + u8 hdmi_level_shifter_value:4; /* 169 */
> + u8 hdmi_max_data_rate:4;/* 204 */
> + u16 dtd_buf_ptr;/* 161 */
> + u8 edidless_efp:1; /* 161 */
> + u8 compression_enable:1;/* 198 */
> + u8 compression_method:1;/* 198 */
> + u8 ganged_edp:1;/* 202 */
> + u8 reserved0:4;
> + u8 compression_structure_index:4; /* 198 */
> + u8 reserved1:4;
> + u8 slave_port; /* 202 */
> + u8 reserved2;
> + u16 addin_offset;
> u8 dvo_port;
> - u8 not_common2[2];
> + u8 i2c_pin;
> + u8 slave_addr;
> u8 ddc_pin;
> u16 edid_ptr;
> u8 dvo_cfg; /* See DEVICE_CFG_* above */
> @@ -281,7 +296,15 @@ struct common_child_dev_config {
> u8 tmds_support:1;
> u8 support_reserved:5;
> u8 aux_channel;
> - u8 not_common3[11];
> + u8 dongle_detect;
> + u8 capabilities;
> + u8 dvo_wiring; /* See DEVICE_WIRE_* above */
> + u8 mipi_bridge_type;/* 171 */
> + u16 extended_type;
> + u8 dvo_function;
> + u8 flags2; /* 195 */
> + u8 dp_gpio_index; /* 195 */
> + u16 dp_gpio_pin_num;/* 195 */
> u8 iboost_level;
The iboost stuff could also use the version comments, and it could be
made to use a bitfield since that seems to be what we do for VBT stuff.
Series lgtm, or at least I wasn't able to spot any mistakes. So for the
series
Reviewed-by: Ville Syrjälä
> } __packed;
>
> --
> 2.11.0
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Add GuC Load time to debugfs
On Thu, Aug 24, 2017 at 09:38:06PM -0700, Anusha Srivatsa wrote:
> Calculate the time that GuC takes to load.
> This information could be very useful in
> determining if GuC is taking unreasonably long time
> to load in a certain platforms.
>
> Cc: Oscar Mateo
> Cc: Michal Wajdeczko
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 4
> drivers/gpu/drm/i915/intel_guc_loader.c | 4
> drivers/gpu/drm/i915/intel_uc.h | 3 +++
> 3 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 48572b157222..9283fc714705 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2379,6 +2379,10 @@ static int i915_guc_load_status_info(struct seq_file
> *m, void *data)
> guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
> seq_printf(m, "\tversion found: %d.%d\n",
> guc_fw->major_ver_found, guc_fw->minor_ver_found);
> + seq_printf(m, "\tLoad time is %lu ms\n",
> +jiffies_to_msecs(dev_priv->guc.guc_finish_load -
> +dev_priv->guc.guc_start_load));
> +
> seq_printf(m, "\theader: offset is %d; size = %d\n",
> guc_fw->header_offset, guc_fw->header_size);
> seq_printf(m, "\tuCode: offset is %d; size = %d\n",
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 8b0ae7fce7f2..1c5059b930f9 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -194,6 +194,7 @@ static inline bool guc_ucode_response(struct
> drm_i915_private *dev_priv,
> static int guc_ucode_xfer_dma(struct drm_i915_private *dev_priv,
> struct i915_vma *vma)
> {
> + struct intel_guc *guc = &dev_priv->guc;
> struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
> unsigned long offset;
> struct sg_table *sg = vma->pages;
> @@ -226,6 +227,7 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
> *dev_priv,
>
> /* Finally start the DMA */
> I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(UOS_MOVE | START_DMA));
> + guc->guc_start_load = jiffies;
>
> /*
>* Wait for the DMA to complete & the GuC to start up.
> @@ -240,6 +242,8 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
> *dev_priv,
> DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",
> I915_READ(DMA_CTRL), status);
>
> + guc->guc_finish_load = jiffies;
> +
On error/timeout we don't know if loading was finished/completed and your
calculations will be wrong. End time shall be captured before any debug logs
to more accurate. Btw, if loading time is so important, maybe it should be
also printed here as part of above DRM_DEBUG ?
> if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
> DRM_ERROR("GuC firmware signature verification failed\n");
> ret = -ENOEXEC;
> diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
> index 22ae52b17b0f..3d5a15ed1995 100644
> --- a/drivers/gpu/drm/i915/intel_uc.h
> +++ b/drivers/gpu/drm/i915/intel_uc.h
> @@ -210,6 +210,9 @@ struct intel_guc {
>
> /* GuC's FW specific notify function */
> void (*notify)(struct intel_guc *guc);
> +
> + unsigned long guc_start_load;
> + unsigned long guc_finish_load;
No need to keep both jiffies here. Calculate "load_time_in_ms" in the
loader function and store only final result. Maybe better place for
this result would be "intel_uc_fw" ? Then we can do the same for Huc.
-Michal
> };
>
> struct intel_huc {
> --
> 2.11.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for igt/kms_hdmi_inject: Require /proc/asound before asserting
== Series Details == Series: igt/kms_hdmi_inject: Require /proc/asound before asserting URL : https://patchwork.freedesktop.org/series/29217/ State : warning == Summary == Test vgem_basic: Subgroup unload: pass -> SKIP (shard-hsw) shard-hswtotal:2230 pass:1230 dwarn:0 dfail:0 fail:18 skip:982 time:9663s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_96/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 tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s (rev2)
== Series Details == Series: tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s (rev2) URL : https://patchwork.freedesktop.org/series/26479/ State : success == Summary == IGT patchset tested on top of latest successful build 29d488034a50cd6fbad792cae61321995f0ab51c aubdump: Log some information about the execbuf calls with latest DRM-Tip kernel build CI_DRM_3003 f22dadc265b3 drm-tip: 2017y-08m-25d-11h-48m-56s UTC integration manifest Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_frontbuffer_tracking: Subgroup basic: dmesg-warn -> PASS (fi-bdw-5557u) fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:463s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:446s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:363s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:564s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:255s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:527s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:528s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:521s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:437s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:617s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:447s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:424s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:430s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:510s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:602s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:595s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:467s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:482s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:487s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:483s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:549s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:404s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_99/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 3/3] intel-ci: Add fast chamelium tests to the fast-feedback list
On Wed, 2017-08-23 at 18:21 +0300, Paul Kocialkowski wrote: > This adds the fastest chamelium tests to the Intel CI fast-feedback > list, with the objective of running in under a minute. For the record, here are average run times for the added tests: dp-hpd-fast: 2.397s dp-edid-read: 1.776s dp-crc-fast: 6.458s hdmi-hpd-fast: 2.732s hdmi-edid-read: 2.165s hdmi-crc-fast: 8.612s vga-hpd-fast: 7.384s vga-edid-read: 3.805s common-hpd-after-suspend: 22.496s total: 57.825s Note that the CRC tests are especially slow because of the interface decoders on the Chamelium board. They take seconds to detect the video input as stable and there isn't much we can do about that. > Signed-off-by: Paul Kocialkowski > --- > tests/intel-ci/fast-feedback.testlist | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel- > ci/fast-feedback.testlist > index 79160624..a8e9c5be 100644 > --- a/tests/intel-ci/fast-feedback.testlist > +++ b/tests/intel-ci/fast-feedback.testlist > @@ -1,5 +1,14 @@ > # Keep alphabetically sorted by default > > +igt@chamelium@dp-hpd-fast > +igt@chamelium@dp-edid-read > +igt@chamelium@dp-crc-fast > +igt@chamelium@hdmi-hpd-fast > +igt@chamelium@hdmi-edid-read > +igt@chamelium@hdmi-crc-fast > +igt@chamelium@vga-hpd-fast > +igt@chamelium@vga-edid-read > +igt@chamelium@common-hpd-after-suspend > igt@core_auth@basic-auth > igt@core_prop_blob@basic > igt@debugfs_test@read_all_entries -- Paul Kocialkowski Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo, Finland ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests: chamelium: Eliminate reset when preparing output
Resetting the Chamelium when preparing the video output is unnecessary and significant increases the tests run-time. Since all video-related tests work just as well without it, eliminate it. This also adds a call to reset_test in the analog frame dump test, that was missing before, although the chamelium was still reset by the call to prepare_output. Signed-off-by: Paul Kocialkowski --- tests/chamelium.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/chamelium.c b/tests/chamelium.c index 00ae484b..484bb537 100644 --- a/tests/chamelium.c +++ b/tests/chamelium.c @@ -417,8 +417,6 @@ prepare_output(data_t *data, drmModeConnector *connector = chamelium_port_get_connector(data->chamelium, port, false); - chamelium_reset(data->chamelium); - igt_assert(res = drmModeGetResources(data->drm_fd)); kmstest_unset_all_crtcs(data->drm_fd, res); @@ -626,6 +624,8 @@ test_analog_frame_dump(data_t *data, struct chamelium_port *port) int fb_id, i; bool bridge; + reset_state(data, port); + output = prepare_output(data, &display, port); connector = chamelium_port_get_connector(data->chamelium, port, false); primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY); -- 2.14.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: Beef up the IPS vs. CRC workaround
On Thu, Aug 17, 2017 at 05:55:09PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Oneshot disabling of IPS when CRC capturing is started is insufficient. > IPS may get re-enabled by any plane update, and hence tests that keep > CRC capturing on across plane updates will start to see inconsistent > results as soon as IPS kicks back in. Add a new knob into the crtc state > to make sure IPS stays disabled as long as CRC capturing is enabled. > > Forcing a modeset is the easiest way to handle this since that's already > how we do the panel fitter workaround. It's a little heavy handed just > for IPS, but seeing as we might already do the panel fitter workaround > I think it's better to follow that. We migth want to optimize both cases > later if someone gets too upset by the extra delay from the modeset. > > v2: Check the right thing when deciding whether to force a modeset > v3: Rebase, check HAS_IPS before forcing a modeset, > move ips_force_disable check into pipe_config_supports_ips() > > Cc: Paulo Zanoni > Cc: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Marta Lofstedt > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101664 > Reviewed-by: Paulo Zanoni > Tested-by: Marta Lofsted #v2 > Signed-off-by: Ville Syrjälä Pushed to dinq. Thanks for the review and testing. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, August 25, 2017 1:47 PM
> To: Lofstedt, Marta ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking:
> increase FBC wait timeout to 5s
>
> Quoting Marta Lofstedt (2017-08-25 11:40:29)
> > From: "Lofstedt, Marta"
> >
> > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw*
> > has non-consistent results, pending between fail and pass.
> > The fails are always due to "FBC disabled".
> > With this increase in timeout the flip-flop behavior is no longer
> > reproducible.
> >
> > This is a partial revert of:
> > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54,
> > where the timeout was decreased from 5s to 2s.
> > After investigating the timeout needed, the conclusion is that the
> > longer timeout is only needed when the test swaps between some
> > specific draw domains, typically blt vs. mmap_cpu.
> > The objective of the FBC part of the tests is not to benchmark draw
> > domain changes, it is to check that FBC was (re-)enabled.
> >
> > V2: Added documentation
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623
> > Signed-off-by: Marta Lofstedt
> > Acked-by: Paulo Zanoni
> > ---
> > tests/kms_frontbuffer_tracking.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tests/kms_frontbuffer_tracking.c
> > b/tests/kms_frontbuffer_tracking.c
> > index e03524f1..2538450c 100644
> > --- a/tests/kms_frontbuffer_tracking.c
> > +++ b/tests/kms_frontbuffer_tracking.c
> > @@ -924,7 +924,7 @@ static bool fbc_stride_not_supported(void)
> >
> > static bool fbc_wait_until_enabled(void) {
>
> Try igt_drop_caches_set(device, DROP_RETIRE); instead of relaxing the
> timeout.
> -Chris
OK, I will test that and do a V3 if it works!
/Marta
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v14 0/7] drm/i915/gvt: Dma-buf support for GVT-g
On Fri, 2017-08-18 at 18:21 +0800, Tina Zhang wrote: > v13->v14: > 1) add PROBE, DMABUF and REGION flags. (Alex) > 2) return -ENXIO when gem proxy object is banned by ioctl. > (Chris) (Daniel) > 3) add some details about the float pixel format. (Daniel) > 4) add F suffix to the defined name. (Daniel) > 5) refine pixel format table. (Zhenyu) Ok, patch series applies cleanly to 4.13-rc6. The new flags are working fine. However, I see VFIO_DEVICE_QUERY_GFX_PLANE failures which I think should not be there. When the guest didn't define a plane yet I get "No such device" errors instead of a plane_info struct with fields (drm_format, width, height, size) set to zero. I also see "Bad address" errors now and then with no obvious cause. Cursor support isn't working too. I'm testing with "-display egl-headless -spice gl=off,port=...". In that configuration qemu will import the dma-bufs as textures and reads them using ReadPixels for display. qemu branch: https://www.kraxel.org/cgit/qemu/log/?h=work/intel-vgpu The qemu branch has support for both dmabufs and regions. The region- based display code is totaly untested though. cheers, Gerd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/12] drm/i915: Switch over to the LLC/eLLC hotspot avoidance hash mode for CCS
On Thu, Aug 24, 2017 at 09:55:54PM -0700, Ben Widawsky wrote:
> On 17-08-24 22:10:51, Ville Syrjälä wrote:
> >From: Ville Syrjälä
> >
> >Use the LLC/eLLC hotspot avoidance mode for CCS on LLC machines. This is
> >reported to give better performance.
> >
>
> Not seeing in the diff how this only hits eLLC machines. Am I misreading when
> this is needed.
It's enabled on all LLC machines, not just those that have eLLC.
>
> >Testing has indicated that we don't need to enforce any massive 2 or 4
> >MiB alignment for all compressed resources even though there are still
> >plenty of stale comments in the spec suggesting that we do.
> >
> >We do need to make sure every hardware unit that deals with the
> >compressed data uses the same hash mode.
> >
> >Cc: Ben Widawsky
> >Cc: Jason Ekstrand
> >Cc: Daniel Stone
> >Signed-off-by: Ville Syrjälä
> >---
> > drivers/gpu/drm/i915/i915_reg.h| 8 +++-
> > drivers/gpu/drm/i915/intel_engine_cs.c | 13 +
> > drivers/gpu/drm/i915/intel_pm.c| 27 +--
> > 3 files changed, 33 insertions(+), 15 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >b/drivers/gpu/drm/i915/i915_reg.h
> >index c59c590e45c4..aa354874c2c1 100644
> >--- a/drivers/gpu/drm/i915/i915_reg.h
> >+++ b/drivers/gpu/drm/i915/i915_reg.h
> >@@ -6909,7 +6909,7 @@ enum {
> > # define CHICKEN3_DGMG_DONE_FIX_DISABLE (1 << 2)
> >
> > #define CHICKEN_PAR1_1 _MMIO(0x42080)
> >-#define SKL_RC_HASH_OUTSIDE(1 << 15)
> >+#define SKL_DE_COMPRESSED_HASH_MODE(1 << 15)
> > #define DPA_MASK_VBLANK_SRD(1 << 15)
> > #define FORCE_ARB_IDLE_PLANES (1 << 14)
> > #define SKL_EDP_PSR_FIX_RDWRAP (1 << 3)
> >@@ -6982,6 +6982,7 @@ enum {
> > # define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((1<<10) | (1<<26))
> > # define GEN9_RHWO_OPTIMIZATION_DISABLE (1<<14)
> > #define COMMON_SLICE_CHICKEN2 _MMIO(0x7014)
> >+# define GEN9_PBE_COMPRESSED_HASH_SELECTION (1<<13)
> > # define GEN9_DISABLE_GATHER_AT_SET_SHADER_COMMON_SLICE (1<<12)
> > # define GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION (1<<8)
> > # define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE (1<<0)
> >@@ -8071,6 +8072,7 @@ enum {
> > #define GEN8_SAMPLER_POWER_BYPASS_DIS (1<<1)
> >
> > #define GEN9_HALF_SLICE_CHICKEN7_MMIO(0xe194)
> >+#define GEN9_SAMPLER_HASH_COMPRESSED_READ_ADDR(1<<8)
> > #define GEN9_ENABLE_YV12_BUGFIX (1<<4)
> > #define GEN9_ENABLE_GPGPU_PREEMPTION (1<<2)
> >
> >@@ -9371,4 +9373,8 @@ enum skl_power_gate {
> > #define GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL 0x67F1427F /*"
> > " */
> > #define GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT 0x5FF101FF /*"
> > " */
> >
> >+#define MMCD_MISC_CTRL _MMIO(0x4ddc) /* skl+ */
> >+#define MMCD_PCLA (1 << 31)
> >+#define MMCD_HOTSPOT_EN(1 << 27)
> >+
> > #endif /* _I915_REG_H_ */
> >diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> >b/drivers/gpu/drm/i915/intel_engine_cs.c
> >index a6ac9d0a4156..61d9d79452c4 100644
> >--- a/drivers/gpu/drm/i915/intel_engine_cs.c
> >+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> >@@ -812,6 +812,19 @@ static int gen9_init_workarounds(struct intel_engine_cs
> >*engine)
> > I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> >ECOCHK_DIS_TLB);
> >
> >+if (HAS_LLC(dev_priv)) {
> >+/* WaCompressedResourceSamplerPbeMediaNewHashMode:skl,kbl
> >+ *
> >+ * Must match Display Engine. See
> >+ * WaCompressedResourceDisplayNewHashMode.
> >+ */
> >+WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
> >+ GEN9_PBE_COMPRESSED_HASH_SELECTION);
> >+WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
> >+ GEN9_SAMPLER_HASH_COMPRESSED_READ_ADDR);
> >+WA_SET_BIT(MMCD_MISC_CTRL, MMCD_PCLA | MMCD_HOTSPOT_EN);
> >+}
> >+
> > /* WaClearFlowControlGpgpuContextSave:skl,bxt,kbl,glk,cfl */
> > /* WaDisablePartialInstShootdown:skl,bxt,kbl,glk,cfl */
> > WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
> >diff --git a/drivers/gpu/drm/i915/intel_pm.c
> >b/drivers/gpu/drm/i915/intel_pm.c
> >index d5ff0b9f999f..45be01ce8e68 100644
> >--- a/drivers/gpu/drm/i915/intel_pm.c
> >+++ b/drivers/gpu/drm/i915/intel_pm.c
> >@@ -58,24 +58,23 @@
> >
> > static void gen9_init_clock_gating(struct drm_i915_private *dev_priv)
> > {
> >+if (HAS_LLC(dev_priv)) {
> >+/*
> >+ * WaCompressedResourceDisplayNewHashMode:skl,kbl
> >+ * Display WA#0390: skl,kbl
> >+ *
> >+ * Must match Sampler, Pixel Back End, and Media. See
> >+ * WaCompressedResourceSamplerPbeMediaNewHashMode.
> >+ */
> >+I915_WRITE(CHICKEN_PAR1_1,
> >+ I915_READ(CHICKEN_PAR1_1) |
> >+ SKL_DE_COMPRESSED_HASH_MODE);
> >+}
> >+
[Intel-gfx] ✗ Fi.CI.IGT: failure for Add retries for dp dual mode reads (rev3)
== Series Details == Series: Add retries for dp dual mode reads (rev3) URL : https://patchwork.freedesktop.org/series/29155/ State : failure == Summary == Test kms_flip: Subgroup flip-vs-expired-vblank-interruptible: pass -> FAIL (shard-hsw) Test kms_sysfs_edid_timing: pass -> WARN (shard-hsw) fdo#100047 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-hswtotal:2230 pass:1229 dwarn:0 dfail:0 fail:19 skip:981 time:9744s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5492/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/12] drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites
On Fri, Aug 25, 2017 at 10:40:28AM +0100, Daniel Stone wrote: > On 24 August 2017 at 20:10, wrote: > > Y/Yf somehow dropped out from the SKL+ sprite modifier list. Add them > > in. > > There's no 'somehow': > https://lists.freedesktop.org/archives/intel-gfx/2017-August/134932.html > > I would prefer to not see this pushed whilst it doesn't actually work. Works fine here. Well, I should say it works just as well as it does for the primary plane. There are no plane specific checks in the wm/ddb code IIRC so if something is broken for sprites then it's most likely equally broken for the primary plane. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Fixing make install
== Series Details == Series: Fixing make install URL : https://patchwork.freedesktop.org/series/29338/ State : success == Summary == IGT patchset tested on top of latest successful build 29d488034a50cd6fbad792cae61321995f0ab51c aubdump: Log some information about the execbuf calls with latest DRM-Tip kernel build CI_DRM_3001 068cd5b2db68 drm-tip: 2017y-08m-24d-22h-49m-38s UTC integration manifest Test gem_ringfill: Subgroup basic-default-hang: incomplete -> DMESG-WARN (fi-pnv-d510) fdo#101600 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 +1 Test prime_vgem: Subgroup basic-fence-flip: incomplete -> SKIP (fi-kbl-7560u) fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:451s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:441s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:364s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:554s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:252s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:518s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:526s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:514s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:442s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:612s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:442s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:423s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:428s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:500s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:482s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:600s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:601s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:524s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:472s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:487s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:485s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:442s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:482s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:555s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:406s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_98/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_fence_thresh: Use streaming reads for verify
== Series Details == Series: igt/gem_fence_thresh: Use streaming reads for verify URL : https://patchwork.freedesktop.org/series/29208/ State : success == Summary == IGT patchset tested on top of latest successful build 29d488034a50cd6fbad792cae61321995f0ab51c aubdump: Log some information about the execbuf calls with latest DRM-Tip kernel build CI_DRM_3001 068cd5b2db68 drm-tip: 2017y-08m-24d-22h-49m-38s UTC integration manifest Test gem_ringfill: Subgroup basic-default-hang: dmesg-warn -> INCOMPLETE (fi-blb-e6850) fdo#101600 +1 Test prime_vgem: Subgroup basic-fence-flip: incomplete -> SKIP (fi-kbl-7560u) fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:456s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:443s fi-blb-e6850 total:147 pass:114 dwarn:0 dfail:0 fail:0 skip:32 fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:557s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:251s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:522s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:521s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:516s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:441s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:609s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:446s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:425s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:424s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:504s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:479s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:601s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:599s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:524s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:470s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:491s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:490s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:443s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:484s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:547s fi-snb-2600 total:279 pass:248 dwarn:0 dfail:0 fail:2 skip:29 time:407s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_97/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for igt/kms_hdmi_inject: Require /proc/asound before asserting
== Series Details == Series: igt/kms_hdmi_inject: Require /proc/asound before asserting URL : https://patchwork.freedesktop.org/series/29217/ State : success == Summary == IGT patchset tested on top of latest successful build 29d488034a50cd6fbad792cae61321995f0ab51c aubdump: Log some information about the execbuf calls with latest DRM-Tip kernel build CI_DRM_3001 068cd5b2db68 drm-tip: 2017y-08m-24d-22h-49m-38s UTC integration manifest Test gem_ringfill: Subgroup basic-default-hang: incomplete -> DMESG-WARN (fi-pnv-d510) fdo#101600 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 +1 Test prime_vgem: Subgroup basic-fence-flip: incomplete -> SKIP (fi-kbl-7560u) fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:456s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:362s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:572s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:252s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:523s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:531s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:522s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:431s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:609s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:447s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:431s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:427s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:501s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:472s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:481s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:599s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:599s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:523s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:470s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:480s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:495s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:479s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:553s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:408s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_96/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s
Quoting Marta Lofstedt (2017-08-25 11:40:29)
> From: "Lofstedt, Marta"
>
> The subtests: igt@kms_frontbuffer_tracking@fbc-*draw*
> has non-consistent results, pending between fail and pass.
> The fails are always due to "FBC disabled".
> With this increase in timeout the flip-flop behavior is no
> longer reproducible.
>
> This is a partial revert of:
> 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54,
> where the timeout was decreased from 5s to 2s.
> After investigating the timeout needed, the conclusion is that
> the longer timeout is only needed when the test swaps between
> some specific draw domains, typically blt vs. mmap_cpu.
> The objective of the FBC part of the tests is not to benchmark
> draw domain changes, it is to check that FBC was (re-)enabled.
>
> V2: Added documentation
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623
> Signed-off-by: Marta Lofstedt
> Acked-by: Paulo Zanoni
> ---
> tests/kms_frontbuffer_tracking.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/kms_frontbuffer_tracking.c
> b/tests/kms_frontbuffer_tracking.c
> index e03524f1..2538450c 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -924,7 +924,7 @@ static bool fbc_stride_not_supported(void)
>
> static bool fbc_wait_until_enabled(void)
> {
Try igt_drop_caches_set(device, DROP_RETIRE); instead of relaxing the
timeout.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: "Race-to-idle" on switching to the kernel context
On Wed, Aug 23, 2017 at 04:03:44PM +0100, Chris Wilson wrote: > Quoting David Weinehall (2017-08-23 15:54:13) > > On Fri, Aug 18, 2017 at 03:08:15PM +0100, Chris Wilson wrote: > > > During suspend we want to flush out all active contexts and their > > > rendering. To do so we queue a request from the kernel's context, once > > > we know that request is done, we know the GPU is completely idle. To > > > speed up that switch bump the GPU clocks. > > > > > > Switching to the kernel context prior to idling is also used to enforce > > > a barrier before changing OA properties, and when evicting active > > > rendering from the global GTT. All cases where we do want to > > > race-to-idle. > > > > > > Signed-off-by: Chris Wilson > > > Cc: David Weinehall > > > > No statistically significant speedup on suspend in our typical > > benchmark, but that one doesn't take into account systems in load--it > > suspends from idle, and from the description it seems that this patch > > would mostly affect systems with load. > > In terms of everything else, I doubt we ever are significantly waiting > for the GPU upon suspend, the user interface would finish showing its > "going to suspend" screen before starting the suspend, so its only going > to be background tasks still rendering to the gpu oblivious of the > incoming suspend. Rare -- I'm going to squirrel this patch away until we > have a need for it. I suspect that the most common use-case for suspend is laptops, triggered by the user closing the lid; ""going to suspend" screens are gonna go unseen by most users. > Thanks for the review and testing, and if you do come across a workload > which could benefit do let me know. It may well be that userspace isn't > as smart as I expect... I think the main reason that I didn't see much improvement in our benchmarks is the way we measure suspend times; to be able to get numbers that are comparable night after night we "normalise" the load by running a non-measured suspend/resume right before the one we actually measure. This means that by the time we benchmark we have already performed the flushing that your patch achieves, so the benefits of your patch wouldn't be visible. With your patch we get more stable results already on the first run, so there definitely is a benefit. Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s
On 08/25/2017 01:40 PM, Marta Lofstedt wrote: After investigating the timeout needed, the conclusion is that the longer timeout is only needed when the test swaps between some specific draw domains, typically blt vs. mmap_cpu. The objective of the FBC part of the tests is not to benchmark draw domain changes, it is to check that FBC was (re-)enabled. Can this explanation be added to the code as a comment too? -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/20] drm/i915: "Race-to-idle" on switching to the kernel context
== Series Details == Series: series starting with [01/20] drm/i915: "Race-to-idle" on switching to the kernel context URL : https://patchwork.freedesktop.org/series/29201/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CHK scripts/mod/devicetable-offsets.h CHK include/generated/compile.h CHK kernel/config_data.h CC [M] drivers/gpu/drm/i915/i915_gem.o drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_close_object’: drivers/gpu/drm/i915/i915_gem.c:3261:1: error: version control conflict marker in file <<< HEAD ^~~ drivers/gpu/drm/i915/i915_gem.c:3269:1: error: version control conflict marker in file === ^~~ scripts/Makefile.build:302: recipe for target 'drivers/gpu/drm/i915/i915_gem.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_gem.o] Error 1 scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:561: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1019: recipe for target 'drivers' failed make: *** [drivers] Error 2 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5473/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
