[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: don't hardcode DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT

[Patchwork]

== 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)

[Patchwork]

== 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

[Patchwork]

== 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)

[Patchwork]

== 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

[Patchwork]

== 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] drm/i915/cnl: don't hardcode DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT

[Paulo Zanoni]

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

Re: [Intel-gfx] [PATCH v6] drm/i915: Fix FBC cfb stride programming for non X-tiled FB

[Paulo Zanoni]

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 = _priv->fbc;
>   struct intel_fbc_state_cache *cache = >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 

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Mark wait_for_engine() as maybe_unused

[Patchwork]

== 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

[Jason Ekstrand]

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

[Patchwork]

== 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

[Srivatsa, Anusha]

>-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 = _priv->guc;
>>  struct intel_uc_fw *guc_fw = _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()

[Andrew Morton]

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

[Patchwork]

== 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

[Daniele Ceraolo Spurio]

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.

[Rodrigo Vivi]

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 = >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 = >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

[Andrew Morton]

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)

[Patchwork]

== 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

[Patchwork]

== 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

[Patchwork]

== 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

[Rodrigo Vivi]

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

[Paulo Zanoni]

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)

[Patchwork]

== 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

[Rogozhkin, Dmitry V]

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)

[Daniel Vetter]

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

[Patchwork]

== 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

[Intel-gfx] [PATCH igt v2] igt/vgem_basic: Load and unload the module first

[Chris Wilson]

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

[Lyude Paul]

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, , 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

[Chris Wilson]

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)

[Patchwork]

== 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)

[Jason Ekstrand]

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, );
+   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(, 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(, 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, , ) == 0);
+
+memset(, 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, , 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 sigval)

[Intel-gfx] [PATCH i-g-t 4/4] syncobj: Add a test for SYNCOBJ_CREATE_SIGNALED

[Jason Ekstrand]

---
 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, , 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

[Jason Ekstrand]

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, );
-
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_handle_to_fd(fd, ), -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, );
-
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_fd_to_handle(fd, ), -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, );
-
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_fd_to_handle(fd, ), -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, );
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_fd_to_handle(fd, ), -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, );
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_handle_to_fd(fd, ), -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, );
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_handle_to_fd(fd, ), -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, );
-   igt_assert(ret == -1 && errno == EINVAL);
+   igt_assert_eq(__syncobj_fd_to_handle(fd, ), -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, );
-
-   destroy.handle = create.handle;
+   destroy.handle = syncobj_create(fd, 0);
destroy.pad = 0xdeadbeef;
 
ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, );
 
igt_assert(ret == -1 && errno == EINVAL);
 
-   destroy.handle = create.handle;
-   destroy.pad = 0;
-
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_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, );
-   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, );
-   igt_assert(ret == 0);
-   handle.handle = 0;
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_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, );
-   igt_assert(ret == 0);
-
-   destroy.handle = first_handle;
-   ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, );
-   igt_assert(ret == 0);
+   syncobj_destroy(fd, 

[Intel-gfx] [PATCH i-g-t 1/4] lib: Add some syncobj helpers (v2)

[Jason Ekstrand]

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, ))
+   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, , 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, ))
+   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, ), 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, ), 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, ), 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_wait(fd, );
+}

[Intel-gfx] ✓ Fi.CI.BAT: success for lib/kmod: Fix error reporting for kmod load/unload

[Patchwork]

== 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

[Patchwork]

== 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)

[Patchwork]

== 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)

[Chris Wilson]

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

[Chris Wilson]

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

[Patchwork]

== 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

