Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/guc: Fix request re-submission after reset

[Tvrtko Ursulin]

On 09/03/2017 20:55, Chris Wilson wrote:

On Thu, Mar 09, 2017 at 04:47:52PM -, Patchwork wrote:

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/guc: Fix request re-submission 
after reset
URL   : https://patchwork.freedesktop.org/series/20991/
State : success

== Summary ==

Series 20991v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20991/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
incomplete -> PASS   (fi-skl-6700k) fdo#100130


Wait... Did that just fix the bxt fails! My hero! :)


It was the team effort I think since you found it while testing the 
scheduler support.


Pushed now, thanks for the review!

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Fix forcewake active domain tracking

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

In commit 003342a50021 ("drm/i915: Keep track of active
forcewake domains in a bitmask") I forgot to adjust the
newly introduce fw_domains_active state across reset.

This caused the assert_forcewakes_inactive to trigger
during suspend and resume if there were user held
forcewakes.

v2: Bitmask checks are required since vfuncs are not
always present.

Signed-off-by: Tvrtko Ursulin 
Fixes: 003342a50021 ("drm/i915: Keep track of active forcewake domains in a 
bitmask")
Testcase: igt/drv_suspend/forcewake
Cc: Tvrtko Ursulin 
Cc: "Paneri, Praveen" 
Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx@lists.freedesktop.org
Cc: v4.10+ 
---
 drivers/gpu/drm/i915/intel_uncore.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 2a3f35c30501..7efae77faca0 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -304,12 +304,14 @@ static void intel_uncore_forcewake_reset(struct 
drm_i915_private *dev_priv,
fw = dev_priv->uncore.fw_domains_active;
if (fw)
dev_priv->uncore.funcs.force_wake_put(dev_priv, fw);
+   dev_priv->uncore.fw_domains_active = 0;
 
fw_domains_reset(dev_priv, FORCEWAKE_ALL);
 
if (restore) { /* If reset with a user forcewake, try to restore */
if (fw)
dev_priv->uncore.funcs.force_wake_get(dev_priv, fw);
+   dev_priv->uncore.fw_domains_active = fw;
 
if (IS_GEN6(dev_priv) || IS_GEN7(dev_priv))
dev_priv->uncore.fifo_count =
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm: Add DPCD definitions for DP 1.4 DSC feature

[Manasi Navare]

On Wed, Feb 22, 2017 at 10:23:18AM +0200, Jani Nikula wrote:
> 
> [Your MUA messed up the quoting, FTFY below.]
> 
> On Wed, 22 Feb 2017, "Navare, Manasi D"  wrote:
> > > On Fri, 17 Feb 2017, Manasi Navare  wrote:
> > >> Display stream compression is supported on DP 1.4 DP devices. This 
> > >> patch adds the corersponding DPCD register definitions for DSC.
> > >>
> > >> v2:
> > >> * Rebased on drm-tip
> > >>
> > >> Signed-off-by: Manasi Navare 
> > >> Cc: Jani Nikula 
> > >> Cc: Paulo Zanoni 
> > >> Cc: dri-de...@lists.freedesktop.org
> > >
> > > Tedious work to cross check this stuff against the spec... found one
> > > real issue; while at it please fix a few nitpicks that I would
> > > otherwise have ignored.
> > >
> > > BR,
> > > Jani.
> > >
> > >
> > >> ---
> > >>  include/drm/drm_dp_helper.h | 102 
> > >> 
> > >>  1 file changed, 102 insertions(+)
> > >>
> > >> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h 
> > >> index ba89295..4c1fc26 100644
> > >> --- a/include/drm/drm_dp_helper.h
> > >> +++ b/include/drm/drm_dp_helper.h
> > >> @@ -179,6 +179,108 @@
> > >>  
> > >>  #define DP_GUID 0x030   /* 1.2 */
> > >>  
> > >> +#define DP_DSC_SUPPORT  0x060   /* DP 1.4 */
> > >> +# define DP_DSC_DECOMPRESSION_IS_SUPPORTED  (1 << 0)
> > >> +
> > >> +#define DP_DSC_REV  0x061
> > >> +# define DP_DSC_MAJOR_MASK  (15 << 0)
> > >> +# define DP_DSC_MINOR_MASK  (15 << 4)
> > >> +# define DP_DSC_MINOR_SHIFT 4
> > >
> > > Nitpick: Hex is preferred for masks. Same for all masks
> > > below. MAJOR_SHIFT for completeness.
> > >
> > So should I add the MAJOR_SHIFT as well even though it will just 0?
> 
> Yes, 0 is not special here. Having it is also self-documenting, so you
> don't have to look up the DP spec to check.
> 
> > >
> > >
> > >> +
> > >> +#define DP_DSC_RC_BUF_BLK_SIZE  0x062
> > >> +# define DP_DSC_RC_BUF_BLK_SIZE_1   0x0
> > >> +# define DP_DSC_RC_BUF_BLK_SIZE_4   0x1
> > >> +# define DP_DSC_RC_BUF_BLK_SIZE_16  0x2
> > >> +# define DP_DSC_RC_BUF_BLK_SIZE_64  0x3
> > >> +
> > >> +#define DP_DSC_RC_BUF_SIZE  0x063
> > >> +
> > >> +#define DP_DSC_SLICE_CAP_1  0x064
> > >> +# define DP_DSC_1_PER_DP_DSC_SINK   (1 << 0)
> > >> +# define DP_DSC_2_PER_DP_DSC_SINK   (1 << 1)
> > >> +# define DP_DSC_4_PER_DP_DSC_SINK   (1 << 3)
> > >> +# define DP_DSC_6_PER_DP_DSC_SINK   (1 << 4)
> > >> +# define DP_DSC_8_PER_DP_DSC_SINK   (1 << 5)
> > >> +# define DP_DSC_10_PER_DP_DSC_SINK  (1 << 6)
> > >> +# define DP_DSC_12_PER_DP_DSC_SINK  (1 << 7)
> > >> +
> > >> +#define DP_DSC_LINE_BUF_BIT_DEPTH   0x065
> > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_MASK (15 << 0)
> > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_90x0
> > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_10   0x1
> > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_11   0x2
> > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_12   0x3
> > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_13   0x4
> > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_14   0x5
> > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_15   0x6
> > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_16   0x7
> > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_80x8
> > >> +
> > >> +#define DP_DSC_BLK_PREDICTION_SUPPORT   0x066
> > >> +# define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0)
> > >> +
> > >> +#define DP_DSC_MAX_BITS_PER_PIXEL_LOW   0x067   /* eDP 1.4 */
> > >> +
> > >> +#define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
> > >> +
> > >> +#define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
> > >> +# define DP_DSC_RGB (1 << 0)
> > >> +# define DP_DSC_YCbCr444(1 << 1)
> > >> +# define DP_DSC_YCbCr422_Simple (1 << 2)
> > >> +# define DP_DSC_YCbCr422_Native (1 << 3)
> > >> +# define DP_DSC_YCbCr420_Native (1 << 4)
> > >> +
> > >> +#define DP_DSC_DEC_COLOR_DEPTH_CAP  0x06A
> > >> +# define DP_DSC_8_BPC   (1 << 1)
> > >> +# define DP_DSC_10_BPC  (1 << 2)
> > >> +# define DP_DSC_12_BPC  (1 >> 3)
> > >
> > > Oops, shifting to wrong direction!
> >
> > Oops, yes that is my mistake, I will fix the shift direction.
> >
> > >> +
> > >> +#define DP_DSC_PEAK_THROUGHPUT  0x06B
> > >> +# define DP_DSC_THROUGHPUT_MODE_0_340   0x1
> > >> +# define DP_DSC_THROUGHPUT_MODE_0_400   0x2
> > >> +# define DP_DSC_THROUGHPUT_MODE_0_450   0x3
> > >> +# define DP_DSC_THROUGHPUT_MODE_0_500   0x4
> > >> +# define DP_DSC_THROUGHPUT_MODE_0_550   0x5
> > >> +# define DP_DSC_THROUGHPUT_MODE_0_600   0x6

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix vGPU balloon for ggtt guard page (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix vGPU balloon for ggtt guard page (rev2)
URL   : https://patchwork.freedesktop.org/series/20983/
State : success

== Summary ==

Series 20983v2 drm/i915: Fix vGPU balloon for ggtt guard page
https://patchwork.freedesktop.org/api/1.0/series/20983/revisions/2/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
incomplete -> PASS   (fi-skl-6700hq) fdo#100130

fdo#100130 https://bugs.freedesktop.org/show_bug.cgi?id=100130

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 463s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 608s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 534s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 605s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 439s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 494s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 480s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 505s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 592s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 504s

efa9a3649bd94a4f35911aaecc723e041d8b99c5 drm-tip: 2017y-03m-09d-21h-28m-20s UTC 
integration manifest
041cc98 drm/i915: Fix vGPU balloon for ggtt guard page

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4129/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Fix vGPU balloon for ggtt guard page

[Zhenyu Wang]

From commit a6508ded2a66 ("drm/i915: Use page coloring to provide the guard
page at the end of the GTT"), we no longer explicitly subtract guard page
at end for GGTT address space init, so shouldn't subtract that for vGPU
balloon too, as that will leave that end page to be available for
vGPU. Change balloon to cover full range too.

This fixes to use recent drm-intel tip kernel for guest OS. Found by GVT-g
cmd parser that guest kernel uses end page as scratch then try to run
MI_STORE_REG_MEM onto it.

v2: remove old comments

Cc: Terrence Xu 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/i915_vgpu.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 14014068dfcf..4ab8a973b61f 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -218,13 +218,9 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
goto err;
}
 
-   /*
-* No need to partition out the last physical page,
-* because it is reserved to the guard page.
-*/
-   if (unmappable_end < ggtt_end - PAGE_SIZE) {
+   if (unmappable_end < ggtt_end) {
ret = vgt_balloon_space(ggtt, _info.space[3],
-   unmappable_end, ggtt_end - PAGE_SIZE);
+   unmappable_end, ggtt_end);
if (ret)
goto err;
}
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Wait for reset to complete before returning from debugfs/i915_wedged

[Patchwork]

== Series Details ==

Series: drm/i915: Wait for reset to complete before returning from 
debugfs/i915_wedged
URL   : https://patchwork.freedesktop.org/series/21030/
State : success

== Summary ==

Series 21030v1 drm/i915: Wait for reset to complete before returning from 
debugfs/i915_wedged
https://patchwork.freedesktop.org/api/1.0/series/21030/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
incomplete -> PASS   (fi-skl-6700hq) fdo#100130

fdo#100130 https://bugs.freedesktop.org/show_bug.cgi?id=100130

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 466s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 607s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 517s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 610s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 443s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 488s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 476s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 515s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 597s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 500s

efa9a3649bd94a4f35911aaecc723e041d8b99c5 drm-tip: 2017y-03m-09d-21h-28m-20s UTC 
integration manifest
c8c4141 drm/i915: Wait for reset to complete before returning from 
debugfs/i915_wedged

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4128/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Wait for reset to complete before returning from debugfs/i915_wedged

[Chris Wilson]

Provide some serialisation between user operations by waiting for the
reset initiated by setting i915_wedged to complete.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 115433d46477..a1eccf2ef313 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4138,6 +4138,10 @@ i915_wedged_set(void *data, u64 val)
i915_handle_error(dev_priv, val,
  "Manually setting wedged to %llu", val);
 
+   wait_on_bit(_priv->gpu_error.flags,
+   I915_RESET_IN_PROGRESS,
+   TASK_UNINTERRUPTIBLE);
+
return 0;
 }
 
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Forward declare struct platform_device

[Chris Wilson]

On Fri, Mar 10, 2017 at 12:41:30AM +, Emil Velikov wrote:
> On 9 March 2017 at 22:46, Chris Wilson  wrote:
> > ./include/drm/drm_pci.h:76:64: warning: ‘struct platform_device’ declared 
> > inside parameter list will not be visible outside of this definition or 
> > declaration
> >  extern int drm_platform_init(struct drm_driver *driver, struct 
> > platform_device *platform_device);
> >
> > Fixes: 23ef59ef6dcc ("drm: Extract drm_pci.h")
> > Signed-off-by: Chris Wilson 
> > Cc: Gustavo Padovan 
> > Cc: Daniel Vetter 
> > ---
> >  include/drm/drm_pci.h | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/drm/drm_pci.h b/include/drm/drm_pci.h
> > index 5081b3eba309..9cd2173fc892 100644
> > --- a/include/drm/drm_pci.h
> > +++ b/include/drm/drm_pci.h
> > @@ -73,6 +73,8 @@ extern int drm_pcie_get_speed_cap_mask(struct drm_device 
> > *dev, u32 *speed_mask);
> >  extern int drm_pcie_get_max_link_width(struct drm_device *dev, u32 *mlw);
> >
> >  /* platform section */
> > -extern int drm_platform_init(struct drm_driver *driver, struct 
> > platform_device *platform_device);
> > +struct platform_device;
> > +extern int drm_platform_init(struct drm_driver *driver,
> > +struct platform_device *platform_device);
> >
> I wouldn't bother with the re-wrap, but regardless
> Reviewed-by: Emil Velikov 

Step by step we become checkpatch clean.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move whole object to CPU domain for coherent shmem access

[Patchwork]

== Series Details ==

Series: drm/i915: Move whole object to CPU domain for coherent shmem access
URL   : https://patchwork.freedesktop.org/series/21020/
State : failure

== Summary ==

Series 21020v1 drm/i915: Move whole object to CPU domain for coherent shmem 
access
https://patchwork.freedesktop.org/api/1.0/series/21020/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-wb-pro-default:
pass   -> INCOMPLETE (fi-bxt-t5700)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 463s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 603s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 540s
fi-bxt-t5700 total:58   pass:50   dwarn:0   dfail:0   fail:0   skip:7   
time: 0s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 439s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 490s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 475s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 510s
fi-skl-6700hqtotal:51   pass:43   dwarn:0   dfail:0   fail:0   skip:7   
time: 0s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 508s

efa9a3649bd94a4f35911aaecc723e041d8b99c5 drm-tip: 2017y-03m-09d-21h-28m-20s UTC 
integration manifest
90a0145 drm/i915: Move whole object to CPU domain for coherent shmem access

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4127/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Forward declare struct platform_device

[Emil Velikov]

On 9 March 2017 at 22:46, Chris Wilson  wrote:
> ./include/drm/drm_pci.h:76:64: warning: ‘struct platform_device’ declared 
> inside parameter list will not be visible outside of this definition or 
> declaration
>  extern int drm_platform_init(struct drm_driver *driver, struct 
> platform_device *platform_device);
>
> Fixes: 23ef59ef6dcc ("drm: Extract drm_pci.h")
> Signed-off-by: Chris Wilson 
> Cc: Gustavo Padovan 
> Cc: Daniel Vetter 
> ---
>  include/drm/drm_pci.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_pci.h b/include/drm/drm_pci.h
> index 5081b3eba309..9cd2173fc892 100644
> --- a/include/drm/drm_pci.h
> +++ b/include/drm/drm_pci.h
> @@ -73,6 +73,8 @@ extern int drm_pcie_get_speed_cap_mask(struct drm_device 
> *dev, u32 *speed_mask);
>  extern int drm_pcie_get_max_link_width(struct drm_device *dev, u32 *mlw);
>
>  /* platform section */
> -extern int drm_platform_init(struct drm_driver *driver, struct 
> platform_device *platform_device);
> +struct platform_device;
> +extern int drm_platform_init(struct drm_driver *driver,
> +struct platform_device *platform_device);
>
I wouldn't bother with the re-wrap, but regardless
Reviewed-by: Emil Velikov 

-Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Move whole object to CPU domain for coherent shmem access

[Chris Wilson]

If the object is coherent, we can simply update the cache domain on the
whole object rather than calculate the before/after clflushes. The
advantage is that we then get correct tracking of ellided flushes when
changing coherency later.

Testcase: igt/gem_pwrite_snooped
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h |  6 +++---
 drivers/gpu/drm/i915/i915_gem.c | 45 +
 2 files changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3002996ddbed..8de104b63209 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3353,9 +3353,9 @@ int i915_gem_obj_prepare_shmem_read(struct 
drm_i915_gem_object *obj,
unsigned int *needs_clflush);
 int i915_gem_obj_prepare_shmem_write(struct drm_i915_gem_object *obj,
 unsigned int *needs_clflush);
-#define CLFLUSH_BEFORE 0x1
-#define CLFLUSH_AFTER 0x2
-#define CLFLUSH_FLAGS (CLFLUSH_BEFORE | CLFLUSH_AFTER)
+#define CLFLUSH_BEFORE BIT(0)
+#define CLFLUSH_AFTER  BIT(1)
+#define CLFLUSH_FLAGS  (CLFLUSH_BEFORE | CLFLUSH_AFTER)
 
 static inline void
 i915_gem_obj_finish_shmem_access(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index aca1eaddafb4..202bb850f260 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -788,6 +788,15 @@ int i915_gem_obj_prepare_shmem_read(struct 
drm_i915_gem_object *obj,
if (ret)
return ret;
 
+   if (i915_gem_object_is_coherent(obj) ||
+   !static_cpu_has(X86_FEATURE_CLFLUSH)) {
+   ret = i915_gem_object_set_to_cpu_domain(obj, false);
+   if (ret)
+   goto err_unpin;
+   else
+   goto out;
+   }
+
i915_gem_object_flush_gtt_write_domain(obj);
 
/* If we're not in the cpu read domain, set ourself into the gtt
@@ -796,16 +805,9 @@ int i915_gem_obj_prepare_shmem_read(struct 
drm_i915_gem_object *obj,
 * anyway again before the next pread happens.
 */
if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU))
-   *needs_clflush = !i915_gem_object_is_coherent(obj);
-
-   if (*needs_clflush && !static_cpu_has(X86_FEATURE_CLFLUSH)) {
-   ret = i915_gem_object_set_to_cpu_domain(obj, false);
-   if (ret)
-   goto err_unpin;
-
-   *needs_clflush = 0;
-   }
+   *needs_clflush = CLFLUSH_BEFORE;
 
+out:
/* return with the pages pinned */
return 0;
 
@@ -838,6 +840,15 @@ int i915_gem_obj_prepare_shmem_write(struct 
drm_i915_gem_object *obj,
if (ret)
return ret;
 
+   if (i915_gem_object_is_coherent(obj) ||
+   !static_cpu_has(X86_FEATURE_CLFLUSH)) {
+   ret = i915_gem_object_set_to_cpu_domain(obj, true);
+   if (ret)
+   goto err_unpin;
+   else
+   goto out;
+   }
+
i915_gem_object_flush_gtt_write_domain(obj);
 
/* If we're not in the cpu write domain, set ourself into the
@@ -846,25 +857,15 @@ int i915_gem_obj_prepare_shmem_write(struct 
drm_i915_gem_object *obj,
 * right away and we therefore have to clflush anyway.
 */
if (obj->base.write_domain != I915_GEM_DOMAIN_CPU)
-   *needs_clflush |= cpu_write_needs_clflush(obj) << 1;
+   *needs_clflush |= CLFLUSH_AFTER;
 
/* Same trick applies to invalidate partially written cachelines read
 * before writing.
 */
if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU))
-   *needs_clflush |= !i915_gem_object_is_coherent(obj);
-
-   if (*needs_clflush && !static_cpu_has(X86_FEATURE_CLFLUSH)) {
-   ret = i915_gem_object_set_to_cpu_domain(obj, true);
-   if (ret)
-   goto err_unpin;
-
-   *needs_clflush = 0;
-   }
-
-   if ((*needs_clflush & CLFLUSH_AFTER) == 0)
-   obj->cache_dirty = true;
+   *needs_clflush |= CLFLUSH_BEFORE;
 
+out:
intel_fb_obj_invalidate(obj, ORIGIN_CPU);
obj->mm.dirty = true;
/* return with the pages pinned */
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: build warning after merge of the drm-misc tree

[Stephen Rothwell]

Hi all,

After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

In file included from drivers/gpu/drm/drm_pci.c:29:0:
include/drm/drm_pci.h:76:64: warning: 'struct platform_device' declared inside 
parameter list
 extern int drm_platform_init(struct drm_driver *driver, struct platform_device 
*platform_device);
^
include/drm/drm_pci.h:76:64: warning: its scope is only this definition or 
declaration, which is probably not what you want

Introduced by commit

  23ef59ef6dcc ("drm: Extract drm_pci.h")

A forgotten include file (or maybe just a forward declaration of the struct).

-- 
Cheers,
Stephen Rothwell
___
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: Forward declare struct platform_device

[Patchwork]

== Series Details ==

Series: drm: Forward declare struct platform_device
URL   : https://patchwork.freedesktop.org/series/21017/
State : success

== Summary ==

Series 21017v1 drm: Forward declare struct platform_device
https://patchwork.freedesktop.org/api/1.0/series/21017/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 471s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 614s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 540s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 598s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 486s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 481s
fi-skl-6700hqtotal:51   pass:43   dwarn:0   dfail:0   fail:0   skip:7   
time: 0s
fi-ilk-650 failed to collect. IGT log at Patchwork_4126/fi-ilk-650/igt.log
fi-skl-6260u failed to collect. IGT log at Patchwork_4126/fi-skl-6260u/igt.log
fi-skl-6700k failed to collect. IGT log at Patchwork_4126/fi-skl-6700k/igt.log

efa9a3649bd94a4f35911aaecc723e041d8b99c5 drm-tip: 2017y-03m-09d-21h-28m-20s UTC 
integration manifest
4ad9d9a drm: Forward declare struct platform_device

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4126/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm: Forward declare struct platform_device

[Chris Wilson]

./include/drm/drm_pci.h:76:64: warning: ‘struct platform_device’ declared 
inside parameter list will not be visible outside of this definition or 
declaration
 extern int drm_platform_init(struct drm_driver *driver, struct platform_device 
*platform_device);

Fixes: 23ef59ef6dcc ("drm: Extract drm_pci.h")
Signed-off-by: Chris Wilson 
Cc: Gustavo Padovan 
Cc: Daniel Vetter 
---
 include/drm/drm_pci.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_pci.h b/include/drm/drm_pci.h
index 5081b3eba309..9cd2173fc892 100644
--- a/include/drm/drm_pci.h
+++ b/include/drm/drm_pci.h
@@ -73,6 +73,8 @@ extern int drm_pcie_get_speed_cap_mask(struct drm_device 
*dev, u32 *speed_mask);
 extern int drm_pcie_get_max_link_width(struct drm_device *dev, u32 *mlw);
 
 /* platform section */
-extern int drm_platform_init(struct drm_driver *driver, struct platform_device 
*platform_device);
+struct platform_device;
+extern int drm_platform_init(struct drm_driver *driver,
+struct platform_device *platform_device);
 
 #endif /* _DRM_PCI_H_ */
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3] drm/i915: Stop using RP_DOWN_EI on Baytrail (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v3] drm/i915: Stop using RP_DOWN_EI on Baytrail 
(rev2)
URL   : https://patchwork.freedesktop.org/series/20314/
State : success

== Summary ==

Series 20314v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20314/revisions/2/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
incomplete -> PASS   (fi-skl-6700hq) fdo#100130

fdo#100130 https://bugs.freedesktop.org/show_bug.cgi?id=100130

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 458s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 610s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 534s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 607s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 438s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 492s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 484s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 523s
fi-skl-6700hqtotal:55   pass:47   dwarn:0   dfail:0   fail:0   skip:7   
time: 0s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 496s

efa9a3649bd94a4f35911aaecc723e041d8b99c5 drm-tip: 2017y-03m-09d-21h-28m-20s UTC 
integration manifest
3bf86e1 drm/i915: Defer unmasking RPS interrupts until after making adjustments
2fac975 drm/i915: Stop using RP_DOWN_EI on Baytrail

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4124/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix request re-submission after reset

[Oscar Mateo]

On 03/09/2017 12:54 PM, Chris Wilson wrote:

On Thu, Mar 09, 2017 at 05:02:16PM +, Tvrtko Ursulin wrote:

On 09/03/2017 08:55, Oscar Mateo wrote:

On 03/09/2017 08:50 AM, Tvrtko Ursulin wrote:

On 09/03/2017 08:42, Oscar Mateo wrote:

On 03/09/2017 02:05 AM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

In order to ensure no missed interrupts we must first re-direct
the interrupts to GuC, and only then re-submit the requests to
be replayed after a GPU reset. Otherwise context switch can fire
before GuC has been set up to receive it triggering more hangs.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Mika Kuoppala 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
Cc: Arkadiusz Hiler 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 58
+++---
  drivers/gpu/drm/i915/intel_guc_loader.c| 47

  2 files changed, 54 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index beb38e30d0e9..5b8ec0fab563 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -936,6 +936,52 @@ static void guc_reset_wq(struct i915_guc_client
*client)
  client->wq_tail = 0;
  }




  int i915_guc_submission_enable(struct drm_i915_private *dev_priv)
  {
  struct intel_guc *guc = _priv->guc;
@@ -953,13 +999,17 @@ int i915_guc_submission_enable(struct
drm_i915_private *dev_priv)
/* Take over from manual control of ELSP (execlists) */
  for_each_engine(engine, dev_priv, id) {
-const int wqi_size = sizeof(struct guc_wq_item);
-struct drm_i915_gem_request *rq;
-
  engine->submit_request = i915_guc_submit;
  engine->schedule = NULL;
+}
+
+guc_interrupts_capture(dev_priv);
+
+/* Replay the current set of previously submitted requests */
+for_each_engine(engine, dev_priv, id) {
+const int wqi_size = sizeof(struct guc_wq_item);
+struct drm_i915_gem_request *rq;


Don't you want to move the guc_interrupts_release to
i915_guc_submission_disable as well?

I can't spot anything broken in that path. We never go in that
direction with the live submission so why do you think it is needed?

Regards,

Tvrtko

Just code symmetry: if we are leaving i915_guc_submission_enable to
capture the interrupts, why doesn't the disable also releases them?
Maybe it's not very important now, but it makes a lot more sense with my
series to do proper unwinding of the whole path (I can tackle it there
if you prefer).

I think so. There is a multitude of people trying to refactor the
GuC code at the moment so I would prefer just to fix the reset fail
quickly and not interfere with that wider refactoring too much.
Because I think it is not just a quick job of moving the interrupt
release to get to full symmetry. Ack to merge then?

Exactly, I don't disagree with the desire to make/keep the code
symmetrical, but I also think push the fix and wait for the dust to
settle to fix the otherside, or volunteer somebody...

Just so long as we remember to do it in the short term and not leave
nits to build up.
-Chris


Ok, push the button then. I'll make it symmetrical later.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Ignore skl+ for debugfs/i915_sr_status

[Chris Wilson]

On Thu, Mar 09, 2017 at 04:27:29PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 09, 2017 at 02:20:49PM +, Chris Wilson wrote:
> > There is no easily digestible single self-refresh status bit, so don't
> > report one for debugfs/i915_sr_status.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Ville Syrjälä 
> 
> Reviewed-by: Ville Syrjälä 

Added a bit more bumpfh to justify the change (avoiding the non-existent
reigster) and pushed. Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Optimize VLV/CHV display FIFO updates

[Chris Wilson]

On Thu, Mar 09, 2017 at 05:44:34PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Use I915_{READ,WRITE}_FW() for updating the DSPARB registers on
> VLV/CHV. This is less expesive as we can grab the uncore.lock across
> the entire sequence of reads and writes instead of each register
> access grabbing it.
> 
> This also allows us to eliminate the dsparb lock entirely as the
> uncore.lock now effectively protects the contents of the DSPARB
> registers.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  1 -
>  drivers/gpu/drm/i915/i915_drv.h |  3 ---
>  drivers/gpu/drm/i915/intel_pm.c | 36 +---
>  3 files changed, 21 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index b1e9027a4f80..debb74a2b2a9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -827,7 +827,6 @@ static int i915_driver_init_early(struct drm_i915_private 
> *dev_priv,
>  
>   spin_lock_init(_priv->mm.object_stat_lock);
>   spin_lock_init(_priv->mmio_flip_lock);
> - spin_lock_init(_priv->wm.dsparb_lock);
>   mutex_init(_priv->sb_lock);
>   mutex_init(_priv->modeset_restore_lock);
>   mutex_init(_priv->av_mutex);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3002996ddbed..6af0b1d33cab 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2375,9 +2375,6 @@ struct drm_i915_private {
>   } sagv_status;
>  
>   struct {
> - /* protects DSPARB registers on pre-g4x/vlv/chv */
> - spinlock_t dsparb_lock;
> -
>   /*
>* Raw watermark latency values:
>* in 0.1us units for WM0,
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 99e09f63d4b3..24cdc13a416a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1358,13 +1358,19 @@ static void vlv_atomic_update_fifo(struct 
> intel_atomic_state *state,
>  
>   trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
>  
> - spin_lock(_priv->wm.dsparb_lock);
> + /*
> +  * uncore.lock serves a double purpose here. It allows us to
> +  * use the less expensive I915_{READ,WRITE}_FW() functions, and
> +  * it protects the DSPARB registers from getting clobbered by
> +  * parallel updates from multiple pipes.
> +  */
> + spin_lock(_priv->uncore.lock);

Might be nice to document that the irq is disabled by
intel_pipe_update_start() (hence why spin_lock is safe).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/2] kms_pipe_crc_basic: Skip sequence tests if the source doesn't provide frame numbers

[Robert Foss]

Reviewed-by: Robert Foss 

On 2017-03-08 08:30 AM, Tomeu Vizoso wrote:

Some frame sources such as sinks aren't able to provide meaningful frame
numbers, so in those cases just skip the TEST_SEQUENCE tests.

Signed-off-by: Tomeu Vizoso 
---
 tests/kms_pipe_crc_basic.c | 29 +++--
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index d0dc2a1b58cf..415efd90330c 100644
--- a/tests/kms_pipe_crc_basic.c
+++ b/tests/kms_pipe_crc_basic.c
@@ -89,7 +89,7 @@ static void test_bad_source(data_t *data)
 #define TEST_SEQUENCE (1<<0)
 #define TEST_NONBLOCK (1<<1)

-static void
+static bool
 test_read_crc_for_output(data_t *data, int pipe, igt_output_t *output,
 unsigned flags)
 {
@@ -163,9 +163,24 @@ test_read_crc_for_output(data_t *data, int pipe, 
igt_output_t *output,
for (j = 0; j < (n_crcs - 1); j++)
igt_assert_crc_equal([j], [j + 1]);

-   if (flags & TEST_SEQUENCE)
-   for (j = 0; j < (n_crcs - 1); j++)
-   igt_assert_eq(crcs[j].frame + 1, crcs[j + 
1].frame);
+   if (flags & TEST_SEQUENCE) {
+   if (!crcs[0].has_valid_frame) {
+   igt_info("Skipping connector, its 'auto' source 
doesn't give us frame numbers.\n");
+
+   free(crcs);
+   igt_pipe_crc_free(pipe_crc);
+   igt_remove_fb(data->drm_fd, >fb);
+   igt_plane_set_fb(primary, NULL);
+
+   igt_output_set_pipe(output, PIPE_ANY);
+
+   return false;
+   } else {
+   for (j = 0; j < (n_crcs - 1); j++)
+   igt_assert_eq(crcs[j].frame + 1,
+   crcs[j + 1].frame);
+   }
+   }

free(crcs);
igt_pipe_crc_free(pipe_crc);
@@ -174,6 +189,8 @@ test_read_crc_for_output(data_t *data, int pipe, 
igt_output_t *output,

igt_output_set_pipe(output, PIPE_ANY);
}
+
+   return true;
 }

 static void test_read_crc(data_t *data, int pipe, unsigned flags)
@@ -190,8 +207,8 @@ static void test_read_crc(data_t *data, int pipe, unsigned 
flags)
 igt_subtest_name(), igt_output_name(output),
 kmstest_pipe_name(pipe));

-   test_read_crc_for_output(data, pipe, output, flags);
-   valid_connectors ++;
+   if (test_read_crc_for_output(data, pipe, output, flags))
+   valid_connectors ++;
}

igt_require_f(valid_connectors, "No connector found for pipe %i\n", 
pipe);


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use highest frequency divider for PWM

[Puthikorn Voravootivat]

Agree that your suggestion is better. I will drop this patch in the
next version of the set.

Thanks

On Thu, Mar 9, 2017 at 2:40 AM, Jani Nikula  wrote:
> On Wed, 08 Mar 2017, Puthikorn Voravootivat  wrote:
>> TCON tend to have better brightness scaling with lower
>> PWM frequency. This patch set the divider to highest
>> value to lower the PWM frequency.
>
> Just setting 0xff to DP_EDP_BACKLIGHT_FREQ_SET is way too arbitrary and
> panel dependent. Going to a too low frequency may lead to flicker, and
> you have no idea how low you're going because you ignore
> DP_EDP_PWMGEN_BIT_COUNT completely. I think it's possible to land in
> audible frequencies too, depending on the TCON hardware. (*)
>
> I think the way to go is to check the VBT for OEM specified backlight
> frequency, tuned for the specific hardware, and do the math to set the
> registers right. This is what we use (well, fall back to) for the PWM
> pin frequency setting in intel_panel.c.
>
> BR,
> Jani.
>
>
> (*) Admittedly there's a certain charm in the idea of getting a bug
> report, "I can hear my backlight". ;)
>
>
>>
>> Signed-off-by: Puthikorn Voravootivat 
>> ---
>>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
>> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> index 643b604be2de..32b426006a6a 100644
>> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> @@ -116,6 +116,7 @@ static void intel_dp_aux_enable_backlight(struct 
>> intel_connector *connector)
>>   uint8_t dpcd_buf = 0;
>>   uint8_t new_dpcd_buf = 0;
>>   uint8_t edp_backlight_mode = 0;
>> + bool freq_cap = false;
>>
>>   set_aux_backlight_enable(intel_dp, true);
>>
>> @@ -146,10 +147,20 @@ static void intel_dp_aux_enable_backlight(struct 
>> intel_connector *connector)
>>   intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
>>   }
>>
>> + /* Use highest frequency divider if supported */
>> + freq_cap = intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP;
>> + if (freq_cap)
>> + new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
>> +
>>   if (new_dpcd_buf != dpcd_buf) {
>>   drm_dp_dpcd_writeb(_dp->aux,
>>   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf);
>>   }
>> +
>> + if (freq_cap) {
>> + drm_dp_dpcd_writeb(_dp->aux, DP_EDP_BACKLIGHT_FREQ_SET,
>> + 0xff);
>> + }
>>  }
>>
>>  static void intel_dp_aux_disable_backlight(struct intel_connector 
>> *connector)
>
> --
> 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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Fix condition check for backlight control via DPCD

[Puthikorn Voravootivat]

I think that there won't be a good way to determine which way of
adjusting backlight
is preferred when the panel support both PWM pin and DPCD.

How about extending the current i915_params.enable_dpcd_backlight to this.
{ 0:disable(default) 1: prefer PWM pin, 2: prefer DPCD }

If it is 1), use the existing condition and if it is 2) use my new condition.

This would solve the limitation of the current code and avoid the
mixed mode complexity
since user need to purposely set the param to 2 to prefer DPCD.

Thanks

On Thu, Mar 9, 2017 at 1:50 AM, Jani Nikula  wrote:
> On Wed, 08 Mar 2017, Puthikorn Voravootivat  wrote:
>> Currently the intel_dp_aux_backlight driver requires eDP panel
>> to support these conditions to allow the backlight adjust via
>> dpcd register.
>> 1) DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP
>> 2) DP_EDP_BACKLIGHT_AUX_ENABLE_CAP
>> 3) not DP_EDP_BACKLIGHT_PIN_ENABLE_CAP
>> 4) not DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP
>>
>> Condition 2,3,4 are incorect because of the following reasons.
>> For 2), "backlight can be enabled via AUX" is not "brightness
>> can be adjusted via AUX". For 3) and 4), this requires panel
>> to not support backlight adjustment via eDP BL_PWM_DIM pin,
>> but there are some panels that support both AUX and eDP pin.
>>
>> This patch fixes the condition by checking for these instead.
>> 1) DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP
>> 2) DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP
>
> I understand your point, but IIRC the goal with the current code was to
> support DPCD backlight control *only* when PWM pin backlight control was
> not possible. Your patch turns it around, and enables DPCD backlight
> control whenever it's possible.
>
>> This patch also add a check to DP_EDP_BACKLIGHT_AUX_ENABLE_CAP
>> in set_aux_backlight_enable() since the backlight enablement
>> can be done via BL_ENABLE eDP connector pin in the case that
>> it does not support doing that via AUX.
>
> It's also true that the current code conflates backlight enable and
> adjustment caps. But that's largely because we also currently do not
> support any type of mixed mode. And that would require quite a bit more
> code. With your patch, you could end up with DPCD backlight adjustment
> with no backligt enable/disable capability.
>
> So I acknowledge the limitations in the current code, but I'm also not
> convinced this patch series would be sufficient.
>
>
> BR,
> Jani.
>
>>
>> Signed-off-by: Puthikorn Voravootivat 
>> ---
>>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 10 ++
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
>> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> index 6532e226db29..abfb09c1269f 100644
>> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> @@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp 
>> *intel_dp, bool enable)
>>  {
>>   uint8_t reg_val = 0;
>>
>> + /* Early return when display use other mechanism to enable backlight. 
>> */
>> + if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
>> + return;
>> +
>>   if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
>> _val) < 0) {
>>   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
>> @@ -142,10 +146,8 @@ intel_dp_aux_display_control_capable(struct 
>> intel_connector *connector)
>>   /* Check the  eDP Display control capabilities registers to determine 
>> if
>>* the panel can support backlight control over the aux channel
>>*/
>> - if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
>> - (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
>> - !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
>> -   (intel_dp->edp_dpcd[2] & 
>> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
>> + if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
>> + (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) 
>> {
>>   DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
>>   return true;
>>   }
>
> --
> 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 v3 2/3] drm/i915: Use max(render, media) for Baytrail busyness calculation

[Chris Wilson]

Currently, we sum the render and media cycles (on different engines) to
compute a percentage - but we fail to factor in the duplication into the
threshold calculations. This makes us very eager to upclock!

If we just consider the maximum busy cycles of either counter, we should
have an accurate reflection on whether there are cycles to spare to
handle the workload at this frequency.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_irq.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b3f9181ef314..e8f4c78c4bdc 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1103,6 +1103,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
*dev_priv, u32 pm_iir)
 
if (prev->cz_clock) {
u64 time, c0;
+   u32 render, media;
unsigned int mul;
 
mul = VLV_CZ_CLOCK_TO_MILLI_SEC * 100; /* scale to % */
@@ -1117,8 +1118,9 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
*dev_priv, u32 pm_iir)
 * mesa. To account for this we need to combine both engines
 * into our activity counter.
 */
-   c0 = now.render_c0 - prev->render_c0;
-   c0 += now.media_c0 - prev->media_c0;
+   render = now.render_c0 - prev->render_c0;
+   media = now.media_c0 - prev->media_c0;
+   c0 = max(render, media);
c0 *= mul;
 
if (c0 > time * dev_priv->rps.up_threshold)
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 3/3] drm/i915: Defer unmasking RPS interrupts until after making adjustments

[Chris Wilson]

To make our adjustments to RPS requires taking a mutex and potentially
sleeping for an unknown duration - until we have completed our
adjustments further RPS interrupts are immaterial (they are based on
stale thresholds) and we can safely ignore them.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_irq.c | 28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e8f4c78c4bdc..ab55a3ddafb3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1149,30 +1149,21 @@ static void gen6_pm_rps_work(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
container_of(work, struct drm_i915_private, rps.work);
-   bool client_boost;
+   bool client_boost = false;
int new_delay, adj, min, max;
-   u32 pm_iir;
+   u32 pm_iir = 0;
 
spin_lock_irq(_priv->irq_lock);
-   /* Speed up work cancelation during disabling rps interrupts. */
-   if (!dev_priv->rps.interrupts_enabled) {
-   spin_unlock_irq(_priv->irq_lock);
-   return;
+   if (dev_priv->rps.interrupts_enabled) {
+   pm_iir = fetch_and_zero(_priv->rps.pm_iir);
+   client_boost = fetch_and_zero(_priv->rps.client_boost);
}
-
-   pm_iir = dev_priv->rps.pm_iir;
-   dev_priv->rps.pm_iir = 0;
-   /* Make sure not to corrupt PMIMR state used by ringbuffer on GEN6 */
-   gen6_unmask_pm_irq(dev_priv, dev_priv->pm_rps_events);
-   client_boost = dev_priv->rps.client_boost;
-   dev_priv->rps.client_boost = false;
spin_unlock_irq(_priv->irq_lock);
 
/* Make sure we didn't queue anything we're not going to process. */
WARN_ON(pm_iir & ~dev_priv->pm_rps_events);
-
if ((pm_iir & dev_priv->pm_rps_events) == 0 && !client_boost)
-   return;
+   goto out;
 
mutex_lock(_priv->rps.hw_lock);
 
@@ -1229,6 +1220,13 @@ static void gen6_pm_rps_work(struct work_struct *work)
}
 
mutex_unlock(_priv->rps.hw_lock);
+
+out:
+   /* Make sure not to corrupt PMIMR state used by ringbuffer on GEN6 */
+   spin_lock_irq(_priv->irq_lock);
+   if (dev_priv->rps.interrupts_enabled)
+   gen6_unmask_pm_irq(dev_priv, dev_priv->pm_rps_events);
+   spin_unlock_irq(_priv->irq_lock);
 }
 
 
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 1/3] drm/i915: Stop using RP_DOWN_EI on Baytrail

[Chris Wilson]

On Baytrail, we manually calculate busyness over the evaluation interval
to avoid issues with miscaluations with RC6 enabled. However, it turns
out that the DOWN_EI interrupt generator is completely bust - it
operates in two modes, continuous or never. Neither of which are
conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just
compute everything from the UP_EI which does seem to correspond to the
desired interval.

v2: Fixup gen6_rps_pm_mask() as well
v3: Inline vlv_c0_above() to combine the now identical elapsed
calculation for up/down and simplify the threshold testing

Fixes: 43cf3bf084ba ("drm/i915: Improved w/a for rps on Baytrail")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc:  # v4.1+
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/i915_irq.c | 73 -
 drivers/gpu/drm/i915/intel_pm.c |  5 +--
 3 files changed, 32 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c52aee5141ca..b399c8fe5ac1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1377,7 +1377,7 @@ struct intel_gen6_power_mgmt {
unsigned boosts;
 
/* manual wa residency calculations */
-   struct intel_rps_ei up_ei, down_ei;
+   struct intel_rps_ei ei;
 
/*
 * Protects RPS/RC6 register access and PCU communication.
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d91078f8e9d4..b3f9181ef314 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1083,68 +1083,51 @@ static void vlv_c0_read(struct drm_i915_private 
*dev_priv,
ei->media_c0 = I915_READ(VLV_MEDIA_C0_COUNT);
 }
 
-static bool vlv_c0_above(struct drm_i915_private *dev_priv,
-const struct intel_rps_ei *old,
-const struct intel_rps_ei *now,
-int threshold)
-{
-   u64 time, c0;
-   unsigned int mul = 100;
-
-   if (old->cz_clock == 0)
-   return false;
-
-   if (I915_READ(VLV_COUNTER_CONTROL) & VLV_COUNT_RANGE_HIGH)
-   mul <<= 8;
-
-   time = now->cz_clock - old->cz_clock;
-   time *= threshold * dev_priv->czclk_freq;
-
-   /* Workload can be split between render + media, e.g. SwapBuffers
-* being blitted in X after being rendered in mesa. To account for
-* this we need to combine both engines into our activity counter.
-*/
-   c0 = now->render_c0 - old->render_c0;
-   c0 += now->media_c0 - old->media_c0;
-   c0 *= mul * VLV_CZ_CLOCK_TO_MILLI_SEC;
-
-   return c0 >= time;
-}
-
 void gen6_rps_reset_ei(struct drm_i915_private *dev_priv)
 {
-   vlv_c0_read(dev_priv, _priv->rps.down_ei);
-   dev_priv->rps.up_ei = dev_priv->rps.down_ei;
+   memset(_priv->rps.ei, 0, sizeof(dev_priv->rps.ei));
 }
 
 static u32 vlv_wa_c0_ei(struct drm_i915_private *dev_priv, u32 pm_iir)
 {
+   const struct intel_rps_ei *prev = _priv->rps.ei;
struct intel_rps_ei now;
u32 events = 0;
 
-   if ((pm_iir & (GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED)) 
== 0)
+   if ((pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) == 0)
return 0;
 
vlv_c0_read(dev_priv, );
if (now.cz_clock == 0)
return 0;
 
-   if (pm_iir & GEN6_PM_RP_DOWN_EI_EXPIRED) {
-   if (!vlv_c0_above(dev_priv,
- _priv->rps.down_ei, ,
- dev_priv->rps.down_threshold))
-   events |= GEN6_PM_RP_DOWN_THRESHOLD;
-   dev_priv->rps.down_ei = now;
-   }
+   if (prev->cz_clock) {
+   u64 time, c0;
+   unsigned int mul;
 
-   if (pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) {
-   if (vlv_c0_above(dev_priv,
-_priv->rps.up_ei, ,
-dev_priv->rps.up_threshold))
-   events |= GEN6_PM_RP_UP_THRESHOLD;
-   dev_priv->rps.up_ei = now;
+   mul = VLV_CZ_CLOCK_TO_MILLI_SEC * 100; /* scale to % */
+   if (I915_READ(VLV_COUNTER_CONTROL) & VLV_COUNT_RANGE_HIGH)
+   mul <<= 8;
+
+   time = now.cz_clock - prev->cz_clock;
+   time *= dev_priv->czclk_freq;
+
+   /* Workload can be split between render + media,
+* e.g. SwapBuffers being blitted in X after being rendered in
+* mesa. To account for this we need to combine both engines
+* into our activity counter.
+*/
+   c0 = now.render_c0 - prev->render_c0;
+   c0 += now.media_c0 - prev->media_c0;
+   c0 *= mul;
+
+   if (c0 > time * 

Re: [Intel-gfx] [PATCH] drm/i915: Fix forcewake active domain tracking

[Chris Wilson]

On Thu, Mar 09, 2017 at 03:52:50PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> In commit 003342a50021 ("drm/i915: Keep track of active
> forcewake domains in a bitmask") I forgot to adjust the
> newly introduce fw_domains_active state across reset.
> 
> This caused the assert_forcewakes_inactive to trigger
> during suspend and resume if there were user held
> forcewakes.
> 
> Signed-off-by: Tvrtko Ursulin 
> Fixes: 003342a50021 ("drm/i915: Keep track of active forcewake domains in a 
> bitmask")
> Testcase: igt/drv_suspend/forcewake
> Cc: Tvrtko Ursulin 
> Cc: "Paneri, Praveen" 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: intel-gfx@lists.freedesktop.org
> Cc: v4.10+ 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 2a3f35c30501..efa040847d69 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -302,22 +302,21 @@ static void intel_uncore_forcewake_reset(struct 
> drm_i915_private *dev_priv,
>   WARN_ON(active_domains);
>  
>   fw = dev_priv->uncore.fw_domains_active;
> - if (fw)
> - dev_priv->uncore.funcs.force_wake_put(dev_priv, fw);

I see. On ilk-, funcs.force_wake_put/_get are NULL, so we need to keep
the if (fw) guard.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Stop using RP_DOWN_EI on Baytrail

[Chris Wilson]

On Thu, Mar 09, 2017 at 09:03:12PM +, Chris Wilson wrote:
> On Baytrail, we manually calculate busyness over the evaluation interval
> to avoid issues with miscaluations with RC6 enabled. However, it turns
> out that the DOWN_EI interrupt generator is completely bust - it
> operates in two modes, continuous or never. Neither of which are
> conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just
> compute everything from the UP_EI which does seem to correspond to the
> desired interval.

Ignore this, I'll resend the 3 as a new series so we have them together.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 1/2] lib: Open debugfs files for the given DRM device

[Robert Foss]

I've only found a very minor nitpick in intel_watermark.c,
other than that this patch does not apply cleanly on upstream/master,
so I've run no compilation or runtime tests.

When it applies to trunk, feel free to add my r-b.

On 2017-03-08 08:29 AM, Tomeu Vizoso wrote:
> When opening a DRM debugfs file, locate the right path based on the
> given DRM device FD.
>
> This is needed so, in setups with more than one DRM device, any
> operations on debugfs files affect the expected DRM device.
>
> Signed-off-by: Tomeu Vizoso 
>
> ---
>
> Guess we could be more conservative and just rename the existing
> functions to have a _legacy postfix and have the new ones accept a FD
> param. Then existing i915-specific code could keep opening the first
> debugfs dir that contains i915-prefixed files and only the generic tests
> would need to be changed to pass the DRM fd.
>
> But the "right" thing to do is to not assume that there's only one DRM
> device on the system, so maybe we want to do the changes in this patch.
> ---
>  benchmarks/gem_latency.c  |   2 +-
>  lib/drmtest.c |   2 +-
>  lib/igt_debugfs.c | 181 
+++---

>  lib/igt_debugfs.h |  28 +++---
>  lib/igt_gt.c  |  12 +--
>  lib/igt_gt.h  |   4 +-
>  lib/igt_kms.c |  10 +--
>  lib/igt_kms.h |   4 +-
>  lib/intel_io.h|   2 +-
>  lib/intel_mmio.c  |   4 +-
>  tests/drv_hangman.c   |   4 +-
>  tests/drv_missed_irq.c|  37 
>  tests/drv_suspend.c   |   8 +-
>  tests/gem_eio.c   |   2 +-
>  tests/gem_exec_latency.c  |   2 +-
>  tests/gem_exec_parse.c|   2 +-
>  tests/gem_exec_whisper.c  |   6 +-
>  tests/gem_mocs_settings.c |  14 +--
>  tests/gem_persistent_relocs.c |   2 +-
>  tests/gem_ppgtt.c |  10 +--
>  tests/gem_reloc_vs_gpu.c  |   2 +-
>  tests/gem_seqno_wrap.c|  24 ++---
>  tests/gem_tiled_swapping.c|   6 +-
>  tests/gem_workarounds.c   |   4 +-
>  tests/kms_atomic_transition.c |   2 +-
>  tests/kms_ccs.c   |   4 +-
>  tests/kms_chv_cursor_fail.c   |   4 +-
>  tests/kms_crtc_background_color.c |   4 +-
>  tests/kms_cursor_crc.c|   4 +-
>  tests/kms_cursor_legacy.c |   4 +-
>  tests/kms_draw_crc.c  |   2 +-
>  tests/kms_fbc_crc.c   |   8 +-
>  tests/kms_fbcon_fbt.c |  44 -
>  tests/kms_flip_tiling.c   |   8 +-
>  tests/kms_frontbuffer_tracking.c  |  26 +++---
>  tests/kms_invalid_dotclock.c  |   6 +-
>  tests/kms_mmap_write_crc.c|   4 +-
>  tests/kms_mmio_vs_cs_flip.c   |   6 +-
>  tests/kms_pipe_color.c|   5 +-
>  tests/kms_pipe_crc_basic.c|  12 +--
>  tests/kms_plane.c |   4 +-
>  tests/kms_plane_lowres.c  |  14 ++-
>  tests/kms_plane_multiple.c|   4 +-
>  tests/kms_plane_scaling.c |   4 +-
>  tests/kms_psr_sink_crc.c  |   6 +-
>  tests/kms_pwrite_crc.c|   4 +-
>  tests/kms_rotation_crc.c  |   4 +-
>  tests/kms_sink_crc_basic.c|   8 +-
>  tests/kms_universal_plane.c   |  12 +--
>  tests/perf.c  |  16 ++--
>  tests/pm_lpsp.c   |   2 +-
>  tests/pm_rpm.c|   6 +-
>  tests/pm_sseu.c   |  28 +++---
>  tests/prime_mmap_kms.c|   2 +-
>  tools/intel_display_crc.c |   2 +-
>  tools/intel_display_poller.c  |   8 +-
>  tools/intel_dp_compliance.c   |   6 +-
>  tools/intel_forcewaked.c  |  10 ++-
>  tools/intel_gpu_top.c |   8 +-
>  tools/intel_guc_logger.c  |  10 ++-
>  tools/intel_infoframes.c  |   7 +-
>  tools/intel_l3_parity.c   |   2 +-
>  tools/intel_panel_fitter.c|   9 +-
>  tools/intel_perf_counters.c   |   2 +-
>  tools/intel_reg.c |  12 ++-
>  tools/intel_watermark.c   |  23 +++--
>  66 files changed, 405 insertions(+), 323 deletions(-)
>
> diff --git a/benchmarks/gem_latency.c b/benchmarks/gem_latency.c
> index 7be78f20358f..fc875f1acb0a 100644
> --- a/benchmarks/gem_latency.c
> +++ b/benchmarks/gem_latency.c
> @@ -470,7 +470,7 @@ static int run(int seconds,
>if (gen < 6)
>return IGT_EXIT_SKIP; /* Needs BCS timestamp */
>
> -  intel_register_access_init(intel_get_pci_device(), false);
> +  intel_register_access_init(intel_get_pci_device(), false, fd);
>
>if (gen == 6)
>timestamp_reg = REG(RCS_TIMESTAMP);
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index 065ab1198e79..35f71c0d4f45 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -183,7 +183,7 @@ void gem_quiescent_gpu(int fd)
>gem_sync(fd, obj.handle);
>gem_close(fd, obj.handle);
>
> -  

[Intel-gfx] [PATCH v3] drm/i915: Stop using RP_DOWN_EI on Baytrail

[Chris Wilson]

On Baytrail, we manually calculate busyness over the evaluation interval
to avoid issues with miscaluations with RC6 enabled. However, it turns
out that the DOWN_EI interrupt generator is completely bust - it
operates in two modes, continuous or never. Neither of which are
conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just
compute everything from the UP_EI which does seem to correspond to the
desired interval.

v2: Fixup gen6_rps_pm_mask() as well
v3: Inline vlv_c0_above() to combine the now identical elapsed
calculation for up/down and simplify the threshold testing

Fixes: 43cf3bf084ba ("drm/i915: Improved w/a for rps on Baytrail")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc:  # v4.1+
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/i915_irq.c | 73 -
 drivers/gpu/drm/i915/intel_pm.c |  5 +--
 3 files changed, 32 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c52aee5141ca..b399c8fe5ac1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1377,7 +1377,7 @@ struct intel_gen6_power_mgmt {
unsigned boosts;
 
/* manual wa residency calculations */
-   struct intel_rps_ei up_ei, down_ei;
+   struct intel_rps_ei ei;
 
/*
 * Protects RPS/RC6 register access and PCU communication.
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d91078f8e9d4..5619c6323bb9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1083,68 +1083,51 @@ static void vlv_c0_read(struct drm_i915_private 
*dev_priv,
ei->media_c0 = I915_READ(VLV_MEDIA_C0_COUNT);
 }
 
-static bool vlv_c0_above(struct drm_i915_private *dev_priv,
-const struct intel_rps_ei *old,
-const struct intel_rps_ei *now,
-int threshold)
-{
-   u64 time, c0;
-   unsigned int mul = 100;
-
-   if (old->cz_clock == 0)
-   return false;
-
-   if (I915_READ(VLV_COUNTER_CONTROL) & VLV_COUNT_RANGE_HIGH)
-   mul <<= 8;
-
-   time = now->cz_clock - old->cz_clock;
-   time *= threshold * dev_priv->czclk_freq;
-
-   /* Workload can be split between render + media, e.g. SwapBuffers
-* being blitted in X after being rendered in mesa. To account for
-* this we need to combine both engines into our activity counter.
-*/
-   c0 = now->render_c0 - old->render_c0;
-   c0 += now->media_c0 - old->media_c0;
-   c0 *= mul * VLV_CZ_CLOCK_TO_MILLI_SEC;
-
-   return c0 >= time;
-}
-
 void gen6_rps_reset_ei(struct drm_i915_private *dev_priv)
 {
-   vlv_c0_read(dev_priv, _priv->rps.down_ei);
-   dev_priv->rps.up_ei = dev_priv->rps.down_ei;
+   memset(_priv->rps.ei, 0, sizeof(dev_priv->rps.ei));
 }
 
 static u32 vlv_wa_c0_ei(struct drm_i915_private *dev_priv, u32 pm_iir)
 {
+   const struct intel_rps_ei *prev = _priv->rps.ei;
struct intel_rps_ei now;
u32 events = 0;
 
-   if ((pm_iir & (GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED)) 
== 0)
+   if ((pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) == 0)
return 0;
 
vlv_c0_read(dev_priv, );
if (now.cz_clock == 0)
return 0;
 
-   if (pm_iir & GEN6_PM_RP_DOWN_EI_EXPIRED) {
-   if (!vlv_c0_above(dev_priv,
- _priv->rps.down_ei, ,
- dev_priv->rps.down_threshold))
-   events |= GEN6_PM_RP_DOWN_THRESHOLD;
-   dev_priv->rps.down_ei = now;
-   }
+   if (prev->cz_clock) {
+   u64 time, c0;
+   unsigned int mul;
 
-   if (pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) {
-   if (vlv_c0_above(dev_priv,
-_priv->rps.up_ei, ,
-dev_priv->rps.up_threshold))
-   events |= GEN6_PM_RP_UP_THRESHOLD;
-   dev_priv->rps.up_ei = now;
+   mul = VLV_CZ_CLOCK_TO_MILLI_SEC;
+   if (I915_READ(VLV_COUNTER_CONTROL) & VLV_COUNT_RANGE_HIGH)
+   mul <<= 8;
+
+   time = now.cz_clock - prev->cz_clock;
+   time *= dev_priv->czclk_freq;
+
+   /* Workload can be split between render + media,
+* e.g. SwapBuffers being blitted in X after being rendered in
+* mesa. To account for this we need to combine both engines
+* into our activity counter.
+*/
+   c0 = now.render_c0 - prev->render_c0;
+   c0 += now.media_c0 - prev->media_c0;
+   c0 *= mul;
+
+   if (c0 > time * 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/guc: Fix request re-submission after reset

[Chris Wilson]

On Thu, Mar 09, 2017 at 04:47:52PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [CI,1/2] drm/i915/guc: Fix request re-submission 
> after reset
> URL   : https://patchwork.freedesktop.org/series/20991/
> State : success
> 
> == Summary ==
> 
> Series 20991v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/20991/revisions/1/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> incomplete -> PASS   (fi-skl-6700k) fdo#100130

Wait... Did that just fix the bxt fails! My hero! :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix request re-submission after reset

[Chris Wilson]

On Thu, Mar 09, 2017 at 05:02:16PM +, Tvrtko Ursulin wrote:
> 
> On 09/03/2017 08:55, Oscar Mateo wrote:
> >On 03/09/2017 08:50 AM, Tvrtko Ursulin wrote:
> >>
> >>On 09/03/2017 08:42, Oscar Mateo wrote:
> >>>On 03/09/2017 02:05 AM, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> In order to ensure no missed interrupts we must first re-direct
> the interrupts to GuC, and only then re-submit the requests to
> be replayed after a GPU reset. Otherwise context switch can fire
> before GuC has been set up to receive it triggering more hangs.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Chris Wilson 
> Cc: Michal Wajdeczko 
> Cc: Mika Kuoppala 
> Cc: Oscar Mateo 
> Cc: Sagar Arun Kamble 
> Cc: Arkadiusz Hiler 
> ---
>   drivers/gpu/drm/i915/i915_guc_submission.c | 58
> +++---
>   drivers/gpu/drm/i915/intel_guc_loader.c| 47
> 
>   2 files changed, 54 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index beb38e30d0e9..5b8ec0fab563 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -936,6 +936,52 @@ static void guc_reset_wq(struct i915_guc_client
> *client)
>   client->wq_tail = 0;
>   }
> 
> >>>
>   int i915_guc_submission_enable(struct drm_i915_private *dev_priv)
>   {
>   struct intel_guc *guc = _priv->guc;
> @@ -953,13 +999,17 @@ int i915_guc_submission_enable(struct
> drm_i915_private *dev_priv)
> /* Take over from manual control of ELSP (execlists) */
>   for_each_engine(engine, dev_priv, id) {
> -const int wqi_size = sizeof(struct guc_wq_item);
> -struct drm_i915_gem_request *rq;
> -
>   engine->submit_request = i915_guc_submit;
>   engine->schedule = NULL;
> +}
> +
> +guc_interrupts_capture(dev_priv);
> +
> +/* Replay the current set of previously submitted requests */
> +for_each_engine(engine, dev_priv, id) {
> +const int wqi_size = sizeof(struct guc_wq_item);
> +struct drm_i915_gem_request *rq;
> 
> >>>Don't you want to move the guc_interrupts_release to
> >>>i915_guc_submission_disable as well?
> >>
> >>I can't spot anything broken in that path. We never go in that
> >>direction with the live submission so why do you think it is needed?
> >>
> >>Regards,
> >>
> >>Tvrtko
> >Just code symmetry: if we are leaving i915_guc_submission_enable to
> >capture the interrupts, why doesn't the disable also releases them?
> >Maybe it's not very important now, but it makes a lot more sense with my
> >series to do proper unwinding of the whole path (I can tackle it there
> >if you prefer).
> 
> I think so. There is a multitude of people trying to refactor the
> GuC code at the moment so I would prefer just to fix the reset fail
> quickly and not interfere with that wider refactoring too much.
> Because I think it is not just a quick job of moving the interrupt
> release to get to full symmetry. Ack to merge then?

Exactly, I don't disagree with the desire to make/keep the code
symmetrical, but I also think push the fix and wait for the dust to
settle to fix the otherside, or volunteer somebody...

Just so long as we remember to do it in the short term and not leave
nits to build up.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
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 drm/i915: Fix forcewake active domain tracking

[Chris Wilson]

On Thu, Mar 09, 2017 at 07:23:14PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Fix forcewake active domain tracking
> URL   : https://patchwork.freedesktop.org/series/21004/
> State : failure
> 
> == Summary ==
> 
> Series 21004v1 drm/i915: Fix forcewake active domain tracking
> https://patchwork.freedesktop.org/api/1.0/series/21004/revisions/1/mbox/
> 
> Test core_auth:
> Subgroup basic-auth:
> pass   -> SKIP   (fi-ilk-650)

[3.470450] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[3.485921] IP:   (null)
[3.489198] PGD 0

[3.492793] Oops: 0010 [#1] PREEMPT SMP
[3.496675] Modules linked in: i915(+) e1000e ptp pps_core prime_numbers
[3.503426] CPU: 1 PID: 194 Comm: systemd-udevd Not tainted 
4.11.0-rc1-CI-Patchwork_4122+ #1
[3.511941] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF 
PC/304Ah, BIOS 786H1 v01.13 07/14/2011
[3.521671] task: 88020961cbc0 task.stack: c947
[3.527634] RIP: 0010:  (null)
[3.531427] RSP: 0018:c9473a60 EFLAGS: 00010046
[3.536696] RAX: 0282 RBX: 880205b70da8 RCX: 88020961d410
[3.543875] RDX: 0001 RSI:  RDI: 880205b7
[3.551057] RBP: c9473ab0 R08: d9242164 R09: 59311d75
[3.558235] R10: 827ede60 R11: 88020961cbc0 R12: 
[3.565412] R13: 880205b70c58 R14: 880205b7 R15: 0282
[3.572590] FS:  7f34796fa8c0() GS:88021bc4() 
knlGS:
[3.580757] CS:  0010 DS:  ES:  CR0: 80050033
[3.586546] CR2:  CR3: 000209753000 CR4: 06e0
[3.593723] Call Trace:
[3.596246]  ? intel_uncore_forcewake_reset+0x110/0x260 [i915]
[3.602153]  __intel_uncore_early_sanitize+0x55/0xb0 [i915]
[3.607801]  intel_uncore_init+0x162/0x5e0 [i915]
[3.612577]  i915_driver_load+0x5c5/0x1570 [i915]
[3.617330]  ? trace_hardirqs_on_caller+0xe7/0x200
[3.622167]  ? trace_hardirqs_on+0xd/0x10
[3.626247]  i915_pci_probe+0x34/0xa0 [i915]
[3.630563]  pci_device_probe+0x91/0x110
[3.634533]  driver_probe_device+0x2ba/0x450
[3.638848]  __driver_attach+0xde/0xe0
[3.642642]  ? driver_probe_device+0x450/0x450
[3.647952]  bus_for_each_dev+0x61/0xa0
[3.651836]  driver_attach+0x19/0x20
[3.655457]  bus_add_driver+0x1fb/0x270
[3.659337]  ? 0xa01fc000
[3.662697]  driver_register+0x5b/0xd0
[3.666490]  ? 0xa01fc000
[3.669852]  __pci_register_driver+0x5b/0x60
[3.674191]  i915_init+0x6b/0x6e [i915]
[3.678076]  do_one_initcall+0x3f/0x170
[3.681958]  ? rcu_read_lock_sched_held+0x75/0x80
[3.686710]  ? kmem_cache_alloc_trace+0x274/0x2e0
[3.691460]  ? do_init_module+0x22/0x1f3
[3.695427]  do_init_module+0x5a/0x1f3
[3.699221]  load_module+0x2091/0x2410
[3.703015]  ? symbol_put_addr+0x60/0x60
[3.706984]  ? kernel_read_file+0x105/0x190
[3.711212]  SyS_finit_module+0xbc/0xf0
[3.715094]  entry_SYSCALL_64_fastpath+0x1c/0xb1

ilk being the only !fw machine in the BAT set.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Optimize plane updates a bit

[Patchwork]

== Series Details ==

Series: drm/i915: Optimize plane updates a bit
URL   : https://patchwork.freedesktop.org/series/21002/
State : failure

== Summary ==

Series 21002v1 drm/i915: Optimize plane updates a bit
https://patchwork.freedesktop.org/api/1.0/series/21002/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
incomplete -> PASS   (fi-skl-6700k) fdo#100130
Subgroup basic-uc-prw-default:
pass   -> INCOMPLETE (fi-skl-6700hq) fdo#100130
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> INCOMPLETE (fi-bxt-t5700)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-j1900)

fdo#100130 https://bugs.freedesktop.org/show_bug.cgi?id=100130

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 459s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 607s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 541s
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12  
time: 0s
fi-byt-j1900 total:278  pass:250  dwarn:1   dfail:0   fail:0   skip:27  
time: 507s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 498s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 441s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 435s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 448s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 506s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 484s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 474s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 520s
fi-skl-6700hqtotal:54   pass:46   dwarn:0   dfail:0   fail:0   skip:7   
time: 0s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 497s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 560s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 555s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 422s

510c200742ced5a91d07e48220b669a3c9b30c0c drm-tip: 2017y-03m-09d-15h-21m-14s UTC 
integration manifest
aa6c0ed drm/i915: Optimize VLV/CHV display FIFO updates
7bdb347 drm/i915: Use I915_READ_FW for plane updates
b03cfd4 drm/i915: Organize plane register writes into tighter bunches
6e789b6 drm/i915: s/__raw_i915_read32/I915_READ_FW/ in the SKL+ scanline read 
w/a
d3af5ca drm/i915: Use I915_READ_FW in i915_get_vblank_counter()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4123/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix forcewake active domain tracking

[Patchwork]

== Series Details ==

Series: drm/i915: Fix forcewake active domain tracking
URL   : https://patchwork.freedesktop.org/series/21004/
State : failure

== Summary ==

Series 21004v1 drm/i915: Fix forcewake active domain tracking
https://patchwork.freedesktop.org/api/1.0/series/21004/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (fi-ilk-650)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (fi-ilk-650)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-subslice-total:
pass   -> SKIP   (fi-ilk-650)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (fi-ilk-650)
Test drv_module_reload:
Subgroup basic-no-display:
pass   -> FAIL   (fi-ilk-650)
Subgroup basic-reload:
pass   -> FAIL   (fi-ilk-650) fdo#100045
Subgroup basic-reload-final:
pass   -> FAIL   (fi-ilk-650) fdo#100045
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-ilk-650)
Subgroup create-close:
pass   -> SKIP   (fi-ilk-650)
Subgroup create-fd-close:
pass   -> SKIP   (fi-ilk-650)
Test gem_busy:
Subgroup basic-busy-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-hang-default:
pass   -> SKIP   (fi-ilk-650)
Test gem_close_race:
Subgroup basic-process:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-threads:
pass   -> SKIP   (fi-ilk-650)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> SKIP   (fi-ilk-650)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> SKIP   (fi-ilk-650)
Test gem_exec_basic:
Subgroup basic-bsd:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-render:
pass   -> SKIP   (fi-ilk-650)
Subgroup gtt-bsd:
pass   -> SKIP   (fi-ilk-650)
Subgroup gtt-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup gtt-render:
pass   -> SKIP   (fi-ilk-650)
Subgroup readonly-bsd:
pass   -> SKIP   (fi-ilk-650)
Subgroup readonly-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup readonly-render:
pass   -> SKIP   (fi-ilk-650)
Test gem_exec_create:
Subgroup basic:
pass   -> SKIP   (fi-ilk-650)
Test gem_exec_fence:
Subgroup await-hang-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-await-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-busy-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-wait-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup nb-await-default:
pass   -> SKIP   (fi-ilk-650)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> SKIP   (fi-ilk-650)
incomplete -> PASS   (fi-skl-6700k) fdo#100130
Subgroup basic-batch-kernel-default-wb:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-uc-pro-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-uc-prw-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-uc-ro-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-uc-rw-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-uc-set-default:
pass   -> SKIP   (fi-ilk-650)
Subgroup basic-wb-pro-default:
pass   -> SKIP   (fi-ilk-650)
pass   -> INCOMPLETE (fi-skl-6700hq)
Subgroup basic-wb-prw-default:
WARNING: Long output truncated

510c200742ced5a91d07e48220b669a3c9b30c0c drm-tip: 2017y-03m-09d-15h-21m-14s UTC 
integration manifest
b1962c6 drm/i915: Fix forcewake active domain tracking

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4122/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Optimize plane updates a bit

[Patchwork]

== Series Details ==

Series: drm/i915: Optimize plane updates a bit
URL   : https://patchwork.freedesktop.org/series/21002/
State : failure

== Summary ==

Series 21002v1 drm/i915: Optimize plane updates a bit
https://patchwork.freedesktop.org/api/1.0/series/21002/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
incomplete -> PASS   (fi-skl-6700k) fdo#100130
Test gem_exec_reloc:
Subgroup basic-gtt-read-noreloc:
pass   -> INCOMPLETE (fi-byt-j1900)

fdo#100130 https://bugs.freedesktop.org/show_bug.cgi?id=100130

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 466s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 615s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 549s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 608s
fi-byt-j1900 total:85   pass:75   dwarn:0   dfail:0   fail:0   skip:9   
time: 0s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 498s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 434s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 435s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 437s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 510s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 495s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 479s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 509s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 597s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 496s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 551s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 553s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 423s

510c200742ced5a91d07e48220b669a3c9b30c0c drm-tip: 2017y-03m-09d-15h-21m-14s UTC 
integration manifest
06676dc drm/i915: Optimize VLV/CHV display FIFO updates
bea48aa drm/i915: Use I915_READ_FW for plane updates
c63745b drm/i915: Organize plane register writes into tighter bunches
6f81bf0 drm/i915: s/__raw_i915_read32/I915_READ_FW/ in the SKL+ scanline read 
w/a
8fcdc34 drm/i915: Use I915_READ_FW in i915_get_vblank_counter()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4121/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] drm/i915: Use new atomic iterator macros.

[Ville Syrjälä]

On Thu, Mar 09, 2017 at 03:52:00PM +0100, Maarten Lankhorst wrote:
> Some small patchset to deal with the atomic iterator changes.
> 
> Maarten Lankhorst (5):
>   drm/i915: Use new atomic iterator macros in ddi
>   drm/i915: Use new atomic iterator macros in fbc
>   drm/i915: Use new atomic iterator macros in wm code
>   drm/i915: Use new atomic iterator macros in display code
>   drm/i915: Use new atomic iterator macros in cdclk

Quite tedious stuff, but I managed to trawl through it. Didn't spot
any mistakes.

For the series
Reviewed-by: Ville Syrjälä 

> 
>  drivers/gpu/drm/i915/intel_cdclk.c   |   2 +-
>  drivers/gpu/drm/i915/intel_ddi.c |   4 +-
>  drivers/gpu/drm/i915/intel_display.c | 161 
> ++-
>  drivers/gpu/drm/i915/intel_drv.h |   2 -
>  drivers/gpu/drm/i915/intel_fbc.c |   2 +-
>  drivers/gpu/drm/i915/intel_pm.c  |   8 +-
>  6 files changed, 90 insertions(+), 89 deletions(-)
> 
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 drm/i915: Use new atomic iterator macros.

[Patchwork]

== Series Details ==

Series: drm/i915: Use new atomic iterator macros.
URL   : https://patchwork.freedesktop.org/series/20998/
State : success

== Summary ==

Series 20998v1 drm/i915: Use new atomic iterator macros.
https://patchwork.freedesktop.org/api/1.0/series/20998/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
incomplete -> PASS   (fi-skl-6700k) fdo#100130

fdo#100130 https://bugs.freedesktop.org/show_bug.cgi?id=100130

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 462s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 607s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 537s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 592s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 501s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 505s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 443s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 435s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 442s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 509s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 476s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 476s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 513s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 597s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 494s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 557s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 555s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 426s

510c200742ced5a91d07e48220b669a3c9b30c0c drm-tip: 2017y-03m-09d-15h-21m-14s UTC 
integration manifest
d341f75 drm/i915: Use new atomic iterator macros in cdclk
9a7ef81 drm/i915: Use new atomic iterator macros in display code
f1f97ac drm/i915: Use new atomic iterator macros in wm code
931fe38 drm/i915: Use new atomic iterator macros in fbc
2dafc3b drm/i915: Use new atomic iterator macros in ddi

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4120/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [drm-intel:drm-intel-nightly 777/788] include/drm/drm_pci.h:76:64: warning: 'struct platform_device' declared inside parameter list

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head:   510c200742ced5a91d07e48220b669a3c9b30c0c
commit: 23ef59ef6dcc9b62bf077490a74df93b3bb0d530 [777/788] drm: Extract 
drm_pci.h
config: tile-tilegx_defconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 23ef59ef6dcc9b62bf077490a74df93b3bb0d530
# save the attached .config to linux build tree
make.cross ARCH=tile 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu/drm/drm_pci.c:29:0:
>> include/drm/drm_pci.h:76:64: warning: 'struct platform_device' declared 
>> inside parameter list [enabled by default]
>> include/drm/drm_pci.h:76:64: warning: its scope is only this definition or 
>> declaration, which is probably not what you want [enabled by default]

vim +76 include/drm/drm_pci.h

60  
61  static inline int drm_pci_set_busid(struct drm_device *dev,
62  struct drm_master *master)
63  {
64  return -ENOSYS;
65  }
66  #endif
67  
68  #define DRM_PCIE_SPEED_25 1
69  #define DRM_PCIE_SPEED_50 2
70  #define DRM_PCIE_SPEED_80 4
71  
72  extern int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 
*speed_mask);
73  extern int drm_pcie_get_max_link_width(struct drm_device *dev, u32 
*mlw);
74  
75  /* platform section */
  > 76  extern int drm_platform_init(struct drm_driver *driver, struct 
platform_device *platform_device);
77  
78  #endif /* _DRM_PCI_H_ */

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Clear the VBT defaults for unused ports

[Manasi Navare]

On Tue, Mar 07, 2017 at 07:36:45PM +0200, Jani Nikula wrote:
> On Fri, 03 Mar 2017, Ville Syrjälä  wrote:
> > On Fri, Mar 03, 2017 at 05:01:42AM -0800, Manasi Navare wrote:
> >> If during VBT parsing we find that the port is unused,
> >> the driver code just bails out without clearing the
> >> defaults for that port. This can cause failures down
> >> the path through link training for unused Port.
> >> This patch fixes this issue by clearing the defaults
> >> before bailing out from the VBT parsing function.
> >> 
> >> Cc: Ville Syrjala 
> >> Signed-off-by: Manasi Navare 
> >> ---
> >>  drivers/gpu/drm/i915/intel_bios.c | 10 --
> >>  1 file changed, 8 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> >> b/drivers/gpu/drm/i915/intel_bios.c
> >> index e144f03..3ac3d24 100644
> >> --- a/drivers/gpu/drm/i915/intel_bios.c
> >> +++ b/drivers/gpu/drm/i915/intel_bios.c
> >> @@ -1148,9 +1148,15 @@ static void parse_ddi_port(struct drm_i915_private 
> >> *dev_priv, enum port port,
> >>}
> >>}
> >>}
> >> -  if (!child)
> >> -  return;
> >> +  if (!child) {
> >> +  /* Clear the DDI VBT Port info values */
> >> +  info->supports_dvi = 0;
> >> +  info->supports_hdmi = 0;
> >> +  info->supports_dp = 0;
> >> +  info->supports_edp = 0;
> >
> > I would s/0/false/ here. Although they are apparently of type 'uint8_t:1'.
> > As a followup someone might want to s/uint8_t:1/bool:1/ the definitions
> > so that the compiler will protect us against values >1 when we assign
> > these.
> >
> > Otherwise lgtm. And based on a cursory glance the bogus port A has now
> > disappaered from the ci results on fi-skl-6700k, so looks like my
> > analysis of the problem was correct.
> >
> > Reviewed-by: Ville Syrjälä 
> 
> Bikeshedding after review...
> 
> I think the approach here is a bit magical, first setting defaults on
> all platforms, then removing same defaults on platforms that a) are DDI,
> b) have VBT, c) have a high enough VBT revision, and d) do not have
> child devices.
> 
> I think I'd go with simplicity, and split out a function from
> init_vbt_defaults() to be called on platforms without VBT. It would
> initially just contain the loop to initialize
> 
>   info->supports_dvi = (port != PORT_A && port != PORT_E);
>   info->supports_hdmi = info->supports_dvi;
>   info->supports_dp = (port != PORT_E);
> 
> 
> BR,
> Jani.
>

How do we determine if the platforms have VBT or not?
So then in case of platforms with VBT, do not initialize them at all??

Regards
Manasi

 
> 
> >
> >>  
> >> +  return;
> >> +  }
> >>aux_channel = child->common.aux_channel;
> >>ddc_pin = child->common.ddc_pin;
> >>  
> >> -- 
> >> 2.1.4
> 
> -- 
> 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] ✓ Fi.CI.BAT: success for drm/i915: Ignore skl+ for debugfs/i915_sr_status

[Patchwork]

== Series Details ==

Series: drm/i915: Ignore skl+ for debugfs/i915_sr_status
URL   : https://patchwork.freedesktop.org/series/20995/
State : success

== Summary ==

Series 20995v1 drm/i915: Ignore skl+ for debugfs/i915_sr_status
https://patchwork.freedesktop.org/api/1.0/series/20995/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
incomplete -> PASS   (fi-skl-6700k) fdo#100130

fdo#100130 https://bugs.freedesktop.org/show_bug.cgi?id=100130

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 471s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 614s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 538s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 601s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 510s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 509s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 439s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 443s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 441s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 510s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 506s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 478s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 509s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 600s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 502s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 546s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 558s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 420s

510c200742ced5a91d07e48220b669a3c9b30c0c drm-tip: 2017y-03m-09d-15h-21m-14s UTC 
integration manifest
87972f8 drm/i915: Ignore skl+ for debugfs/i915_sr_status

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4119/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic.

[Ville Syrjälä]

On Thu, Mar 09, 2017 at 02:06:15PM +0100, Maarten Lankhorst wrote:
> As a proof of concept, first try to convert intel_tv, which is a rarely
> used connector. It has 5 properties, tv format and 4 margins.

Since it's so rare, if you want someone to actually test the code
it'll probably make sense to pick another connector ;)

> 
> I'm less certain about the state behavior itself, should we pass a size
> parameter to intel_connector_alloc instead, so duplicate_state
> can be done globally if it can be blindly copied?
> 
> Can we also have a atomic_check function for connectors, so the
> crtc_state->connectors_changed can be set there? It would be cleaner
> and more atomic-like.

Hmm. I think it migth be really useful only if we have some
interactions between multiple properties that really need to be
checked. We might have those already I suppose but we don't seem
to check any of it currently. So as a first step I guess we can
just keep ignoring any such issues.

> 
> To match the legacy behavior, format can be changed by probing just like
> in legacy mode.

Self modifying state irks me, but it's what we've been doing so I guess
we should keep it.

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_tv.c | 238 
> +++-
>  1 file changed, 136 insertions(+), 102 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 6ed1a3ce47b7..0fb1d8621fe8 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -48,8 +48,6 @@ struct intel_tv {
>   struct intel_encoder base;
>  
>   int type;
> - const char *tv_format;
> - int margin[4];
>   u32 save_TV_H_CTL_1;
>   u32 save_TV_H_CTL_2;
>   u32 save_TV_H_CTL_3;
> @@ -85,6 +83,16 @@ struct intel_tv {
>   u32 save_TV_CTL;
>  };
>  
> +struct intel_tv_connector_state {
> + struct drm_connector_state base;
> +
> + int format;
> + int margin[4];
> +};
> +
> +#define to_intel_tv_connector_state(state) \
> + container_of((state), struct intel_tv_connector_state, base)
> +
>  struct video_levels {
>   u16 blank, black;
>   u8 burst;
> @@ -873,32 +881,18 @@ intel_disable_tv(struct intel_encoder *encoder,
>   I915_WRITE(TV_CTL, I915_READ(TV_CTL) & ~TV_ENC_ENABLE);
>  }
>  
> -static const struct tv_mode *
> -intel_tv_mode_lookup(const char *tv_format)
> +static const struct tv_mode *intel_tv_mode_find(struct drm_connector_state 
> *conn_state)
>  {
> - int i;
> + int format = to_intel_tv_connector_state(conn_state)->format;
>  
> - for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
> - const struct tv_mode *tv_mode = _modes[i];
> -
> - if (!strcmp(tv_format, tv_mode->name))
> - return tv_mode;
> - }
> - return NULL;
> -}
> -
> -static const struct tv_mode *
> -intel_tv_mode_find(struct intel_tv *intel_tv)
> -{
> - return intel_tv_mode_lookup(intel_tv->tv_format);
> + return _modes[format];
>  }
>  
>  static enum drm_mode_status
>  intel_tv_mode_valid(struct drm_connector *connector,
>   struct drm_display_mode *mode)
>  {
> - struct intel_tv *intel_tv = intel_attached_tv(connector);
> - const struct tv_mode *tv_mode = intel_tv_mode_find(intel_tv);
> + const struct tv_mode *tv_mode = intel_tv_mode_find(connector->state);

It feels a bit fishy to use the state here. Generally that's a no-no.
But in this case I wonder if it's the right choice after all. 

Not sure if some kind of "automatic" enum value might also work. It
would at least avoid the self modifying property problem. Although I
wonder if the user would still like to know what was actually used
if they chose they automatic mode, so we might need a self modifying
RO property for the current mode anyway.

But that still leaves the problem of how the user would know which modes
they should be able to use if .get_modes()/.mode_valid() doesn't respect
the users choice of the tv format. Hmm, tricky. Might be the self
modifying property is the only good choice.

But if we would use the state here, what's the story with locking going
to be? connection_mutex is what protects this stuff, but we're not
holding that during mode enumeration.

>   int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
>  
>   if (mode->clock > max_dotclk)
> @@ -925,8 +919,7 @@ intel_tv_compute_config(struct intel_encoder *encoder,
>   struct intel_crtc_state *pipe_config,
>   struct drm_connector_state *conn_state)
>  {
> - struct intel_tv *intel_tv = enc_to_tv(encoder);
> - const struct tv_mode *tv_mode = intel_tv_mode_find(intel_tv);
> + const struct tv_mode *tv_mode = intel_tv_mode_find(conn_state);
>  
>   if (!tv_mode)
>   return false;
> @@ -1032,7 +1025,7 @@ static void intel_tv_pre_enable(struct intel_encoder 
> *encoder,
>   struct 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c

[Patchwork]

== Series Details ==

Series: drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c
URL   : https://patchwork.freedesktop.org/series/20992/
State : success

== Summary ==

Series 20992v1 drm/i915: Remove intel_ prefix from encoder variables in 
intel_ddi.c
https://patchwork.freedesktop.org/api/1.0/series/20992/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
incomplete -> PASS   (fi-skl-6700k) fdo#100130
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-bxt-t5700) fdo#100125

fdo#100130 https://bugs.freedesktop.org/show_bug.cgi?id=100130
fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 463s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 607s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 534s
fi-bxt-t5700 total:278  pass:257  dwarn:1   dfail:0   fail:0   skip:20  
time: 609s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 505s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 502s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 445s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 433s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 434s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 507s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 488s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 478s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 505s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 591s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 500s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 546s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 552s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 424s

510c200742ced5a91d07e48220b669a3c9b30c0c drm-tip: 2017y-03m-09d-15h-21m-14s UTC 
integration manifest
4f73f19 drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4118/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix request re-submission after reset

[Tvrtko Ursulin]

On 09/03/2017 08:55, Oscar Mateo wrote:

On 03/09/2017 08:50 AM, Tvrtko Ursulin wrote:


On 09/03/2017 08:42, Oscar Mateo wrote:

On 03/09/2017 02:05 AM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

In order to ensure no missed interrupts we must first re-direct
the interrupts to GuC, and only then re-submit the requests to
be replayed after a GPU reset. Otherwise context switch can fire
before GuC has been set up to receive it triggering more hangs.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Mika Kuoppala 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
Cc: Arkadiusz Hiler 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 58
+++---
  drivers/gpu/drm/i915/intel_guc_loader.c| 47

  2 files changed, 54 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index beb38e30d0e9..5b8ec0fab563 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -936,6 +936,52 @@ static void guc_reset_wq(struct i915_guc_client
*client)
  client->wq_tail = 0;
  }




  int i915_guc_submission_enable(struct drm_i915_private *dev_priv)
  {
  struct intel_guc *guc = _priv->guc;
@@ -953,13 +999,17 @@ int i915_guc_submission_enable(struct
drm_i915_private *dev_priv)
/* Take over from manual control of ELSP (execlists) */
  for_each_engine(engine, dev_priv, id) {
-const int wqi_size = sizeof(struct guc_wq_item);
-struct drm_i915_gem_request *rq;
-
  engine->submit_request = i915_guc_submit;
  engine->schedule = NULL;
+}
+
+guc_interrupts_capture(dev_priv);
+
+/* Replay the current set of previously submitted requests */
+for_each_engine(engine, dev_priv, id) {
+const int wqi_size = sizeof(struct guc_wq_item);
+struct drm_i915_gem_request *rq;


Don't you want to move the guc_interrupts_release to
i915_guc_submission_disable as well?


I can't spot anything broken in that path. We never go in that
direction with the live submission so why do you think it is needed?

Regards,

Tvrtko

Just code symmetry: if we are leaving i915_guc_submission_enable to
capture the interrupts, why doesn't the disable also releases them?
Maybe it's not very important now, but it makes a lot more sense with my
series to do proper unwinding of the whole path (I can tackle it there
if you prefer).


I think so. There is a multitude of people trying to refactor the GuC 
code at the moment so I would prefer just to fix the reset fail quickly 
and not interfere with that wider refactoring too much. Because I think 
it is not just a quick job of moving the interrupt release to get to 
full symmetry. Ack to merge then?


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix request re-submission after reset

[Oscar Mateo]

On 03/09/2017 08:50 AM, Tvrtko Ursulin wrote:


On 09/03/2017 08:42, Oscar Mateo wrote:

On 03/09/2017 02:05 AM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

In order to ensure no missed interrupts we must first re-direct
the interrupts to GuC, and only then re-submit the requests to
be replayed after a GPU reset. Otherwise context switch can fire
before GuC has been set up to receive it triggering more hangs.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Mika Kuoppala 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
Cc: Arkadiusz Hiler 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 58
+++---
  drivers/gpu/drm/i915/intel_guc_loader.c| 47

  2 files changed, 54 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index beb38e30d0e9..5b8ec0fab563 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -936,6 +936,52 @@ static void guc_reset_wq(struct i915_guc_client
*client)
  client->wq_tail = 0;
  }




  int i915_guc_submission_enable(struct drm_i915_private *dev_priv)
  {
  struct intel_guc *guc = _priv->guc;
@@ -953,13 +999,17 @@ int i915_guc_submission_enable(struct
drm_i915_private *dev_priv)
/* Take over from manual control of ELSP (execlists) */
  for_each_engine(engine, dev_priv, id) {
-const int wqi_size = sizeof(struct guc_wq_item);
-struct drm_i915_gem_request *rq;
-
  engine->submit_request = i915_guc_submit;
  engine->schedule = NULL;
+}
+
+guc_interrupts_capture(dev_priv);
+
+/* Replay the current set of previously submitted requests */
+for_each_engine(engine, dev_priv, id) {
+const int wqi_size = sizeof(struct guc_wq_item);
+struct drm_i915_gem_request *rq;


Don't you want to move the guc_interrupts_release to
i915_guc_submission_disable as well?


I can't spot anything broken in that path. We never go in that 
direction with the live submission so why do you think it is needed?


Regards,

Tvrtko
Just code symmetry: if we are leaving i915_guc_submission_enable to 
capture the interrupts, why doesn't the disable also releases them? 
Maybe it's not very important now, but it makes a lot more sense with my 
series to do proper unwinding of the whole path (I can tackle it there 
if you prefer).

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix request re-submission after reset

[Tvrtko Ursulin]

On 09/03/2017 08:42, Oscar Mateo wrote:

On 03/09/2017 02:05 AM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

In order to ensure no missed interrupts we must first re-direct
the interrupts to GuC, and only then re-submit the requests to
be replayed after a GPU reset. Otherwise context switch can fire
before GuC has been set up to receive it triggering more hangs.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Mika Kuoppala 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
Cc: Arkadiusz Hiler 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 58
+++---
  drivers/gpu/drm/i915/intel_guc_loader.c| 47

  2 files changed, 54 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index beb38e30d0e9..5b8ec0fab563 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -936,6 +936,52 @@ static void guc_reset_wq(struct i915_guc_client
*client)
  client->wq_tail = 0;
  }




  int i915_guc_submission_enable(struct drm_i915_private *dev_priv)
  {
  struct intel_guc *guc = _priv->guc;
@@ -953,13 +999,17 @@ int i915_guc_submission_enable(struct
drm_i915_private *dev_priv)
/* Take over from manual control of ELSP (execlists) */
  for_each_engine(engine, dev_priv, id) {
-const int wqi_size = sizeof(struct guc_wq_item);
-struct drm_i915_gem_request *rq;
-
  engine->submit_request = i915_guc_submit;
  engine->schedule = NULL;
+}
+
+guc_interrupts_capture(dev_priv);
+
+/* Replay the current set of previously submitted requests */
+for_each_engine(engine, dev_priv, id) {
+const int wqi_size = sizeof(struct guc_wq_item);
+struct drm_i915_gem_request *rq;


Don't you want to move the guc_interrupts_release to
i915_guc_submission_disable as well?


I can't spot anything broken in that path. We never go in that direction 
with the live submission so why do you think it is needed?


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/guc: Fix request re-submission after reset

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/guc: Fix request re-submission 
after reset
URL   : https://patchwork.freedesktop.org/series/20991/
State : success

== Summary ==

Series 20991v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20991/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
incomplete -> PASS   (fi-skl-6700k) fdo#100130

fdo#100130 https://bugs.freedesktop.org/show_bug.cgi?id=100130

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 474s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 598s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 523s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 576s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 504s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 503s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 437s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 436s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 445s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 492s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 497s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 464s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 493s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 584s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 484s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 536s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 552s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 421s

510c200742ced5a91d07e48220b669a3c9b30c0c drm-tip: 2017y-03m-09d-15h-21m-14s UTC 
integration manifest
938a1af HAX enable guc submission for CI
4c5011d drm/i915/guc: Fix request re-submission after reset

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4117/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix request re-submission after reset

[Oscar Mateo]

On 03/09/2017 02:05 AM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

In order to ensure no missed interrupts we must first re-direct
the interrupts to GuC, and only then re-submit the requests to
be replayed after a GPU reset. Otherwise context switch can fire
before GuC has been set up to receive it triggering more hangs.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Mika Kuoppala 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
Cc: Arkadiusz Hiler 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 58 +++---
  drivers/gpu/drm/i915/intel_guc_loader.c| 47 
  2 files changed, 54 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index beb38e30d0e9..5b8ec0fab563 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -936,6 +936,52 @@ static void guc_reset_wq(struct i915_guc_client *client)
client->wq_tail = 0;
  }
  



  int i915_guc_submission_enable(struct drm_i915_private *dev_priv)
  {
struct intel_guc *guc = _priv->guc;
@@ -953,13 +999,17 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  
  	/* Take over from manual control of ELSP (execlists) */

for_each_engine(engine, dev_priv, id) {
-   const int wqi_size = sizeof(struct guc_wq_item);
-   struct drm_i915_gem_request *rq;
-
engine->submit_request = i915_guc_submit;
engine->schedule = NULL;
+   }
+
+   guc_interrupts_capture(dev_priv);
+
+   /* Replay the current set of previously submitted requests */
+   for_each_engine(engine, dev_priv, id) {
+   const int wqi_size = sizeof(struct guc_wq_item);
+   struct drm_i915_gem_request *rq;
  
Don't you want to move the guc_interrupts_release to 
i915_guc_submission_disable as well?


With that, Reviewed-by: Oscar Mateo 
___
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: Convert tv/dp_mst and crt connector properties to atomic.

[Patchwork]

== Series Details ==

Series: drm/i915: Convert tv/dp_mst and crt connector properties to atomic.
URL   : https://patchwork.freedesktop.org/series/20990/
State : success

== Summary ==

Series 20990v1 drm/i915: Convert tv/dp_mst and crt connector properties to 
atomic.
https://patchwork.freedesktop.org/api/1.0/series/20990/revisions/1/mbox/

Test gem_ctx_create:
Subgroup basic-files:
pass   -> INCOMPLETE (fi-skl-6700k) fdo#100130
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-bxt-t5700) fdo#100125

fdo#100130 https://bugs.freedesktop.org/show_bug.cgi?id=100130
fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 474s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 616s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 543s
fi-bxt-t5700 total:278  pass:257  dwarn:1   dfail:0   fail:0   skip:20  
time: 610s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 507s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 501s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 446s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 435s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 437s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 507s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 491s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 480s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 509s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 601s
fi-skl-6700k total:17   pass:16   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 548s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 554s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 421s

510c200742ced5a91d07e48220b669a3c9b30c0c drm-tip: 2017y-03m-09d-15h-21m-14s UTC 
integration manifest
0f77d01 drm/i915: Convert intel_crt connector properties to atomic.
465968e drm/i915: Convert intel_dp_mst connector properties to atomic.
423cf50 drm/i915: Convert intel_tv connector properties to atomic.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4116/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] drm/i915: Optimize plane updates a bit

[Ville Syrjälä]

On Thu, Mar 09, 2017 at 04:56:23PM +0100, Maarten Lankhorst wrote:
> Hey,
> 
> Op 09-03-17 om 16:44 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä 
> >
> > Now that commit e1edbd44e23b ("drm/i915: Complain if we take too
> > long under vblank evasion.") has expose just how badly we suck,
> > it seems like a good time to optimize things a little bit.
> >
> > Prior to this one of my VLV machines exceed the 100 usec vblank
> > evade deadline pretty regularly, and at ever boot I was hitting
> > numbers as high as 500 usec. Granted that was with lockdep and
> > all kinds of other debug things enabled. After these changes
> > things seem stay below the 33 usec mark, and with all that debug
> > junk enabled we seem to staying below 22 usec.
> >
> > Note that I was testing single plane updates mostly, so I'm
> > not 100% sure multi plane updates couldn't still exceed the
> > deadline. That will need to be checked.
> I've considered doing the same before, but thanks to the commit it's clear 
> that it seems to worth the effort to do so.
> Maybe a bit more radical, but could we grab the uncore lock for the entire 
> update perhaps if it's still an issue?

Yes that might be the ultimate goal. One of the problems is that we
don't use pipe_update_start()/end() everywhere we do plane updates. Some
of those we need to fix (eg. crtc disable really should disable things
atomically). The "disable all extra planes at driver load time" case
I'd like to eliminate by having proper state readout/takeover for
planes. And then there's the legacy cursor thing. I guess we could
avoid bigger surgery by simply grabbing the lock manually around the
update_plane/disable_plane call in those places.

Another thing I'd like to figure out is how much are we wasting CPU
cycles for computing  the register values in the .update_plane() hooks.
If it's at all significant we should probably try to move absolutely
everything but the register writes out from those functions.

Oh, and we might even try to take advantage of the hardware's limite
atomic capabilities and only write the absolute minimum set of registers
under the vblank evasion (ie. just the ones that actually arm the
update to occur on the next vblank). Unfortunately the split between
the two classes of registers isn't all that clear. It would also make
it impossible to do the fps>vrefresh thing.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [drm-tip:drm-tip 777/788] include/drm/drm_pci.h:76:64: warning: 'struct platform_device' declared inside parameter list will not be visible outside of this definition or declaration

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   510c200742ced5a91d07e48220b669a3c9b30c0c
commit: 23ef59ef6dcc9b62bf077490a74df93b3bb0d530 [777/788] drm: Extract 
drm_pci.h
config: i386-randconfig-x070-201710 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 23ef59ef6dcc9b62bf077490a74df93b3bb0d530
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu/drm/drm_pci.c:29:0:
>> include/drm/drm_pci.h:76:64: warning: 'struct platform_device' declared 
>> inside parameter list will not be visible outside of this definition or 
>> declaration
extern int drm_platform_init(struct drm_driver *driver, struct 
platform_device *platform_device);
   
^~~

vim +76 include/drm/drm_pci.h

60  
61  static inline int drm_pci_set_busid(struct drm_device *dev,
62  struct drm_master *master)
63  {
64  return -ENOSYS;
65  }
66  #endif
67  
68  #define DRM_PCIE_SPEED_25 1
69  #define DRM_PCIE_SPEED_50 2
70  #define DRM_PCIE_SPEED_80 4
71  
72  extern int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 
*speed_mask);
73  extern int drm_pcie_get_max_link_width(struct drm_device *dev, u32 
*mlw);
74  
75  /* platform section */
  > 76  extern int drm_platform_init(struct drm_driver *driver, struct 
platform_device *platform_device);
77  
78  #endif /* _DRM_PCI_H_ */

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] drm/i915: Optimize plane updates a bit

[Maarten Lankhorst]

Hey,

Op 09-03-17 om 16:44 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä 
>
> Now that commit e1edbd44e23b ("drm/i915: Complain if we take too
> long under vblank evasion.") has expose just how badly we suck,
> it seems like a good time to optimize things a little bit.
>
> Prior to this one of my VLV machines exceed the 100 usec vblank
> evade deadline pretty regularly, and at ever boot I was hitting
> numbers as high as 500 usec. Granted that was with lockdep and
> all kinds of other debug things enabled. After these changes
> things seem stay below the 33 usec mark, and with all that debug
> junk enabled we seem to staying below 22 usec.
>
> Note that I was testing single plane updates mostly, so I'm
> not 100% sure multi plane updates couldn't still exceed the
> deadline. That will need to be checked.
I've considered doing the same before, but thanks to the commit it's clear that 
it seems to worth the effort to do so.
Maybe a bit more radical, but could we grab the uncore lock for the entire 
update perhaps if it's still an issue?

Patch series looks sane, might be worth fixing all chips at some point. :)

Assuming testbot is happy..

Reviewed-by: Maarten Lankhorst 

~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Fix forcewake active domain tracking

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

In commit 003342a50021 ("drm/i915: Keep track of active
forcewake domains in a bitmask") I forgot to adjust the
newly introduce fw_domains_active state across reset.

This caused the assert_forcewakes_inactive to trigger
during suspend and resume if there were user held
forcewakes.

Signed-off-by: Tvrtko Ursulin 
Fixes: 003342a50021 ("drm/i915: Keep track of active forcewake domains in a 
bitmask")
Testcase: igt/drv_suspend/forcewake
Cc: Tvrtko Ursulin 
Cc: "Paneri, Praveen" 
Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx@lists.freedesktop.org
Cc: v4.10+ 
---
 drivers/gpu/drm/i915/intel_uncore.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 2a3f35c30501..efa040847d69 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -302,22 +302,21 @@ static void intel_uncore_forcewake_reset(struct 
drm_i915_private *dev_priv,
WARN_ON(active_domains);
 
fw = dev_priv->uncore.fw_domains_active;
-   if (fw)
-   dev_priv->uncore.funcs.force_wake_put(dev_priv, fw);
+   dev_priv->uncore.funcs.force_wake_put(dev_priv, fw);
+   dev_priv->uncore.fw_domains_active = 0;
 
fw_domains_reset(dev_priv, FORCEWAKE_ALL);
 
if (restore) { /* If reset with a user forcewake, try to restore */
-   if (fw)
-   dev_priv->uncore.funcs.force_wake_get(dev_priv, fw);
+   dev_priv->uncore.funcs.force_wake_get(dev_priv, fw);
+   dev_priv->uncore.fw_domains_active = fw;
 
if (IS_GEN6(dev_priv) || IS_GEN7(dev_priv))
dev_priv->uncore.fifo_count =
fifo_free_entries(dev_priv);
-   }
-
-   if (!restore)
+   } else {
assert_forcewakes_inactive(dev_priv);
+   }
 
spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
 }
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9] drm/i915: enable scrambling

[Sharma, Shashank]

+ intel-gfx 
+ dri-devl
(missed in in-reply-to)

Regards
Shashank
-Original Message-
From: Sharma, Shashank 
Sent: Thursday, March 9, 2017 6:02 PM
To: ville.syrj...@linux.intel.com; conselv...@gmail.com
Cc: Sharma, Shashank 
Subject: [PATCH v9] drm/i915: enable scrambling

Geminilake platform sports a native HDMI 2.0 controller, and is capable of 
driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these 
higher clocks, for reduced RF footprint.

This patch checks if the monitor supports scrambling, and if required, enables 
it during the modeset.

V2: Addressed review comments from Ville:
 - Do not track scrambling status in DRM layer, track somewhere in
   driver like in intel_crtc_state.
 - Don't talk to monitor at such a low layer, set monitor scrambling
   in intel_enable_ddi() before enabling the port.

V3: Addressed review comments from Jani
 - In comments, function names, use "sink" instead of "monitor",
   so that the implementation could be close to the language of
   HDMI spec.

V4: Addressed review comment from Maarten
 - scrambling -> hdmi_scrambling
 - high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio

V5: Addressed review comments from Ville and Ander
 - Do not modifiy the crtc_state after compute_config. Move all
   scrambling and tmds_clock_ratio calcutations to compute_config.
 - While setting scrambling for source/sink, do not check the
   conditions again, just go by the crtc_state flags. This will
   simplyfy the condition checks.

V6: Addressed review comments from Ville
 - Do not add IS_GLK check in disable/enable function, instead add it
   in compute_config, while setting state flags.
 - Remove unnecessary paranthesis.
 - Simplyfy handle_sink_scrambling function as suggested.
 - Add readout code for scrambling status in get_ddi_config and add a
   check for the same in pipe_config_compare.

V7: Addressed review comments from Ander/Ville
 - No separate function for source scrambling, make it inline
 - Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
 - Do not add platform check while setting source scrambling
 - Use pipe_config instead of crtc->config to set sink scrambling
 - To readout scrambling status, Compare with SCRAMBLING_MASK
   not any of its bits
 - Remove platform check in intel_pipe_config_compare while checking
   scrambling status

V8: Fixed mege conflict, Addressed review comments from Ander
 - Remove the desciption/comment about scrambling fom the caller, move
   it to the function
 - Move the IS_GLK check into scrambling function
 - Fix alignment

V9: Fixed review comments from Ville, Ander
 - Pass the scrambling state variables as bool input to the sink_scrambling
   function and let the disable call be unconditional.
 - Fix alignments in function calls and debug messages.
 - Add kernel doc for function intel_hdmi_handle_sink_scrambling

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/i915_reg.h  |  7 
 drivers/gpu/drm/i915/intel_ddi.c | 23 +
 drivers/gpu/drm/i915/intel_display.c |  3 ++
 drivers/gpu/drm/i915/intel_drv.h | 10 ++
 drivers/gpu/drm/i915/intel_hdmi.c| 63 
 5 files changed, 106 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h 
index cc843f9..2d50fdc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7830,7 +7830,14 @@ enum {
 #define  TRANS_DDI_EDP_INPUT_B_ONOFF   (5<<12)
 #define  TRANS_DDI_EDP_INPUT_C_ONOFF   (6<<12)
 #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
+#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7) #define  
+TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
 #define  TRANS_DDI_BFI_ENABLE  (1<<4)
+#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define  TRANS_DDI_HDMI_SCRAMBLING (1<<0)
+#define  TRANS_DDI_HDMI_SCRAMBLING_MASK (TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE \
+   | TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ \
+   | TRANS_DDI_HDMI_SCRAMBLING)
 
 /* DisplayPort Transport Control */
 #define _DP_TP_CTL_A   0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ee341ef..169d2b4 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1309,6 +1309,11 @@ void intel_ddi_enable_transcoder_func(const struct 
intel_crtc_state *crtc_state)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+   if (crtc_state->hdmi_scrambling)
+   temp |= TRANS_DDI_HDMI_SCRAMBLING_MASK;
+   if (crtc_state->hdmi_high_tmds_clock_ratio)
+   temp |= TRANS_DDI_HIGH_TMDS_CHAR_RATE;
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Stop using RP_DOWN_EI on Baytrail

[Chris Wilson]

On Thu, Mar 09, 2017 at 05:24:14PM +0200, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > On Baytrail, we manually calculate busyness over the evaluation interval
> > to avoid issues with miscaluations with RC6 enabled. However, it turns
> > out that the DOWN_EI interrupt generator is completely bust - it
> > operates in two modes, continuous or never. Neither of which are
> > conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just
> > compute everything from the UP_EI which does seem to correspond to the
> > desired interval.
> >
> > v2: Fixup gen6_rps_pm_mask() as well
> >
> > Fixes: 43cf3bf084ba ("drm/i915: Improved w/a for rps on Baytrail")
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Cc:  # v4.1+
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h |  2 +-
> >  drivers/gpu/drm/i915/i915_irq.c | 28 +---
> >  drivers/gpu/drm/i915/intel_pm.c |  5 +++--
> >  3 files changed, 13 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 9c5b3dd9f6f1..d70bbbd6a5fd 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1366,7 +1366,7 @@ struct intel_gen6_power_mgmt {
> > unsigned boosts;
> >  
> > /* manual wa residency calculations */
> > -   struct intel_rps_ei up_ei, down_ei;
> > +   struct intel_rps_ei ei;
> >  
> > /*
> >  * Protects RPS/RC6 register access and PCU communication.
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index bc70e2c451b2..29b10bab38b6 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1050,10 +1050,10 @@ static void vlv_c0_read(struct drm_i915_private 
> > *dev_priv,
> >  }
> >  
> >  static bool vlv_c0_above(struct drm_i915_private *dev_priv,
> > -const struct intel_rps_ei *old,
> >  const struct intel_rps_ei *now,
> >  int threshold)
> >  {
> > +   const struct intel_rps_ei *old = _priv->rps.ei;
> > u64 time, c0;
> > unsigned int mul = 100;
> >  
> > @@ -1079,8 +1079,7 @@ static bool vlv_c0_above(struct drm_i915_private 
> > *dev_priv,
> >  
> >  void gen6_rps_reset_ei(struct drm_i915_private *dev_priv)
> >  {
> > -   vlv_c0_read(dev_priv, _priv->rps.down_ei);
> > -   dev_priv->rps.up_ei = dev_priv->rps.down_ei;
> > +   memset(_priv->rps.ei, 0, sizeof(dev_priv->rps.ei));
> 
> With this change you will always downclock with the first change
> after reset. Is this desired? (due to busy handling the rampup?).

No, it was just noticing the skip for vlv_c0_above without thinking
about the effect of ! for DOWN.
 
> I would have made it so that vlv_c0_above returns true if
> the value was reset. Then we would be on the safe side going
> upwards for the first tick.

Easier, just don't evaluate vlv_v0_above.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/5] drm/i915: Optimize VLV/CHV display FIFO updates

[ville . syrjala]

From: Ville Syrjälä 

Use I915_{READ,WRITE}_FW() for updating the DSPARB registers on
VLV/CHV. This is less expesive as we can grab the uncore.lock across
the entire sequence of reads and writes instead of each register
access grabbing it.

This also allows us to eliminate the dsparb lock entirely as the
uncore.lock now effectively protects the contents of the DSPARB
registers.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c |  1 -
 drivers/gpu/drm/i915/i915_drv.h |  3 ---
 drivers/gpu/drm/i915/intel_pm.c | 36 +---
 3 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b1e9027a4f80..debb74a2b2a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -827,7 +827,6 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
 
spin_lock_init(_priv->mm.object_stat_lock);
spin_lock_init(_priv->mmio_flip_lock);
-   spin_lock_init(_priv->wm.dsparb_lock);
mutex_init(_priv->sb_lock);
mutex_init(_priv->modeset_restore_lock);
mutex_init(_priv->av_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3002996ddbed..6af0b1d33cab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2375,9 +2375,6 @@ struct drm_i915_private {
} sagv_status;
 
struct {
-   /* protects DSPARB registers on pre-g4x/vlv/chv */
-   spinlock_t dsparb_lock;
-
/*
 * Raw watermark latency values:
 * in 0.1us units for WM0,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 99e09f63d4b3..24cdc13a416a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1358,13 +1358,19 @@ static void vlv_atomic_update_fifo(struct 
intel_atomic_state *state,
 
trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
 
-   spin_lock(_priv->wm.dsparb_lock);
+   /*
+* uncore.lock serves a double purpose here. It allows us to
+* use the less expensive I915_{READ,WRITE}_FW() functions, and
+* it protects the DSPARB registers from getting clobbered by
+* parallel updates from multiple pipes.
+*/
+   spin_lock(_priv->uncore.lock);
 
switch (crtc->pipe) {
uint32_t dsparb, dsparb2, dsparb3;
case PIPE_A:
-   dsparb = I915_READ(DSPARB);
-   dsparb2 = I915_READ(DSPARB2);
+   dsparb = I915_READ_FW(DSPARB);
+   dsparb2 = I915_READ_FW(DSPARB2);
 
dsparb &= ~(VLV_FIFO(SPRITEA, 0xff) |
VLV_FIFO(SPRITEB, 0xff));
@@ -1376,12 +1382,12 @@ static void vlv_atomic_update_fifo(struct 
intel_atomic_state *state,
dsparb2 |= (VLV_FIFO(SPRITEA_HI, sprite0_start >> 8) |
   VLV_FIFO(SPRITEB_HI, sprite1_start >> 8));
 
-   I915_WRITE(DSPARB, dsparb);
-   I915_WRITE(DSPARB2, dsparb2);
+   I915_WRITE_FW(DSPARB, dsparb);
+   I915_WRITE_FW(DSPARB2, dsparb2);
break;
case PIPE_B:
-   dsparb = I915_READ(DSPARB);
-   dsparb2 = I915_READ(DSPARB2);
+   dsparb = I915_READ_FW(DSPARB);
+   dsparb2 = I915_READ_FW(DSPARB2);
 
dsparb &= ~(VLV_FIFO(SPRITEC, 0xff) |
VLV_FIFO(SPRITED, 0xff));
@@ -1393,12 +1399,12 @@ static void vlv_atomic_update_fifo(struct 
intel_atomic_state *state,
dsparb2 |= (VLV_FIFO(SPRITEC_HI, sprite0_start >> 8) |
   VLV_FIFO(SPRITED_HI, sprite1_start >> 8));
 
-   I915_WRITE(DSPARB, dsparb);
-   I915_WRITE(DSPARB2, dsparb2);
+   I915_WRITE_FW(DSPARB, dsparb);
+   I915_WRITE_FW(DSPARB2, dsparb2);
break;
case PIPE_C:
-   dsparb3 = I915_READ(DSPARB3);
-   dsparb2 = I915_READ(DSPARB2);
+   dsparb3 = I915_READ_FW(DSPARB3);
+   dsparb2 = I915_READ_FW(DSPARB2);
 
dsparb3 &= ~(VLV_FIFO(SPRITEE, 0xff) |
 VLV_FIFO(SPRITEF, 0xff));
@@ -1410,16 +1416,16 @@ static void vlv_atomic_update_fifo(struct 
intel_atomic_state *state,
dsparb2 |= (VLV_FIFO(SPRITEE_HI, sprite0_start >> 8) |
   VLV_FIFO(SPRITEF_HI, sprite1_start >> 8));
 
-   I915_WRITE(DSPARB3, dsparb3);
-   I915_WRITE(DSPARB2, dsparb2);
+   I915_WRITE_FW(DSPARB3, dsparb3);
+   I915_WRITE_FW(DSPARB2, dsparb2);
break;
default:
break;
}
 
-   POSTING_READ(DSPARB);
+   POSTING_READ_FW(DSPARB);
 
-   

[Intel-gfx] [PATCH 3/5] drm/i915: Organize plane register writes into tighter bunches

[ville . syrjala]

From: Ville Syrjälä 

Pull all the plane register writes closer together to avoid having
a lot of unrelated stuff in between them. This will make things more
clear once we'll grab the uncore lock around the entire bunch. Also
in the future we might even consider moving more of the register
value computation out from the plane update hooks. This should make
that easier to do.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 44 +++
 drivers/gpu/drm/i915/intel_sprite.c  | 59 ++--
 2 files changed, 54 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5526a196e8a2..253f064bde3e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2984,20 +2984,6 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
if (INTEL_GEN(dev_priv) < 4) {
if (intel_crtc->pipe == PIPE_B)
dspcntr |= DISPPLANE_SEL_PIPE_B;
-
-   /* pipesrc and dspsize control the size that is scaled from,
-* which should always be the user's requested size.
-*/
-   I915_WRITE(DSPSIZE(plane),
-  ((crtc_state->pipe_src_h - 1) << 16) |
-  (crtc_state->pipe_src_w - 1));
-   I915_WRITE(DSPPOS(plane), 0);
-   } else if (IS_CHERRYVIEW(dev_priv) && plane == PLANE_B) {
-   I915_WRITE(PRIMSIZE(plane),
-  ((crtc_state->pipe_src_h - 1) << 16) |
-  (crtc_state->pipe_src_w - 1));
-   I915_WRITE(PRIMPOS(plane), 0);
-   I915_WRITE(PRIMCNSTALPHA(plane), 0);
}
 
switch (fb->format->format) {
@@ -3060,6 +3046,22 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
intel_crtc->adjusted_x = x;
intel_crtc->adjusted_y = y;
 
+   if (INTEL_GEN(dev_priv) < 4) {
+   /* pipesrc and dspsize control the size that is scaled from,
+* which should always be the user's requested size.
+*/
+   I915_WRITE(DSPSIZE(plane),
+  ((crtc_state->pipe_src_h - 1) << 16) |
+  (crtc_state->pipe_src_w - 1));
+   I915_WRITE(DSPPOS(plane), 0);
+   } else if (IS_CHERRYVIEW(dev_priv) && plane == PLANE_B) {
+   I915_WRITE(PRIMSIZE(plane),
+  ((crtc_state->pipe_src_h - 1) << 16) |
+  (crtc_state->pipe_src_w - 1));
+   I915_WRITE(PRIMPOS(plane), 0);
+   I915_WRITE(PRIMCNSTALPHA(plane), 0);
+   }
+
I915_WRITE(reg, dspcntr);
 
I915_WRITE(DSPSTRIDE(plane), fb->pitches[0]);
@@ -3344,12 +3346,7 @@ static void skylake_update_primary_plane(struct 
drm_plane *plane,
 
plane_ctl = PLANE_CTL_ENABLE;
 
-   if (IS_GEMINILAKE(dev_priv)) {
-   I915_WRITE(PLANE_COLOR_CTL(pipe, plane_id),
-  PLANE_COLOR_PIPE_GAMMA_ENABLE |
-  PLANE_COLOR_PIPE_CSC_ENABLE |
-  PLANE_COLOR_PLANE_GAMMA_DISABLE);
-   } else {
+   if (!IS_GEMINILAKE(dev_priv)) {
plane_ctl |=
PLANE_CTL_PIPE_GAMMA_ENABLE |
PLANE_CTL_PIPE_CSC_ENABLE |
@@ -3371,6 +3368,13 @@ static void skylake_update_primary_plane(struct 
drm_plane *plane,
intel_crtc->adjusted_x = src_x;
intel_crtc->adjusted_y = src_y;
 
+   if (IS_GEMINILAKE(dev_priv)) {
+   I915_WRITE(PLANE_COLOR_CTL(pipe, plane_id),
+  PLANE_COLOR_PIPE_GAMMA_ENABLE |
+  PLANE_COLOR_PIPE_CSC_ENABLE |
+  PLANE_COLOR_PLANE_GAMMA_DISABLE);
+   }
+
I915_WRITE(PLANE_CTL(pipe, plane_id), plane_ctl);
I915_WRITE(PLANE_OFFSET(pipe, plane_id), (src_y << 16) | src_x);
I915_WRITE(PLANE_STRIDE(pipe, plane_id), stride);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 300776b9e935..532db7d62290 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -233,12 +233,7 @@ skl_update_plane(struct drm_plane *drm_plane,
 
plane_ctl = PLANE_CTL_ENABLE;
 
-   if (IS_GEMINILAKE(dev_priv)) {
-   I915_WRITE(PLANE_COLOR_CTL(pipe, plane_id),
-  PLANE_COLOR_PIPE_GAMMA_ENABLE |
-  PLANE_COLOR_PIPE_CSC_ENABLE |
-  PLANE_COLOR_PLANE_GAMMA_DISABLE);
-   } else {
+   if (!IS_GEMINILAKE(dev_priv)) {
plane_ctl |=
PLANE_CTL_PIPE_GAMMA_ENABLE |
PLANE_CTL_PIPE_CSC_ENABLE |
@@ -249,12 +244,6 @@ skl_update_plane(struct 

[Intel-gfx] [PATCH 4/5] drm/i915: Use I915_READ_FW for plane updates

[ville . syrjala]

From: Ville Syrjälä 

Optimize the plane register accesses a little bit by grabbing
the uncore lock manually across the entire pile of accesses and
using I915_READ_FW().

This helps keep the pipe update vblank evade critical section
below our 100 usec deadline, particularly with lockdep enabled.
And in general we want to keep that critical section as short
as possible as it's executed with interrupts disabled.

Not all plane updates currently happen from within the vblank evade
critical section, so we must use the irqsave/irqrestore variants
of the spinlock functions in the plane hooks.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 158 ++--
 drivers/gpu/drm/i915/intel_sprite.c  | 228 ---
 2 files changed, 228 insertions(+), 158 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 253f064bde3e..abd05e0d7896 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2976,6 +2976,7 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
unsigned int rotation = plane_state->base.rotation;
int x = plane_state->base.src.x1 >> 16;
int y = plane_state->base.src.y1 >> 16;
+   unsigned long irqflags;
 
dspcntr = DISPPLANE_GAMMA_ENABLE;
 
@@ -3046,37 +3047,41 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
intel_crtc->adjusted_x = x;
intel_crtc->adjusted_y = y;
 
+   spin_lock_irqsave(_priv->uncore.lock, irqflags);
+
if (INTEL_GEN(dev_priv) < 4) {
/* pipesrc and dspsize control the size that is scaled from,
 * which should always be the user's requested size.
 */
-   I915_WRITE(DSPSIZE(plane),
-  ((crtc_state->pipe_src_h - 1) << 16) |
-  (crtc_state->pipe_src_w - 1));
-   I915_WRITE(DSPPOS(plane), 0);
+   I915_WRITE_FW(DSPSIZE(plane),
+ ((crtc_state->pipe_src_h - 1) << 16) |
+ (crtc_state->pipe_src_w - 1));
+   I915_WRITE_FW(DSPPOS(plane), 0);
} else if (IS_CHERRYVIEW(dev_priv) && plane == PLANE_B) {
-   I915_WRITE(PRIMSIZE(plane),
-  ((crtc_state->pipe_src_h - 1) << 16) |
-  (crtc_state->pipe_src_w - 1));
-   I915_WRITE(PRIMPOS(plane), 0);
-   I915_WRITE(PRIMCNSTALPHA(plane), 0);
+   I915_WRITE_FW(PRIMSIZE(plane),
+ ((crtc_state->pipe_src_h - 1) << 16) |
+ (crtc_state->pipe_src_w - 1));
+   I915_WRITE_FW(PRIMPOS(plane), 0);
+   I915_WRITE_FW(PRIMCNSTALPHA(plane), 0);
}
 
-   I915_WRITE(reg, dspcntr);
+   I915_WRITE_FW(reg, dspcntr);
 
-   I915_WRITE(DSPSTRIDE(plane), fb->pitches[0]);
+   I915_WRITE_FW(DSPSTRIDE(plane), fb->pitches[0]);
if (INTEL_GEN(dev_priv) >= 4) {
-   I915_WRITE(DSPSURF(plane),
-  intel_plane_ggtt_offset(plane_state) +
-  intel_crtc->dspaddr_offset);
-   I915_WRITE(DSPTILEOFF(plane), (y << 16) | x);
-   I915_WRITE(DSPLINOFF(plane), linear_offset);
+   I915_WRITE_FW(DSPSURF(plane),
+ intel_plane_ggtt_offset(plane_state) +
+ intel_crtc->dspaddr_offset);
+   I915_WRITE_FW(DSPTILEOFF(plane), (y << 16) | x);
+   I915_WRITE_FW(DSPLINOFF(plane), linear_offset);
} else {
-   I915_WRITE(DSPADDR(plane),
-  intel_plane_ggtt_offset(plane_state) +
-  intel_crtc->dspaddr_offset);
+   I915_WRITE_FW(DSPADDR(plane),
+ intel_plane_ggtt_offset(plane_state) +
+ intel_crtc->dspaddr_offset);
}
-   POSTING_READ(reg);
+   POSTING_READ_FW(reg);
+
+   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
 }
 
 static void i9xx_disable_primary_plane(struct drm_plane *primary,
@@ -3086,13 +3091,18 @@ static void i9xx_disable_primary_plane(struct drm_plane 
*primary,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int plane = intel_crtc->plane;
+   unsigned long irqflags;
 
-   I915_WRITE(DSPCNTR(plane), 0);
+   spin_lock_irqsave(_priv->uncore.lock, irqflags);
+
+   I915_WRITE_FW(DSPCNTR(plane), 0);
if (INTEL_INFO(dev_priv)->gen >= 4)
-   I915_WRITE(DSPSURF(plane), 0);
+   I915_WRITE_FW(DSPSURF(plane), 0);
else
-   I915_WRITE(DSPADDR(plane), 0);
-   POSTING_READ(DSPCNTR(plane));
+   

[Intel-gfx] [PATCH 2/5] drm/i915: s/__raw_i915_read32/I915_READ_FW/ in the SKL+ scanline read w/a

[ville . syrjala]

From: Ville Syrjälä 

Replace __raw_i915_read32() with I915_READ_FW() in the workaround for
the SKL+ scanline counter hardware fail. The two are the same thing
but everyone else uses I915_READ_FW() so let's follow suit.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_irq.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 70214e1fcd10..3c2109b4be2c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -817,8 +817,7 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
*crtc)
 
for (i = 0; i < 100; i++) {
udelay(1);
-   temp = __raw_i915_read32(dev_priv, PIPEDSL(pipe)) &
-   DSL_LINEMASK_GEN3;
+   temp = I915_READ_FW(PIPEDSL(pipe)) & DSL_LINEMASK_GEN3;
if (temp != position) {
position = temp;
break;
-- 
2.10.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/5] drm/i915: Use I915_READ_FW in i915_get_vblank_counter()

[ville . syrjala]

From: Ville Syrjälä 

Optimize the multi-register read in i915_get_vblank_counter() a little
bit by grabbing the uncore lock manually and using I915_READ_FW().

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_irq.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 22ac70374ac1..70214e1fcd10 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -728,6 +728,7 @@ static u32 i915_get_vblank_counter(struct drm_device *dev, 
unsigned int pipe)
struct intel_crtc *intel_crtc = intel_get_crtc_for_pipe(dev_priv,
pipe);
const struct drm_display_mode *mode = _crtc->base.hwmode;
+   unsigned long irqflags;
 
htotal = mode->crtc_htotal;
hsync_start = mode->crtc_hsync_start;
@@ -744,17 +745,21 @@ static u32 i915_get_vblank_counter(struct drm_device 
*dev, unsigned int pipe)
high_frame = PIPEFRAME(pipe);
low_frame = PIPEFRAMEPIXEL(pipe);
 
+   spin_lock_irqsave(_priv->uncore.lock, irqflags);
+
/*
 * High & low register fields aren't synchronized, so make sure
 * we get a low value that's stable across two reads of the high
 * register.
 */
do {
-   high1 = I915_READ(high_frame) & PIPE_FRAME_HIGH_MASK;
-   low   = I915_READ(low_frame);
-   high2 = I915_READ(high_frame) & PIPE_FRAME_HIGH_MASK;
+   high1 = I915_READ_FW(high_frame) & PIPE_FRAME_HIGH_MASK;
+   low   = I915_READ_FW(low_frame);
+   high2 = I915_READ_FW(high_frame) & PIPE_FRAME_HIGH_MASK;
} while (high1 != high2);
 
+   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+
high1 >>= PIPE_FRAME_HIGH_SHIFT;
pixel = low & PIPE_PIXEL_MASK;
low >>= PIPE_FRAME_LOW_SHIFT;
-- 
2.10.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/5] drm/i915: Optimize plane updates a bit

[ville . syrjala]

From: Ville Syrjälä 

Now that commit e1edbd44e23b ("drm/i915: Complain if we take too
long under vblank evasion.") has expose just how badly we suck,
it seems like a good time to optimize things a little bit.

Prior to this one of my VLV machines exceed the 100 usec vblank
evade deadline pretty regularly, and at ever boot I was hitting
numbers as high as 500 usec. Granted that was with lockdep and
all kinds of other debug things enabled. After these changes
things seem stay below the 33 usec mark, and with all that debug
junk enabled we seem to staying below 22 usec.

Note that I was testing single plane updates mostly, so I'm
not 100% sure multi plane updates couldn't still exceed the
deadline. That will need to be checked.

Ville Syrjälä (5):
  drm/i915: Use I915_READ_FW in i915_get_vblank_counter()
  drm/i915: s/__raw_i915_read32/I915_READ_FW/ in the SKL+ scanline read
w/a
  drm/i915: Organize plane register writes into tighter bunches
  drm/i915: Use I915_READ_FW for plane updates
  drm/i915: Optimize VLV/CHV display FIFO updates

 drivers/gpu/drm/i915/i915_drv.c  |   1 -
 drivers/gpu/drm/i915/i915_drv.h  |   3 -
 drivers/gpu/drm/i915/i915_irq.c  |  14 +-
 drivers/gpu/drm/i915/intel_display.c | 176 ++-
 drivers/gpu/drm/i915/intel_pm.c  |  36 +++--
 drivers/gpu/drm/i915/intel_sprite.c  | 269 ---
 6 files changed, 290 insertions(+), 209 deletions(-)

-- 
2.10.2

___
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: Stop using RP_DOWN_EI on Baytrail

[Mika Kuoppala]

Chris Wilson  writes:

> On Baytrail, we manually calculate busyness over the evaluation interval
> to avoid issues with miscaluations with RC6 enabled. However, it turns
> out that the DOWN_EI interrupt generator is completely bust - it
> operates in two modes, continuous or never. Neither of which are
> conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just
> compute everything from the UP_EI which does seem to correspond to the
> desired interval.
>
> v2: Fixup gen6_rps_pm_mask() as well
>
> Fixes: 43cf3bf084ba ("drm/i915: Improved w/a for rps on Baytrail")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc:  # v4.1+
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  2 +-
>  drivers/gpu/drm/i915/i915_irq.c | 28 +---
>  drivers/gpu/drm/i915/intel_pm.c |  5 +++--
>  3 files changed, 13 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9c5b3dd9f6f1..d70bbbd6a5fd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1366,7 +1366,7 @@ struct intel_gen6_power_mgmt {
>   unsigned boosts;
>  
>   /* manual wa residency calculations */
> - struct intel_rps_ei up_ei, down_ei;
> + struct intel_rps_ei ei;
>  
>   /*
>* Protects RPS/RC6 register access and PCU communication.
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index bc70e2c451b2..29b10bab38b6 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1050,10 +1050,10 @@ static void vlv_c0_read(struct drm_i915_private 
> *dev_priv,
>  }
>  
>  static bool vlv_c0_above(struct drm_i915_private *dev_priv,
> -  const struct intel_rps_ei *old,
>const struct intel_rps_ei *now,
>int threshold)
>  {
> + const struct intel_rps_ei *old = _priv->rps.ei;
>   u64 time, c0;
>   unsigned int mul = 100;
>  
> @@ -1079,8 +1079,7 @@ static bool vlv_c0_above(struct drm_i915_private 
> *dev_priv,
>  
>  void gen6_rps_reset_ei(struct drm_i915_private *dev_priv)
>  {
> - vlv_c0_read(dev_priv, _priv->rps.down_ei);
> - dev_priv->rps.up_ei = dev_priv->rps.down_ei;
> + memset(_priv->rps.ei, 0, sizeof(dev_priv->rps.ei));

With this change you will always downclock with the first change
after reset. Is this desired? (due to busy handling the rampup?).

I would have made it so that vlv_c0_above returns true if
the value was reset. Then we would be on the safe side going
upwards for the first tick.

-Mika


>  }
>  
>  static u32 vlv_wa_c0_ei(struct drm_i915_private *dev_priv, u32 pm_iir)
> @@ -1088,28 +1087,19 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
> *dev_priv, u32 pm_iir)
>   struct intel_rps_ei now;
>   u32 events = 0;
>  
> - if ((pm_iir & (GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED)) 
> == 0)
> + if ((pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) == 0)
>   return 0;
>  
>   vlv_c0_read(dev_priv, );
>   if (now.cz_clock == 0)
>   return 0;
>  
> - if (pm_iir & GEN6_PM_RP_DOWN_EI_EXPIRED) {
> - if (!vlv_c0_above(dev_priv,
> -   _priv->rps.down_ei, ,
> -   dev_priv->rps.down_threshold))
> - events |= GEN6_PM_RP_DOWN_THRESHOLD;
> - dev_priv->rps.down_ei = now;
> - }
> + if (vlv_c0_above(dev_priv, , dev_priv->rps.up_threshold))
> + events |= GEN6_PM_RP_UP_THRESHOLD;
> + else if (!vlv_c0_above(dev_priv, , dev_priv->rps.down_threshold))
> + events |= GEN6_PM_RP_DOWN_THRESHOLD;
>  
> - if (pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) {
> - if (vlv_c0_above(dev_priv,
> -  _priv->rps.up_ei, ,
> -  dev_priv->rps.up_threshold))
> - events |= GEN6_PM_RP_UP_THRESHOLD;
> - dev_priv->rps.up_ei = now;
> - }
> + dev_priv->rps.ei = now;
>  
>   return events;
>  }
> @@ -4250,7 +4240,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
>   /* Let's track the enabled rps events */
>   if (IS_VALLEYVIEW(dev_priv))
>   /* WaGsvRC0ResidencyMethod:vlv */
> - dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | 
> GEN6_PM_RP_UP_EI_EXPIRED;
> + dev_priv->pm_rps_events = GEN6_PM_RP_UP_EI_EXPIRED;
>   else
>   dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
>  
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ac0cd82f61e5..56472905d782 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4916,8 +4916,9 @@ static u32 gen6_rps_pm_mask(struct drm_i915_private 
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: make context status notifier head be per engine (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: make context status notifier head be per engine (rev2)
URL   : https://patchwork.freedesktop.org/series/20552/
State : success

== Summary ==

Series 20552v2 drm/i915: make context status notifier head be per engine
https://patchwork.freedesktop.org/api/1.0/series/20552/revisions/2/mbox/

Test gem_ctx_create:
Subgroup basic-files:
incomplete -> PASS   (fi-skl-6700k) fdo#100130
Test gem_exec_flush:
Subgroup basic-uc-ro-default:
incomplete -> PASS   (fi-kbl-7500u) fdo#100130

fdo#100130 https://bugs.freedesktop.org/show_bug.cgi?id=100130

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 465s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 613s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 532s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 612s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 506s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 500s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 443s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 432s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 447s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 505s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 491s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 470s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 509s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 597s
fi-skl-6700k total:53   pass:45   dwarn:0   dfail:0   fail:0   skip:7   
time: 0s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 547s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 558s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 419s

789c80247ee92848a46d66a32ca723e16a261913 drm-tip: 2017y-03m-09d-12h-32m-54s UTC 
integration manifest
f793ac6 drm/i915: make context status notifier head be per engine

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4115/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: cleanup patch for intel_ddi.c

[Sharma, Shashank]

Sure, Thanks for this information. 
Will give this a try. 

Regards
Shashank
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] 
Sent: Thursday, March 9, 2017 5:04 PM
To: Sharma, Shashank 
Cc: Conselvan De Oliveira, Ander ; 
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: cleanup patch for intel_ddi.c

On Thu, Mar 09, 2017 at 04:28:20PM +0530, Shashank Sharma wrote:
> In I915 driver, there are many places where variable name for 
> intel_encoder object is given as 'intel_encoder' whereas it would make 
> more sense in many places to call it just 'encoder'.
> 
> This patch does a similar cleanup in file intel_ddi.c.
> 
> PS: There are few functions where both drm_encoder and intel_encoder 
> are present. For such functions, this patch does nothing.
> 
> Suggested-by: Ander Conselvan De Oliveira 
> Signed-off-by: Shashank Sharma 

Just FYI. This sort of cleanup is pretty nice to perform with coccinelle.
It's a somewhat frustrating tool at times, but using it generally makes patches 
like this easier to review as you can mostly just review the semantic patch and 
don't have to comb the actual diff too closely.

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 66 
> 
>  1 file changed, 33 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0467676..ee341ef 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -821,11 +821,11 @@ void intel_ddi_init_dp_buf_reg(struct 
> intel_encoder *encoder)  intel_ddi_get_crtc_encoder(struct intel_crtc 
> *crtc)  {
>   struct drm_device *dev = crtc->base.dev;
> - struct intel_encoder *intel_encoder, *ret = NULL;
> + struct intel_encoder *encoder, *ret = NULL;
>   int num_encoders = 0;
>  
> - for_each_encoder_on_crtc(dev, >base, intel_encoder) {
> - ret = intel_encoder;
> + for_each_encoder_on_crtc(dev, >base, encoder) {
> + ret = encoder;
>   num_encoders++;
>   }
>  
> @@ -1130,12 +1130,12 @@ void intel_ddi_clock_get(struct intel_encoder 
> *encoder,  static bool  hsw_ddi_pll_select(struct intel_crtc 
> *intel_crtc,
>  struct intel_crtc_state *crtc_state,
> -struct intel_encoder *intel_encoder)
> +struct intel_encoder *encoder)
>  {
>   struct intel_shared_dpll *pll;
>  
>   pll = intel_get_shared_dpll(intel_crtc, crtc_state,
> - intel_encoder);
> + encoder);
>   if (!pll)
>   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(intel_crtc->pipe));
> @@ -1146,11 +1146,11 @@ void intel_ddi_clock_get(struct intel_encoder 
> *encoder,  static bool  skl_ddi_pll_select(struct intel_crtc 
> *intel_crtc,
>  struct intel_crtc_state *crtc_state,
> -struct intel_encoder *intel_encoder)
> +struct intel_encoder *encoder)
>  {
>   struct intel_shared_dpll *pll;
>  
> - pll = intel_get_shared_dpll(intel_crtc, crtc_state, intel_encoder);
> + pll = intel_get_shared_dpll(intel_crtc, crtc_state, encoder);
>   if (pll == NULL) {
>   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(intel_crtc->pipe));
> @@ -1163,9 +1163,9 @@ void intel_ddi_clock_get(struct intel_encoder 
> *encoder,  static bool  bxt_ddi_pll_select(struct intel_crtc 
> *intel_crtc,
>  struct intel_crtc_state *crtc_state,
> -struct intel_encoder *intel_encoder)
> +struct intel_encoder *encoder)
>  {
> - return !!intel_get_shared_dpll(intel_crtc, crtc_state, intel_encoder);
> + return !!intel_get_shared_dpll(intel_crtc, crtc_state, encoder);
>  }
>  
>  /*
> @@ -1179,27 +1179,27 @@ bool intel_ddi_pll_select(struct intel_crtc 
> *intel_crtc,
> struct intel_crtc_state *crtc_state)  {
>   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> - struct intel_encoder *intel_encoder =
> + struct intel_encoder *encoder =
>   intel_ddi_get_crtc_new_encoder(crtc_state);
>  
>   if (IS_GEN9_BC(dev_priv))
>   return skl_ddi_pll_select(intel_crtc, crtc_state,
> -   intel_encoder);
> +   encoder);
>   else if (IS_GEN9_LP(dev_priv))
>   return bxt_ddi_pll_select(intel_crtc, crtc_state,
> -   intel_encoder);
> +   encoder);
>   else
>   return hsw_ddi_pll_select(intel_crtc, crtc_state,
> -   intel_encoder);
> + 

[Intel-gfx] [PATCH v2] drm/i915/gvt: add enable_execlists check before enable gvt

[Chuanxiao Dong]

The GVT-g needs execlists to be enabled otherwise gvt should be
disabled. Add a check for enable_execlists before enabling gvt.

v2: use DRM_INFO in response to the user action

Signed-off-by: Chuanxiao Dong 
---
 drivers/gpu/drm/i915/intel_gvt.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index d23c0fc..8c04eca 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -77,6 +77,11 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
goto bail;
}
 
+   if (!i915.enable_execlists) {
+   DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to 
disabled execlist submission [i915.enable_execlists module parameter]\n");
+   goto bail;
+   }
+
/*
 * We're not in host or fail to find a MPT module, disable GVT-g
 */
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: cleanup patch for intel_ddi.c

[Ville Syrjälä]

On Thu, Mar 09, 2017 at 04:28:20PM +0530, Shashank Sharma wrote:
> In I915 driver, there are many places where variable name for
> intel_encoder object is given as 'intel_encoder' whereas it would
> make more sense in many places to call it just 'encoder'.
> 
> This patch does a similar cleanup in file intel_ddi.c.
> 
> PS: There are few functions where both drm_encoder and intel_encoder
> are present. For such functions, this patch does nothing.
> 
> Suggested-by: Ander Conselvan De Oliveira 
> Signed-off-by: Shashank Sharma 

Just FYI. This sort of cleanup is pretty nice to perform with coccinelle.
It's a somewhat frustrating tool at times, but using it generally makes
patches like this easier to review as you can mostly just review the
semantic patch and don't have to comb the actual diff too closely.

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 66 
> 
>  1 file changed, 33 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0467676..ee341ef 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -821,11 +821,11 @@ void intel_ddi_init_dp_buf_reg(struct intel_encoder 
> *encoder)
>  intel_ddi_get_crtc_encoder(struct intel_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->base.dev;
> - struct intel_encoder *intel_encoder, *ret = NULL;
> + struct intel_encoder *encoder, *ret = NULL;
>   int num_encoders = 0;
>  
> - for_each_encoder_on_crtc(dev, >base, intel_encoder) {
> - ret = intel_encoder;
> + for_each_encoder_on_crtc(dev, >base, encoder) {
> + ret = encoder;
>   num_encoders++;
>   }
>  
> @@ -1130,12 +1130,12 @@ void intel_ddi_clock_get(struct intel_encoder 
> *encoder,
>  static bool
>  hsw_ddi_pll_select(struct intel_crtc *intel_crtc,
>  struct intel_crtc_state *crtc_state,
> -struct intel_encoder *intel_encoder)
> +struct intel_encoder *encoder)
>  {
>   struct intel_shared_dpll *pll;
>  
>   pll = intel_get_shared_dpll(intel_crtc, crtc_state,
> - intel_encoder);
> + encoder);
>   if (!pll)
>   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(intel_crtc->pipe));
> @@ -1146,11 +1146,11 @@ void intel_ddi_clock_get(struct intel_encoder 
> *encoder,
>  static bool
>  skl_ddi_pll_select(struct intel_crtc *intel_crtc,
>  struct intel_crtc_state *crtc_state,
> -struct intel_encoder *intel_encoder)
> +struct intel_encoder *encoder)
>  {
>   struct intel_shared_dpll *pll;
>  
> - pll = intel_get_shared_dpll(intel_crtc, crtc_state, intel_encoder);
> + pll = intel_get_shared_dpll(intel_crtc, crtc_state, encoder);
>   if (pll == NULL) {
>   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(intel_crtc->pipe));
> @@ -1163,9 +1163,9 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
>  static bool
>  bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
>  struct intel_crtc_state *crtc_state,
> -struct intel_encoder *intel_encoder)
> +struct intel_encoder *encoder)
>  {
> - return !!intel_get_shared_dpll(intel_crtc, crtc_state, intel_encoder);
> + return !!intel_get_shared_dpll(intel_crtc, crtc_state, encoder);
>  }
>  
>  /*
> @@ -1179,27 +1179,27 @@ bool intel_ddi_pll_select(struct intel_crtc 
> *intel_crtc,
> struct intel_crtc_state *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> - struct intel_encoder *intel_encoder =
> + struct intel_encoder *encoder =
>   intel_ddi_get_crtc_new_encoder(crtc_state);
>  
>   if (IS_GEN9_BC(dev_priv))
>   return skl_ddi_pll_select(intel_crtc, crtc_state,
> -   intel_encoder);
> +   encoder);
>   else if (IS_GEN9_LP(dev_priv))
>   return bxt_ddi_pll_select(intel_crtc, crtc_state,
> -   intel_encoder);
> +   encoder);
>   else
>   return hsw_ddi_pll_select(intel_crtc, crtc_state,
> -   intel_encoder);
> +   encoder);
>  }
>  
>  void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
> + struct intel_encoder *encoder = intel_ddi_get_crtc_encoder(crtc);
>   

[Intel-gfx] [PATCH 1/5] drm/i915: Use new atomic iterator macros in ddi

[Maarten Lankhorst]

Use for_each_new_connector_in_state instead of for_each_connector_in_state.
Also make the function static, it's only used inside intel_ddi.c

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
 drivers/gpu/drm/i915/intel_drv.h | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 04676760e6fd..4da81d4ae166 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -837,7 +837,7 @@ intel_ddi_get_crtc_encoder(struct intel_crtc *crtc)
return ret;
 }
 
-struct intel_encoder *
+static struct intel_encoder *
 intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
@@ -850,7 +850,7 @@ intel_ddi_get_crtc_new_encoder(struct intel_crtc_state 
*crtc_state)
 
state = crtc_state->base.state;
 
-   for_each_connector_in_state(state, connector, connector_state, i) {
+   for_each_new_connector_in_state(state, connector, connector_state, i) {
if (connector_state->crtc != crtc_state->base.crtc)
continue;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 578f7d20501f..937623ff6d7c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1239,8 +1239,6 @@ bool intel_ddi_is_audio_enabled(struct drm_i915_private 
*dev_priv,
 struct intel_crtc *intel_crtc);
 void intel_ddi_get_config(struct intel_encoder *encoder,
  struct intel_crtc_state *pipe_config);
-struct intel_encoder *
-intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state);
 
 void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder);
 void intel_ddi_clock_get(struct intel_encoder *encoder,
-- 
2.7.4

___
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: cleanup patch for intel_ddi.c

[Patchwork]

== Series Details ==

Series: drm/i915: cleanup patch for intel_ddi.c
URL   : https://patchwork.freedesktop.org/series/20984/
State : success

== Summary ==

Series 20984v1 drm/i915: cleanup patch for intel_ddi.c
https://patchwork.freedesktop.org/api/1.0/series/20984/revisions/1/mbox/

Test gem_ctx_create:
Subgroup basic-files:
incomplete -> PASS   (fi-skl-6700k)
Test gem_exec_flush:
Subgroup basic-uc-ro-default:
incomplete -> PASS   (fi-kbl-7500u)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 470s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 613s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 535s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 507s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 502s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 440s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 433s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 446s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 507s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 488s
fi-kbl-7500u total:58   pass:50   dwarn:0   dfail:0   fail:0   skip:7   
time: 0s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 502s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 599s
fi-skl-6700k total:51   pass:43   dwarn:0   dfail:0   fail:0   skip:7   
time: 0s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 555s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 558s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 420s
fi-bxt-t5700 failed to collect. IGT log at Patchwork_4114/fi-bxt-t5700/igt.log

789c80247ee92848a46d66a32ca723e16a261913 drm-tip: 2017y-03m-09d-12h-32m-54s UTC 
integration manifest
63fc381 drm/i915: cleanup patch for intel_ddi.c

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4114/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/5] drm/i915: Use new atomic iterator macros in cdclk

[Maarten Lankhorst]

Calculating the max pixel rate requires the new state, so use it there.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index de5ce6bfc7d7..c2cc33f3d888 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1470,7 +1470,7 @@ static int intel_max_pixel_rate(struct drm_atomic_state 
*state)
memcpy(intel_state->min_pixclk, dev_priv->min_pixclk,
   sizeof(intel_state->min_pixclk));
 
-   for_each_crtc_in_state(state, crtc, cstate, i) {
+   for_each_new_crtc_in_state(state, crtc, cstate, i) {
int pixel_rate;
 
crtc_state = to_intel_crtc_state(cstate);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/5] drm/i915: Use new atomic iterator macros in display code

[Maarten Lankhorst]

Add a big fat warning in __intel_display_resume that the old state is
invalid, and use the correct state everywhere.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 161 ++-
 1 file changed, 82 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5526a196e8a2..83f86cf44f66 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3464,7 +3464,12 @@ __intel_display_resume(struct drm_device *dev,
if (!state)
return 0;
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   /*
+* We've duplicated the state, pointers to the old state are invalid.
+*
+* Don't attempt to use the old state until we commit the duplicated 
state.
+*/
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
/*
 * Force recalculation even if we restore
 * current state. With fast modeset this may not result
@@ -5002,13 +5007,12 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
}
 }
 
-static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state)
+static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
+  struct intel_crtc_state *pipe_config)
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc_state *pipe_config =
-   to_intel_crtc_state(crtc->base.state);
struct drm_atomic_state *old_state = old_crtc_state->base.state;
struct drm_plane *primary = crtc->base.primary;
struct drm_plane_state *old_pri_state =
@@ -5105,12 +5109,11 @@ static void intel_encoders_pre_pll_enable(struct 
drm_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct drm_atomic_state *old_state)
 {
-   struct drm_connector_state *old_conn_state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
-   struct drm_connector_state *conn_state = conn->state;
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);
 
@@ -5126,12 +5129,11 @@ static void intel_encoders_pre_enable(struct drm_crtc 
*crtc,
  struct intel_crtc_state *crtc_state,
  struct drm_atomic_state *old_state)
 {
-   struct drm_connector_state *old_conn_state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
-   struct drm_connector_state *conn_state = conn->state;
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);
 
@@ -5147,12 +5149,11 @@ static void intel_encoders_enable(struct drm_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct drm_atomic_state *old_state)
 {
-   struct drm_connector_state *old_conn_state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
-   struct drm_connector_state *conn_state = conn->state;
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);
 
@@ -5172,7 +5173,7 @@ static void intel_encoders_disable(struct drm_crtc *crtc,
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
+   for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(old_conn_state->best_encoder);
 
@@ -5192,7 +5193,7 @@ static void intel_encoders_post_disable(struct drm_crtc 
*crtc,
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
+   for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(old_conn_state->best_encoder);
 
@@ -5212,7 +5213,7 @@ static void 

[Intel-gfx] [PATCH 3/5] drm/i915: Use new atomic iterator macros in wm code

[Maarten Lankhorst]

The watermark code needs to look at the new allocations, so use
for_each_new_crtc_in_state everywhere.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 99e09f63d4b3..8670ef7707e7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4120,7 +4120,7 @@ pipes_modified(struct drm_atomic_state *state)
struct drm_crtc_state *cstate;
uint32_t i, ret = 0;
 
-   for_each_crtc_in_state(state, crtc, cstate, i)
+   for_each_new_crtc_in_state(state, crtc, cstate, i)
ret |= drm_crtc_mask(crtc);
 
return ret;
@@ -4263,7 +4263,7 @@ skl_print_wm_changes(const struct drm_atomic_state *state)
const struct skl_ddb_allocation *new_ddb = _state->wm_results.ddb;
int i;
 
-   for_each_crtc_in_state(state, crtc, cstate, i) {
+   for_each_new_crtc_in_state(state, crtc, cstate, i) {
const struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
 
@@ -4305,7 +4305,7 @@ skl_compute_wm(struct drm_atomic_state *state)
 * since any racing commits that want to update them would need to
 * hold _all_ CRTC state mutexes.
 */
-   for_each_crtc_in_state(state, crtc, cstate, i)
+   for_each_new_crtc_in_state(state, crtc, cstate, i)
changed = true;
if (!changed)
return 0;
@@ -4327,7 +4327,7 @@ skl_compute_wm(struct drm_atomic_state *state)
 * should allow skl_update_pipe_wm() to return failure in cases where
 * no suitable watermark values can be found.
 */
-   for_each_crtc_in_state(state, crtc, cstate, i) {
+   for_each_new_crtc_in_state(state, crtc, cstate, i) {
struct intel_crtc_state *intel_cstate =
to_intel_crtc_state(cstate);
const struct skl_pipe_wm *old_pipe_wm =
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/5] drm/i915: Use new atomic iterator macros.

[Maarten Lankhorst]

Some small patchset to deal with the atomic iterator changes.

Maarten Lankhorst (5):
  drm/i915: Use new atomic iterator macros in ddi
  drm/i915: Use new atomic iterator macros in fbc
  drm/i915: Use new atomic iterator macros in wm code
  drm/i915: Use new atomic iterator macros in display code
  drm/i915: Use new atomic iterator macros in cdclk

 drivers/gpu/drm/i915/intel_cdclk.c   |   2 +-
 drivers/gpu/drm/i915/intel_ddi.c |   4 +-
 drivers/gpu/drm/i915/intel_display.c | 161 ++-
 drivers/gpu/drm/i915/intel_drv.h |   2 -
 drivers/gpu/drm/i915/intel_fbc.c |   2 +-
 drivers/gpu/drm/i915/intel_pm.c  |   8 +-
 6 files changed, 90 insertions(+), 89 deletions(-)

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/5] drm/i915: Use new atomic iterator macros in fbc

[Maarten Lankhorst]

Use for_each_new_plane_in_state, only the new state is needed.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_fbc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 17d418b23d77..ded2add18b26 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1061,7 +1061,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
 * plane. We could go for fancier schemes such as checking the plane
 * size, but this would just affect the few platforms that don't tie FBC
 * to pipe or plane A. */
-   for_each_plane_in_state(state, plane, plane_state, i) {
+   for_each_new_plane_in_state(state, plane, plane_state, i) {
struct intel_plane_state *intel_plane_state =
to_intel_plane_state(plane_state);
struct intel_crtc_state *intel_crtc_state;
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: add enable_execlists check before enable gvt

[Dong, Chuanxiao]

> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Thursday, March 9, 2017 9:48 PM
> To: Chris Wilson; Dong, Chuanxiao
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/gvt: add enable_execlists check
> before enable gvt
> 
> On Thu, 09 Mar 2017, Chris Wilson  wrote:
> > On Thu, Mar 09, 2017 at 01:03:17PM +, Dong, Chuanxiao wrote:
> >> The message printed is longer than 80 characters, and checkpatch tool
> also complain with " quoted string split across lines" by splitting to 
> multiple
> lines. So should I use the message print like below?
> >>
> >> DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to ");
> >> DRM_INFO("disabled execlist submission ");
> >> DRM_INFO("[i915.enable_execlists module parameter]\n");
> >>
> >> Or any better idea?
> >
> > Just ignore checkpatch. Either split the line or not, that's up to you
> > :)
> 
> Btw ignoring checkpatch is not general advise. Please do always look at
> checkpatch results, it does give helpful feedback on silly mistakes. But just
> don't regard it as the final authority on kernel style, use your own 
> discretion.
> In this case, checkpatch is just silly.

I see. Thanks Chris and Jani for the guide. :) Will send out the v2 with the 
suggested message.

Thanks
Chuanxiao

> 
> 
> BR,
> Jani.
> 
> 
> --
> 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] drm/i915: Ignore skl+ for debugfs/i915_sr_status

[Ville Syrjälä]

On Thu, Mar 09, 2017 at 02:20:49PM +, Chris Wilson wrote:
> There is no easily digestible single self-refresh status bit, so don't
> report one for debugfs/i915_sr_status.
> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 59d1eaf75b21..31bce5130ce6 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1755,7 +1755,9 @@ static int i915_sr_status(struct seq_file *m, void 
> *unused)
>   intel_runtime_pm_get(dev_priv);
>   intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
>  
> - if (HAS_PCH_SPLIT(dev_priv))
> + if (INTEL_GEN(dev_priv) >= 9)
> + /* no global SR status; inspect per-plane WM */;
> + else if (HAS_PCH_SPLIT(dev_priv))
>   sr_enabled = I915_READ(WM1_LP_ILK) & WM1_LP_SR_EN;
>   else if (IS_I965GM(dev_priv) || IS_G4X(dev_priv) ||
>IS_I945G(dev_priv) || IS_I945GM(dev_priv))
> -- 
> 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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix vGPU balloon for ggtt guard page

[Patchwork]

== Series Details ==

Series: drm/i915: Fix vGPU balloon for ggtt guard page
URL   : https://patchwork.freedesktop.org/series/20983/
State : failure

== Summary ==

Series 20983v1 drm/i915: Fix vGPU balloon for ggtt guard page
https://patchwork.freedesktop.org/api/1.0/series/20983/revisions/1/mbox/

Test gem_ctx_create:
Subgroup basic-files:
incomplete -> PASS   (fi-skl-6700k)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> INCOMPLETE (fi-kbl-7500u)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 464s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 614s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 544s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 599s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 508s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 498s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 441s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 436s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 434s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 502s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 489s
fi-kbl-7500u total:51   pass:43   dwarn:0   dfail:0   fail:0   skip:7   
time: 0s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 511s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 598s
fi-skl-6700k total:51   pass:43   dwarn:0   dfail:0   fail:0   skip:7   
time: 0s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 547s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 558s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 424s

789c80247ee92848a46d66a32ca723e16a261913 drm-tip: 2017y-03m-09d-12h-32m-54s UTC 
integration manifest
6040acc drm/i915: Fix vGPU balloon for ggtt guard page

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4113/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Ignore skl+ for debugfs/i915_sr_status

[Chris Wilson]

There is no easily digestible single self-refresh status bit, so don't
report one for debugfs/i915_sr_status.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 59d1eaf75b21..31bce5130ce6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1755,7 +1755,9 @@ static int i915_sr_status(struct seq_file *m, void 
*unused)
intel_runtime_pm_get(dev_priv);
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
 
-   if (HAS_PCH_SPLIT(dev_priv))
+   if (INTEL_GEN(dev_priv) >= 9)
+   /* no global SR status; inspect per-plane WM */;
+   else if (HAS_PCH_SPLIT(dev_priv))
sr_enabled = I915_READ(WM1_LP_ILK) & WM1_LP_SR_EN;
else if (IS_I965GM(dev_priv) || IS_G4X(dev_priv) ||
 IS_I945G(dev_priv) || IS_I945GM(dev_priv))
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: add enable_execlists check before enable gvt

[Jani Nikula]

On Thu, 09 Mar 2017, Chris Wilson  wrote:
> On Thu, Mar 09, 2017 at 01:03:17PM +, Dong, Chuanxiao wrote:
>> The message printed is longer than 80 characters, and checkpatch tool also 
>> complain with " quoted string split across lines" by splitting to multiple 
>> lines. So should I use the message print like below?
>> 
>> DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to ");
>> DRM_INFO("disabled execlist submission ");
>> DRM_INFO("[i915.enable_execlists module parameter]\n");
>> 
>> Or any better idea?
>
> Just ignore checkpatch. Either split the line or not, that's up to you :)

Btw ignoring checkpatch is not general advise. Please do always look at
checkpatch results, it does give helpful feedback on silly mistakes. But
just don't regard it as the final authority on kernel style, use your
own discretion. In this case, checkpatch is just silly.


BR,
Jani.


-- 
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 v2] drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c

[Shashank Sharma]

In I915 driver, there are many places where variable name for
intel_encoder object is given as 'intel_encoder' whereas it would
make more sense to call it just 'encoder' when possible.

This patch does this cleanup in file intel_ddi.c.

PS: There are few functions where both drm_encoder and intel_encoder
are present. For such functions, this patch does nothing.

Suggested-by: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
Acked-by: Jani Nikula 
Reviewed-by: Ander Conselvan De Oliveira 
---
 drivers/gpu/drm/i915/intel_ddi.c | 66 
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0467676..ee341ef 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -821,11 +821,11 @@ void intel_ddi_init_dp_buf_reg(struct intel_encoder 
*encoder)
 intel_ddi_get_crtc_encoder(struct intel_crtc *crtc)
 {
struct drm_device *dev = crtc->base.dev;
-   struct intel_encoder *intel_encoder, *ret = NULL;
+   struct intel_encoder *encoder, *ret = NULL;
int num_encoders = 0;
 
-   for_each_encoder_on_crtc(dev, >base, intel_encoder) {
-   ret = intel_encoder;
+   for_each_encoder_on_crtc(dev, >base, encoder) {
+   ret = encoder;
num_encoders++;
}
 
@@ -1130,12 +1130,12 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
 static bool
 hsw_ddi_pll_select(struct intel_crtc *intel_crtc,
   struct intel_crtc_state *crtc_state,
-  struct intel_encoder *intel_encoder)
+  struct intel_encoder *encoder)
 {
struct intel_shared_dpll *pll;
 
pll = intel_get_shared_dpll(intel_crtc, crtc_state,
-   intel_encoder);
+   encoder);
if (!pll)
DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
 pipe_name(intel_crtc->pipe));
@@ -1146,11 +1146,11 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
 static bool
 skl_ddi_pll_select(struct intel_crtc *intel_crtc,
   struct intel_crtc_state *crtc_state,
-  struct intel_encoder *intel_encoder)
+  struct intel_encoder *encoder)
 {
struct intel_shared_dpll *pll;
 
-   pll = intel_get_shared_dpll(intel_crtc, crtc_state, intel_encoder);
+   pll = intel_get_shared_dpll(intel_crtc, crtc_state, encoder);
if (pll == NULL) {
DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
 pipe_name(intel_crtc->pipe));
@@ -1163,9 +1163,9 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
 static bool
 bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
   struct intel_crtc_state *crtc_state,
-  struct intel_encoder *intel_encoder)
+  struct intel_encoder *encoder)
 {
-   return !!intel_get_shared_dpll(intel_crtc, crtc_state, intel_encoder);
+   return !!intel_get_shared_dpll(intel_crtc, crtc_state, encoder);
 }
 
 /*
@@ -1179,27 +1179,27 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc,
  struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
-   struct intel_encoder *intel_encoder =
+   struct intel_encoder *encoder =
intel_ddi_get_crtc_new_encoder(crtc_state);
 
if (IS_GEN9_BC(dev_priv))
return skl_ddi_pll_select(intel_crtc, crtc_state,
- intel_encoder);
+ encoder);
else if (IS_GEN9_LP(dev_priv))
return bxt_ddi_pll_select(intel_crtc, crtc_state,
- intel_encoder);
+ encoder);
else
return hsw_ddi_pll_select(intel_crtc, crtc_state,
- intel_encoder);
+ encoder);
 }
 
 void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
+   struct intel_encoder *encoder = intel_ddi_get_crtc_encoder(crtc);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
-   int type = intel_encoder->type;
+   int type = encoder->type;
uint32_t temp;
 
if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP || type == 
INTEL_OUTPUT_DP_MST) {
@@ -1244,12 +1244,12 @@ void intel_ddi_set_vc_payload_alloc(const struct 
intel_crtc_state 

Re: [Intel-gfx] [PATCH] drm/i915/gvt: add enable_execlists check before enable gvt

[Chris Wilson]

On Thu, Mar 09, 2017 at 01:03:17PM +, Dong, Chuanxiao wrote:
> 
> 
> > -Original Message-
> > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> > Behalf Of Chris Wilson
> > Sent: Thursday, March 9, 2017 8:45 PM
> > To: Dong, Chuanxiao 
> > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/gvt: add enable_execlists check
> > before enable gvt
> > 
> > On Thu, Mar 09, 2017 at 12:32:18PM +, Dong, Chuanxiao wrote:
> > > Hi,
> > >
> > > Any comments to this patch?
> > >
> > > Thanks
> > > Chuanxiao
> > >
> > > > -Original Message-
> > > > From: intel-gvt-dev
> > > > [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On Behalf Of
> > > > Chuanxiao Dong
> > > > Sent: Monday, March 6, 2017 1:16 PM
> > > > To: intel-gfx@lists.freedesktop.org;
> > > > intel-gvt-...@lists.freedesktop.org
> > > > Subject: [PATCH] drm/i915/gvt: add enable_execlists check before
> > > > enable gvt
> > > >
> > > > The GVT-g needs execlists to be enabled otherwise gvt should be 
> > > > disabled.
> > > > Add a check for enable_execlists before enabling gvt.
> > > >
> > > > Signed-off-by: Chuanxiao Dong 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_gvt.c | 5 +
> > > >  1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_gvt.c
> > > > b/drivers/gpu/drm/i915/intel_gvt.c
> > > > index d23c0fc..3799cb3 100644
> > > > --- a/drivers/gpu/drm/i915/intel_gvt.c
> > > > +++ b/drivers/gpu/drm/i915/intel_gvt.c
> > > > @@ -77,6 +77,11 @@ int intel_gvt_init(struct drm_i915_private
> > *dev_priv)
> > > > goto bail;
> > > > }
> > > >
> > > > +   if (!i915.enable_execlists) {
> > > > +   DRM_DEBUG_DRIVER("Execlists unsupported, GVT-g is
> > > > disabled\n");
> > 
> > Should be DRM_INFO() in response to the user action, and should be treated
> > as a user visible string.
> > 
> > DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to disabled
> > execlist submission [i915.enable_execlists module parameter]\n"); -Chris
> 
> Thanks Chris for the comments. Use "DRM_DEBUG_DRIVER" is just following the 
> same print level with the other fail case in intel_gvt_init(). Anyway, I will 
> take your suggestion to use DRM_INFO instead.

Just a challenge to identify something that may be in response to user
action, typically module parameters or quirks, that may either have
intended or unintended side-effects.

> The message printed is longer than 80 characters, and checkpatch tool also 
> complain with " quoted string split across lines" by splitting to multiple 
> lines. So should I use the message print like below?
> 
> DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to ");
> DRM_INFO("disabled execlist submission ");
> DRM_INFO("[i915.enable_execlists module parameter]\n");
> 
> Or any better idea?

Just ignore checkpatch. Either split the line or not, that's up to you :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI 2/2] HAX enable guc submission for CI

[Tvrtko Ursulin]

From: Chris Wilson 

---
 drivers/gpu/drm/i915/i915_params.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 2e9645e6555a..8fa96edddf9f 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,8 +56,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
+   .enable_guc_loading = 1,
+   .enable_guc_submission = 1,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI 1/2] drm/i915/guc: Fix request re-submission after reset

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

In order to ensure no missed interrupts we must first re-direct
the interrupts to GuC, and only then re-submit the requests to
be replayed after a GPU reset. Otherwise context switch can fire
before GuC has been set up to receive it triggering more hangs.

v2: Rebase.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Mika Kuoppala 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
Cc: Arkadiusz Hiler 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 32 ++
 drivers/gpu/drm/i915/intel_guc_loader.c| 21 
 2 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index beb38e30d0e9..41f2dd87b413 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -936,6 +936,26 @@ static void guc_reset_wq(struct i915_guc_client *client)
client->wq_tail = 0;
 }
 
+static void guc_interrupts_capture(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   int irqs;
+
+   /* tell all command streamers to forward interrupts (but not vblank) to 
GuC */
+   irqs = _MASKED_BIT_ENABLE(GFX_INTERRUPT_STEERING);
+   for_each_engine(engine, dev_priv, id)
+   I915_WRITE(RING_MODE_GEN7(engine), irqs);
+
+   /* route USER_INTERRUPT to Host, all others are sent to GuC. */
+   irqs = GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
+  GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT;
+   /* These three registers have the same bit definitions */
+   I915_WRITE(GUC_BCS_RCS_IER, ~irqs);
+   I915_WRITE(GUC_VCS2_VCS1_IER, ~irqs);
+   I915_WRITE(GUC_WD_VECS_IER, ~irqs);
+}
+
 int i915_guc_submission_enable(struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = _priv->guc;
@@ -953,13 +973,17 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
 
/* Take over from manual control of ELSP (execlists) */
for_each_engine(engine, dev_priv, id) {
-   const int wqi_size = sizeof(struct guc_wq_item);
-   struct drm_i915_gem_request *rq;
-
engine->submit_request = i915_guc_submit;
engine->schedule = NULL;
+   }
+
+   guc_interrupts_capture(dev_priv);
+
+   /* Replay the current set of previously submitted requests */
+   for_each_engine(engine, dev_priv, id) {
+   const int wqi_size = sizeof(struct guc_wq_item);
+   struct drm_i915_gem_request *rq;
 
-   /* Replay the current set of previously submitted requests */
spin_lock_irq(>timeline->lock);
list_for_each_entry(rq, >timeline->requests, link) {
guc_client_update_wq_rsvd(client, wqi_size);
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 64cdef479d1d..2e24712cf3ee 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -109,26 +109,6 @@ static void guc_interrupts_release(struct drm_i915_private 
*dev_priv)
I915_WRITE(GUC_WD_VECS_IER, 0);
 }
 
-static void guc_interrupts_capture(struct drm_i915_private *dev_priv)
-{
-   struct intel_engine_cs *engine;
-   enum intel_engine_id id;
-   int irqs;
-
-   /* tell all command streamers to forward interrupts (but not vblank) to 
GuC */
-   irqs = _MASKED_BIT_ENABLE(GFX_INTERRUPT_STEERING);
-   for_each_engine(engine, dev_priv, id)
-   I915_WRITE(RING_MODE_GEN7(engine), irqs);
-
-   /* route USER_INTERRUPT to Host, all others are sent to GuC. */
-   irqs = GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
-  GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT;
-   /* These three registers have the same bit definitions */
-   I915_WRITE(GUC_BCS_RCS_IER, ~irqs);
-   I915_WRITE(GUC_VCS2_VCS1_IER, ~irqs);
-   I915_WRITE(GUC_WD_VECS_IER, ~irqs);
-}
-
 static u32 get_gttype(struct drm_i915_private *dev_priv)
 {
/* XXX: GT type based on PCI device ID? field seems unused by fw */
@@ -503,7 +483,6 @@ int intel_guc_setup(struct drm_i915_private *dev_priv)
err = i915_guc_submission_enable(dev_priv);
if (err)
goto fail;
-   guc_interrupts_capture(dev_priv);
}
 
DRM_INFO("GuC %s (firmware %s [version %u.%u])\n",
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915: Convert intel_dp_mst connector properties to atomic.

[Maarten Lankhorst]

MST doesn't support setting any properties, but it should still
use the atomic helper for setting properties.

Only path and tile properties are supported (read-only), so keep
using the i915 helper for obtaining those properties.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 094cbdcbcd6d..ab756672e2cf 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -294,14 +294,6 @@ intel_dp_mst_detect(struct drm_connector *connector, bool 
force)
return drm_dp_mst_detect_port(connector, _dp->mst_mgr, 
intel_connector->port);
 }
 
-static int
-intel_dp_mst_set_property(struct drm_connector *connector,
- struct drm_property *property,
- uint64_t val)
-{
-   return 0;
-}
-
 static void
 intel_dp_mst_connector_destroy(struct drm_connector *connector)
 {
@@ -318,7 +310,7 @@ static const struct drm_connector_funcs 
intel_dp_mst_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.detect = intel_dp_mst_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
-   .set_property = intel_dp_mst_set_property,
+   .set_property = drm_atomic_helper_connector_set_property,
.atomic_get_property = intel_connector_atomic_get_property,
.late_register = intel_connector_register,
.early_unregister = intel_connector_unregister,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic.

[Maarten Lankhorst]

As a proof of concept, first try to convert intel_tv, which is a rarely
used connector. It has 5 properties, tv format and 4 margins.

I'm less certain about the state behavior itself, should we pass a size
parameter to intel_connector_alloc instead, so duplicate_state
can be done globally if it can be blindly copied?

Can we also have a atomic_check function for connectors, so the
crtc_state->connectors_changed can be set there? It would be cleaner
and more atomic-like.

To match the legacy behavior, format can be changed by probing just like
in legacy mode.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_tv.c | 238 +++-
 1 file changed, 136 insertions(+), 102 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 6ed1a3ce47b7..0fb1d8621fe8 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -48,8 +48,6 @@ struct intel_tv {
struct intel_encoder base;
 
int type;
-   const char *tv_format;
-   int margin[4];
u32 save_TV_H_CTL_1;
u32 save_TV_H_CTL_2;
u32 save_TV_H_CTL_3;
@@ -85,6 +83,16 @@ struct intel_tv {
u32 save_TV_CTL;
 };
 
+struct intel_tv_connector_state {
+   struct drm_connector_state base;
+
+   int format;
+   int margin[4];
+};
+
+#define to_intel_tv_connector_state(state) \
+   container_of((state), struct intel_tv_connector_state, base)
+
 struct video_levels {
u16 blank, black;
u8 burst;
@@ -873,32 +881,18 @@ intel_disable_tv(struct intel_encoder *encoder,
I915_WRITE(TV_CTL, I915_READ(TV_CTL) & ~TV_ENC_ENABLE);
 }
 
-static const struct tv_mode *
-intel_tv_mode_lookup(const char *tv_format)
+static const struct tv_mode *intel_tv_mode_find(struct drm_connector_state 
*conn_state)
 {
-   int i;
+   int format = to_intel_tv_connector_state(conn_state)->format;
 
-   for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
-   const struct tv_mode *tv_mode = _modes[i];
-
-   if (!strcmp(tv_format, tv_mode->name))
-   return tv_mode;
-   }
-   return NULL;
-}
-
-static const struct tv_mode *
-intel_tv_mode_find(struct intel_tv *intel_tv)
-{
-   return intel_tv_mode_lookup(intel_tv->tv_format);
+   return _modes[format];
 }
 
 static enum drm_mode_status
 intel_tv_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
 {
-   struct intel_tv *intel_tv = intel_attached_tv(connector);
-   const struct tv_mode *tv_mode = intel_tv_mode_find(intel_tv);
+   const struct tv_mode *tv_mode = intel_tv_mode_find(connector->state);
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
 
if (mode->clock > max_dotclk)
@@ -925,8 +919,7 @@ intel_tv_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
 {
-   struct intel_tv *intel_tv = enc_to_tv(encoder);
-   const struct tv_mode *tv_mode = intel_tv_mode_find(intel_tv);
+   const struct tv_mode *tv_mode = intel_tv_mode_find(conn_state);
 
if (!tv_mode)
return false;
@@ -1032,7 +1025,7 @@ static void intel_tv_pre_enable(struct intel_encoder 
*encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
struct intel_tv *intel_tv = enc_to_tv(encoder);
-   const struct tv_mode *tv_mode = intel_tv_mode_find(intel_tv);
+   const struct tv_mode *tv_mode = intel_tv_mode_find(conn_state);
u32 tv_ctl;
u32 scctl1, scctl2, scctl3;
int i, j;
@@ -1041,6 +1034,8 @@ static void intel_tv_pre_enable(struct intel_encoder 
*encoder,
bool burst_ena;
int xpos = 0x0, ypos = 0x0;
unsigned int xsize, ysize;
+   struct intel_tv_connector_state *tv_state =
+   to_intel_tv_connector_state(conn_state);
 
if (!tv_mode)
return; /* can't happen (mode_prepare prevents this) */
@@ -1135,12 +1130,12 @@ static void intel_tv_pre_enable(struct intel_encoder 
*encoder,
else
ysize = 2*tv_mode->nbr_end + 1;
 
-   xpos += intel_tv->margin[TV_MARGIN_LEFT];
-   ypos += intel_tv->margin[TV_MARGIN_TOP];
-   xsize -= (intel_tv->margin[TV_MARGIN_LEFT] +
- intel_tv->margin[TV_MARGIN_RIGHT]);
-   ysize -= (intel_tv->margin[TV_MARGIN_TOP] +
- intel_tv->margin[TV_MARGIN_BOTTOM]);
+   xpos += tv_state->margin[TV_MARGIN_LEFT];
+   ypos += tv_state->margin[TV_MARGIN_TOP];
+   xsize -= (tv_state->margin[TV_MARGIN_LEFT] +
+ tv_state->margin[TV_MARGIN_RIGHT]);
+   ysize -= (tv_state->margin[TV_MARGIN_TOP] +
+ tv_state->margin[TV_MARGIN_BOTTOM]);

[Intel-gfx] [PATCH 3/3] drm/i915: Convert intel_crt connector properties to atomic.

[Maarten Lankhorst]

No properties are supported, so just use the helper and reject
everything.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_crt.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 8c82607294c6..4ee4df37e683 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -778,13 +778,6 @@ static int intel_crt_get_modes(struct drm_connector 
*connector)
return ret;
 }
 
-static int intel_crt_set_property(struct drm_connector *connector,
- struct drm_property *property,
- uint64_t value)
-{
-   return 0;
-}
-
 void intel_crt_reset(struct drm_encoder *encoder)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
@@ -816,7 +809,7 @@ static const struct drm_connector_funcs 
intel_crt_connector_funcs = {
.late_register = intel_connector_register,
.early_unregister = intel_connector_unregister,
.destroy = intel_crt_destroy,
-   .set_property = intel_crt_set_property,
+   .set_property = drm_atomic_helper_connector_set_property,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_get_property = intel_connector_atomic_get_property,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/3] drm/i915: Convert tv/dp_mst and crt connector properties to atomic.

[Maarten Lankhorst]

intel_tv is a proof of concept conversion to discuss the API.
The other 2 connectors are straightforward.

Maarten Lankhorst (3):
  drm/i915: Convert intel_tv connector properties to atomic.
  drm/i915: Convert intel_dp_mst connector properties to atomic.
  drm/i915: Convert intel_crt connector properties to atomic.

 drivers/gpu/drm/i915/intel_crt.c|   9 +-
 drivers/gpu/drm/i915/intel_dp_mst.c |  10 +-
 drivers/gpu/drm/i915/intel_tv.c | 238 
 3 files changed, 138 insertions(+), 119 deletions(-)

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: add enable_execlists check before enable gvt

[Dong, Chuanxiao]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Chris Wilson
> Sent: Thursday, March 9, 2017 8:45 PM
> To: Dong, Chuanxiao 
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/gvt: add enable_execlists check
> before enable gvt
> 
> On Thu, Mar 09, 2017 at 12:32:18PM +, Dong, Chuanxiao wrote:
> > Hi,
> >
> > Any comments to this patch?
> >
> > Thanks
> > Chuanxiao
> >
> > > -Original Message-
> > > From: intel-gvt-dev
> > > [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On Behalf Of
> > > Chuanxiao Dong
> > > Sent: Monday, March 6, 2017 1:16 PM
> > > To: intel-gfx@lists.freedesktop.org;
> > > intel-gvt-...@lists.freedesktop.org
> > > Subject: [PATCH] drm/i915/gvt: add enable_execlists check before
> > > enable gvt
> > >
> > > The GVT-g needs execlists to be enabled otherwise gvt should be disabled.
> > > Add a check for enable_execlists before enabling gvt.
> > >
> > > Signed-off-by: Chuanxiao Dong 
> > > ---
> > >  drivers/gpu/drm/i915/intel_gvt.c | 5 +
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_gvt.c
> > > b/drivers/gpu/drm/i915/intel_gvt.c
> > > index d23c0fc..3799cb3 100644
> > > --- a/drivers/gpu/drm/i915/intel_gvt.c
> > > +++ b/drivers/gpu/drm/i915/intel_gvt.c
> > > @@ -77,6 +77,11 @@ int intel_gvt_init(struct drm_i915_private
> *dev_priv)
> > >   goto bail;
> > >   }
> > >
> > > + if (!i915.enable_execlists) {
> > > + DRM_DEBUG_DRIVER("Execlists unsupported, GVT-g is
> > > disabled\n");
> 
> Should be DRM_INFO() in response to the user action, and should be treated
> as a user visible string.
> 
> DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to disabled
> execlist submission [i915.enable_execlists module parameter]\n"); -Chris

Thanks Chris for the comments. Use "DRM_DEBUG_DRIVER" is just following the 
same print level with the other fail case in intel_gvt_init(). Anyway, I will 
take your suggestion to use DRM_INFO instead.

The message printed is longer than 80 characters, and checkpatch tool also 
complain with " quoted string split across lines" by splitting to multiple 
lines. So should I use the message print like below?

DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to ");
DRM_INFO("disabled execlist submission ");
DRM_INFO("[i915.enable_execlists module parameter]\n");

Or any better idea?

Thanks
Chuanxiao

> 
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Restore engine->submit_request before unwedging

[Patchwork]

== Series Details ==

Series: drm/i915: Restore engine->submit_request before unwedging
URL   : https://patchwork.freedesktop.org/series/20982/
State : failure

== Summary ==

Series 20982v1 drm/i915: Restore engine->submit_request before unwedging
https://patchwork.freedesktop.org/api/1.0/series/20982/revisions/1/mbox/

Test gem_ctx_create:
Subgroup basic-files:
incomplete -> PASS   (fi-skl-6700hq)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> INCOMPLETE (fi-skl-6700k)
Subgroup basic-uc-rw-default:
pass   -> INCOMPLETE (fi-kbl-7500u)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 465s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 607s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 533s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 600s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 505s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 502s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 445s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 442s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 441s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 505s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 492s
fi-kbl-7500u total:56   pass:48   dwarn:0   dfail:0   fail:0   skip:7   
time: 0s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 509s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 596s
fi-skl-6700k total:51   pass:43   dwarn:0   dfail:0   fail:0   skip:7   
time: 0s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 555s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 552s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 425s

6fa1f12c25f9c8f71a704c0bae5e0f150e04dacd drm-tip: 2017y-03m-09d-10h-41m-48s UTC 
integration manifest
66f7540 drm/i915: Restore engine->submit_request before unwedging

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4112/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: add enable_execlists check before enable gvt

[Chris Wilson]

On Thu, Mar 09, 2017 at 12:32:18PM +, Dong, Chuanxiao wrote:
> Hi,
> 
> Any comments to this patch?
> 
> Thanks
> Chuanxiao
> 
> > -Original Message-
> > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> > Behalf Of Chuanxiao Dong
> > Sent: Monday, March 6, 2017 1:16 PM
> > To: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> > Subject: [PATCH] drm/i915/gvt: add enable_execlists check before enable gvt
> > 
> > The GVT-g needs execlists to be enabled otherwise gvt should be disabled.
> > Add a check for enable_execlists before enabling gvt.
> > 
> > Signed-off-by: Chuanxiao Dong 
> > ---
> >  drivers/gpu/drm/i915/intel_gvt.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_gvt.c
> > b/drivers/gpu/drm/i915/intel_gvt.c
> > index d23c0fc..3799cb3 100644
> > --- a/drivers/gpu/drm/i915/intel_gvt.c
> > +++ b/drivers/gpu/drm/i915/intel_gvt.c
> > @@ -77,6 +77,11 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
> > goto bail;
> > }
> > 
> > +   if (!i915.enable_execlists) {
> > +   DRM_DEBUG_DRIVER("Execlists unsupported, GVT-g is
> > disabled\n");

Should be DRM_INFO() in response to the user action, and should be
treated as a user visible string.

DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to disabled execlist 
submission [i915.enable_execlists module parameter]\n");
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix request re-submission after reset

[Chris Wilson]

On Thu, Mar 09, 2017 at 12:06:37PM +, Chris Wilson wrote:
> On Thu, Mar 09, 2017 at 10:19:10AM +, Chris Wilson wrote:
> > On Thu, Mar 09, 2017 at 10:05:21AM +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > In order to ensure no missed interrupts we must first re-direct
> > > the interrupts to GuC, and only then re-submit the requests to
> > > be replayed after a GPU reset. Otherwise context switch can fire
> > > before GuC has been set up to receive it triggering more hangs.
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Cc: Chris Wilson 
> > > Cc: Michal Wajdeczko 
> > > Cc: Mika Kuoppala 
> > > Cc: Oscar Mateo 
> > > Cc: Sagar Arun Kamble 
> > > Cc: Arkadiusz Hiler 
> > > ---
> > >  drivers/gpu/drm/i915/i915_guc_submission.c | 58 
> > > +++---
> > >  drivers/gpu/drm/i915/intel_guc_loader.c| 47 
> > >  2 files changed, 54 insertions(+), 51 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> > > b/drivers/gpu/drm/i915/i915_guc_submission.c
> > > index beb38e30d0e9..5b8ec0fab563 100644
> > > --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> > > @@ -936,6 +936,52 @@ static void guc_reset_wq(struct i915_guc_client 
> > > *client)
> > >   client->wq_tail = 0;
> > >  }
> > >  
> > > +static void guc_interrupts_capture(struct drm_i915_private *dev_priv)
> > > +{
> > > + struct intel_engine_cs *engine;
> > > + enum intel_engine_id id;
> > > + int irqs;
> > > + u32 tmp;
> > > +
> > > + /* tell all command streamers to forward interrupts (but not vblank) to 
> > > GuC */
> > > + irqs = _MASKED_BIT_ENABLE(GFX_INTERRUPT_STEERING);
> > > + for_each_engine(engine, dev_priv, id)
> > > + I915_WRITE(RING_MODE_GEN7(engine), irqs);
> > > +
> > > + /* route USER_INTERRUPT to Host, all others are sent to GuC. */
> > > + irqs = GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
> > > +GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT;
> > > + /* These three registers have the same bit definitions */
> > > + I915_WRITE(GUC_BCS_RCS_IER, ~irqs);
> > > + I915_WRITE(GUC_VCS2_VCS1_IER, ~irqs);
> > > + I915_WRITE(GUC_WD_VECS_IER, ~irqs);
> > > +
> > > + /*
> > > +  * The REDIRECT_TO_GUC bit of the PMINTRMSK register directs all
> > > +  * (unmasked) PM interrupts to the GuC. All other bits of this
> > > +  * register *disable* generation of a specific interrupt.
> > > +  *
> > > +  * 'pm_intr_keep' indicates bits that are NOT to be set when
> > > +  * writing to the PM interrupt mask register, i.e. interrupts
> > > +  * that must not be disabled.
> > > +  *
> > > +  * If the GuC is handling these interrupts, then we must not let
> > > +  * the PM code disable ANY interrupt that the GuC is expecting.
> > > +  * So for each ENABLED (0) bit in this register, we must SET the
> > > +  * bit in pm_intr_keep so that it's left enabled for the GuC.
> > > +  *
> > > +  * OTOH the REDIRECT_TO_GUC bit is initially SET in pm_intr_keep
> > > +  * (so interrupts go to the DISPLAY unit at first); but here we
> > > +  * need to CLEAR that bit, which will result in the register bit
> > > +  * being left SET!
> > > +  */
> > > + tmp = I915_READ(GEN6_PMINTRMSK);
> > > + if (tmp & GEN8_PMINTR_REDIRECT_TO_GUC) {
> > > + dev_priv->rps.pm_intr_keep |= ~tmp;
> > > + dev_priv->rps.pm_intr_keep &= ~GEN8_PMINTR_REDIRECT_TO_GUC;
> > > + }
> > 
> > Let me just remove this code first (drm/i915: Initialize pm_intr_keep
> > during intel_irq_init for GuC) depending on the outcome of
> > https://patchwork.freedesktop.org/series/20980/.
> 
> That failed, so blocker removed.

And just to be really confusing, baseline had identical failure, so
pushed :-p

Removes the majority of lines from this patch :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Initialize pm_intr_keep during intel_irq_init for GuC

[Chris Wilson]

On Tue, Mar 07, 2017 at 10:22:35AM +0530, Sagar Arun Kamble wrote:
> Driver needs to ensure that it doesn't mask the PM interrupts, which are
> unmasked/needed by GuC firmware. For that, Driver maintains a bitmask of
> interrupts to be kept unmasked, pm_intr_keep.
> 
> pm_intr_keep was determined across GuC load. GuC gets loaded in different
> scenarios and it is not going to change the pm_intr_keep so this patch
> moves its setup to intel_irq_init.
> 
> This patch fixes incorrect RPS masking leading to UP interrupts triggered
> even when at cur_freq=max and inversly for Down interrupts.
> 
> Cc: Radoslaw Szwichtenberg 
> Cc: Arkadiusz Hiler 
> Cc: Michal Wajdeczko 
> Cc: Michal Winiarski 
> Cc: Daniele Ceraolo Spurio 
> Signed-off-by: Sagar Arun Kamble 
> Reviewed-by: Chris Wilson 

CI is having issues with guc on bxt, but pushed. Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
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 HAX enable guc submission for CI

[Chris Wilson]

On Thu, Mar 09, 2017 at 12:23:24PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: HAX enable guc submission for CI
> URL   : https://patchwork.freedesktop.org/series/20981/
> State : failure
> 
> == Summary ==
> 
> Series 20981v1 HAX enable guc submission for CI
> https://patchwork.freedesktop.org/api/1.0/series/20981/revisions/1/mbox/
> 
> Test gem_ctx_create:
> Subgroup basic-files:
> incomplete -> PASS   (fi-skl-6700hq)
> Test gem_exec_fence:
> Subgroup await-hang-default:
> pass   -> INCOMPLETE (fi-kbl-7500u)
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> pass   -> FAIL   (fi-snb-2600) fdo#17
> Test gem_ringfill:
> Subgroup basic-default-hang:
> pass   -> INCOMPLETE (fi-bxt-t5700)
> pass   -> INCOMPLETE (fi-skl-6700k)

Oh noes. We need that missing bug report asap.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: add enable_execlists check before enable gvt

[Dong, Chuanxiao]

Hi,

Any comments to this patch?

Thanks
Chuanxiao

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Chuanxiao Dong
> Sent: Monday, March 6, 2017 1:16 PM
> To: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: [PATCH] drm/i915/gvt: add enable_execlists check before enable gvt
> 
> The GVT-g needs execlists to be enabled otherwise gvt should be disabled.
> Add a check for enable_execlists before enabling gvt.
> 
> Signed-off-by: Chuanxiao Dong 
> ---
>  drivers/gpu/drm/i915/intel_gvt.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_gvt.c
> b/drivers/gpu/drm/i915/intel_gvt.c
> index d23c0fc..3799cb3 100644
> --- a/drivers/gpu/drm/i915/intel_gvt.c
> +++ b/drivers/gpu/drm/i915/intel_gvt.c
> @@ -77,6 +77,11 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
>   goto bail;
>   }
> 
> + if (!i915.enable_execlists) {
> + DRM_DEBUG_DRIVER("Execlists unsupported, GVT-g is
> disabled\n");
> + goto bail;
> + }
> +
>   /*
>* We're not in host or fail to find a MPT module, disable GVT-g
>*/
> --
> 2.7.4
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for HAX enable guc submission for CI

[Patchwork]

== Series Details ==

Series: HAX enable guc submission for CI
URL   : https://patchwork.freedesktop.org/series/20981/
State : failure

== Summary ==

Series 20981v1 HAX enable guc submission for CI
https://patchwork.freedesktop.org/api/1.0/series/20981/revisions/1/mbox/

Test gem_ctx_create:
Subgroup basic-files:
incomplete -> PASS   (fi-skl-6700hq)
Test gem_exec_fence:
Subgroup await-hang-default:
pass   -> INCOMPLETE (fi-kbl-7500u)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> INCOMPLETE (fi-bxt-t5700)
pass   -> INCOMPLETE (fi-skl-6700k)

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 466s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 618s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 489s
fi-bxt-t5700 total:146  pass:132  dwarn:0   dfail:0   fail:0   skip:13  
time: 0s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 511s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 500s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 437s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 438s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 440s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 498s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 485s
fi-kbl-7500u total:48   pass:41   dwarn:0   dfail:0   fail:0   skip:6   
time: 0s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 489s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 596s
fi-skl-6700k total:146  pass:134  dwarn:0   dfail:0   fail:0   skip:11  
time: 0s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 519s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 560s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 420s

6fa1f12c25f9c8f71a704c0bae5e0f150e04dacd drm-tip: 2017y-03m-09d-10h-41m-48s UTC 
integration manifest
5c14d2c HAX enable guc submission for CI

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4111/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix request re-submission after reset

[Chris Wilson]

On Thu, Mar 09, 2017 at 10:19:10AM +, Chris Wilson wrote:
> On Thu, Mar 09, 2017 at 10:05:21AM +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin 
> > 
> > In order to ensure no missed interrupts we must first re-direct
> > the interrupts to GuC, and only then re-submit the requests to
> > be replayed after a GPU reset. Otherwise context switch can fire
> > before GuC has been set up to receive it triggering more hangs.
> > 
> > Signed-off-by: Tvrtko Ursulin 
> > Cc: Chris Wilson 
> > Cc: Michal Wajdeczko 
> > Cc: Mika Kuoppala 
> > Cc: Oscar Mateo 
> > Cc: Sagar Arun Kamble 
> > Cc: Arkadiusz Hiler 
> > ---
> >  drivers/gpu/drm/i915/i915_guc_submission.c | 58 
> > +++---
> >  drivers/gpu/drm/i915/intel_guc_loader.c| 47 
> >  2 files changed, 54 insertions(+), 51 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> > b/drivers/gpu/drm/i915/i915_guc_submission.c
> > index beb38e30d0e9..5b8ec0fab563 100644
> > --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> > @@ -936,6 +936,52 @@ static void guc_reset_wq(struct i915_guc_client 
> > *client)
> > client->wq_tail = 0;
> >  }
> >  
> > +static void guc_interrupts_capture(struct drm_i915_private *dev_priv)
> > +{
> > +   struct intel_engine_cs *engine;
> > +   enum intel_engine_id id;
> > +   int irqs;
> > +   u32 tmp;
> > +
> > +   /* tell all command streamers to forward interrupts (but not vblank) to 
> > GuC */
> > +   irqs = _MASKED_BIT_ENABLE(GFX_INTERRUPT_STEERING);
> > +   for_each_engine(engine, dev_priv, id)
> > +   I915_WRITE(RING_MODE_GEN7(engine), irqs);
> > +
> > +   /* route USER_INTERRUPT to Host, all others are sent to GuC. */
> > +   irqs = GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
> > +  GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT;
> > +   /* These three registers have the same bit definitions */
> > +   I915_WRITE(GUC_BCS_RCS_IER, ~irqs);
> > +   I915_WRITE(GUC_VCS2_VCS1_IER, ~irqs);
> > +   I915_WRITE(GUC_WD_VECS_IER, ~irqs);
> > +
> > +   /*
> > +* The REDIRECT_TO_GUC bit of the PMINTRMSK register directs all
> > +* (unmasked) PM interrupts to the GuC. All other bits of this
> > +* register *disable* generation of a specific interrupt.
> > +*
> > +* 'pm_intr_keep' indicates bits that are NOT to be set when
> > +* writing to the PM interrupt mask register, i.e. interrupts
> > +* that must not be disabled.
> > +*
> > +* If the GuC is handling these interrupts, then we must not let
> > +* the PM code disable ANY interrupt that the GuC is expecting.
> > +* So for each ENABLED (0) bit in this register, we must SET the
> > +* bit in pm_intr_keep so that it's left enabled for the GuC.
> > +*
> > +* OTOH the REDIRECT_TO_GUC bit is initially SET in pm_intr_keep
> > +* (so interrupts go to the DISPLAY unit at first); but here we
> > +* need to CLEAR that bit, which will result in the register bit
> > +* being left SET!
> > +*/
> > +   tmp = I915_READ(GEN6_PMINTRMSK);
> > +   if (tmp & GEN8_PMINTR_REDIRECT_TO_GUC) {
> > +   dev_priv->rps.pm_intr_keep |= ~tmp;
> > +   dev_priv->rps.pm_intr_keep &= ~GEN8_PMINTR_REDIRECT_TO_GUC;
> > +   }
> 
> Let me just remove this code first (drm/i915: Initialize pm_intr_keep
> during intel_irq_init for GuC) depending on the outcome of
> https://patchwork.freedesktop.org/series/20980/.

That failed, so blocker removed.
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
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 series starting with [CI,1/2] drm/i915: Initialize pm_intr_keep during intel_irq_init for GuC

[Chris Wilson]

On Thu, Mar 09, 2017 at 11:54:31AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [CI,1/2] drm/i915: Initialize pm_intr_keep 
> during intel_irq_init for GuC
> URL   : https://patchwork.freedesktop.org/series/20980/
> State : failure
> 
> == Summary ==
> 
> Series 20980v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/20980/revisions/1/mbox/
> 
> Test gem_ctx_create:
> Subgroup basic-files:
> incomplete -> PASS   (fi-skl-6700hq)
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-wb:
> pass   -> INCOMPLETE (fi-skl-6770hq)
> Test gem_ringfill:
> Subgroup basic-default-hang:
> pass   -> INCOMPLETE (fi-bxt-j4205)
> pass   -> INCOMPLETE (fi-bxt-t5700)

Two "identical" uncaptured explosions in Broxton, no go.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 4/4] assembler/gen8_disasm.c: Remove unused m_mask_ctrl

[Mika Kahola]

On Wed, 2017-03-08 at 16:44 +0200, Petri Latvala wrote:
> Signed-off-by: Petri Latvala 

Reviewed-by: Mika Kahola 

> ---
>  assembler/gen8_disasm.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/assembler/gen8_disasm.c b/assembler/gen8_disasm.c
> index 7fc7a65..68bc033 100644
> --- a/assembler/gen8_disasm.c
> +++ b/assembler/gen8_disasm.c
> @@ -138,11 +138,6 @@ static const char *const m_dep_ctrl[4] = {
> "NoDDClr,NoDDChk",
>  };
>  
> -static const char *const m_mask_ctrl[4] = {
> -   "",
> -   "nomask",
> -};
> -
>  static const char *const m_access_mode[2] = { "align1", "align16" };
>  
>  static const char *const m_reg_type[8] = {
___
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 [CI,1/2] drm/i915: Initialize pm_intr_keep during intel_irq_init for GuC

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Initialize pm_intr_keep during 
intel_irq_init for GuC
URL   : https://patchwork.freedesktop.org/series/20980/
State : failure

== Summary ==

Series 20980v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20980/revisions/1/mbox/

Test gem_ctx_create:
Subgroup basic-files:
incomplete -> PASS   (fi-skl-6700hq)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-wb:
pass   -> INCOMPLETE (fi-skl-6770hq)
Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> INCOMPLETE (fi-bxt-j4205)
pass   -> INCOMPLETE (fi-bxt-t5700)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 466s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 602s
fi-bxt-j4205 total:146  pass:133  dwarn:0   dfail:0   fail:0   skip:12  
time: 0s
fi-bxt-t5700 total:146  pass:132  dwarn:0   dfail:0   fail:0   skip:13  
time: 0s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 505s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 506s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 437s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 440s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 443s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 506s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 484s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 468s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 500s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 568s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 486s
fi-skl-6770hqtotal:52   pass:50   dwarn:0   dfail:0   fail:0   skip:1   
time: 0s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 553s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 422s

6fa1f12c25f9c8f71a704c0bae5e0f150e04dacd drm-tip: 2017y-03m-09d-10h-41m-48s UTC 
integration manifest
ebf3da2 HAX enable guc submission for CI
2b9d11b drm/i915: Initialize pm_intr_keep during intel_irq_init for GuC

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4110/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v3] Add the new tool for create GVT-g Linux guest based on KVMGT

[Xu, Terrence]

Thanks Petri, agree with all your comments!

Thanks
Terrence

>-Original Message-
>From: Latvala, Petri
>Sent: Thursday, March 9, 2017 6:58 PM
>To: Xu, Terrence 
>Cc: intel-gfx@lists.freedesktop.org; Jin, Gordon ; 
>Sarvela,
>Tomi P ; Lv, Zhiyuan ; Wang,
>Zhenyu Z ; Wang, Hongbo
>; Xu, BenyuX 
>Subject: Re: [PATCH i-g-t v3] Add the new tool for create GVT-g Linux guest 
>based
>on KVMGT
>
>On Fri, Mar 10, 2017 at 03:34:49AM +0800, Terrence Xu wrote:
>> GVT-g (Intel(r) Graphics Virtualization Technology) is a full GPU
>> virtualization solution with mediated pass-through support.
>>
>> This tool is for create basic Linux guest based on KVMGT with VFIO
>> framework, it including create vgpu, create guest, check IP address,
>> destroy guest, remove vgpu,check dmesg log, etc functions.
>>
>> v2: Treat this case as a free-standing tool, with detect & skip when
>> it's not running on GVT-g capable platform or running without the
>> required tools.
>>
>> v3: Make some optimizations: like "update the generate mac address
>> scripts", "provide more useful information for end user", etc.
>>
>> Signed-off-by: Terrence Xu 
>> Signed-off-by: Benyu Xu 
>> ---
>>  tools/.gitignore|   1 +
>>  tools/Makefile.sources  |   1 +
>>  tools/intel_gvtg_test.c | 359
>> 
>>  3 files changed, 361 insertions(+)
>>  create mode 100644 tools/intel_gvtg_test.c
>>
>> diff --git a/tools/.gitignore b/tools/.gitignore index
>> 13825a3..f777f2b 100644
>> --- a/tools/.gitignore
>> +++ b/tools/.gitignore
>> @@ -30,5 +30,6 @@ intel_reg_checker
>>  intel_residency
>>  intel_stepping
>>  intel_watermark
>> +intel_gvtg_test
>>  skl_compute_wrpll
>>  skl_ddb_allocation
>
>
>Sort alphabetically.
>
>
>> diff --git a/tools/Makefile.sources b/tools/Makefile.sources index
>> e2451ea..5f1e747 100644
>> --- a/tools/Makefile.sources
>> +++ b/tools/Makefile.sources
>> @@ -30,6 +30,7 @@ tools_prog_lists = \
>>  intel_stepping  \
>>  intel_watermark \
>>  intel_gem_info  \
>> +intel_gvtg_test \
>>  $(NULL)
>>
>>  dist_bin_SCRIPTS = intel_gpu_abrt
>> diff --git a/tools/intel_gvtg_test.c b/tools/intel_gvtg_test.c new
>> file mode 100644 index 000..ec6dd99
>> --- /dev/null
>> +++ b/tools/intel_gvtg_test.c
>> @@ -0,0 +1,359 @@
>> +/*
>> + * Copyright 2016 Intel Corporation
>> + *   Terrence Xu 
>> + *
>
>
>This should be
>
>
> * Copyright (c) 2016-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 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.
>> + */
>> +
>> +/*
>> + * This program is intended for testing of validate GVT-g virtual
>> +machine
>> + * creation of allow for testing of KVMGT / XenGT (the tool should be
>> +root
>> + * privilege only).
>> + *
>> + * TODO:
>> + * Enable more GVT-g related test cases.
>> + */
>> +#ifdef HAVE_CONFIG_H
>> +#include "config.h"
>> +#endif
>> +
>> +#include "igt.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define RANDOM(x) (rand() % x)
>> +
>> +
>> +static char uuid[40];
>> +static char guest_ip[32];
>> +
>> +static char mac_addr[20] = {0};
>> +static char qemu_path[PATH_MAX] = {0}; static char hda_path[PATH_MAX]
>> += {0}; static char bios_path[PATH_MAX] = {0};
>> +
>> +static int super_system(const char *cmd, char *retmsg, int msg_len) {
>> +FILE *fp;
>> +int res = -1;
>> + 

[Intel-gfx] [PATCH] drm/i915: make context status notifier head be per engine

[changbin . du]

From: Changbin Du 

GVTg has introduced the context status notifier to schedule the GVTg
workload. At that time, the notifier is bound to GVTg context only,
so GVTg is not aware of host workloads.

Now we are going to improve GVTg's guest workload scheduler policy,
and add Guc emulation support for new Gen graphics. Both these two
features require acknowledgment for all contexts running on hardware.
(But will not alter host workload.) So here try to make some change.

The change is simple:
  1. Move the context status notifier head from i915_gem_context to
 intel_engine_cs. Which means there is a notifier head per engine
 instead of per context. Execlist driver still call notifier for
 each context sched-in/out events of current engine.
  2. At GVTg side, it binds a notifier_block for each physical engine
 at GVTg initialization period. Then GVTg can hear all context
 status events.

In this patch, GVTg do nothing for host context event, but later
will add a function there. But in any case, the notifier callback is
a noop if this is no active vGPU.

Since intel_gvt_init() is called at early initialization stage and
require the status notifier head has been initiated, I initiate it in
intel_engine_setup().

Signed-off-by: Changbin Du 
---
 drivers/gpu/drm/i915/gvt/gvt.h  |  2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c| 46 ++---
 drivers/gpu/drm/i915/i915_gem_context.c |  1 -
 drivers/gpu/drm/i915/i915_gem_context.h |  3 ---
 drivers/gpu/drm/i915/intel_engine_cs.c  |  2 ++
 drivers/gpu/drm/i915/intel_lrc.c|  3 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  3 +++
 7 files changed, 28 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 2379192..6dfc48b 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -162,7 +162,6 @@ struct intel_vgpu {
atomic_t running_workload_num;
DECLARE_BITMAP(tlb_handle_pending, I915_NUM_ENGINES);
struct i915_gem_context *shadow_ctx;
-   struct notifier_block shadow_ctx_notifier_block;
 
 #if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
struct {
@@ -233,6 +232,7 @@ struct intel_gvt {
struct intel_gvt_gtt gtt;
struct intel_gvt_opregion opregion;
struct intel_gvt_workload_scheduler scheduler;
+   struct notifier_block shadow_ctx_notifier_block[I915_NUM_ENGINES];
DECLARE_HASHTABLE(cmd_table, GVT_CMD_HASH_BITS);
struct intel_vgpu_type *types;
unsigned int num_types;
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index d3a56c9..64875ec 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -127,15 +127,14 @@ static int populate_shadow_context(struct 
intel_vgpu_workload *workload)
return 0;
 }
 
+
 static int shadow_context_status_change(struct notifier_block *nb,
unsigned long action, void *data)
 {
-   struct intel_vgpu *vgpu = container_of(nb,
-   struct intel_vgpu, shadow_ctx_notifier_block);
-   struct drm_i915_gem_request *req =
-   (struct drm_i915_gem_request *)data;
-   struct intel_gvt_workload_scheduler *scheduler =
-   >gvt->scheduler;
+   struct drm_i915_gem_request *req = (struct drm_i915_gem_request *)data;
+   struct intel_gvt *gvt = container_of(nb, struct intel_gvt,
+   shadow_ctx_notifier_block[req->engine->id]);
+   struct intel_gvt_workload_scheduler *scheduler = >scheduler;
struct intel_vgpu_workload *workload =
scheduler->current_workload[req->engine->id];
 
@@ -513,15 +512,16 @@ void intel_gvt_wait_vgpu_idle(struct intel_vgpu *vgpu)
 void intel_gvt_clean_workload_scheduler(struct intel_gvt *gvt)
 {
struct intel_gvt_workload_scheduler *scheduler = >scheduler;
-   int i;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id i;
 
gvt_dbg_core("clean workload scheduler\n");
 
-   for (i = 0; i < I915_NUM_ENGINES; i++) {
-   if (scheduler->thread[i]) {
-   kthread_stop(scheduler->thread[i]);
-   scheduler->thread[i] = NULL;
-   }
+   for_each_engine(engine, gvt->dev_priv, i) {
+   atomic_notifier_chain_unregister(
+   >context_status_notifier,
+   >shadow_ctx_notifier_block[i]);
+   kthread_stop(scheduler->thread[i]);
}
 }
 
@@ -529,18 +529,15 @@ int intel_gvt_init_workload_scheduler(struct intel_gvt 
*gvt)
 {
struct intel_gvt_workload_scheduler *scheduler = >scheduler;
struct workload_thread_param *param = NULL;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id i;
int ret;
-   int i;
 

Re: [Intel-gfx] [PATCH] drm/i915: cleanup patch for intel_ddi.c

[Ander Conselvan De Oliveira]

The summary should say what the clean up is about. For example:

drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c

With that fixed,

Reviewed-by: Ander Conselvan de Oliveira 

On Thu, 2017-03-09 at 16:28 +0530, Shashank Sharma wrote:
> In I915 driver, there are many places where variable name for
> intel_encoder object is given as 'intel_encoder' whereas it would
> make more sense in many places to call it just 'encoder'.
> 
> This patch does a similar cleanup in file intel_ddi.c.
> 
> PS: There are few functions where both drm_encoder and intel_encoder
> are present. For such functions, this patch does nothing.
> 
> Suggested-by: Ander Conselvan De Oliveira 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 66 
> 
>  1 file changed, 33 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0467676..ee341ef 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -821,11 +821,11 @@ void intel_ddi_init_dp_buf_reg(struct intel_encoder 
> *encoder)
>  intel_ddi_get_crtc_encoder(struct intel_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->base.dev;
> - struct intel_encoder *intel_encoder, *ret = NULL;
> + struct intel_encoder *encoder, *ret = NULL;
>   int num_encoders = 0;
>  
> - for_each_encoder_on_crtc(dev, >base, intel_encoder) {
> - ret = intel_encoder;
> + for_each_encoder_on_crtc(dev, >base, encoder) {
> + ret = encoder;
>   num_encoders++;
>   }
>  
> @@ -1130,12 +1130,12 @@ void intel_ddi_clock_get(struct intel_encoder 
> *encoder,
>  static bool
>  hsw_ddi_pll_select(struct intel_crtc *intel_crtc,
>  struct intel_crtc_state *crtc_state,
> -struct intel_encoder *intel_encoder)
> +struct intel_encoder *encoder)
>  {
>   struct intel_shared_dpll *pll;
>  
>   pll = intel_get_shared_dpll(intel_crtc, crtc_state,
> - intel_encoder);
> + encoder);
>   if (!pll)
>   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(intel_crtc->pipe));
> @@ -1146,11 +1146,11 @@ void intel_ddi_clock_get(struct intel_encoder 
> *encoder,
>  static bool
>  skl_ddi_pll_select(struct intel_crtc *intel_crtc,
>  struct intel_crtc_state *crtc_state,
> -struct intel_encoder *intel_encoder)
> +struct intel_encoder *encoder)
>  {
>   struct intel_shared_dpll *pll;
>  
> - pll = intel_get_shared_dpll(intel_crtc, crtc_state, intel_encoder);
> + pll = intel_get_shared_dpll(intel_crtc, crtc_state, encoder);
>   if (pll == NULL) {
>   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(intel_crtc->pipe));
> @@ -1163,9 +1163,9 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
>  static bool
>  bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
>  struct intel_crtc_state *crtc_state,
> -struct intel_encoder *intel_encoder)
> +struct intel_encoder *encoder)
>  {
> - return !!intel_get_shared_dpll(intel_crtc, crtc_state, intel_encoder);
> + return !!intel_get_shared_dpll(intel_crtc, crtc_state, encoder);
>  }
>  
>  /*
> @@ -1179,27 +1179,27 @@ bool intel_ddi_pll_select(struct intel_crtc 
> *intel_crtc,
> struct intel_crtc_state *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> - struct intel_encoder *intel_encoder =
> + struct intel_encoder *encoder =
>   intel_ddi_get_crtc_new_encoder(crtc_state);
>  
>   if (IS_GEN9_BC(dev_priv))
>   return skl_ddi_pll_select(intel_crtc, crtc_state,
> -   intel_encoder);
> +   encoder);
>   else if (IS_GEN9_LP(dev_priv))
>   return bxt_ddi_pll_select(intel_crtc, crtc_state,
> -   intel_encoder);
> +   encoder);
>   else
>   return hsw_ddi_pll_select(intel_crtc, crtc_state,
> -   intel_encoder);
> +   encoder);
>  }
>  
>  void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
> + struct intel_encoder *encoder = intel_ddi_get_crtc_encoder(crtc);
>   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> - int 

Re: [Intel-gfx] [PATCH i-g-t v3] Add the new tool for create GVT-g Linux guest based on KVMGT

[Petri Latvala]

On Fri, Mar 10, 2017 at 03:34:49AM +0800, Terrence Xu wrote:
> GVT-g (Intel® Graphics Virtualization Technology) is a full GPU
> virtualization solution with mediated pass-through support.
> 
> This tool is for create basic Linux guest based on KVMGT with
> VFIO framework, it including create vgpu, create guest, check IP
> address, destroy guest, remove vgpu,check dmesg log, etc functions.
> 
> v2: Treat this case as a free-standing tool, with detect & skip
> when it's not running on GVT-g capable platform or running without
> the required tools.
> 
> v3: Make some optimizations: like "update the generate mac address
> scripts", "provide more useful information for end user", etc.
> 
> Signed-off-by: Terrence Xu 
> Signed-off-by: Benyu Xu 
> ---
>  tools/.gitignore|   1 +
>  tools/Makefile.sources  |   1 +
>  tools/intel_gvtg_test.c | 359 
> 
>  3 files changed, 361 insertions(+)
>  create mode 100644 tools/intel_gvtg_test.c
> 
> diff --git a/tools/.gitignore b/tools/.gitignore
> index 13825a3..f777f2b 100644
> --- a/tools/.gitignore
> +++ b/tools/.gitignore
> @@ -30,5 +30,6 @@ intel_reg_checker
>  intel_residency
>  intel_stepping
>  intel_watermark
> +intel_gvtg_test
>  skl_compute_wrpll
>  skl_ddb_allocation


Sort alphabetically.


> diff --git a/tools/Makefile.sources b/tools/Makefile.sources
> index e2451ea..5f1e747 100644
> --- a/tools/Makefile.sources
> +++ b/tools/Makefile.sources
> @@ -30,6 +30,7 @@ tools_prog_lists =  \
>   intel_stepping  \
>   intel_watermark \
>   intel_gem_info  \
> + intel_gvtg_test \
>   $(NULL)
>  
>  dist_bin_SCRIPTS = intel_gpu_abrt
> diff --git a/tools/intel_gvtg_test.c b/tools/intel_gvtg_test.c
> new file mode 100644
> index 000..ec6dd99
> --- /dev/null
> +++ b/tools/intel_gvtg_test.c
> @@ -0,0 +1,359 @@
> +/*
> + * Copyright 2016 Intel Corporation
> + *   Terrence Xu 
> + *


This should be


 * Copyright © 2016-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 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.
> + */
> +
> +/*
> + * This program is intended for testing of validate GVT-g virtual machine
> + * creation of allow for testing of KVMGT / XenGT (the tool should be root
> + * privilege only).
> + *
> + * TODO:
> + * Enable more GVT-g related test cases.
> + */
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include "igt.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define RANDOM(x) (rand() % x)
> +
> +
> +static char uuid[40];
> +static char guest_ip[32];
> +
> +static char mac_addr[20] = {0};
> +static char qemu_path[PATH_MAX] = {0};
> +static char hda_path[PATH_MAX] = {0};
> +static char bios_path[PATH_MAX] = {0};
> +
> +static int super_system(const char *cmd, char *retmsg, int msg_len)
> +{
> +FILE *fp;
> +int res = -1;
> +if (cmd == NULL || retmsg == NULL || msg_len < 0) {
> +igt_info("Error: %s system parameter invalid!\n", __func__);
> +return 1;
> +}
> +fp = popen(cmd, "r");
> +if (fp == NULL) {
> +perror("popen");
> +igt_info("Error: %s popen error: %s\n", __func__, strerror(errno));
> +return 2;
> +} else {
> +memset(retmsg, 0, msg_len);
> +while (fgets(retmsg, msg_len, fp)) {
> +;
> +}
> +res = pclose(fp);
> +if (res == -1) {
> +igt_info("Error:%s close popen file pointer fp error!\n", 
> __func__);
> +return 3;
> +}
> +retmsg[strlen(retmsg) - 1] = '\0';
> +return 0;
> +}
> +}
> +
>