[Daniel Vetter]

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 = _priv->drm.vblank[crtc->pipe];
>  
>   if (drm_crtc_vblank_get(>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(>lock);
>   work->scheduled = false;
>   mutex_unlock(>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

[Daniel Vetter]

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, 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

[Daniel Vetter]

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)

[Daniel Vetter]

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

[Matthias Kaehlcke]

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

[Srivatsa, Anusha]

>-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 = _priv->guc;
>>  struct intel_uc_fw *guc_fw = _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

[Oscar Mateo]

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

[Patchwork]

== 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()

[Emil Velikov]

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

[Patchwork]

== 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

[Paul Kocialkowski]

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

[Paul Kocialkowski]

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 

[Intel-gfx] [PATCH i-g-t 3/3] docs: Add user documentation about audio support

[Paul Kocialkowski]

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

[Oscar Mateo]

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 = _priv->guc;
struct intel_uc_fw *guc_fw = _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)

[Patchwork]

== 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

[Ville Syrjälä]

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

[Chris Wilson]

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 = _priv->drm.vblank[crtc->pipe];
 
if (drm_crtc_vblank_get(>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(>lock);
work->scheduled = false;
mutex_unlock(>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

[Hans de Goede]

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 =
_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(>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(>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 = 

[Intel-gfx] [PATCH v4 0/1] drm/i915: Deal with upside-down mounted LCD panels

[Hans de Goede]

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

[Patchwork]

== 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

[Ville Syrjälä]

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

[Jani Nikula]

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

[Jani Nikula]

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 = >power_seqs[panel_type];
-   edp_link_params = >link_params[panel_type];
+   edp_link_params = >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

[Jani Nikula]

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

[Jani Nikula]

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

[Jani Nikula]

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

[Jani Nikula]

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

[Patchwork]

== 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

[Daniel Stone]

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

[Jani Nikula]

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

[Daniel Vetter]

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,
> -  _name));
> +  _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,
> -   
> _name));
> +   _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;

Re: [Intel-gfx] [PATCH 10/12] drm: Fix modifiers_property kernel doc

[Daniel Vetter]

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

[Lofstedt, Marta]

+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

[Patchwork]

== 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

[Chris Wilson]

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.

[Ville Syrjälä]

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 = >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 = >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.

[Ville Syrjälä]

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(>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

[Wang, Zhi A]

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

[Lofstedt, Marta]

> -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.

[Ville Syrjälä]

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 = >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 = >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

[Patchwork]

== 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

[Ville Syrjälä]

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

[Michal Wajdeczko]

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 = _priv->guc;
>   struct intel_uc_fw *guc_fw = _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

[Patchwork]

== 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)

[Patchwork]

== 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

[Paul Kocialkowski]

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

[Paul Kocialkowski]

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, , 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

[Ville Syrjälä]

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

[Lofstedt, Marta]

> -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

[Gerd Hoffmann]

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

[Ville Syrjälä]

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,

[Intel-gfx] ✗ Fi.CI.IGT: failure for Add retries for dp dual mode reads (rev3)

[Patchwork]

== 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

[Ville Syrjälä]

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

[Patchwork]

== 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

[Patchwork]

== 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

[Patchwork]

== 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

[Chris Wilson]

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

[David Weinehall]

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

[Petri Latvala]

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

[Patchwork]

== 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

[Intel-gfx] ✓ Fi.CI.BAT: success for Add retries for dp dual mode reads (rev3)

[Patchwork]

== Series Details ==

Series: Add retries for dp dual mode reads (rev3)
URL   : https://patchwork.freedesktop.org/series/29155/
State : success

== Summary ==

Series 29155v3 Add retries for dp dual mode reads
https://patchwork.freedesktop.org/api/1.0/series/29155/revisions/3/mbox/

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
Test kms_flip:
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-x1585l) fdo#101781
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
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:464s
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:360s
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:252s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:516s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:532s
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:446s
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:450s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:430s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:425s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:551s
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:477s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:606s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:626s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:520s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:479s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:489s
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:452s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:509s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:561s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:414s

068cd5b2db68ecd9f52d4d7c66e6e9e71d33ab0d drm-tip: 2017y-08m-24d-22h-49m-38s UTC 
integration manifest
eb69a22cba81 drm/i915: Don't give up waiting on INVALID_MODE
19d161de2e01 drm: Add retries for dp dual mode read

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5492/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx